From: Nick Piggin <npiggin@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Hugh Dickins <hugh@veritas.com>,
linux-arch@vger.kernel.org,
Linux Memory Management List <linux-mm@kvack.org>,
Paul McKenney <paulmck@us.ibm.com>
Subject: Re: [patch 2/2] fix SMP data race in pagetable setup vs walking
Date: Wed, 14 May 2008 03:18:41 +0200 [thread overview]
Message-ID: <20080514011841.GC24516@wotan.suse.de> (raw)
In-Reply-To: <alpine.LFD.1.10.0805131753150.3019@woody.linux-foundation.org>
On Tue, May 13, 2008 at 05:55:50PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 14 May 2008, Nick Piggin wrote:
> >
> > Uh, I don't follow your logic. The "reference" Linux memory model
> > requires it, so I don't see how you can justify saying it is wrong
> > just because a *specific* architecture doesn't need it.
>
> You're thinking about it the wrong way.
>
> NO specific architecture requires it except for alpha, and alpha already
> has it.
>
> Nobody else is *ever* likely to want it ever again.
Sure, I understand that. But unless you're hinting about removing
SMP support for those alphas that require it, all generic code
obviously still has to care about it. And not many people would
say they only ever look at x86 code and nothing else. I just think
it is a good exercise to _always_ be thinking about barriers, and
be thinking about them in terms of the Linux memory consistency
standard. Maybe I'm biased because I don't do much arch work...
> In other words, it's not a "reference model". It's an "alpha hack". We do
> not want to copy it in code that doesn't need or want it.
>
> And that's especially true when it's not needed at all, and adding it just
> makes a really simple macro much more complex and totally unreadable.
>
> If it was about adding something to a function that was already a real
> function, it would be different.
>
> If you coudl write it as a nice inline function, it would be different.
>
> But when that alpha hack turns a regular (simple) #define into a thing of
> horror, the downside is much *much* bigger than any (non-existent) upside.
Oh that's the main thing you're worried about. Then what about the
ACCESS_ONCE that might be required? That would require the same kind
of thing as I did. And actually smp_read_barrier_depends is a pretty
good indicator for (one of the) cases where we need that macro (although
as I said, I prefer gcc to be fixed).
Anyway, what I will do is send a patch which does the core, and the
alpha bits. At least then the actual bugs will be fixed.
next prev parent reply other threads:[~2008-05-14 1:18 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-05 11:20 [patch 1/2] read_barrier_depends fixlets Nick Piggin
2008-05-05 11:20 ` Nick Piggin
2008-05-05 12:12 ` [patch 2/2] fix SMP data race in pagetable setup vs walking Nick Piggin
2008-05-05 12:12 ` Nick Piggin
2008-05-05 14:35 ` Paul E. McKenney
2008-05-06 9:38 ` Nick Piggin
2008-05-06 13:32 ` Paul E. McKenney
2008-05-13 7:55 ` Nick Piggin
2008-05-13 13:26 ` Paul E. McKenney
2008-05-05 15:32 ` Linus Torvalds
2008-05-05 16:37 ` Hugh Dickins
2008-05-06 9:51 ` Nick Piggin
2008-05-06 14:53 ` Linus Torvalds
2008-05-06 19:11 ` Paul E. McKenney
2008-05-14 4:27 ` Nick Piggin
2008-05-13 8:01 ` Nick Piggin
2008-05-13 15:45 ` Linus Torvalds
2008-05-14 0:34 ` Nick Piggin
2008-05-14 0:55 ` Linus Torvalds
2008-05-14 1:18 ` Nick Piggin [this message]
2008-05-14 4:35 ` [patch 1/2] read_barrier_depends arch fixlets Nick Piggin
2008-05-14 4:37 ` [patch 2/2] fix SMP data race in pagetable setup vs walking Nick Piggin
2008-05-14 13:26 ` [patch 1/2] read_barrier_depends arch fixlets Paul E. McKenney
2008-05-05 16:57 ` [patch 2/2] fix SMP data race in pagetable setup vs walking Hugh Dickins
2008-05-06 9:52 ` Nick Piggin
2008-05-06 7:08 ` David Miller
2008-05-06 9:56 ` Nick Piggin
2008-05-05 14:27 ` [patch 1/2] read_barrier_depends fixlets Paul E. McKenney
2008-05-06 9:01 ` Nick Piggin
2008-05-06 14:06 ` Paul E. McKenney
2008-05-06 15:29 ` David Howells
2008-05-06 19:09 ` Paul E. McKenney
2008-05-13 8:05 ` Nick Piggin
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=20080514011841.GC24516@wotan.suse.de \
--to=npiggin@suse.de \
--cc=hugh@veritas.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=paulmck@us.ibm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox