linux-kernel - Re: [PATCH v2] driver core: allow kobj_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y00Mfgymi+Xv6El3@kroah.com>
Date:   Mon, 17 Oct 2022 10:04:14 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH v2] driver core: allow kobj_to_dev() to take a const
 pointer

On Mon, Oct 17, 2022 at 07:54:52AM +0000, Sakari Ailus wrote:
> Hi Greg,
> 
> On Sun, Oct 16, 2022 at 12:41:26PM +0200, Greg Kroah-Hartman wrote:
> > If a const * to a kobject is passed to kobj_to_dev(), we want to return
> > back a const * to a device as the driver core shouldn't be modifying a
> > constant structure.  But when dealing with container_of() the pointer
> > const attribute is cast away, so we need to manually handle this by
> > determining the type of the pointer passed in to know the type of the
> > pointer to pass out.
> 
> Alternatively container_of() could be fixed, but that will likely produce
> lots of warnings currently.

Yeah, we can not do that because, as you found out, there's just too
many warnings that it would cause.  Let's work on the individual
subsystems to clean them all up first before worrying about the core
container_of() macro as that should fix the majority of the build
warnings.

> > Luckily _Generic can do this type of magic, and as the kernel now
> > supports C11 it is availble to us to handle this type of build-time type
> > detection.
> > 
> > Cc: Sakari Ailus <sakari.ailus@...ux.intel.com>
> > Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> > Cc: "Rafael J. Wysocki" <rafael@...nel.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > ---
> > v2 - use _Generic() to make this type safe as pointed out by Sakari
> > 
> >  include/linux/device.h | 18 +++++++++++++++++-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 424b55df0272..023ea50b1916 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -680,11 +680,27 @@ struct device_link {
> >  	bool supplier_preactivated; /* Owned by consumer probe. */
> >  };
> >  
> > -static inline struct device *kobj_to_dev(struct kobject *kobj)
> > +static inline struct device *__kobj_to_dev(struct kobject *kobj)
> >  {
> >  	return container_of(kobj, struct device, kobj);
> >  }
> >  
> > +static inline const struct device *__kobj_to_dev_const(const struct kobject *kobj)
> > +{
> > +	return container_of(kobj, const struct device, kobj);
> > +}
> > +
> > +/*
> > + * container_of() will happily take a const * and spit back a non-const * as it
> > + * is just doing pointer math.  But we want to be a bit more careful in the
> > + * driver code, so manually force any const * of a kobject to also be a const *
> > + * to a device.
> > + */
> 
> container_of() documentation has (probably?) never warned about this.

We never thought of it before :(

> Wouldn't such a comment be more appropriate there? Albeit it wouldn't be
> needed if container_of() were fixed.

Some comment added to container_of() would be great, but that does not
remove the need to keep this one.

thanks,

greg k-h