linux-kernel - Re: [PATCH] staging: wilc1000: use kernel define byte order 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]

Message-ID: <1490132410.17318.6.camel@gmail.com>
Date:   Tue, 21 Mar 2017 15:40:10 -0600
From:   Robert Perry Hooker <perry.hooker@...il.com>
To:     Dan Carpenter <dan.carpenter@...cle.com>
Cc:     gregkh@...uxfoundation.org, devel@...verdev.osuosl.org,
        aditya.shankar@...rochip.com, linux-kernel@...r.kernel.org,
        ganesh.krishna@...rochip.com
Subject: Re: [PATCH] staging: wilc1000: use kernel define byte order macros

Thanks for taking a look, Dan. Sorry if I missed the mark here.

Can you tell me a bit more about the bug this would introduce?

I see that ieee80211_is_action is defined like this: static inline bool ieee80211_is_action(__le16 fc)

...and that buff[FRAME_TYPE_ID]is a u8 (since FRAME_TYPE_ID = 0).

Is there an issue with calling cpu_to_le16 on a u8 that isn't encountered by implicitly casting a u8 to __le16? Or am I
missing something else?

Regards,
Perry

On Tue, 2017-03-21 at 23:19 +0300, Dan Carpenter wrote:
> On Tue, Mar 21, 2017 at 01:55:40PM -0600, Perry Hooker wrote:
> > This commit fixes the following sparse warnings:
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:1473:45: warning: incorrect type in argument 1 (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2006:51: warning: incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2011:52: warning: incorrect type in assignment (different base > > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2012:51: warning: incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2078:51: warning: incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2083:52: warning: incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2084:51: warning: incorrect type in assignment (different base 
> > types)
> > 
> > Signed-off-by: Perry Hooker <perry.hooker@...il.com>
> > ---
> >  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 20 +++++++++++++-------
> >  1 file changed, 13 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > index a37896f..d1c75c7 100644
> > --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > @@ -1470,7 +1470,7 @@ void WILC_WFI_p2p_rx(struct net_device *dev, u8 *buff, u32 size)
> >     } else {
> >             s32Freq = ieee80211_channel_to_frequency(curr_channel, NL80211_BAND_2GHZ);
> >  
> > -           if (ieee80211_is_action(buff[FRAME_TYPE_ID])) {
> > +           if (ieee80211_is_action(cpu_to_le16(buff[FRAME_TYPE_ID]))) {
> 
> Nah...  You're just introducing bugs here.  Please be more careful.
> 
> regards,
> dan carpenter
>