From: David Stevens <stevensd@chromium.org>
To: Andrew Morton <akpm@linux-foundation.org>,
"jiaqiyan@google.com" <jiaqiyan@google.com>
Cc: Peter Xu <peterx@redhat.com>,
linux-mm@kvack.org, Matthew Wilcox <willy@infradead.org>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
Yang Shi <shy828301@gmail.com>,
David Hildenbrand <david@redhat.com>,
Hugh Dickins <hughd@google.com>,
linux-kernel@vger.kernel.org,
"Zach O'Keefe" <zokeefe@google.com>
Subject: Re: [PATCH v4 0/3] mm/khugepaged: fix khugepaged+shmem races
Date: Mon, 6 Mar 2023 11:44:59 +0900 [thread overview]
Message-ID: <CAD=HUj5Ygjyi9pNryH=VSKOUFCvvCcMFtRRAYM0Vdr9LP4mtaA@mail.gmail.com> (raw)
In-Reply-To: <20230303145258.866b985b21b3ccd9bc41bc4b@linux-foundation.org>
On Sat, Mar 4, 2023 at 7:53 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 3 Mar 2023 10:35:53 -0500 Peter Xu <peterx@redhat.com> wrote:
>
> > On Fri, Feb 17, 2023 at 05:54:36PM +0900, David Stevens wrote:
> > > From: David Stevens <stevensd@chromium.org>
> > >
> > > 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@redhat.com
> >
> > 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.
>
next prev parent reply other threads:[~2023-03-06 2:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 8:54 [PATCH v4 0/3] mm/khugepaged: fix khugepaged+shmem races David Stevens
2023-02-17 8:54 ` [PATCH v4 1/3] mm/khugepaged: refactor collapse_file control flow David Stevens
2023-02-17 23:44 ` Yang Shi
2023-02-21 21:54 ` Peter Xu
2023-02-21 22:28 ` Yang Shi
2023-02-22 4:08 ` David Stevens
2023-02-22 16:24 ` Peter Xu
2023-02-17 8:54 ` [PATCH v4 2/3] mm/khugepaged: skip shmem with userfaultfd David Stevens
2023-02-21 22:12 ` Peter Xu
2023-02-17 8:54 ` [PATCH v4 3/3] mm/khugepaged: maintain page cache uptodate flag David Stevens
2023-02-21 22:18 ` Peter Xu
2023-02-17 10:37 ` [PATCH v4 0/3] mm/khugepaged: fix khugepaged+shmem races Miko Larsson
2023-03-03 15:35 ` Peter Xu
2023-03-03 15:45 ` Zach O'Keefe
2023-03-03 18:55 ` Yang Shi
2023-03-03 22:52 ` Andrew Morton
2023-03-06 2:44 ` David Stevens [this message]
2023-03-06 21:25 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAD=HUj5Ygjyi9pNryH=VSKOUFCvvCcMFtRRAYM0Vdr9LP4mtaA@mail.gmail.com' \
--to=stevensd@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=jiaqiyan@google.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=shy828301@gmail.com \
--cc=willy@infradead.org \
--cc=zokeefe@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).