From: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
To: Nick Piggin <npiggin-l3A5Bk7waGM@public.gmane.org>
Cc: Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>,
linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Memory Management List
<linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>
Subject: Re: [rfc] data race in page table setup/walking?
Date: Tue, 29 Apr 2008 15:08:44 +1000 [thread overview]
Message-ID: <1209445724.18023.136.camel@pasglop> (raw)
In-Reply-To: <20080429050054.GC21795-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
On Tue, 2008-04-29 at 07:00 +0200, Nick Piggin wrote:
>
> At this point, the spinlock is not guaranteed to have ordered the previous
> stores to initialize the pte page with the subsequent store to put it in the
> page tables. So another Linux page table walker might be walking down (without
> any locks, because we have split-leaf-ptls), and find that new pte we've
> inserted. It might try to take the spinlock before the store from the other
> CPU initializes it. And subsequently it might read a pte_t out before stores
> from the other CPU have cleared the memory.
Funny, we used to have a similar race where the zeros for clearing a
newly allocated anonymous pages end up reaching the coherency domain
after the new PTE in set_pte, causing memory corruption on threaded
apps. I think back then we fixed that with an explicit smp_wmb() before
a set_pte(). Maybe we need that also when setting the higher levels.
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Hugh Dickins <hugh@veritas.com>,
linux-arch@vger.kernel.org,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [rfc] data race in page table setup/walking?
Date: Tue, 29 Apr 2008 15:08:44 +1000 [thread overview]
Message-ID: <1209445724.18023.136.camel@pasglop> (raw)
Message-ID: <20080429050844.oRPq5W1IMjyz9_Kp6RzOmbFuhtO_vVV-Hdz7IUX5AGo@z> (raw)
In-Reply-To: <20080429050054.GC21795@wotan.suse.de>
On Tue, 2008-04-29 at 07:00 +0200, Nick Piggin wrote:
>
> At this point, the spinlock is not guaranteed to have ordered the previous
> stores to initialize the pte page with the subsequent store to put it in the
> page tables. So another Linux page table walker might be walking down (without
> any locks, because we have split-leaf-ptls), and find that new pte we've
> inserted. It might try to take the spinlock before the store from the other
> CPU initializes it. And subsequently it might read a pte_t out before stores
> from the other CPU have cleared the memory.
Funny, we used to have a similar race where the zeros for clearing a
newly allocated anonymous pages end up reaching the coherency domain
after the new PTE in set_pte, causing memory corruption on threaded
apps. I think back then we fixed that with an explicit smp_wmb() before
a set_pte(). Maybe we need that also when setting the higher levels.
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Hugh Dickins <hugh@veritas.com>,
linux-arch@vger.kernel.org,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [rfc] data race in page table setup/walking?
Date: Tue, 29 Apr 2008 15:08:44 +1000 [thread overview]
Message-ID: <1209445724.18023.136.camel@pasglop> (raw)
In-Reply-To: <20080429050054.GC21795@wotan.suse.de>
On Tue, 2008-04-29 at 07:00 +0200, Nick Piggin wrote:
>
> At this point, the spinlock is not guaranteed to have ordered the previous
> stores to initialize the pte page with the subsequent store to put it in the
> page tables. So another Linux page table walker might be walking down (without
> any locks, because we have split-leaf-ptls), and find that new pte we've
> inserted. It might try to take the spinlock before the store from the other
> CPU initializes it. And subsequently it might read a pte_t out before stores
> from the other CPU have cleared the memory.
Funny, we used to have a similar race where the zeros for clearing a
newly allocated anonymous pages end up reaching the coherency domain
after the new PTE in set_pte, causing memory corruption on threaded
apps. I think back then we fixed that with an explicit smp_wmb() before
a set_pte(). Maybe we need that also when setting the higher levels.
Ben.
--
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:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-04-29 5:08 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-29 5:00 [rfc] data race in page table setup/walking? Nick Piggin
2008-04-29 5:00 ` Nick Piggin
2008-04-29 5:00 ` Nick Piggin
[not found] ` <20080429050054.GC21795-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2008-04-29 5:08 ` Benjamin Herrenschmidt [this message]
2008-04-29 5:08 ` Benjamin Herrenschmidt
2008-04-29 5:08 ` Benjamin Herrenschmidt
2008-04-29 5:41 ` Nick Piggin
2008-04-29 5:41 ` Nick Piggin
2008-04-29 5:41 ` Nick Piggin
2008-04-29 10:56 ` David Miller
2008-04-29 10:56 ` David Miller, Nick Piggin
2008-04-29 10:56 ` David Miller
2008-04-29 12:36 ` Hugh Dickins
2008-04-29 12:36 ` Hugh Dickins
2008-04-29 12:36 ` Hugh Dickins
[not found] ` <Pine.LNX.4.64.0804291333540.22025-popGQ1T0qN76K7/ahGyk6A@public.gmane.org>
2008-04-29 21:37 ` Benjamin Herrenschmidt
2008-04-29 21:37 ` Benjamin Herrenschmidt
2008-04-29 21:37 ` Benjamin Herrenschmidt
2008-04-29 22:47 ` Hugh Dickins
2008-04-29 22:47 ` Hugh Dickins
2008-04-29 22:47 ` Hugh Dickins
[not found] ` <Pine.LNX.4.64.0804292328110.23470-popGQ1T0qN76K7/ahGyk6A@public.gmane.org>
2008-04-30 0:09 ` Benjamin Herrenschmidt
2008-04-30 0:09 ` Benjamin Herrenschmidt
2008-04-30 0:09 ` Benjamin Herrenschmidt
2008-04-30 6:03 ` Nick Piggin
2008-04-30 6:03 ` Nick Piggin
2008-04-30 6:03 ` Nick Piggin
[not found] ` <20080430060340.GE27652-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2008-04-30 6:05 ` David Miller
2008-04-30 6:05 ` David Miller, Nick Piggin
2008-04-30 6:05 ` David Miller
[not found] ` <20080429.230543.98200575.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-04-30 6:17 ` Nick Piggin
2008-04-30 6:17 ` Nick Piggin
2008-04-30 6:17 ` Nick Piggin
2008-04-30 11:14 ` Hugh Dickins
2008-04-30 11:14 ` Hugh Dickins
2008-04-30 11:14 ` Hugh Dickins
[not found] ` <Pine.LNX.4.64.0804301140490.4651-popGQ1T0qN76K7/ahGyk6A@public.gmane.org>
2008-05-01 0:35 ` Nick Piggin
2008-05-01 0:35 ` Nick Piggin
2008-05-01 0:35 ` Nick Piggin
[not found] ` <20080501003542.GB11312-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2008-05-01 12:45 ` Hugh Dickins
2008-05-01 12:45 ` Hugh Dickins
2008-05-01 12:45 ` Hugh Dickins
2008-04-30 15:53 ` Linus Torvalds
2008-04-30 15:53 ` Linus Torvalds
2008-04-30 15:53 ` Linus Torvalds
[not found] ` <alpine.LFD.1.10.0804300848390.2997-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
2008-05-01 0:29 ` Nick Piggin
2008-05-01 0:29 ` Nick Piggin
2008-05-01 0:29 ` Nick Piggin
[not found] ` <20080501002955.GA11312-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2008-05-01 3:24 ` Linus Torvalds
2008-05-01 3:24 ` Linus Torvalds
2008-05-01 3:24 ` Linus Torvalds
2008-05-02 1:20 ` Nick Piggin
2008-05-02 1:20 ` Nick Piggin
2008-05-02 1:33 ` Linus Torvalds
2008-05-02 1:33 ` Linus Torvalds
2008-05-02 1:43 ` Nick Piggin
2008-05-02 1:43 ` 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=1209445724.18023.136.camel@pasglop \
--to=benh-xvmvhmargas8u2djnn8i7kb+6bgklq7r@public.gmane.org \
--cc=hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org \
--cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=npiggin-l3A5Bk7waGM@public.gmane.org \
--cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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.