linux-kernel - Re: [PATCH] staging: wfx: add gcc extension _

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:   Mon, 11 Nov 2019 13:51:33 +0000 (GMT)
From:   Jules Irenge <jbi.octave@...il.com>
To:     Al Viro <viro@...iv.linux.org.uk>
cc:     Jules Irenge <jbi.octave@...il.com>, gregkh@...uxfoundation.org,
        jerome.pouiller@...abs.com, linux-kernel@...r.kernel.org,
        devel@...verdev.osuosl.org, Boqun.Feng@...rosoft.com
Subject: Re: [PATCH] staging: wfx: add gcc extension __force cast



On Sat, 9 Nov 2019, Al Viro wrote:

> On Fri, Nov 08, 2019 at 11:38:37PM +0000, Jules Irenge wrote:
> > Add gcc extension __force and __le32 cast to fix warning issued by Sparse tool."warning: cast to restricted __le32"
> >
> > Signed-off-by: Jules Irenge <jbi.octave@...il.com>
> > ---
> >  drivers/staging/wfx/debug.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/wfx/debug.c b/drivers/staging/wfx/debug.c
> > index 0a9ca109039c..aa7b2dd691b9 100644
> > --- a/drivers/staging/wfx/debug.c
> > +++ b/drivers/staging/wfx/debug.c
> > @@ -72,7 +72,7 @@ static int wfx_counters_show(struct seq_file *seq, void *v)
> >  		return -EIO;
> >  
> >  #define PUT_COUNTER(name) \
> > -	seq_printf(seq, "%24s %d\n", #name ":", le32_to_cpu(counters.count_##name))
> > +	seq_printf(seq, "%24s %d\n", #name ":", le32_to_cpu((__force __le32)(counters.count_##name)))
> 
> NAK.  force-cast (and it's not a gcc extension, BTW - it's sparse) is basically
> "I know better; the code is right, so STFU already".  *IF* counters.count_...
> is really little-endian 32bit, then why isn't it declared that way?  And if
> it's host-endian, you've just papered over a real bug here.
> 
> As a general rule "fix" doesn't mean "tell it to shut up"...
> 

Thanks for the comments, I have updated  but I have a mixed mind on the 
__le32. I have to read more about it. 

I would appreciate if you can comment again on the update.