On Tue, Oct 15, 2019 at 10:59 PM Thomas Hellström (VMware)
wrote:
>
> Hi, Dan,
>
> On 10/16/19 3:44 AM, Dan Williams wrote:
> > On Tue, Oct 15, 2019 at 3:06 AM Kirill A. Shutemov
> > wrote:
> >> On Tue, Oct 08, 2019 at 11:37:11AM +0200, Thomas Hellström (VMware) wrote:
> >>> From: Thomas Hellstr
Hi, Dan,
On 10/16/19 3:44 AM, Dan Williams wrote:
On Tue, Oct 15, 2019 at 3:06 AM Kirill A. Shutemov wrote:
On Tue, Oct 08, 2019 at 11:37:11AM +0200, Thomas Hellström (VMware) wrote:
From: Thomas Hellstrom
A huge pud page can theoretically be faulted in racing with pmd_alloc()
in __handle_m
On Tue, Oct 15, 2019 at 3:06 AM Kirill A. Shutemov wrote:
>
> On Tue, Oct 08, 2019 at 11:37:11AM +0200, Thomas Hellström (VMware) wrote:
> > From: Thomas Hellstrom
> >
> > A huge pud page can theoretically be faulted in racing with pmd_alloc()
> > in __handle_mm_fault(). That will lead to pmd_all
On Tue, Oct 08, 2019 at 11:37:11AM +0200, Thomas Hellström (VMware) wrote:
> From: Thomas Hellstrom
>
> 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_tran
From: Thomas Hellstrom
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 re
5 matches
Mail list logo