From: Matthew Wilcox <willy@debian.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Andrea Arcangeli <andrea@suse.de>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Andrew Morton <akpm@osdl.org>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>, Ben LaHaise <bcrl@kvack.org>,
linux-mm@kvack.org,
Architectures Group <linux-arch@vger.kernel.org>
Subject: Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE
Date: Tue, 25 May 2004 12:44:37 +0100 [thread overview]
Message-ID: <20040525114437.GC29154@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <Pine.LNX.4.58.0405242051460.32189@ppc970.osdl.org>
On Mon, May 24, 2004 at 09:00:02PM -0700, Linus Torvalds wrote:
> I suspect we should just make a "ptep_set_bits()" inline function that
> _atomically_ does "set the dirty/accessed bits". On x86, it would be a
> simple
>
> asm("lock ; orl %1,%0"
> :"m" (*ptep)
> :"r" (entry));
>
> and similarly on most other architectures it should be quite easy to do
> the equivalent. You can always do it with a simple compare-and-exchange
> loop, something any SMP-capable architecture should have.
... but PA doesn't. Just load-and-clear-word (and its 64-bit equivalent
in 64-bit mode). And that word has to be 16-byte aligned. What race
are we protecting against? If it's like xchg() and we only need to
protect against a racing xchg() and not a reader, we can just reuse the
global array of hashed spinlocks we have for that.
> Of course, arguably we can actually optimize this by "knowing" that it is
> safe to set the dirty bit, so then we don't even need an atomic operation,
> we just need one atomic write. So we only actually need the atomic op for
> the accessed bit case, and if we make the write-case be totally separate..
Ah, atomic writes we can do. That's easy. I think all Linux architectures
support atomic writes to naturally aligned addresses, don't they?
> Anybody willing to write up a patch for a few architectures? Is there any
> architecture out there that would have a problem with this?
>
> Linus
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@debian.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Andrea Arcangeli <andrea@suse.de>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Andrew Morton <akpm@osdl.org>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>, Ben LaHaise <bcrl@kvack.org>,
linux-mm@kvack.org,
Architectures Group <linux-arch@vger.kernel.org>
Subject: Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE
Date: Tue, 25 May 2004 12:44:37 +0100 [thread overview]
Message-ID: <20040525114437.GC29154@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <Pine.LNX.4.58.0405242051460.32189@ppc970.osdl.org>
On Mon, May 24, 2004 at 09:00:02PM -0700, Linus Torvalds wrote:
> I suspect we should just make a "ptep_set_bits()" inline function that
> _atomically_ does "set the dirty/accessed bits". On x86, it would be a
> simple
>
> asm("lock ; orl %1,%0"
> :"m" (*ptep)
> :"r" (entry));
>
> and similarly on most other architectures it should be quite easy to do
> the equivalent. You can always do it with a simple compare-and-exchange
> loop, something any SMP-capable architecture should have.
... but PA doesn't. Just load-and-clear-word (and its 64-bit equivalent
in 64-bit mode). And that word has to be 16-byte aligned. What race
are we protecting against? If it's like xchg() and we only need to
protect against a racing xchg() and not a reader, we can just reuse the
global array of hashed spinlocks we have for that.
> Of course, arguably we can actually optimize this by "knowing" that it is
> safe to set the dirty bit, so then we don't even need an atomic operation,
> we just need one atomic write. So we only actually need the atomic op for
> the accessed bit case, and if we make the write-case be totally separate..
Ah, atomic writes we can do. That's easy. I think all Linux architectures
support atomic writes to naturally aligned addresses, don't they?
> Anybody willing to write up a patch for a few architectures? Is there any
> architecture out there that would have a problem with this?
>
> Linus
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-05-25 11:44 UTC|newest]
Thread overview: 153+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-24 3:29 [PATCH] ppc64: Fix possible race with set_pte on a present PTE Benjamin Herrenschmidt
2004-05-24 3:47 ` Linus Torvalds
2004-05-24 4:13 ` Benjamin Herrenschmidt
2004-05-24 4:36 ` Linus Torvalds
2004-05-24 4:44 ` Benjamin Herrenschmidt
2004-05-24 5:10 ` Linus Torvalds
2004-05-24 5:10 ` Linus Torvalds
2004-05-24 5:34 ` Benjamin Herrenschmidt
2004-05-24 5:34 ` Benjamin Herrenschmidt
2004-05-24 5:38 ` Benjamin Herrenschmidt
2004-05-24 5:38 ` Benjamin Herrenschmidt
2004-05-24 5:52 ` Benjamin Herrenschmidt
2004-05-24 5:52 ` Benjamin Herrenschmidt
2004-05-24 7:39 ` Ingo Molnar
2004-05-24 7:39 ` Ingo Molnar
2004-05-24 5:39 ` Benjamin Herrenschmidt
2004-05-24 5:39 ` Benjamin Herrenschmidt
2004-05-25 3:43 ` Andrea Arcangeli
2004-05-25 3:43 ` Andrea Arcangeli
2004-05-25 4:00 ` Linus Torvalds
2004-05-25 4:00 ` Linus Torvalds
2004-05-25 4:17 ` Benjamin Herrenschmidt
2004-05-25 4:17 ` Benjamin Herrenschmidt
2004-05-25 4:37 ` Andrea Arcangeli
2004-05-25 4:37 ` Andrea Arcangeli
2004-05-25 4:40 ` Benjamin Herrenschmidt
2004-05-25 4:40 ` Benjamin Herrenschmidt
2004-05-25 4:20 ` Andrea Arcangeli
2004-05-25 4:20 ` Andrea Arcangeli
2004-05-25 4:39 ` Linus Torvalds
2004-05-25 4:39 ` Linus Torvalds
2004-05-25 4:44 ` Linus Torvalds
2004-05-25 4:44 ` Linus Torvalds
2004-05-25 4:59 ` Andrea Arcangeli
2004-05-25 4:59 ` Andrea Arcangeli
2004-05-25 5:09 ` Andrea Arcangeli
2004-05-25 5:09 ` Andrea Arcangeli
2004-05-25 4:50 ` Andrea Arcangeli
2004-05-25 4:50 ` Andrea Arcangeli
2004-05-25 4:59 ` Linus Torvalds
2004-05-25 4:59 ` Linus Torvalds
2004-05-25 4:43 ` David Mosberger
2004-05-25 4:43 ` David Mosberger
2004-05-25 4:53 ` Andrea Arcangeli
2004-05-25 4:53 ` Andrea Arcangeli
2004-05-27 21:56 ` David Mosberger
2004-05-27 21:56 ` David Mosberger
2004-05-27 22:00 ` Benjamin Herrenschmidt
2004-05-27 22:00 ` Benjamin Herrenschmidt
2004-05-27 22:12 ` David Mosberger
2004-05-27 22:12 ` David Mosberger
2004-05-25 11:44 ` Matthew Wilcox [this message]
2004-05-25 11:44 ` Matthew Wilcox
2004-05-25 14:48 ` Linus Torvalds
2004-05-25 14:48 ` Linus Torvalds
2004-05-25 15:35 ` Keith M Wesolowski
2004-05-25 15:35 ` Keith M Wesolowski
2004-05-25 16:19 ` Linus Torvalds
2004-05-25 16:19 ` Linus Torvalds
2004-05-25 17:25 ` David S. Miller
2004-05-25 17:25 ` David S. Miller
2004-05-25 17:49 ` Linus Torvalds
2004-05-25 17:49 ` Linus Torvalds
2004-05-25 17:54 ` David S. Miller
2004-05-25 17:54 ` David S. Miller
2004-05-25 18:05 ` Linus Torvalds
2004-05-25 18:05 ` Linus Torvalds
2004-05-25 20:30 ` Linus Torvalds
2004-05-25 20:30 ` Linus Torvalds
2004-05-25 20:35 ` David S. Miller
2004-05-25 20:35 ` David S. Miller
2004-05-25 20:35 ` David S. Miller
2004-05-25 20:49 ` Linus Torvalds
2004-05-25 20:49 ` Linus Torvalds
2004-05-25 20:57 ` David S. Miller
2004-05-25 20:57 ` David S. Miller
2004-05-26 6:20 ` Keith M Wesolowski
2004-05-26 6:20 ` Keith M Wesolowski
2004-05-25 21:40 ` Benjamin Herrenschmidt
2004-05-25 21:40 ` Benjamin Herrenschmidt
2004-05-25 21:54 ` Linus Torvalds
2004-05-25 21:54 ` Linus Torvalds
2004-05-25 22:00 ` Linus Torvalds
2004-05-25 22:00 ` Linus Torvalds
2004-05-25 22:07 ` Benjamin Herrenschmidt
2004-05-25 22:07 ` Benjamin Herrenschmidt
2004-05-25 22:14 ` Linus Torvalds
2004-05-25 22:14 ` Linus Torvalds
2004-05-26 0:21 ` Benjamin Herrenschmidt
2004-05-26 0:21 ` Benjamin Herrenschmidt
2004-05-26 0:50 ` Linus Torvalds
2004-05-26 0:50 ` Linus Torvalds
2004-05-26 3:25 ` Benjamin Herrenschmidt
2004-05-26 3:25 ` Benjamin Herrenschmidt
2004-05-26 4:08 ` Linus Torvalds
2004-05-26 4:08 ` Linus Torvalds
2004-05-26 4:12 ` Benjamin Herrenschmidt
2004-05-26 4:12 ` Benjamin Herrenschmidt
2004-05-26 4:18 ` Benjamin Herrenschmidt
2004-05-26 4:18 ` Benjamin Herrenschmidt
2004-05-26 4:50 ` Linus Torvalds
2004-05-26 4:50 ` Linus Torvalds
2004-05-26 4:49 ` Benjamin Herrenschmidt
2004-05-26 4:49 ` Benjamin Herrenschmidt
2004-05-26 4:28 ` Linus Torvalds
2004-05-26 4:28 ` Linus Torvalds
2004-05-26 4:46 ` Benjamin Herrenschmidt
2004-05-26 4:46 ` Benjamin Herrenschmidt
2004-05-26 4:54 ` Linus Torvalds
2004-05-26 4:54 ` Linus Torvalds
2004-05-26 4:55 ` Benjamin Herrenschmidt
2004-05-26 4:55 ` Benjamin Herrenschmidt
2004-05-26 5:41 ` Benjamin Herrenschmidt
2004-05-26 5:41 ` Benjamin Herrenschmidt
2004-05-26 5:59 ` [PATCH] (signoff) " Benjamin Herrenschmidt
2004-05-26 5:59 ` Benjamin Herrenschmidt
2004-05-26 6:55 ` Benjamin Herrenschmidt
2004-05-26 6:55 ` Benjamin Herrenschmidt
2004-05-26 7:11 ` [PATCH] ppc32 implementation of ptep_set_access_flags Benjamin Herrenschmidt
2004-05-26 15:22 ` Linus Torvalds
2004-05-26 18:49 ` David S. Miller
2004-05-26 21:43 ` Benjamin Herrenschmidt
2004-05-28 1:29 ` David Mosberger
2004-05-25 22:05 ` [PATCH] ppc64: Fix possible race with set_pte on a present PTE Benjamin Herrenschmidt
2004-05-25 22:05 ` Benjamin Herrenschmidt
2004-05-25 22:09 ` Linus Torvalds
2004-05-25 22:09 ` Linus Torvalds
2004-05-25 22:19 ` Benjamin Herrenschmidt
2004-05-25 22:19 ` Benjamin Herrenschmidt
2004-05-25 22:24 ` Linus Torvalds
2004-05-25 22:24 ` Linus Torvalds
2004-05-25 21:27 ` Andrea Arcangeli
2004-05-25 21:27 ` Andrea Arcangeli
2004-05-25 21:43 ` Linus Torvalds
2004-05-25 21:43 ` Linus Torvalds
2004-05-25 21:55 ` Andrea Arcangeli
2004-05-25 21:55 ` Andrea Arcangeli
2004-05-25 22:01 ` Linus Torvalds
2004-05-25 22:01 ` Linus Torvalds
2004-05-25 22:18 ` Ivan Kokshaysky
2004-05-25 22:18 ` Ivan Kokshaysky
2004-05-25 22:42 ` Andrea Arcangeli
2004-05-25 22:42 ` Andrea Arcangeli
2004-05-26 2:26 ` Linus Torvalds
2004-05-26 2:26 ` Linus Torvalds
2004-05-26 7:06 ` Andrea Arcangeli
2004-05-26 7:06 ` Andrea Arcangeli
2004-05-25 21:44 ` Andrea Arcangeli
2004-05-25 21:44 ` Andrea Arcangeli
-- strict thread matches above, loose matches on Subject: below --
2004-06-01 12:04 Martin Schwidefsky
2004-06-01 12:04 ` Martin Schwidefsky
2004-06-01 12:10 Martin Schwidefsky
2004-06-01 12:10 ` Martin Schwidefsky
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=20040525114437.GC29154@parcelfarce.linux.theplanet.co.uk \
--to=willy@debian.org \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=bcrl@kvack.org \
--cc=benh@kernel.crashing.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=torvalds@osdl.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.