Re: [PATCH v4 0/3] mm/khugepaged: fix khugepaged+shmem races

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Mar 4, 2023 at 7:53 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, 3 Mar 2023 10:35:53 -0500 Peter Xu <peterx@xxxxxxxxxx> wrote:
>
> > On Fri, Feb 17, 2023 at 05:54:36PM +0900, David Stevens wrote:
> > > From: David Stevens <stevensd@xxxxxxxxxxxx>
> > >
> > > Fix two races in khugepaged+shmem that cause issues with userfaultfd and
> > > lseek, respectively.
> > >
> > > v3 -> v4:
> > >  - Base changes on mm-everything (fba720cb4dc0)
> > >  - Add patch to refactor error handling control flow in collapse_file
> > >  - Rebase userfaultfd patch with no significant logic changes
> > >  - Different approach for fixing lseek race
> >
> > I just noticed this one hasn't landed unstable, so I guess I just posted a
> > trivial cleanup that can conflict with this so it won't apply cleanly..
> >
> > https://lore.kernel.org/r/20230303151218.311015-1-peterx@xxxxxxxxxx
> >
> > The resolution will be fairly straightforward though, and I'm happy to
> > rebase that one to this since this targets a real bug so should have higher
> > priority.
>
> Even without the above patch ("mm/khugepaged: Cleanup memcg uncharge
> for failure path") I'm seeing a big reject in khugepaged.c.  Might be
> easily fixed, didn't look.
>
> > I guess it's possible Andrew thought the series has unsettled comment so
> > Andrew could just have ignored that whole set in the mark ups.  A repost
> > could possibly clarify that.
>
> Yes please.  Lets gather the acks thus far, rebase on
> git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm's mm-unstable
> branch and resend?

This conflicts pretty heavily with the "Memory poison recovery in
khugepaged collapsing" series. This series was written on top of v9 of
that series, but it looks like v9 of that series was dropped and is
being replaced with v10. Which series should go in first? If we're
confident that v10 of that series won't also be dropped, then rebasing
this series onto v10 of that series should be pretty easy. Otherwise
we could try reworking things to minimize conflicts between the two
series (create a 0th refactoring series?). Andrew, what course would
you prefer?

-David

> > Again, it'll always great to get another eye on this slightly involved
> > series. Matthew / Yang were already on the list, also copying Zach for his
> > recent works on khugepaged just in case he spots anything wrong.
>





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux