From: Kiryl Shutsemau <kas@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Lorenzo Stoakes <ljs@kernel.org>,
Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH 0/6] userfaultfd/pagemap: pre-existing fixes
Date: Wed, 3 Jun 2026 10:21:13 +0100 [thread overview]
Message-ID: <ah_xuV5PUKTfT5ua@thinkstation> (raw)
In-Reply-To: <04875b82-6671-4f43-aa59-190fd09c7108@kernel.org>
On Mon, Jun 01, 2026 at 05:04:31PM +0200, David Hildenbrand (Arm) wrote:
> On 6/1/26 16:17, Kiryl Shutsemau wrote:
> > On Fri, May 29, 2026 at 05:34:48PM -0700, Andrew Morton wrote:
> >> On Fri, 29 May 2026 18:23:24 +0100 "Kiryl Shutsemau (Meta)" <kas@kernel.org> wrote:
> >>
> >>> These are pre-existing bug fixes that were carried at the front of the
> >>> userfaultfd RWP working-set-tracking series up to v5 [1]. Per review
> >>> feedback that fixes should not sit in the middle of a feature series,
> >>> they are split out and sent on their own; the RWP series is reposted
> >>> rebased on top of this.
> >>>
> >>> All six were flagged by the Sashiko AI review of the RWP series and
> >>> carry Reported-by: Sashiko AI review <sashiko-bot@kernel.org>. They are
> >>> independent of RWP, apply to mm-new directly, and carry Cc: stable@.
> >>
> >> And... this made Sashiko point at other stuff:
> >> https://sashiko.dev/#/patchset/20260529172331.356655-1-kas@kernel.org
> >>
> >> I can't figure out why four of the scans failed - "View Raw Log" comes up empty.
> >
> > Seems to be passed now.
> >
> >> It's concerning how frequently Sashiko is finding pre-existing things. What
> >> would a full scan of mm/ tell us? Gulp.
> >
> > Yeah... :/
> >
> > I will look at the new batch of pre-existing issues when I have spare
> > cycles. I am not sure I have the bandwidth to find the bottom of this
> > rabbit hole.
> >
> > What do you want me to with the main userfaultfd patchset? Sashiko
> > failed to apply it because it is on top of the pre-existing fixes.
>
> I suspect it might have a minor conflict with another incoming fix from Lorenzo
> as well.
>
> Probably put it into mm-unstable early after the next release? At least I think
> it's not in mm-unstable yet and we are approaching the net release quickly ...
I guess I would need to patch man-pages that got applied. I put 7.2
there...
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2026-06-03 9:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-29 17:23 [PATCH 0/6] userfaultfd/pagemap: pre-existing fixes Kiryl Shutsemau (Meta)
2026-05-29 17:23 ` [PATCH 1/6] fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Kiryl Shutsemau (Meta)
2026-06-01 17:55 ` Lorenzo Stoakes
2026-06-01 18:00 ` Lorenzo Stoakes
2026-06-02 6:32 ` Dev Jain
2026-05-29 17:23 ` [PATCH 2/6] fs/proc/task_mmu: use huge_page_size() in pagemap_scan_hugetlb_entry() Kiryl Shutsemau (Meta)
2026-06-01 18:06 ` Lorenzo Stoakes
2026-06-02 6:36 ` Dev Jain
2026-05-29 17:23 ` [PATCH 3/6] fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole() Kiryl Shutsemau (Meta)
2026-05-29 17:23 ` [PATCH 4/6] mm/huge_memory: preserve pmd_swp_uffd_wp on device-private PMD downgrade Kiryl Shutsemau (Meta)
2026-06-01 0:17 ` Balbir Singh
2026-05-29 17:23 ` [PATCH 5/6] userfaultfd: gate must_wait writability check on pte_present() Kiryl Shutsemau (Meta)
2026-06-01 18:11 ` Lorenzo Stoakes
2026-06-02 8:28 ` Mike Rapoport
2026-05-29 17:23 ` [PATCH 6/6] userfaultfd: build __VMA_UFFD_FLAGS from config-gated masks Kiryl Shutsemau (Meta)
2026-06-01 18:34 ` Lorenzo Stoakes
2026-06-02 8:32 ` Mike Rapoport
2026-06-03 9:17 ` Kiryl Shutsemau
2026-05-30 0:34 ` [PATCH 0/6] userfaultfd/pagemap: pre-existing fixes Andrew Morton
2026-06-01 14:17 ` Kiryl Shutsemau
2026-06-01 15:04 ` David Hildenbrand (Arm)
2026-06-03 9:21 ` Kiryl Shutsemau [this message]
2026-06-01 17:38 ` Lorenzo Stoakes
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=ah_xuV5PUKTfT5ua@thinkstation \
--to=kas@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=rppt@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.