drivers/char/mem.c | 8 +- include/linux/mm.h | 74 ++++++++++++++--- include/linux/mm_types.h | 4 + include/linux/pagemap.h | 66 +++++++++++++++ include/linux/rmap.h | 2 + mm/huge_memory.c | 3 +- mm/internal.h | 76 ++++++++++++----- mm/interval_tree.c | 4 +- mm/ksm.c | 7 +- mm/memory-failure.c | 4 +- mm/memory.c | 8 +- mm/migrate.c | 6 +- mm/mremap.c | 6 +- mm/page_vma_mapped.c | 6 +- mm/rmap.c | 23 +++--- mm/userfaultfd.c | 6 +- mm/vma.c | 116 ++++++++++++++++++++------ mm/vma.h | 144 +++++++++++++++++++++++++-------- mm/vma_exec.c | 2 +- mm/vma_init.c | 1 + mm/vma_internal.h | 1 + tools/testing/selftests/mm/merge.c | 161 +++++++++++++++++++++++++++++++++++++ tools/testing/vma/include/dup.h | 77 ++++++++++++++++++ tools/testing/vma/shared.c | 3 +- tools/testing/vma/tests/merge.c | 22 ++++- tools/testing/vma/tests/mmap.c | 49 +++++++++++ tools/testing/vma/tests/vma.c | 4 +- tools/testing/vma/vma_internal.h | 1 + 28 files changed, 764 insertions(+), 120 deletions(-)
In memory management we've managed to manufacture a great deal of confusion
around the concept of anonymous memory. We have:
1. 'Pure anon' memory - anonymous VMAs whose folios are anonymous and
swap-backed (thus for reclaim purposes, treated as anonymous). These are
simple enough.
2. shmem - file-backed VMAs, file-backed folios (from rmap perspective) so
present in the page cache and mapped by an address_space object, but
whose folios are also swap-backed (thus treated as anonymous for reclaim
purposes).
3. MAP_PRIVATE-mapped /dev/zero - a strange beast whose VMAs have
vma->vm_file set, but whose mmap_prepare callback clears vma->vm_ops to
satisfy vma_is_anonymous(), which results in VMAs that were mmap()'d
referencing a file and whose VMAs reference a file, but are in every other
sense anonymous, including the folios.
4. Other MAP_PRIVATE-file backed mappings - These possess file-backed VMAs
and have file-backed folios until CoW'd, at which point those CoW'd
folios are anonymous.
This series focuses upon issue 4.
In order for us to traverse VMAs using the reverse mapping, we require two
fields - folio->mapping and folio->index. The first tells the rmap code
where to look for VMAs, and the second tells it at which offset the folio
starts within the referenced object.
For anonymous folios, folio->mapping points at an anon_vma object. For
file-backed folios, it points at an address_space. And:
* For file-backed folios folio->index is simply the page offset of the start
of the folio within the file.
* For anonymous folios belonging to pure anon mappings, folio->index is
equal to the virtual page offset of the folio.
* For anonymous folios belonging to file-backed mappings (i.e. CoW'd folios
of a MAP_PRIVATE file-backed mapping), folio->index is equal to the file
page offset.
This series establishes a new virtual page offset property of VMAs to
allow us to map anonymous folios at their virtual page offset, consistent
with pure anon.
The purpose of doing so is to lay the foundations for the scalable CoW
work. This is necessary because firstly the approach first looks in the
maple tree for the VMA located at folio->index << PAGE_SHIFT, before
falling back to looking up tracked remaps if necessary.
The MAP_PRIVATE file-backed case means that folio indices will very often
conflict with one another and this remap tracking becomes substantially
more contended, and of course the fast path can never be used.
This also makes it possible, in future, to unshare anonymously mapped
folios with deep fork hierarchies on remap, eliminating the need for remap
tracking in the vast majority of cases.
Similar to page offset of pure anonymous VMAs, we update the virtual page
offset of unfaulted file-backed VMAs on remap, but do not once
CoW'd:(i.e. vma->anon_vma is non-NULL).
Overall, there is little impact on mergeability - for shared file-backed
mappings, we treat the anonymous page offset as equal to the file-backed
one (via vma_start_anon_pgoff()), so merge behaviour remains the same
there.
The only impact is on MAP_PRIVATE-mapped file-backed mappings, which must
now match on virtual page offset as well as file page offset to be merged.
To fail to merge like this would require CoW'ing the mapping, then finding
another VMA with identical file and compatible page offset to remap next
to. This is therefore very much an edge case that should have very little
impact (and which scalable CoW may very well address in any case).
We also address the outlier case of MAP_PRIVATE-/dev/zero mappings which
have file page offset but satisfy vma_is_anonymous() by making them truly
anonymous.
This is low-risk as for anything meaningful these mappings behave
anonymously, but it is very beneficial to do so as we eliminate an odd
corner case, and those are notorious for attracting subtle bugs.
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
v1:
- Rebased onto mm-new.
- Dependent series heavily reviewed and looks highly likely to land, so
un-RFC.
- Added explicit check for /dev/zero and removed ability for arbitrary
mmap/mmap_prepare hooks to make themselves anonymous.
- Made MAP_PRIVATE-/dev/zero mappings truly anonymous.
- Added MAP_PRIVATE file-backed mapping merge test to selftests.
- Added a MAP_PRIVATE-/dev/zero VMA userland test to assert that the VMA
really is made anonymous.
- Added MAP_PRIVATE-/dev/zero merge tests to selftests.
- Fixed missed virtual page index site in try_to_merge_with_ksm_page().
- Updated folio_within_range() to use virtual page offset for anon
folio. This had no impact as it is only called for large folios at the
moment (and MAP_PRIVATE-file backed mappings can't currently be backed by
a large folio) but making the change now protects us for the future.
- Fixed typos etc.
RFC:
https://patch.msgid.link/cover.1782745153.git.ljs@kernel.org
To: Andrew Morton <akpm@linux-foundation.org>
To: David Hildenbrand <david@kernel.org>
To: "Liam R. Howlett" <liam@infradead.org>
To: Vlastimil Babka <vbabka@kernel.org>
To: Mike Rapoport <rppt@kernel.org>
To: Suren Baghdasaryan <surenb@google.com>
To: Michal Hocko <mhocko@suse.com>
To: Jann Horn <jannh@google.com>
To: Pedro Falcato <pfalcato@suse.de>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
To: Jan Kara <jack@suse.cz>
To: Miaohe Lin <linmiaohe@huawei.com>
To: Naoya Horiguchi <nao.horiguchi@gmail.com>
To: Rik van Riel <riel@surriel.com>
To: Harry Yoo <harry@kernel.org>
To: Lance Yang <lance.yang@linux.dev>
To: Kees Cook <kees@kernel.org>
To: Zi Yan <ziy@nvidia.com>
To: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Nico Pache <npache@redhat.com>
To: Ryan Roberts <ryan.roberts@arm.com>
To: Dev Jain <dev.jain@arm.com>
To: Barry Song <baohua@kernel.org>
To: Usama Arif <usama.arif@linux.dev>
To: Matthew Brost <matthew.brost@intel.com>
To: Joshua Hahn <joshua.hahnjy@gmail.com>
To: Rakie Kim <rakie.kim@sk.com>
To: Byungchul Park <byungchul@sk.com>
To: Gregory Price <gourry@gourry.net>
To: Ying Huang <ying.huang@linux.alibaba.com>
To: Alistair Popple <apopple@nvidia.com>
To: Peter Xu <peterx@redhat.com>
To: Xu Xin <xu.xin16@zte.com.cn>
To: Chengming Zhou <chengming.zhou@linux.dev>
To: Arnd Bergmann <arnd@arndb.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: ljs@kernel.org
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kselftest@vger.kernel.org
---
Lorenzo Stoakes (ARM) (15):
mm/vma: introduce VMA virtual page offset field and add helpers
mm: introduce linear_virt_page_index()
mm: abstract vma_address() and introduce vma_anon_address()
mm: update print_bad_page_map() to show virtual page index
mm: introduce and use vma_filebacked_address()
mm: propagate VMA virtual page offset on map, remap, split + merge
mm/rmap: track whether the page VMA mapped walk is anonymous
mm: introduce and use linear_folio_page_index()
mm/rmap: use virt pgoff for MAP_PRIVATE file-backed anon folios
tools/testing/vma: expand VMA merge tests to assert virt pgoff
tools/testing/selftests/mm: test virtual page offset merge behaviour
mm/vma: only permit MAP_PRIVATE /dev/zero to be mapped anonymous
mm/vma: make MAP_PRIVATE-mapped /dev/zero mappings truly anonymous
tools/testing/vma: add test to assert MAP_PRIVATE-/dev/zero is anon
tools/testing/selftests/mm: add MAP_PRIVATE-/dev/zero merge tests
drivers/char/mem.c | 8 +-
include/linux/mm.h | 74 ++++++++++++++---
include/linux/mm_types.h | 4 +
include/linux/pagemap.h | 66 +++++++++++++++
include/linux/rmap.h | 2 +
mm/huge_memory.c | 3 +-
mm/internal.h | 76 ++++++++++++-----
mm/interval_tree.c | 4 +-
mm/ksm.c | 7 +-
mm/memory-failure.c | 4 +-
mm/memory.c | 8 +-
mm/migrate.c | 6 +-
mm/mremap.c | 6 +-
mm/page_vma_mapped.c | 6 +-
mm/rmap.c | 23 +++---
mm/userfaultfd.c | 6 +-
mm/vma.c | 116 ++++++++++++++++++++------
mm/vma.h | 144 +++++++++++++++++++++++++--------
mm/vma_exec.c | 2 +-
mm/vma_init.c | 1 +
mm/vma_internal.h | 1 +
tools/testing/selftests/mm/merge.c | 161 +++++++++++++++++++++++++++++++++++++
tools/testing/vma/include/dup.h | 77 ++++++++++++++++++
tools/testing/vma/shared.c | 3 +-
tools/testing/vma/tests/merge.c | 22 ++++-
tools/testing/vma/tests/mmap.c | 49 +++++++++++
tools/testing/vma/tests/vma.c | 4 +-
tools/testing/vma/vma_internal.h | 1 +
28 files changed, 764 insertions(+), 120 deletions(-)
---
base-commit: 5093dba1014c1d7f7e247fd118f0fa8f22136046
change-id: 20260711-b4-scalable-cow-virt-pgoff-a0cc0eb14bc6
Cheers,
--
Lorenzo Stoakes (ARM) <ljs@kernel.org>
Dealing with the sashiko feedback ([0]):
Since there's not been review of this yet, I'll send a quick respin with the
valid bits of the below addressed.
Many duplicated variants of:
> vma_start_virt_pgoff() is wrong for zero-initialised VMAs prior to
> their page offset being set up
<incorrect>
Sashiko seems to be using a crystal ball to predict that I won't set this
field at the same time vma->vm_pgoff is set, which is incorrect.
Nor does it quite understand 'this feature is not switched on yet' :)
Also in the sensitive case where asserts might fail due to chicken-and-egg
'assigning to a fresh VMA', I use e.g. __vma_set_range() which doesn't perform
the assert.
Note that vma_set_range(), which is typically how the pgoff field is set, now
also sets virtual page offset.
Many duplicated variants of:
> vma->vm_file is an incorrect check for anon because of 'special' VMAs such as
> VDSO, VVAR etc. not setting this, so don't assert !vma->vm_file and assume
> it's anon.
<incorrect in practice, but dubiously valid>
These are only called in instances where a virtual variant of vma_start_pgoff(),
linear_page_index(), etc. are called, that is places where a 'special' VMA
should not have that called on it.
However for belts + braces will update the asserts to also test
vma_is_anonymous() (the 'special' VMAs have vma->vm_ops set so will be excluded
by this).
Also noticed linear_virt_page_index() was not updated to account for
MAP_PRIVATE-/dev/zero being made into pure anon, so will fix that too.
(will send fixes for this on respin)
> Does this patch miss updating the VMA merge criteria to check anon_pgoff
> contiguity?...
<incorrect>
Another case of sashiko not understanding the meaning of 'this feature
isn't enabled yet'.
I make the relevant change _when I enable the feature_ to avoid bisection
hazards.
>Can this result in a NULL pointer dereference when CONFIG_DEBUG_VM is enabled?
<correct but already addressed>
Yup :) this is valid but already reported by syzbot and already fixed, both
inline with a note to Andrew and also locally to be sent in any respin.
> Are there additional core anonymous folio creation and validation paths
> that also need this update to prevent breaking reverse mapping lookups
> when the underlying behavior changes?
<incorrect>
More of sashiko not understanding the concept of bisection hazards or the
fact the feature is not switched on yet.
> Does this change break NUMA node interleaving for mixed MAP_PRIVATE
> mappings? (9/15)
<incorrect assessment, valid that it's something that changes>
It doesn't 'break' anything, but it does affect it.
Commit 88c91dc58582 ("mempolicy: migration attempt to match interleave
nodes") already makes it clear that this is best effort and may cross VMA
boundaries, so this was already fuzzy in the sense that it's best effort
and designed to endure a varying 'base'.
So CoW'd folios of MAP_PRIVATE-mapped file-backed mappings will simply be
equivalent to the base varying.
It's also very unlikely that anything in the wild relying upon this
interleaving behaviour will be doing significant amounts of MAP_PRIVATE
CoW'ing, as in practice this is largely used for things like ELF image
relocations, etc.
I will update the commit message to mention it.
> Does this code miss asserting virt_pgoff for adjacent VMAs modified during
> the merge? (10/15)
<correct>
Trivial VMA userland test change, fixed up will send on respin.
> Does this code unintentionally overwrite the anonymous state of
> MAP_PRIVATE /dev/zero mappings? (12/15)
<correct>
Yeah it does... I deal with this correctly when I make
MAP_PRIVATE-/dev/zero mappings pure anon, but this is a bisection hazard,
so have fixed this for respin by gating on !map_is_anon() when calling
set_vma_user_defined_fields().
> Does this missing device type check in map_is_dev_zero() allow block devices
> sharing the same major/minor numbers to falsely match and lose their mapping
> data here?
<correct>
Yes :)) I added an `S_ISCHR(inode->i_mode)` check locally. I was not aware
that char and block devices have entirely separately major/minor
namespaces...
Cheers, Lorenzo
[0]:https://sashiko.dev/#/patchset/20260717-b4-scalable-cow-virt-pgoff-v1-0-cf24910ef094%40kernel.org
syzbot ci has tested the following series [v1] mm/rmap: index MAP_PRIVATE file-backed folios by virt pgoff https://lore.kernel.org/all/20260717-b4-scalable-cow-virt-pgoff-v1-0-cf24910ef094@kernel.org * [PATCH 01/15] mm/vma: introduce VMA virtual page offset field and add helpers * [PATCH 02/15] mm: introduce linear_virt_page_index() * [PATCH 03/15] mm: abstract vma_address() and introduce vma_anon_address() * [PATCH 04/15] mm: update print_bad_page_map() to show virtual page index * [PATCH 05/15] mm: introduce and use vma_filebacked_address() * [PATCH 06/15] mm: propagate VMA virtual page offset on map, remap, split + merge * [PATCH 07/15] mm/rmap: track whether the page VMA mapped walk is anonymous * [PATCH 08/15] mm: introduce and use linear_folio_page_index() * [PATCH 09/15] mm/rmap: use virt pgoff for MAP_PRIVATE file-backed anon folios * [PATCH 10/15] tools/testing/vma: expand VMA merge tests to assert virt pgoff * [PATCH 11/15] tools/testing/selftests/mm: test virtual page offset merge behaviour * [PATCH 12/15] mm/vma: only permit MAP_PRIVATE /dev/zero to be mapped anonymous * [PATCH 13/15] mm/vma: make MAP_PRIVATE-mapped /dev/zero mappings truly anonymous * [PATCH 14/15] tools/testing/vma: add test to assert MAP_PRIVATE-/dev/zero is anon * [PATCH 15/15] tools/testing/selftests/mm: add MAP_PRIVATE-/dev/zero merge tests and found the following issue: general protection fault in mapping_wrprotect_range_one Full report is available here: https://ci.syzbot.org/series/b5c827e8-78a4-494c-b925-417c34a60e85 *** general protection fault in mapping_wrprotect_range_one tree: mm-new URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git base: 5093dba1014c1d7f7e247fd118f0fa8f22136046 arch: amd64 compiler: Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6 config: https://ci.syzbot.org/builds/0d856612-f1b4-4e6e-86af-4ed3215225aa/config syz repro: https://ci.syzbot.org/findings/3484dc14-c12f-477e-b14a-6b249c47b2fd/syz_repro Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 1 UID: 0 PID: 32 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Workqueue: events fb_deferred_io_work RIP: 0010:folio_test_anon include/linux/page-flags.h:718 [inline] RIP: 0010:mapping_wrprotect_range_one+0x147/0x230 mm/rmap.c:1246 Code: 7c 24 40 49 8d 7f 28 ba 18 00 00 00 31 f6 e8 e0 2e 14 00 48 c7 84 24 80 00 00 00 01 00 00 00 49 83 c6 18 4c 89 f0 48 c1 e8 03 <42> 80 3c 20 00 74 08 4c 89 f7 e8 ea 2b 14 00 4d 8b 36 44 89 f6 83 RSP: 0018:ffffc90000a777c0 EFLAGS: 00010206 RAX: 0000000000000003 RBX: ffffc90000a779e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffc90000a77840 RBP: ffffc90000a778e0 R08: ffffc90000a7783f R09: 0000000000000000 R10: ffffc90000a77828 R11: fffff5200014ef08 R12: dffffc0000000000 R13: 1ffff9200014eefc R14: 0000000000000018 R15: ffffc90000a77800 FS: 0000000000000000(0000) GS:ffff8882a920c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f84a91e9c38 CR3: 000000000e746000 CR4: 00000000000006f0 Call Trace: <TASK> __rmap_walk_file+0x4cd/0x6a0 mm/rmap.c:3116 mapping_wrprotect_range+0x110/0x180 mm/rmap.c:1294 fb_deferred_io_work+0x15a/0x310 drivers/video/fbdev/core/fb_defio.c:399 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:folio_test_anon include/linux/page-flags.h:718 [inline] RIP: 0010:mapping_wrprotect_range_one+0x147/0x230 mm/rmap.c:1246 Code: 7c 24 40 49 8d 7f 28 ba 18 00 00 00 31 f6 e8 e0 2e 14 00 48 c7 84 24 80 00 00 00 01 00 00 00 49 83 c6 18 4c 89 f0 48 c1 e8 03 <42> 80 3c 20 00 74 08 4c 89 f7 e8 ea 2b 14 00 4d 8b 36 44 89 f6 83 RSP: 0018:ffffc90000a777c0 EFLAGS: 00010206 RAX: 0000000000000003 RBX: ffffc90000a779e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffc90000a77840 RBP: ffffc90000a778e0 R08: ffffc90000a7783f R09: 0000000000000000 R10: ffffc90000a77828 R11: fffff5200014ef08 R12: dffffc0000000000 R13: 1ffff9200014eefc R14: 0000000000000018 R15: ffffc90000a77800 FS: 0000000000000000(0000) GS:ffff8882a920c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000025d35e991000 CR3: 0000000110c34000 CR4: 00000000000006f0 ---------------- Code disassembly (best guess): 0: 7c 24 jl 0x26 2: 40 rex 3: 49 8d 7f 28 lea 0x28(%r15),%rdi 7: ba 18 00 00 00 mov $0x18,%edx c: 31 f6 xor %esi,%esi e: e8 e0 2e 14 00 call 0x142ef3 13: 48 c7 84 24 80 00 00 movq $0x1,0x80(%rsp) 1a: 00 01 00 00 00 1f: 49 83 c6 18 add $0x18,%r14 23: 4c 89 f0 mov %r14,%rax 26: 48 c1 e8 03 shr $0x3,%rax * 2a: 42 80 3c 20 00 cmpb $0x0,(%rax,%r12,1) <-- trapping instruction 2f: 74 08 je 0x39 31: 4c 89 f7 mov %r14,%rdi 34: e8 ea 2b 14 00 call 0x142c23 39: 4d 8b 36 mov (%r14),%r14 3c: 44 89 f6 mov %r14d,%esi 3f: 83 .byte 0x83 *** If these findings have caused you to resend the series or submit a separate fix, please add the following tag to your commit message: Tested-by: syzbot@syzkaller.appspotmail.com --- This report is generated by a bot. It may contain errors. syzbot ci engineers can be reached at syzkaller@googlegroups.com. To test a patch for this bug, please reply with `#syz test` (should be on a separate line). The patch should be attached to the email. Note: arguments like custom git repos and branches are not supported.
On Fri, Jul 17, 2026 at 11:47:18PM -0700, syzbot ci wrote: > syzbot ci has tested the following series > > [v1] mm/rmap: index MAP_PRIVATE file-backed folios by virt pgoff > https://lore.kernel.org/all/20260717-b4-scalable-cow-virt-pgoff-v1-0-cf24910ef094@kernel.org > * [PATCH 01/15] mm/vma: introduce VMA virtual page offset field and add helpers > * [PATCH 02/15] mm: introduce linear_virt_page_index() > * [PATCH 03/15] mm: abstract vma_address() and introduce vma_anon_address() > * [PATCH 04/15] mm: update print_bad_page_map() to show virtual page index > * [PATCH 05/15] mm: introduce and use vma_filebacked_address() > * [PATCH 06/15] mm: propagate VMA virtual page offset on map, remap, split + merge > * [PATCH 07/15] mm/rmap: track whether the page VMA mapped walk is anonymous > * [PATCH 08/15] mm: introduce and use linear_folio_page_index() > * [PATCH 09/15] mm/rmap: use virt pgoff for MAP_PRIVATE file-backed anon folios > * [PATCH 10/15] tools/testing/vma: expand VMA merge tests to assert virt pgoff > * [PATCH 11/15] tools/testing/selftests/mm: test virtual page offset merge behaviour > * [PATCH 12/15] mm/vma: only permit MAP_PRIVATE /dev/zero to be mapped anonymous > * [PATCH 13/15] mm/vma: make MAP_PRIVATE-mapped /dev/zero mappings truly anonymous > * [PATCH 14/15] tools/testing/vma: add test to assert MAP_PRIVATE-/dev/zero is anon > * [PATCH 15/15] tools/testing/selftests/mm: add MAP_PRIVATE-/dev/zero merge tests > > and found the following issue: > general protection fault in mapping_wrprotect_range_one > > Full report is available here: > https://ci.syzbot.org/series/b5c827e8-78a4-494c-b925-417c34a60e85 > > *** > > general protection fault in mapping_wrprotect_range_one > > tree: mm-new > URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git > base: 5093dba1014c1d7f7e247fd118f0fa8f22136046 > arch: amd64 > compiler: Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6 > config: https://ci.syzbot.org/builds/0d856612-f1b4-4e6e-86af-4ed3215225aa/config > syz repro: https://ci.syzbot.org/findings/3484dc14-c12f-477e-b14a-6b249c47b2fd/syz_repro > > Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] SMP KASAN PTI > KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] > CPU: 1 UID: 0 PID: 32 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT(full) > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 > Workqueue: events fb_deferred_io_work > RIP: 0010:folio_test_anon include/linux/page-flags.h:718 [inline] > RIP: 0010:mapping_wrprotect_range_one+0x147/0x230 mm/rmap.c:1246 Ah yeah, this is: VM_WARN_ON_ONCE(folio_test_anon(folio)); In mapping_wrprotect_range_one() and... this test is completely superfluous actually :) The only caller is mapping_wrprotect_range() which literally passes a NULL folio NULL to __rmap_walk_file() (with mapping_wrprotect_range_one set as the rwc->rmap_one). I'll ping on the relevant commit and ask Andrew to just drop this line. Cheers, Lorenzo > Code: 7c 24 40 49 8d 7f 28 ba 18 00 00 00 31 f6 e8 e0 2e 14 00 48 c7 84 24 80 00 00 00 01 00 00 00 49 83 c6 18 4c 89 f0 48 c1 e8 03 <42> 80 3c 20 00 74 08 4c 89 f7 e8 ea 2b 14 00 4d 8b 36 44 89 f6 83 > RSP: 0018:ffffc90000a777c0 EFLAGS: 00010206 > RAX: 0000000000000003 RBX: ffffc90000a779e0 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffc90000a77840 > RBP: ffffc90000a778e0 R08: ffffc90000a7783f R09: 0000000000000000 > R10: ffffc90000a77828 R11: fffff5200014ef08 R12: dffffc0000000000 > R13: 1ffff9200014eefc R14: 0000000000000018 R15: ffffc90000a77800 > FS: 0000000000000000(0000) GS:ffff8882a920c000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007f84a91e9c38 CR3: 000000000e746000 CR4: 00000000000006f0 > Call Trace: > <TASK> > __rmap_walk_file+0x4cd/0x6a0 mm/rmap.c:3116 > mapping_wrprotect_range+0x110/0x180 mm/rmap.c:1294 > fb_deferred_io_work+0x15a/0x310 drivers/video/fbdev/core/fb_defio.c:399 > process_one_work kernel/workqueue.c:3322 [inline] > process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 > worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 > kthread+0x388/0x470 kernel/kthread.c:436 > ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 > ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 > </TASK> > Modules linked in: > ---[ end trace 0000000000000000 ]--- > RIP: 0010:folio_test_anon include/linux/page-flags.h:718 [inline] > RIP: 0010:mapping_wrprotect_range_one+0x147/0x230 mm/rmap.c:1246 > Code: 7c 24 40 49 8d 7f 28 ba 18 00 00 00 31 f6 e8 e0 2e 14 00 48 c7 84 24 80 00 00 00 01 00 00 00 49 83 c6 18 4c 89 f0 48 c1 e8 03 <42> 80 3c 20 00 74 08 4c 89 f7 e8 ea 2b 14 00 4d 8b 36 44 89 f6 83 > RSP: 0018:ffffc90000a777c0 EFLAGS: 00010206 > RAX: 0000000000000003 RBX: ffffc90000a779e0 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffc90000a77840 > RBP: ffffc90000a778e0 R08: ffffc90000a7783f R09: 0000000000000000 > R10: ffffc90000a77828 R11: fffff5200014ef08 R12: dffffc0000000000 > R13: 1ffff9200014eefc R14: 0000000000000018 R15: ffffc90000a77800 > FS: 0000000000000000(0000) GS:ffff8882a920c000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 000025d35e991000 CR3: 0000000110c34000 CR4: 00000000000006f0 > ---------------- > Code disassembly (best guess): > 0: 7c 24 jl 0x26 > 2: 40 rex > 3: 49 8d 7f 28 lea 0x28(%r15),%rdi > 7: ba 18 00 00 00 mov $0x18,%edx > c: 31 f6 xor %esi,%esi > e: e8 e0 2e 14 00 call 0x142ef3 > 13: 48 c7 84 24 80 00 00 movq $0x1,0x80(%rsp) > 1a: 00 01 00 00 00 > 1f: 49 83 c6 18 add $0x18,%r14 > 23: 4c 89 f0 mov %r14,%rax > 26: 48 c1 e8 03 shr $0x3,%rax > * 2a: 42 80 3c 20 00 cmpb $0x0,(%rax,%r12,1) <-- trapping instruction > 2f: 74 08 je 0x39 > 31: 4c 89 f7 mov %r14,%rdi > 34: e8 ea 2b 14 00 call 0x142c23 > 39: 4d 8b 36 mov (%r14),%r14 > 3c: 44 89 f6 mov %r14d,%esi > 3f: 83 .byte 0x83 > > > *** > > If these findings have caused you to resend the series or submit a > separate fix, please add the following tag to your commit message: > Tested-by: syzbot@syzkaller.appspotmail.com > > --- > This report is generated by a bot. It may contain errors. > syzbot ci engineers can be reached at syzkaller@googlegroups.com. > > To test a patch for this bug, please reply with `#syz test` > (should be on a separate line). > > The patch should be attached to the email. > Note: arguments like custom git repos and branches are not supported.
© 2016 - 2026 Red Hat, Inc.