linux-kernel - Re: [PATCH v2] staging: greybus: use inline function for macros

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 21 Mar 2023 22:29:25 +0100 (CET)
From:   Julia Lawall <julia.lawall@...ia.fr>
To:     Alex Elder <elder@...e.org>
cc:     Menna Mahmoud <eng.mennamahmoud.mm@...il.com>,
        gregkh@...uxfoundation.org, outreachy@...ts.linux.dev,
        johan@...nel.org, elder@...nel.org, linux-kernel@...r.kernel.org,
        linux-staging@...ts.linux.dev
Subject: Re: [PATCH v2] staging: greybus: use inline function for macros



On Tue, 21 Mar 2023, Alex Elder wrote:

> On 3/21/23 3:43 PM, Julia Lawall wrote:
> >
> >
> > On Tue, 21 Mar 2023, Alex Elder wrote:
> >
> > > On 3/21/23 1:34 PM, Menna Mahmoud wrote:
> > > > Convert `to_gbphy_dev` and `to_gbphy_driver` macros into a
> > > > static inline function.
> > > >
> > > > It is not great to have macros that use the `container_of` macro,
> > > > because from looking at the definition one cannot tell what type
> > > > it applies to.
> > > >
> > > > One can get the same benefit from an efficiency point of view
> > > > by making an inline function.
> > > >
> > > > Suggested-by: Julia Lawall <julia.lawall@...ia.fr>
> > > > Signed-off-by: Menna Mahmoud <eng.mennamahmoud.mm@...il.com>
> > >
> > > I'm sorry if this conflicts with what others have said.
> > >
> > > But the use of a macro (with a container_of() right-hand
> > > side) to get at the structure containing a field pointer
> > > is a widely-used idiom throughout the kernel.
> > >
> > > What you propose achieves the same result but I would
> > > lean toward keeping it as a macro, mainly because it
> > > is so common.
> >
> > Common is not necessarily good.  Macros are less safe and less
> > informative.
>
> I do agree that the inline function is better, and
> is functionally equivalent (while being explicit
> with types and avoiding any macro expansion funny
> business).
>
> Do you think we should make changes like this throughout
> the kernel (along the lines of the flexible array fixes,
> to make things safer)?  I don't think it's a terrible idea,
> but it's likely a big undertaking and I predict push-back.

I agree that it's not a terrible idea and that it's a big undertaking.
The code would be a little safer if people had the habit of making
functions, as it avoids the risk of parameterizing over the field name in
the third argument.  But the impact is probably lesser than for the
flexible array fixes.  But if we have the chance to clean up the staging
code, at least, then why not.

There do seem to be more than 100 definitions like:

#define to_dove_clk(hw) container_of(hw, struct dove_clk, hw)

where we have to hope that at all of the usage sites the argument is
called hw.  Probably anything else would cause a compiler error, but still
it looks strange.

julia

>
> Bottom line on this is that I don't think the proposed
> change is wrong, but there is value in consistently
> adhering to conventions.
>
> Others can comment; I have no real objection.
>
> 					-Alex
>
> >
> > julia
> >
> >
> > >
> > > 					-Alex
> > > > ---
> > > > changes in v2:
> > > > 	-send patch as a single patch.
> > > > 	-edit the name of struct object.
> > > > 	-edit commit message.
> > > > ---
> > > >    drivers/staging/greybus/gbphy.h | 10 ++++++++--
> > > >    1 file changed, 8 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/greybus/gbphy.h
> > > > b/drivers/staging/greybus/gbphy.h
> > > > index d4a225b76338..e7ba232bada1 100644
> > > > --- a/drivers/staging/greybus/gbphy.h
> > > > +++ b/drivers/staging/greybus/gbphy.h
> > > > @@ -15,7 +15,10 @@ struct gbphy_device {
> > > >    	struct list_head list;
> > > >    	struct device dev;
> > > >    };
> > > > -#define to_gbphy_dev(d) container_of(d, struct gbphy_device, dev)
> > > > +static inline struct gbphy_device *to_gbphy_dev(const struct device
> > > > *_dev)
> > > > +{
> > > > +	return container_of(_dev, struct gbphy_device, dev);
> > > > +}
> > > >      static inline void *gb_gbphy_get_data(struct gbphy_device *gdev)
> > > >    {
> > > > @@ -43,7 +46,10 @@ struct gbphy_driver {
> > > >      	struct device_driver driver;
> > > >    };
> > > > -#define to_gbphy_driver(d) container_of(d, struct gbphy_driver, driver)
> > > > +static inline struct gbphy_driver *to_gbphy_driver(struct device_driver
> > > > *drv)
> > > > +{
> > > > +	return container_of(drv, struct gbphy_driver, driver);
> > > > +}
> > > >      int gb_gbphy_register_driver(struct gbphy_driver *driver,
> > > >    			     struct module *owner, const char
> > > > *mod_name);
> > >
> > >
>
>