linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Andy Shevchenko' <andriy.shevchenko@linux.intel.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>
Subject: RE: [PATCH 1/1] linux/container_of.h: Warn about loss of constness
Date: Mon, 24 Oct 2022 09:34:42 +0000	[thread overview]
Message-ID: <fbe735d131a44c2a95248cc4ad51485b@AcuMS.aculab.com> (raw)
In-Reply-To: <Y1ZZcL/Q7QJ+YYhJ@smile.fi.intel.com>

From: Andy Shevchenko
> Sent: 24 October 2022 10:23
...
> > > Wait, no one uses this macro, so why not just remove it entirely?
> >
> > Good question. It appears to be a (relatively) common pattern to look up
> > something and the return its containing object if the lookup was
> > successful. Doing a quick
> >
> > 	$ git grep 'container_of.*:' drivers include
> >
> > reveals more than 20 instances of the pattern. There are probably more
> > those that use if for testing for NULL. I guess people don't know about
> > this macro, apart from the developers of the staging driver it was added
> > for (commit 05e6557b8ed833546ee2b66ce6b58fecf09f439e).
> 
> Maybe we can provide an example to keep this macro in the kernel, meaning
> convert one of the drivers / subsystem to actually use it?

Adding _safe() to a function name doesn't actually tell you anything.
You still need to look up what it is 'safe' against.

In this case the full code pattern is actually much clearer.

It is also quite likely that it is followed by an:
	if (!ptr)
		return xxx;
You that can/should really be put before the container_of() call.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  reply	other threads:[~2022-10-24  9:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-24  8:26 [PATCH 1/1] linux/container_of.h: Warn about loss of constness Sakari Ailus
2022-10-24  8:43 ` Greg Kroah-Hartman
2022-10-24  8:45   ` Greg Kroah-Hartman
2022-10-24  9:00     ` Andy Shevchenko
2022-10-24 17:39       ` Kees Cook
2022-10-24 17:51         ` Rafael J. Wysocki
2022-10-24 21:24           ` David Laight
2022-10-25  7:47           ` Greg Kroah-Hartman
2022-10-24  9:11     ` Sakari Ailus
2022-10-24  9:22       ` Andy Shevchenko
2022-10-24  9:34         ` David Laight [this message]
2022-10-24  9:37           ` 'Andy Shevchenko'
2022-10-24  9:46             ` David Laight
2022-10-24 10:01               ` Greg Kroah-Hartman
2022-10-24 10:05                 ` David Laight
2022-10-24  9:48       ` Greg Kroah-Hartman
2022-10-24 10:07         ` Sakari Ailus
2022-10-24  8:59   ` David Laight
2022-10-24 10:11     ` Sakari Ailus

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=fbe735d131a44c2a95248cc4ad51485b@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@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;
as well as URLs for NNTP newsgroup(s).