linux-kernel - Re: [PATCH/RFC] m68k/bitops: Make bitmap data pointer of atomic ops volatile

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]

Date:	Tue, 7 Jun 2011 15:56:58 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	linux-m68k@...ts.linux-m68k.org,
	Akinobu Mita <akinobu.mita@...il.com>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH/RFC] m68k/bitops: Make bitmap data pointer of atomic ops volatile

On Tuesday 07 June 2011, Ben Hutchings wrote:
> On Tue, Jun 07, 2011 at 01:22:29PM +0200, Arnd Bergmann wrote:

> > I guess what happened is that some variables are traditionally marked
> > as volatile although they shouldn't be, and most architectures have
> > adapted their bitops to make the warnings go away. If you see more
> > warnings of that kind, it's probably fine to just do the same on m68k.
> > The volatile modifier doesn't really hurt in this case.
>  
> These operations are required to be atomic and therefore they
> must be suitable for use with volatile-qualified variables.

As I said, it's not wrong for them to have a volatile qualifier in the
argument list. However, there should also not be the need for the
qualifier in any of the callers, because the bitops only work if
all accesses to the data are done through bitops functions, and that
means that the qualifier on the variable is completely meaningless.

	Arnd
--
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/