fs/proc/task_mmu.c | 73 ++++++++++++++++++++++++++++++++--- include/linux/mm.h | 39 +++++++++++++++++++ include/linux/userfaultfd_k.h | 4 +- mm/huge_memory.c | 2 + mm/userfaultfd.c | 20 ++++++++++ 5 files changed, 130 insertions(+), 8 deletions(-)
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@.
1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in
make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates
when PAGEMAP_SCAN write-protects a hugetlb PTE.
2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range
against HPAGE_SIZE rather than the hstate page size, so it never
write-protects gigantic hugetlb pages.
3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an
unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole()
calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb
vma lock for read, and hugetlb_change_protection() then takes it
for write. Install the marker inline instead.
4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp
on a device-private PMD permission downgrade, silently losing the
uffd-wp marker.
5: userfaultfd: must_wait() applies pte_write() to a locklessly read
PTE without checking pte_present(), so swap/migration entries
decode random offset bits and a thread can stay parked on a stale
fault.
6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to
mk_vma_flags() unconditionally, an out-of-bounds write into the
single-word vma_flags_t on 32-bit. Build the mask from config-gated
per-mode masks so an unavailable bit is never materialised.
[1] https://lore.kernel.org/all/20260526130509.2748441-1-kirill@shutemov.name/
Kiryl Shutsemau (Meta) (6):
fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race
fs/proc/task_mmu: use huge_page_size() in pagemap_scan_hugetlb_entry()
fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole()
mm/huge_memory: preserve pmd_swp_uffd_wp on device-private PMD
downgrade
userfaultfd: gate must_wait writability check on pte_present()
userfaultfd: build __VMA_UFFD_FLAGS from config-gated masks
fs/proc/task_mmu.c | 73 ++++++++++++++++++++++++++++++++---
include/linux/mm.h | 39 +++++++++++++++++++
include/linux/userfaultfd_k.h | 4 +-
mm/huge_memory.c | 2 +
mm/userfaultfd.c | 20 ++++++++++
5 files changed, 130 insertions(+), 8 deletions(-)
base-commit: 449a5df98f8dffa9b037e3b6838fc5af327df072
--
2.54.0
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. It's concerning how frequently Sashiko is finding pre-existing things. What would a full scan of mm/ tell us? Gulp.
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. > > It's concerning how frequently Sashiko is finding pre-existing things. What > would a full scan of mm/ tell us? Gulp. > Yeah, but I also kinda wish it didn't do this :) It's similar to sending a series, and somebody replying saying 'well this is totally unrelated but <blah blah blah>' and expecting a reply :>) You'd want that person to just submit a patch for the issue or a [DISCUSSION] or [BUG] thread or something, but interrupting, possibly delaying + taking people's (usually very limited) time on something unrelated is just unhelpful I think. I'd prefer Sashiko had a passive mode that checked for existing stuff elsewhere, and it saved the tokens doing it for a new series :) Just my 2 pence! Cheers, Lorenzo
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. -- Kiryl Shutsemau / Kirill A. Shutemov
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 ... -- Cheers, David
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
© 2016 - 2026 Red Hat, Inc.