lkml.org 
[lkml]   [2021]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/7] mm/thp: fix __split_huge_pmd_locked() on shmem migration entry
    On Tue, Jun 01, 2021 at 02:05:45PM -0700, Hugh Dickins wrote:
    > Stressing huge tmpfs page migration racing hole punch often crashed on the
    > VM_BUG_ON(!pmd_present) in pmdp_huge_clear_flush(), with DEBUG_VM=y kernel;
    > or shortly afterwards, on a bad dereference in __split_huge_pmd_locked()
    > when DEBUG_VM=n. They forgot to allow for pmd migration entries in the
    > non-anonymous case.
    >
    > Full disclosure: those particular experiments were on a kernel with more
    > relaxed mmap_lock and i_mmap_rwsem locking, and were not repeated on the
    > vanilla kernel: it is conceivable that stricter locking happens to avoid
    > those cases, or makes them less likely; but __split_huge_pmd_locked()
    > already allowed for pmd migration entries when handling anonymous THPs,
    > so this commit brings the shmem and file THP handling into line.
    >
    > Are there more places that need to be careful about pmd migration entries?
    > None hit in practice, but several of those is_huge_zero_pmd() tests were
    > done without checking pmd_present() first: I believe a pmd migration entry
    > could end up satisfying that test. Ah, the inversion of swap offset, to
    > protect against L1TF, makes that impossible on x86; but other arches need
    > the pmd_present() check, and even x86 ought not to apply pmd_page() to a
    > swap-like pmd. Fix those instances; __split_huge_pmd_locked() was not
    > wrong to be checking with pmd_trans_huge() instead, but I think it's
    > clearer to use pmd_present() in each instance.
    >
    > And while there: make it clearer to the eye that the !vma_is_anonymous()
    > and is_huge_zero_pmd() blocks make early returns (and don't return void).
    >
    > Fixes: e71769ae5260 ("mm: enable thp migration for shmem thp")
    > Signed-off-by: Hugh Dickins <hughd@google.com>
    > Cc: <stable@vger.kernel.org>

    Looks like a two fixes got squashed into one patch. Zero-page fix and
    migration entries in __split_huge_pmd_locked() deserve separate patches,
    no?

    Maybe add VM_BUG_ON(!pmd_present()) in is_huge_zero_pmd()?

    Also I wounder how much code we can remove if we would not establish
    migration ptes for file pages. We can make these page table entries 'none'
    on migration.

    --
    Kirill A. Shutemov

    \
     
     \ /
      Last update: 2021-06-04 17:35    [W:2.104 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site