From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] container_of: Document container_of() is not to be used in new code
Date: Wed, 21 May 2025 15:43:06 +0200 [thread overview]
Message-ID: <2025052118-unneeded-viscosity-8790@gregkh> (raw)
In-Reply-To: <2025052121-drastic-hacker-aab6@gregkh>
On Wed, May 21, 2025 at 03:31:36PM +0200, Greg Kroah-Hartman wrote:
> On Wed, May 21, 2025 at 03:27:19PM +0200, Greg Kroah-Hartman wrote:
> > On Tue, May 20, 2025 at 10:09:18PM +0000, Sakari Ailus wrote:
> > > Hi Greg,
> > >
> > > On Tue, May 20, 2025 at 04:30:19PM +0200, Greg Kroah-Hartman wrote:
> > > > On Tue, May 20, 2025 at 05:16:45PM +0300, Andy Shevchenko wrote:
> > > > > On Tue, May 20, 2025 at 01:34:37PM +0300, Sakari Ailus wrote:
> > > > > > There is a warning in the kerneldoc documentation of container_of() that
> > > > > > constness of its ptr argument is lost. While this is a faible suggestion
> > > > > > container_of_const() should be used instead, the vast majority of new code
> > > > > > still uses container_of():
> > > > > >
> > > > > > $ git diff v6.13 v6.14|grep container_of\(|wc -l
> > > > > > 646
> > > > > > $ git diff v6.13 v6.14|grep container_of_const|wc -l
> > > > > > 9
> > > > > >
> > > > > > Make an explicit recommendation to use container_of_const().
> > > > > >
> > > > > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > > > ---
> > > > > > Hi Greg, Andy,
> > > > > >
> > > > > > I guess we generally agree the additional constness check in
> > > > > > container_of_const() is useful, but adding the same check to
> > > > > > container_of() generates warnings -- there are some errors, too -- such as
> > > > > > this one currently:
> > > > > >
> > > > > > In file included from /home/sailus/src/linux/include/linux/bcma/bcma.h:14,
> > > > > > from /home/sailus/src/linux/arch/x86/kernel/early-quirks.c:17:
> > > > > > /home/sailus/src/linux/include/linux/ssb/ssb.h: In function ‘dev_to_ssb_dev’:
> > > > > > /home/sailus/src/linux/include/linux/ssb/ssb.h:291:14: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
> > > > > > 291 | wrap = container_of(dev, struct __ssb_dev_wrapper, dev);
> > > > > > | ^
> > > > > >
> > > > > > As noted above, 646 new missing constness checks were introduced through
> > > > > > container_of() macro use during the 6.14 cycle alone. Most of these are
> > > > > > likely harmless, but with so many new users some are bound to be ignoring
> > > > > > constness.
> > > > > >
> > > > > > Once the warnings from bad container_of() use are worked out in a way or
> > > > > > another, the constness check could be added to the container_of() macro
> > > > > > and the current container_of_const() be dropped altogether.
> > > > > >
> > > > > > If this patch is accepted, I'll see how to add a warning on container_of()
> > > > > > to checkpatch.pl.
> > > > >
> > > > > Hmm... Wouldn't be better to fix non-const cases and add the const check, etc
> > > > > to the container_of() instead of doing these comments?
> > > >
> > > > Yes, fixing up the existing places where it is broken would be best, how
> > > > many of them are there now?
> > >
> > > Adding constness check for container_of(), with my partial build on x86-64
> > > I'm getting 893 such warnings. A fair number are probably duplicates or
> > > repeat of the same pattern, but also the compilation didn't succeed --
> > > there were multiple compilation failures.
> >
> > So who is going to do that work? I just did it for drivers/usb and it
> > was pretty trivial, just declaring "do not use this!" feels like the
> > easy way out, absolving yourself from any responsibility here :)
>
> I tried it for the whole tree, and ugh, there are some real "errors" in
> there. The nfs inode handling logic is crazy, passing in a const
> pointer and then setting fields in it. So this will be some real work
> to unwind and fix in some places.
Oh, and here's the patch I used to test this out if anyone else wants to
attempt it. I've sent out fixes for drivers/usb/ already, let me see
about a few other small subsystems...
diff --git a/include/linux/container_of.h b/include/linux/container_of.h
index 713890c867be..2f62729e49d8 100644
--- a/include/linux/container_of.h
+++ b/include/linux/container_of.h
@@ -15,7 +15,7 @@
*
* WARNING: any const qualifier of @ptr is lost.
*/
-#define container_of(ptr, type, member) ({ \
+#define __container_of(ptr, type, member) ({ \
void *__mptr = (void *)(ptr); \
static_assert(__same_type(*(ptr), ((type *)0)->member) || \
__same_type(*(ptr), void), \
@@ -31,8 +31,11 @@
*/
#define container_of_const(ptr, type, member) \
_Generic(ptr, \
- const typeof(*(ptr)) *: ((const type *)container_of(ptr, type, member)),\
- default: ((type *)container_of(ptr, type, member)) \
+ const typeof(*(ptr)) *: ((const type *)__container_of(ptr, type, member)),\
+ default: ((type *)__container_of(ptr, type, member)) \
)
+#define container_of(ptr, type, member) container_of_const(ptr, type, member)
+
+
#endif /* _LINUX_CONTAINER_OF_H */
next prev parent reply other threads:[~2025-05-21 13:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-20 10:34 [PATCH 1/1] container_of: Document container_of() is not to be used in new code Sakari Ailus
2025-05-20 14:16 ` Andy Shevchenko
2025-05-20 14:30 ` Greg Kroah-Hartman
2025-05-20 22:09 ` Sakari Ailus
2025-05-21 13:27 ` Greg Kroah-Hartman
2025-05-21 13:31 ` Greg Kroah-Hartman
2025-05-21 13:43 ` Greg Kroah-Hartman [this message]
2025-05-22 13:47 ` Greg Kroah-Hartman
2025-05-22 21:01 ` David Laight
2025-05-23 8:36 ` Greg Kroah-Hartman
2025-05-24 12:45 ` David Laight
2025-05-24 15:06 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025052118-unneeded-viscosity-8790@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sakari.ailus@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox