From: Michael Matz <matz@suse.de>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Colin Walters <walters@verbum.org>, Jan Kara <jack@suse.cz>,
LKML <linux-kernel@vger.kernel.org>,
linux-ia64@vger.kernel.org, dsterba@suse.cz, ptesarik@suse.cz,
rguenther@suse.de, gcc@gcc.gnu.org
Subject: Re: Memory corruption due to word sharing
Date: Wed, 1 Feb 2012 18:41:05 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.4.64.1202011818570.25409@wotan.suse.de> (raw)
In-Reply-To: <alpine.LRH.2.00.1202011808240.22725@twin.jikos.cz>
Hi,
On Wed, 1 Feb 2012, Jiri Kosina wrote:
> # cat x.c
> struct x {
> long a;
> volatile unsigned int lock;
> unsigned int full:1;
> };
>
> void
> wrong(struct x *ptr)
> {
> ptr->full = 1;
> }
>
> In my opinion, this is a clear bug
Even that depends (sadly) on who you ask. half-volatile objects (i.e.
struct where some members are volatile and others aren't) are terribly
underspecified. You can make the bitfield volatile, and for ia64 that
would at least result of ld8.acq/st8.rel pairs.
And Linus: don't be so hastily dismissive. People (even the compiler
ones) do agree that using an 8 byte access for a 4 byte entity is
problematic. Even if allowed by the standard it's a quality of
implementation problem.
One problem is that it's not a new problem, GCC emitted similar code since
about forever, and still they turned up only now (well, probably because
ia64 is dead, but sparc64 should have similar problems). The bitfield
handling code is _terribly_ complex and fixing it is quite involved. So
don't expect any quick fixes.
The other problem is specification. While you think that the code you
wrote is totally obvious it might not actually be so. For instance, what
about this struct:
{long l:32; int i1:16; short s; int i2:1; char c:7; short s2:8; short s3;}
What are the obviously correct accesses for various writes into this
struct?
One rule may be to never write to a bitfield with accesses larger than
their underlying declared type. Well, but only if the bitfield fits into
that type (int:96 is quite okay to have, and what accesses should be
allowed there?). That might be one obvious rule. But it's not how
traditional bitfield layout works. It works based on underlying objects,
and for that e.g. the three fields i2,c,s are all in the same one, of int
type.
The rule above would at least work for code that most people do write,
i.e. sequence of same-typed bitfields mixed with normal members.
And then, there's the last problem: are you sure that if GCC would use 4
byte accesses for the case at hand, that the hardware wouldn't screw you
again? What about using atomic instructions for one half of the
cache-line (the spinlock) but non-atomic instructions on the other half
(the bitfield). Are you sure the latter won't interfere with the former?
Ciao,
Michael.
next prev parent reply other threads:[~2012-02-01 17:41 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-01 15:19 Memory corruption due to word sharing Jan Kara
2012-02-01 15:34 ` Markus Trippelsdorf
2012-02-01 16:37 ` Colin Walters
2012-02-01 16:56 ` Linus Torvalds
2012-02-01 17:11 ` Jiri Kosina
2012-02-01 17:37 ` Linus Torvalds
2012-02-01 17:41 ` Michael Matz [this message]
2012-02-01 18:09 ` David Miller
2012-02-01 18:45 ` Jeff Law
2012-02-01 19:09 ` Linus Torvalds
2012-02-02 15:51 ` Jeff Garzik
2012-02-01 18:57 ` Linus Torvalds
2012-02-01 19:04 ` Peter Bergner
2012-02-01 18:52 ` Linus Torvalds
2012-02-02 9:35 ` Richard Guenther
2012-02-02 9:37 ` Richard Guenther
2012-02-02 13:43 ` Michael Matz
2012-02-01 16:41 ` Linus Torvalds
2012-02-01 17:42 ` Torvald Riegel
2012-02-01 19:40 ` Jakub Jelinek
2012-02-01 20:01 ` Linus Torvalds
2012-02-01 20:16 ` Jakub Jelinek
2012-02-01 20:44 ` Linus Torvalds
2012-02-02 15:58 ` Aldy Hernandez
2012-02-02 16:28 ` Michael Matz
2012-02-02 17:51 ` Linus Torvalds
2012-02-01 20:19 ` Linus Torvalds
2012-02-02 9:46 ` Richard Guenther
2012-02-01 19:44 ` Boehm, Hans
2012-02-01 19:54 ` Jeff Law
2012-02-01 19:47 ` Linus Torvalds
2012-02-01 19:58 ` Alan Cox
2012-02-01 20:41 ` Torvald Riegel
2012-02-01 20:59 ` Linus Torvalds
2012-02-01 21:24 ` Torvald Riegel
2012-02-01 21:55 ` Linus Torvalds
2012-02-01 21:25 ` Boehm, Hans
2012-02-01 22:27 ` Linus Torvalds
2012-02-01 22:45 ` Paul E. McKenney
2012-02-01 23:11 ` Linus Torvalds
2012-02-02 18:42 ` Paul E. McKenney
2012-02-02 19:08 ` Linus Torvalds
2012-02-02 19:37 ` Paul E. McKenney
2012-02-03 16:38 ` Andrew MacLeod
2012-02-03 17:16 ` Linus Torvalds
2012-02-03 19:16 ` Andrew MacLeod
2012-02-03 20:00 ` Linus Torvalds
2012-02-03 20:19 ` Paul E. McKenney
2012-02-06 15:38 ` Torvald Riegel
2012-02-10 19:27 ` Richard Henderson
2012-02-02 11:19 ` Ingo Molnar
2012-02-01 21:04 ` Boehm, Hans
2012-02-02 9:28 ` Bernd Petrovitsch
2012-02-01 17:08 ` Torvald Riegel
2012-02-01 17:29 ` Linus Torvalds
2012-02-01 20:53 ` Torvald Riegel
2012-02-01 21:20 ` Linus Torvalds
2012-02-01 21:37 ` Torvald Riegel
2012-02-01 22:18 ` Boehm, Hans
2012-02-02 11:11 ` James Courtier-Dutton
2012-02-02 11:24 ` Richard Guenther
2012-02-02 11:13 ` David Sterba
2012-02-02 11:23 ` Richard Guenther
2012-02-03 6:45 ` DJ Delorie
2012-02-03 9:37 ` Richard Guenther
2012-02-03 10:03 ` Matthew Gretton-Dann
2012-02-01 17:52 Dennis Clarke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1202011818570.25409@wotan.suse.de \
--to=matz@suse.de \
--cc=dsterba@suse.cz \
--cc=gcc@gcc.gnu.org \
--cc=jack@suse.cz \
--cc=jkosina@suse.cz \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ptesarik@suse.cz \
--cc=rguenther@suse.de \
--cc=torvalds@linux-foundation.org \
--cc=walters@verbum.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).