lkml.org 
[lkml]   [2020]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] bitfield.h: annotate type_replace_bits functions with __must_check
On 16-09-20, 16:33, Srinivas Kandagatla wrote:
>
>
> On 16/09/2020 16:20, Greg KH wrote:
> > On Wed, Sep 16, 2020 at 04:03:33PM +0100, Srinivas Kandagatla wrote:
> > > usage of apis like u32_replace_bits() without actually catching the return
> > > value could hide problems without any warning!
> > >
> > > Found this with recent usage of this api in SoundWire!
> > > Having __must_check annotation would really catch this issues in future!
> > >
> > > Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> > > ---
> > > include/linux/bitfield.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> > > index 4e035aca6f7e..eb4f69253946 100644
> > > --- a/include/linux/bitfield.h
> > > +++ b/include/linux/bitfield.h
> > > @@ -131,7 +131,7 @@ static __always_inline __##type type##_encode_bits(base v, base field) \
> > > __field_overflow(); \
> > > return to((v & field_mask(field)) * field_multiplier(field)); \
> > > } \
> > > -static __always_inline __##type type##_replace_bits(__##type old, \
> > > +static __always_inline __must_check __##type type##_replace_bits(__##type old, \
> > > base val, base field) \
> > > { \
> > > return (old & ~to(field)) | type##_encode_bits(val, field); \
> > > --
> > > 2.21.0
> > >
> >
> > Don't add __must_check to things that if merged will instantly cause
> > build warnings to the system, that's just rude :(
> Currently there are not many users for this api, found only one instance in
> drivers/net/ipa/ipa_table.c which is also fixed with
> https://lkml.org/lkml/2020/9/10/1062
>
> >
> > Fix up everything first, and then try to make this type of change.
> >
> > But why does this function have to be checked?
> As this function would return updated value, this check is more to with
> using the return value!
>
> It is easy for someone to ignore this return value assuming that the new
> value is already updated! So this check should help!
>
> TBH, This is what happened when we(vkoul and me) tried use this api :-)

So the only user of this has been moved to *p_replace_bits(), looking
back I think we should remove *_replace_bits (no users atm) and
duplicate of *p_replace_bits(). If not adding this patch would be
sensible thing to do

Somehow I feel former is a better idea ;-)

Thanks
--
~Vinod

\
 
 \ /
  Last update: 2020-09-17 06:11    [W:0.097 / U:0.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site