[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B7060@saturn3.aculab.com>
Date: Wed, 24 Oct 2012 10:06:36 +0100
From: "David Laight" <David.Laight@...LAB.COM>
To: "Ming Lei" <ming.lei@...onical.com>,
"Alan Stern" <stern@...land.harvard.edu>
Cc: <linux-kernel@...r.kernel.org>, "Oliver Neukum" <oneukum@...e.de>,
"Minchan Kim" <minchan@...nel.org>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rjw@...k.pl>, "Jens Axboe" <axboe@...nel.dk>,
"David S. Miller" <davem@...emloft.net>,
"Andrew Morton" <akpm@...ux-foundation.org>,
<netdev@...r.kernel.org>, <linux-usb@...r.kernel.org>,
<linux-pm@...r.kernel.org>, <linux-mm@...ck.org>
Subject: RE: [RFC PATCH v2 2/6] PM / Runtime: introduce pm_runtime_set_memalloc_noio()
> Looks the problem is worse than above, not only bitfields are affected, the
> adjacent fields might be involved too, see:
>
> http://lwn.net/Articles/478657/
Not mentioned in there is that even with x86/amd64 given
a struct with the following adjacent fields:
char a;
char b;
char c;
then foo->b |= 0x80; might do a 32bit RMW cycle.
This will (well might - but probably does) happen
if compiled to a 'BTS' instruction.
The x86 instruction set docs are actually unclear
as to whether the 32bit cycle might even be misaligned!
amd64 might do a 64bit cycle (not checked the docs).
David
--
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