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] [day] [month] [year] [list]
Message-ID: <20200220143229.00002d4d@intel.com>
Date:   Thu, 20 Feb 2020 14:32:29 -0800
From:   Jesse Brandeburg <jesse.brandeburg@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     <tglx@...utronix.de>, <mingo@...hat.com>, <bp@...en8.de>,
        <x86@...nel.org>, <linux-kernel@...r.kernel.org>,
        <linux@...musvillemoes.dk>, <andriy.shevchenko@...el.com>,
        <dan.j.williams@...el.com>
Subject: Re: [PATCH v2 1/2] x86: fix bitops.h warning with a moved cast

On Thu, 20 Feb 2020 19:12:36 +0100 Peter wrote:
> On Thu, Feb 20, 2020 at 09:37:21AM -0800, Jesse Brandeburg wrote:
> > @@ -72,9 +74,11 @@ static __always_inline void
> >  arch_clear_bit(long nr, volatile unsigned long *addr)
> >  {
> >  	if (__builtin_constant_p(nr)) {
> > +		u8 cmaski = ~CONST_MASK(nr);
> > +
> >  		asm volatile(LOCK_PREFIX "andb %1,%0"
> >  			: CONST_MASK_ADDR(nr, addr)
> > -			: "iq" ((u8)~CONST_MASK(nr)));
> > +			: "iq" (cmaski));
> 
> Urgh, that's sad. So why doesn't this still generate a warning, ~ should
> promote your u8 to int, and then you down-cast to u8 on assignment
> again.

My suspicion is that using the right size types on the lvalue causes
the compiler (and sparse) to know that the type and number of bits in
the "iq" statement is unambiguous.

> 
> So now you have more lines, more ugly casts and exactly the same
> generated code; where the win?

The win as I see it is that sparse (C=1) doesn't warn, but you're right,
it wasn't my first choice to do it the way I ended up with (see below) 

> Perhaps you should write it like:
> 
> 		: "iq" (0xFF ^ CONST_MASK(nr))
> 
> hmm?

Thanks! That works, for my tests at least. FWIW, at one point during
review I got some feedback from a build bot (zero day tester) that
certain compilers like gcc 7.5.0 interpret ~CONST_MASK(nr) into needing
32 bits. So I solved that issue by using correctly typed (and width)
local variables, but I didn't try the 0xff^ way at that time.

I'll change back to the simpler version of the changes (without locals)
and with your 0xff^ change, we'll see if anything comes up from build
bots.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ