lkml.org 
[lkml]   [2018]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux 4.18-rc7
    On Tue, Jul 31, 2018 at 09:29:27AM +0300, Kirill A. Shutemov wrote:
    > On Mon, Jul 30, 2018 at 06:01:26PM -0700, Linus Torvalds wrote:
    > > On Mon, Jul 30, 2018 at 2:53 PM Hugh Dickins <hughd@google.com> wrote:
    > > >
    > > > I have no problem with reverting -rc7's vma_is_anonymous() series.
    > >
    > > I don't think we need to revert the whole series: I think the rest are
    > > all fairly obvious cleanups, and shouldn't really have any semantic
    > > changes.
    > >
    > > It's literally only that last patch in the series that then changes
    > > that meaning of "vm_ops". And I don't really _mind_ that last step
    > > either, but since we don't know exactly what it was that it broke, and
    > > we're past rc7, I don't think we really have any option but the revert
    > > it.
    > >
    > > And if we revert it, I think we need to just remove the
    > > VM_BUG_ON_VMA() that it was supposed to fix. Because I do think that
    > > it is quite likely that the real bug is that overzealous BUG_ON(),
    > > since I can't see any reason why anonymous mappings should be special
    > > there.
    > >
    > > But I'm certainly also ok with re-visiting that commit later. I just
    > > think that right _now_ the above is my preferred plan.
    > >
    > > Kirill?
    >
    > Considering the timing, I'm okay with reverting the last patch with
    > dropping the VM_BUG_ON_VMA().
    >
    > But in the end I would like to see strong vma_is_anonymous().
    >
    > The VM_BUG_ON_VMA() is only triggerable by the test case because
    > vma_is_anonymous() false-positive in fault path and we get anon-THP
    > allocated in file-private mapping.
    >
    > I don't see immediately how this may trigger other crashes.
    > But it definitely looks wrong.
    >
    > > > I'm all for deleting that VM_BUG_ON_VMA() in zap_pmd_range(), it was
    > > > just a compromise with those who wanted to keep something there;
    > > > I don't think we even need a WARN_ON_ONCE() now.
    > >
    > > So to me it looks like a historical check that simply doesn't
    > > "normally" trigger, but there's no reason I can see why we should care
    > > about the case it tests against.
    >
    > I'll think more on what could go wrong with __split_huge_pmd() called on
    > anon-THP page without mmap_sem(). It's not yet clear cut to me.

    I think not having mmap_sem taken at least on read when we call
    __split_huge_pmd() opens possiblity of race with khugepaged:
    khugepaged can collapse the page back to THP as soon as we drop ptl.
    As result pmd_none_or_trans_huge_or_clear_bad() would return true and we
    basically leave the THP behind, not zapped.

    --
    Kirill A. Shutemov

    \
     
     \ /
      Last update: 2018-07-31 16:58    [W:3.308 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site