From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-arch@vger.kernel.org, Davidlohr Bueso <dave@stgolabs.net>,
dvyukov@google.com, peterz@infradead.org,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH RFC] locking: Add volatile to arch_spinlock_t structures
Date: Wed, 3 Dec 2014 23:02:48 -0800 [thread overview]
Message-ID: <20141204070248.GJ25340@linux.vnet.ibm.com> (raw)
In-Reply-To: <CA+55aFxGCxQNE4HzRP_Uk2FmFDn_+Hfm6GBz75S+5+SDeODVJQ@mail.gmail.com>
On Wed, Dec 03, 2014 at 10:40:45PM -0800, Linus Torvalds wrote:
> On Dec 3, 2014 10:31 PM, "Linus Torvalds" <torvalds@linux-foundation.org>
> wrote:
> >
> > So no, no, no. C got this wrong. Volatile data structures are a
> fundamental mistake and a bug.
>
> BTW, I'm not at all interested in language lawyering and people who say
> "but but we can do x". A compiler that modifies adjacent fields because the
> standard leaves is open is a crap compiler, and we won't use it, or disable
> the broken optimization. It is wrong from a concurrency standpoint anyway,
> and adding broken volatiles is just making things worse.
Understood, for example, adjacent fields protected by different locks
as one example, where adjacent-field overwriting completely breaks even
very conservatively designed code. Should be entertaining! ;-)
Thanx, Paul
next prev parent reply other threads:[~2014-12-04 7:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-04 6:20 [PATCH RFC] locking: Add volatile to arch_spinlock_t structures Paul E. McKenney
[not found] ` <CA+55aFzn-6asfWHB8SAvz4GJWz7uEriujgVLfaqoo_VPtNBLuA@mail.gmail.com>
2014-12-04 6:57 ` Paul E. McKenney
[not found] ` <CA+55aFxGCxQNE4HzRP_Uk2FmFDn_+Hfm6GBz75S+5+SDeODVJQ@mail.gmail.com>
2014-12-04 7:02 ` Paul E. McKenney [this message]
2014-12-04 18:02 ` Linus Torvalds
2014-12-04 18:36 ` Paul E. McKenney
2014-12-04 19:18 ` Linus Torvalds
2014-12-04 20:00 ` Paul E. McKenney
2014-12-04 20:12 ` Paul E. McKenney
2014-12-04 21:45 ` One Thousand Gnomes
2014-12-04 22:06 ` Paul E. McKenney
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=20141204070248.GJ25340@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=dave@stgolabs.net \
--cc=dvyukov@google.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.