[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191118102219.om5monxih7kfodyz@box>
Date: Mon, 18 Nov 2019 13:22:19 +0300
From: "Kirill A. Shutemov" <kirill@...temov.name>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Thomas Hellström <thomas_os@...pmail.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Thomas Hellstrom <thellstrom@...are.com>,
Arnd Bergmann <arnd@...db.de>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH 2/2] mm: Fix a huge pud insertion race during faulting
On Fri, Nov 15, 2019 at 11:58:00AM -0800, Andrew Morton wrote:
> On Fri, 15 Nov 2019 12:58:08 +0100 Thomas Hellström (VMware) <thomas_os@...pmail.org> wrote:
>
> > A huge pud page can theoretically be faulted in racing with pmd_alloc()
> > in __handle_mm_fault(). That will lead to pmd_alloc() returning an
> > invalid pmd pointer. Fix this by adding a pud_trans_unstable() function
> > similar to pmd_trans_unstable() and check whether the pud is really stable
> > before using the pmd pointer.
> >
> > Race:
> > Thread 1: Thread 2: Comment
> > create_huge_pud() Fallback - not taken.
> > create_huge_pud() Taken.
> > pmd_alloc() Returns an invalid pointer.
>
> What are the user-visible runtime effects of this change?
Data corruption: kernel writes to a huge page thing it's page table.
> Is a -stable backport warranted?
I believe it is.
Acked-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
--
Kirill A. Shutemov
Powered by blists - more mailing lists