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:	Sun, 23 Oct 2011 23:19:21 +0200
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Josh Stone <jistone@...hat.com>
Cc:	linux-kernel@...r.kernel.org,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Jakub Jelinek <jakub@...hat.com>
Subject: Re: [PATCH] x86: Fix compilation bug in kprobes' twobyte_is_boostable

On Sun, Oct 23, 2011 at 7:07 PM, Josh Stone <jistone@...hat.com> wrote:
>
> Unfortunately, no.  Whatever const-propagation gcc is doing here
> (somewhat wrongly per PR50571) is not affected by volatile on that cast.
>  I also tried leaving it to the parameter type (no cast), no help.

Oh, ok.

> I just tried removing the const from twobyte_is_boostable[], and that
> also does the trick.  Not sure why I didn't try that first -- I guess
> because I saw all the volatiles in bitops.  Is that more palatable, or
> would you still rather try to fix it in bitops.h directly?

I guess there's no nice bitops.h fix, so maybe the minimal "remove
const" is the right thing to do.

>>  - Long long ago, we had that "big array" approach for ADDR too. So
>> we've wavered between the volatile and using a block memory op. But
>> we've used the "volatile" for a long time now for the bit change ones,
>> so I don't think we should mix concepts like your patch.
>
> Do you recall why it settled on volatile?  That seems like the less
> descriptive of the two approaches.  But "long long ago" appears to be
> beyond recorded (git) history...

Yeah, it's really long ago. Iirc the reason it got removed was that
there were gcc versions that were unhappy about it, we've had problems
in this area before..

             Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ