[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20191115115800.45c053abcdb550d70b9baec9@linux-foundation.org>
Date: Fri, 15 Nov 2019 11:58:00 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Thomas Hellström (VMware)
<thomas_os@...pmail.org>
Cc: 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, 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?
Is a -stable backport warranted?
Powered by blists - more mailing lists