Re: [PATCH 00/13] fs/dax: Fix FS DAX page reference counts
Dave Chinner writes: > On Thu, Jun 27, 2024 at 10:54:15AM +1000, Alistair Popple wrote: >> FS DAX pages have always maintained their own page reference counts >> without following the normal rules for page reference counting. In >> particular pages are considered free when the refcount hits one rather >> than zero and refcounts are not added when mapping the page. >> >> Tracking this requires special PTE bits (PTE_DEVMAP) and a secondary >> mechanism for allowing GUP to hold references on the page (see >> get_dev_pagemap). However there doesn't seem to be any reason why FS >> DAX pages need their own reference counting scheme. >> >> By treating the refcounts on these pages the same way as normal pages >> we can remove a lot of special checks. In particular pXd_trans_huge() >> becomes the same as pXd_leaf(), although I haven't made that change >> here. It also frees up a valuable SW define PTE bit on architectures >> that have devmap PTE bits defined. >> >> It also almost certainly allows further clean-up of the devmap managed >> functions, but I have left that as a future improvment. >> >> This is an update to the original RFC rebased onto v6.10-rc5. Unlike >> the original RFC it passes the same number of ndctl test suite >> (https://github.com/pmem/ndctl) tests as my current development >> environment does without these patches. > > I strongly suggest running fstests on pmem devices with '-o > dax=always' mount options to get much more comprehensive fsdax test > coverage. That exercises a lot of the weird mmap corner cases that > cause problems so it would be good to actually test that nothing new > got broken in FSDAX by this patchset. Thanks Dave, I will do that and report back. I suspect it will turn up something, given Dan was seeing a crash with these patches. - Alistair > -Dave.
Re: [PATCH 00/13] fs/dax: Fix FS DAX page reference counts
On Thu, Jun 27, 2024 at 10:54:15AM +1000, Alistair Popple wrote: > FS DAX pages have always maintained their own page reference counts > without following the normal rules for page reference counting. In > particular pages are considered free when the refcount hits one rather > than zero and refcounts are not added when mapping the page. > > Tracking this requires special PTE bits (PTE_DEVMAP) and a secondary > mechanism for allowing GUP to hold references on the page (see > get_dev_pagemap). However there doesn't seem to be any reason why FS > DAX pages need their own reference counting scheme. > > By treating the refcounts on these pages the same way as normal pages > we can remove a lot of special checks. In particular pXd_trans_huge() > becomes the same as pXd_leaf(), although I haven't made that change > here. It also frees up a valuable SW define PTE bit on architectures > that have devmap PTE bits defined. > > It also almost certainly allows further clean-up of the devmap managed > functions, but I have left that as a future improvment. > > This is an update to the original RFC rebased onto v6.10-rc5. Unlike > the original RFC it passes the same number of ndctl test suite > (https://github.com/pmem/ndctl) tests as my current development > environment does without these patches. I strongly suggest running fstests on pmem devices with '-o dax=always' mount options to get much more comprehensive fsdax test coverage. That exercises a lot of the weird mmap corner cases that cause problems so it would be good to actually test that nothing new got broken in FSDAX by this patchset. -Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH 00/13] fs/dax: Fix FS DAX page reference counts
Dan Williams writes: > Alistair Popple wrote: >> >> Dan Williams writes: >> >> > Alistair Popple wrote: >> >> FS DAX pages have always maintained their own page reference counts >> >> without following the normal rules for page reference counting. In >> >> particular pages are considered free when the refcount hits one rather >> >> than zero and refcounts are not added when mapping the page. >> >> >> >> Tracking this requires special PTE bits (PTE_DEVMAP) and a secondary >> >> mechanism for allowing GUP to hold references on the page (see >> >> get_dev_pagemap). However there doesn't seem to be any reason why FS >> >> DAX pages need their own reference counting scheme. >> >> >> >> By treating the refcounts on these pages the same way as normal pages >> >> we can remove a lot of special checks. In particular pXd_trans_huge() >> >> becomes the same as pXd_leaf(), although I haven't made that change >> >> here. It also frees up a valuable SW define PTE bit on architectures >> >> that have devmap PTE bits defined. >> >> >> >> It also almost certainly allows further clean-up of the devmap managed >> >> functions, but I have left that as a future improvment. >> >> >> >> This is an update to the original RFC rebased onto v6.10-rc5. Unlike >> >> the original RFC it passes the same number of ndctl test suite >> >> (https://github.com/pmem/ndctl) tests as my current development >> >> environment does without these patches. >> > >> > Are you seeing the 'mmap.sh' test fail even without these patches? >> >> No. But I also don't see it failing with these patches :) >> >> For reference this is what I see on my test machine with or without: >> >> [1/70] Generating version.h with a custom command >> 1/13 ndctl:dax / daxdev-errors.sh SKIP 0.06s exit >> status 77 >> 2/13 ndctl:dax / multi-dax.sh SKIP 0.05s exit >> status 77 >> 3/13 ndctl:dax / sub-section.shSKIP 0.14s exit >> status 77 > > I really need to get this test built as a service as this shows a > pre-req is missing, and it's not quite fair to expect submitters to put > it all together. Ok. I didn't dig into why this was being skipped but I might if I find some time. The rest of the tests seemed more relevant anyway and turned up enough bugs with my initial implementation to keep me busy which gave me some confidence. If I'm being honest though I found the whole test setup a bit of a pain. In particular remembering you have to manually (re)build the special test versions of the modules tripped me up a few times until I updated my build scripts. But I got there in the end. >> 4/13 ndctl:dax / dax-dev OK 0.02s >> 5/13 ndctl:dax / dax-ext4.sh OK 12.97s >> 6/13 ndctl:dax / dax-xfs.shOK 12.44s >> 7/13 ndctl:dax / device-daxOK 13.40s >> 8/13 ndctl:dax / revoke-devmem FAIL 0.31s (exit >> status 250 or signal 122 SIGinvalid) >> >>> TEST_PATH=/home/apopple/ndctl/build/test >> >>> LD_LIBRARY_PATH=/home/apopple/ndctl/build/cxl/lib:/home/apopple/ndctl/build/daxctl/lib:/home/apopple/ndctl/build/ndctl/lib >> >>> NDCTL=/home/apopple/ndctl/build/ndctl/ndctl MALLOC_PERTURB_=227 >> >>> DATA_PATH=/home/apopple/ndctl/test >> >>> DAXCTL=/home/apopple/ndctl/build/daxctl/daxctl >> >>> /home/apopple/ndctl/build/test/revoke_devmem >> >> 9/13 ndctl:dax / device-dax-fio.sh OK 32.43s >> 10/13 ndctl:dax / daxctl-devices.sh SKIP 0.07s exit >> status 77 >> 11/13 ndctl:dax / daxctl-create.sh SKIP 0.04s exit >> status 77 >> 12/13 ndctl:dax / dm.sh FAIL 0.08s exit >> status 1 >> >>> MALLOC_PERTURB_=209 TEST_PATH=/home/apopple/ndctl/build/test >> >>> LD_LIBRARY_PATH=/home/apopple/ndctl/build/cxl/lib:/home/apopple/ndctl/build/daxctl/lib:/home/apopple/ndctl/build/ndctl/lib >> >>> NDCTL=/home/apopple/ndctl/build/ndctl/ndctl >> >>> DATA_PATH=/home/apopple/ndctl/test >> >>> DAXCTL=/home/apopple/ndctl/build/daxctl/daxctl >> >>> /home/apopple/ndctl/test/dm.sh >> >> 13/13 ndctl:dax / mmap.sh OK 107.57s > > I need to think through why this one might false succeed, but that can > wait until we get this series reviewed. For now my failure is stable > which allows it to be bisected. > >> >> Ok: 6 >> Expected Fail: 0 >> Fail: 2 >> Unexpected Pass:0 >> Skipped:5 >> Timeout:0 >> >> I have been using QEMU for my testing. Maybe I missed some condition in >> the unmap path though so will take another look. > > I was able to bisect to: I could have guessed that one, as it's pretty much the crux of this series given it's the one that switches everything away from pXX_devmap. That means pXX_leaf/_trans_huge will start returning true for DAX pages.
Re: [PATCH 00/13] fs/dax: Fix FS DAX page reference counts
Alistair Popple wrote: > > Dan Williams writes: > > > Alistair Popple wrote: > >> FS DAX pages have always maintained their own page reference counts > >> without following the normal rules for page reference counting. In > >> particular pages are considered free when the refcount hits one rather > >> than zero and refcounts are not added when mapping the page. > >> > >> Tracking this requires special PTE bits (PTE_DEVMAP) and a secondary > >> mechanism for allowing GUP to hold references on the page (see > >> get_dev_pagemap). However there doesn't seem to be any reason why FS > >> DAX pages need their own reference counting scheme. > >> > >> By treating the refcounts on these pages the same way as normal pages > >> we can remove a lot of special checks. In particular pXd_trans_huge() > >> becomes the same as pXd_leaf(), although I haven't made that change > >> here. It also frees up a valuable SW define PTE bit on architectures > >> that have devmap PTE bits defined. > >> > >> It also almost certainly allows further clean-up of the devmap managed > >> functions, but I have left that as a future improvment. > >> > >> This is an update to the original RFC rebased onto v6.10-rc5. Unlike > >> the original RFC it passes the same number of ndctl test suite > >> (https://github.com/pmem/ndctl) tests as my current development > >> environment does without these patches. > > > > Are you seeing the 'mmap.sh' test fail even without these patches? > > No. But I also don't see it failing with these patches :) > > For reference this is what I see on my test machine with or without: > > [1/70] Generating version.h with a custom command > 1/13 ndctl:dax / daxdev-errors.sh SKIP 0.06s exit > status 77 > 2/13 ndctl:dax / multi-dax.sh SKIP 0.05s exit > status 77 > 3/13 ndctl:dax / sub-section.shSKIP 0.14s exit > status 77 I really need to get this test built as a service as this shows a pre-req is missing, and it's not quite fair to expect submitters to put it all together. > 4/13 ndctl:dax / dax-dev OK 0.02s > 5/13 ndctl:dax / dax-ext4.sh OK 12.97s > 6/13 ndctl:dax / dax-xfs.shOK 12.44s > 7/13 ndctl:dax / device-daxOK 13.40s > 8/13 ndctl:dax / revoke-devmem FAIL 0.31s (exit > status 250 or signal 122 SIGinvalid) > >>> TEST_PATH=/home/apopple/ndctl/build/test > >>> LD_LIBRARY_PATH=/home/apopple/ndctl/build/cxl/lib:/home/apopple/ndctl/build/daxctl/lib:/home/apopple/ndctl/build/ndctl/lib > >>> NDCTL=/home/apopple/ndctl/build/ndctl/ndctl MALLOC_PERTURB_=227 > >>> DATA_PATH=/home/apopple/ndctl/test > >>> DAXCTL=/home/apopple/ndctl/build/daxctl/daxctl > >>> /home/apopple/ndctl/build/test/revoke_devmem > > 9/13 ndctl:dax / device-dax-fio.sh OK 32.43s > 10/13 ndctl:dax / daxctl-devices.sh SKIP 0.07s exit > status 77 > 11/13 ndctl:dax / daxctl-create.sh SKIP 0.04s exit > status 77 > 12/13 ndctl:dax / dm.sh FAIL 0.08s exit > status 1 > >>> MALLOC_PERTURB_=209 TEST_PATH=/home/apopple/ndctl/build/test > >>> LD_LIBRARY_PATH=/home/apopple/ndctl/build/cxl/lib:/home/apopple/ndctl/build/daxctl/lib:/home/apopple/ndctl/build/ndctl/lib > >>> NDCTL=/home/apopple/ndctl/build/ndctl/ndctl > >>> DATA_PATH=/home/apopple/ndctl/test > >>> DAXCTL=/home/apopple/ndctl/build/daxctl/daxctl > >>> /home/apopple/ndctl/test/dm.sh > > 13/13 ndctl:dax / mmap.sh OK 107.57s I need to think through why this one might false succeed, but that can wait until we get this series reviewed. For now my failure is stable which allows it to be bisected. > > Ok: 6 > Expected Fail: 0 > Fail: 2 > Unexpected Pass:0 > Skipped:5 > Timeout:0 > > I have been using QEMU for my testing. Maybe I missed some condition in > the unmap path though so will take another look. I was able to bisect to: [PATCH 10/13] fs/dax: Properly refcount fs dax pages ...I will prioritize that one in my review queue.
Re: [PATCH 00/13] fs/dax: Fix FS DAX page reference counts
Dan Williams writes: > Alistair Popple wrote: >> FS DAX pages have always maintained their own page reference counts >> without following the normal rules for page reference counting. In >> particular pages are considered free when the refcount hits one rather >> than zero and refcounts are not added when mapping the page. >> >> Tracking this requires special PTE bits (PTE_DEVMAP) and a secondary >> mechanism for allowing GUP to hold references on the page (see >> get_dev_pagemap). However there doesn't seem to be any reason why FS >> DAX pages need their own reference counting scheme. >> >> By treating the refcounts on these pages the same way as normal pages >> we can remove a lot of special checks. In particular pXd_trans_huge() >> becomes the same as pXd_leaf(), although I haven't made that change >> here. It also frees up a valuable SW define PTE bit on architectures >> that have devmap PTE bits defined. >> >> It also almost certainly allows further clean-up of the devmap managed >> functions, but I have left that as a future improvment. >> >> This is an update to the original RFC rebased onto v6.10-rc5. Unlike >> the original RFC it passes the same number of ndctl test suite >> (https://github.com/pmem/ndctl) tests as my current development >> environment does without these patches. > > Are you seeing the 'mmap.sh' test fail even without these patches? No. But I also don't see it failing with these patches :) For reference this is what I see on my test machine with or without: [1/70] Generating version.h with a custom command 1/13 ndctl:dax / daxdev-errors.sh SKIP 0.06s exit status 77 2/13 ndctl:dax / multi-dax.sh SKIP 0.05s exit status 77 3/13 ndctl:dax / sub-section.shSKIP 0.14s exit status 77 4/13 ndctl:dax / dax-dev OK 0.02s 5/13 ndctl:dax / dax-ext4.sh OK 12.97s 6/13 ndctl:dax / dax-xfs.shOK 12.44s 7/13 ndctl:dax / device-daxOK 13.40s 8/13 ndctl:dax / revoke-devmem FAIL 0.31s (exit status 250 or signal 122 SIGinvalid) >>> TEST_PATH=/home/apopple/ndctl/build/test >>> LD_LIBRARY_PATH=/home/apopple/ndctl/build/cxl/lib:/home/apopple/ndctl/build/daxctl/lib:/home/apopple/ndctl/build/ndctl/lib >>> NDCTL=/home/apopple/ndctl/build/ndctl/ndctl MALLOC_PERTURB_=227 >>> DATA_PATH=/home/apopple/ndctl/test >>> DAXCTL=/home/apopple/ndctl/build/daxctl/daxctl >>> /home/apopple/ndctl/build/test/revoke_devmem 9/13 ndctl:dax / device-dax-fio.sh OK 32.43s 10/13 ndctl:dax / daxctl-devices.sh SKIP 0.07s exit status 77 11/13 ndctl:dax / daxctl-create.sh SKIP 0.04s exit status 77 12/13 ndctl:dax / dm.sh FAIL 0.08s exit status 1 >>> MALLOC_PERTURB_=209 TEST_PATH=/home/apopple/ndctl/build/test >>> LD_LIBRARY_PATH=/home/apopple/ndctl/build/cxl/lib:/home/apopple/ndctl/build/daxctl/lib:/home/apopple/ndctl/build/ndctl/lib >>> NDCTL=/home/apopple/ndctl/build/ndctl/ndctl >>> DATA_PATH=/home/apopple/ndctl/test >>> DAXCTL=/home/apopple/ndctl/build/daxctl/daxctl >>> /home/apopple/ndctl/test/dm.sh 13/13 ndctl:dax / mmap.sh OK 107.57s Ok: 6 Expected Fail: 0 Fail: 2 Unexpected Pass:0 Skipped:5 Timeout:0 I have been using QEMU for my testing. Maybe I missed some condition in the unmap path though so will take another look. > I see this with the patches, will try without in the morning. > > EXT4-fs (pmem0): unmounting filesystem 26ea1463-343a-464f-9f16-91cb176dbdc7. > XFS (pmem0): Mounting V5 Filesystem 554953fd-c9f4-460f-bc37-f43979986b68 > XFS (pmem0): Ending clean mount > Oops: general protection fault, probably for non-canonical address > 0xdead0518: 00 > T SMP PTI > CPU: 15 PID: 1295 Comm: mmap Tainted: G OEN 6.10.0-rc5+ #261 > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS > edk2-20240524-3.fc40 05/24/2024 > RIP: 0010:folio_mark_dirty+0x25/0x60 > Code: 90 90 90 90 90 0f 1f 44 00 00 53 48 89 fb e8 22 18 02 00 48 85 c0 74 > 26 48 89 c7 48 > 0 02 00 74 05 f0 80 63 02 fd <48> 8b 87 18 01 00 00 48 89 de 5b 48 8b 40 18 > e9 77 90 c0 00 > RSP: 0018:b073022f7b08 EFLAGS: 00010246 > RAX: 00482000 RBX: d0d005000300 RCX: 0440 > RDX: RSI: 7f400620 RDI: dead0400 > RBP: R08: 9a4b04504a30 R09: 000f > R10: d0d005000300 R11: R12: 7f400620 > R13: 9a4b7c96c000 R14: 9a4b7daba440 R15: b073022f7cb0 > FS: 7f4046351740() GS:9a4d7778() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7f40461ff000 CR3: 00027aea6000 CR4: 06f0 > DR0:
Re: [PATCH 00/13] fs/dax: Fix FS DAX page reference counts
Alistair Popple wrote: > FS DAX pages have always maintained their own page reference counts > without following the normal rules for page reference counting. In > particular pages are considered free when the refcount hits one rather > than zero and refcounts are not added when mapping the page. > > Tracking this requires special PTE bits (PTE_DEVMAP) and a secondary > mechanism for allowing GUP to hold references on the page (see > get_dev_pagemap). However there doesn't seem to be any reason why FS > DAX pages need their own reference counting scheme. > > By treating the refcounts on these pages the same way as normal pages > we can remove a lot of special checks. In particular pXd_trans_huge() > becomes the same as pXd_leaf(), although I haven't made that change > here. It also frees up a valuable SW define PTE bit on architectures > that have devmap PTE bits defined. > > It also almost certainly allows further clean-up of the devmap managed > functions, but I have left that as a future improvment. > > This is an update to the original RFC rebased onto v6.10-rc5. Unlike > the original RFC it passes the same number of ndctl test suite > (https://github.com/pmem/ndctl) tests as my current development > environment does without these patches. Are you seeing the 'mmap.sh' test fail even without these patches? I see this with the patches, will try without in the morning. EXT4-fs (pmem0): unmounting filesystem 26ea1463-343a-464f-9f16-91cb176dbdc7. XFS (pmem0): Mounting V5 Filesystem 554953fd-c9f4-460f-bc37-f43979986b68 XFS (pmem0): Ending clean mount Oops: general protection fault, probably for non-canonical address 0xdead0518: 00 T SMP PTI CPU: 15 PID: 1295 Comm: mmap Tainted: G OEN 6.10.0-rc5+ #261 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20240524-3.fc40 05/24/2024 RIP: 0010:folio_mark_dirty+0x25/0x60 Code: 90 90 90 90 90 0f 1f 44 00 00 53 48 89 fb e8 22 18 02 00 48 85 c0 74 26 48 89 c7 48 0 02 00 74 05 f0 80 63 02 fd <48> 8b 87 18 01 00 00 48 89 de 5b 48 8b 40 18 e9 77 90 c0 00 RSP: 0018:b073022f7b08 EFLAGS: 00010246 RAX: 00482000 RBX: d0d005000300 RCX: 0440 RDX: RSI: 7f400620 RDI: dead0400 RBP: R08: 9a4b04504a30 R09: 000f R10: d0d005000300 R11: R12: 7f400620 R13: 9a4b7c96c000 R14: 9a4b7daba440 R15: b073022f7cb0 FS: 7f4046351740() GS:9a4d7778() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f40461ff000 CR3: 00027aea6000 CR4: 06f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: ? __die_body.cold+0x19/0x26 ? die_addr+0x38/0x60 ? exc_general_protection+0x143/0x420 ? asm_exc_general_protection+0x22/0x30 ? folio_mark_dirty+0x25/0x60 ? folio_mark_dirty+0xe/0x60 unmap_page_range+0xea5/0x1550 unmap_vmas+0xf8/0x1e0 unmap_region.constprop.0+0xd7/0x150 ? lock_is_held_type+0xd5/0x130 do_vmi_align_munmap.isra.0+0x3f4/0x580 ? mas_walk+0x101/0x1b0 __vm_munmap+0xa6/0x170 __x64_sys_munmap+0x17/0x20 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e $ faddr2line vmlinux folio_mark_dirty+0x25 folio_mark_dirty+0x25/0x58: folio_mark_dirty at mm/page-writeback.c:2860
[PATCH 00/13] fs/dax: Fix FS DAX page reference counts
FS DAX pages have always maintained their own page reference counts without following the normal rules for page reference counting. In particular pages are considered free when the refcount hits one rather than zero and refcounts are not added when mapping the page. Tracking this requires special PTE bits (PTE_DEVMAP) and a secondary mechanism for allowing GUP to hold references on the page (see get_dev_pagemap). However there doesn't seem to be any reason why FS DAX pages need their own reference counting scheme. By treating the refcounts on these pages the same way as normal pages we can remove a lot of special checks. In particular pXd_trans_huge() becomes the same as pXd_leaf(), although I haven't made that change here. It also frees up a valuable SW define PTE bit on architectures that have devmap PTE bits defined. It also almost certainly allows further clean-up of the devmap managed functions, but I have left that as a future improvment. This is an update to the original RFC rebased onto v6.10-rc5. Unlike the original RFC it passes the same number of ndctl test suite (https://github.com/pmem/ndctl) tests as my current development environment does without these patches. I am not intimately familiar with the FS DAX code so would appreciate some careful review there. In particular I have not given any thought at all to CONFIG_FS_DAX_LIMITED. Signed-off-by: Alistair Popple Alistair Popple (13): mm/gup.c: Remove redundant check for PCI P2PDMA page pci/p2pdma: Don't initialise page refcount to one fs/dax: Refactor wait for dax idle page fs/dax: Add dax_page_free callback mm: Allow compound zone device pages mm/memory: Add dax_insert_pfn huge_memory: Allow mappings of PUD sized pages huge_memory: Allow mappings of PMD sized pages gup: Don't allow FOLL_LONGTERM pinning of FS DAX pages fs/dax: Properly refcount fs dax pages huge_memory: Remove dead vmf_insert_pXd code mm: Remove pXX_devmap callers mm: Remove devmap related functions and page table bits Documentation/mm/arch_pgtable_helpers.rst | 6 +- arch/arm64/Kconfig| 1 +- arch/arm64/include/asm/pgtable-prot.h | 1 +- arch/arm64/include/asm/pgtable.h | 24 +-- arch/powerpc/Kconfig | 1 +- arch/powerpc/include/asm/book3s/64/hash-4k.h | 6 +- arch/powerpc/include/asm/book3s/64/hash-64k.h | 7 +- arch/powerpc/include/asm/book3s/64/pgtable.h | 52 + arch/powerpc/include/asm/book3s/64/radix.h| 14 +- arch/powerpc/mm/book3s64/hash_pgtable.c | 3 +- arch/powerpc/mm/book3s64/pgtable.c| 8 +- arch/powerpc/mm/book3s64/radix_pgtable.c | 5 +- arch/powerpc/mm/pgtable.c | 2 +- arch/x86/Kconfig | 1 +- arch/x86/include/asm/pgtable.h| 50 + arch/x86/include/asm/pgtable_types.h | 5 +- drivers/dax/device.c | 12 +- drivers/dax/super.c | 2 +- drivers/gpu/drm/nouveau/nouveau_dmem.c| 2 +- drivers/nvdimm/pmem.c | 9 +- drivers/pci/p2pdma.c | 4 +- fs/dax.c | 204 +++- fs/ext4/inode.c | 5 +- fs/fuse/dax.c | 4 +- fs/fuse/virtio_fs.c | 8 +- fs/userfaultfd.c | 2 +- fs/xfs/xfs_inode.c| 4 +- include/linux/dax.h | 11 +- include/linux/huge_mm.h | 17 +- include/linux/memremap.h | 23 +- include/linux/migrate.h | 2 +- include/linux/mm.h| 40 +--- include/linux/page-flags.h| 6 +- include/linux/pfn_t.h | 20 +-- include/linux/pgtable.h | 21 +-- include/linux/rmap.h | 14 +- lib/test_hmm.c| 2 +- mm/Kconfig| 4 +- mm/debug_vm_pgtable.c | 59 +- mm/gup.c | 178 +-- mm/hmm.c | 12 +- mm/huge_memory.c | 248 +++ mm/internal.h | 2 +- mm/khugepaged.c | 2 +- mm/mapping_dirty_helpers.c| 4 +- mm/memory-failure.c | 6 +- mm/memory.c | 114 ++--- mm/memremap.c | 38 +--- mm/migrate_device.c | 6 +- mm/mlock.c| 2 +- mm/mm_init.c | 5 +- mm/mprotect.c | 2
