Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

panic: VERIFY(vm_page_none_valid(ma[i])) failed #16810

Closed
phoatfreebsd opened this issue Nov 26, 2024 · 2 comments · Fixed by #16834
Closed

panic: VERIFY(vm_page_none_valid(ma[i])) failed #16810

phoatfreebsd opened this issue Nov 26, 2024 · 2 comments · Fixed by #16834
Labels
Type: Defect Incorrect behavior (e.g. crash, hang)

Comments

@phoatfreebsd
Copy link

System information

Type Version/Name
Distribution Name FreeBSD current
Distribution Version
Kernel Version main-bde575b273eeb
Architecture amd64
OpenZFS Version zfs-2.3.99-64-FreeBSD_g1c9a4c8cb zfs-kmod-2.3.99-92-FreeBSD_gd0a91b9f8

Describe the problem you're observing

Stress test with a KASAN kernel build

Describe how to reproduce the problem

cd /usr/src/tools/test/stress2/misc; ./all.sh -o zfs11.sh

Include any warning/errors/backtraces from the system logs

20241126 01:32:46 all (64/676): zfs11.sh
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
panic: VERIFY(vm_page_none_valid(ma[i])) failed

cpuid = 4
time = 1732581173
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0xa5/frame 0xfffffe014d3201f0
kdb_backtrace() at kdb_backtrace+0xc6/frame 0xfffffe014d320350
vpanic() at vpanic+0x214/frame 0xfffffe014d3204f0
spl_panic() at spl_panic+0xa9/frame 0xfffffe014d3205b0
zfs_freebsd_getpages() at zfs_freebsd_getpages+0x36a/frame 0xfffffe014d320740
VOP_GETPAGES_APV() at VOP_GETPAGES_APV+0x91/frame 0xfffffe014d320770
vnode_pager_getpages() at vnode_pager_getpages+0x12d/frame 0xfffffe014d320870
vm_pager_get_pages() at vm_pager_get_pages+0xae/frame 0xfffffe014d3208d0
vm_fault() at vm_fault+0xedf/frame 0xfffffe014d320be0
vm_fault_trap() at vm_fault_trap+0x95/frame 0xfffffe014d320c30
trap_pfault() at trap_pfault+0x3a6/frame 0xfffffe014d320d50
trap() at trap+0x817/frame 0xfffffe014d320f30
calltrap() at calltrap+0x8/frame 0xfffffe014d320f30
--- trap 0xc, rip = 0xdebcd7291cc, rsp = 0xdf3ee63a9f0, rbp = 0xdf3ee63aa50 ---
KDB: enter: panic
[ thread pid 47272 tid 101315 ]
Stopped at      kdb_enter+0x34: movq    $0,0x20f2991(%rip)
db> x/s version
version:        FreeBSD 15.0-CURRENT #0 main-n273839-bde575b273eeb-dirty: Mon Nov 25 21:09:13 CET 2024\012    pho@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/PHO-KASAN\012
db> 
``
@phoatfreebsd phoatfreebsd added the Type: Defect Incorrect behavior (e.g. crash, hang) label Nov 26, 2024
@amotin
Copy link
Member

amotin commented Dec 2, 2024

@markjdb ^^^

@markjdb
Copy link
Contributor

markjdb commented Dec 3, 2024

Thanks Peter. I believe the assertion is incorrect - it's only true during the first iteration of the loop, and when I reproduced the crash locally we were on the second iteration. I'll post a patch shortly.

markjdb added a commit to markjdb/zfs that referenced this issue Dec 3, 2024
The pages in the array may become valid after this initial unbusying,
so the assertion only holds during the first iteration of the outer
loop.

Later in zfs_getpages(), the dmu_read_pages() loop handles already-valid
pages.  Just drop the assertion, it's not terribly useful.

Fixes openzfs#16810

Sponsored-by: Klara, Inc.
Reported-by: Peter Holm <pho@FreeBSD.org>
Signed-off-by: Mark Johnston <markj@FreeBSD.org>
@amotin amotin closed this as completed in 0e020bf Dec 4, 2024
behlendorf pushed a commit to behlendorf/zfs that referenced this issue Dec 5, 2024
The pages in the array may become valid after this initial unbusying,
so the assertion only holds during the first iteration of the outer
loop.

Later in zfs_getpages(), the dmu_read_pages() loop handles already-valid
pages.  Just drop the assertion, it's not terribly useful.

Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Brian Atkinson <batkinson@lanl.gov>
Reported-by: Peter Holm <pho@FreeBSD.org>
Signed-off-by: Mark Johnston <markj@FreeBSD.org>
Sponsored-by: Klara, Inc.
Closes openzfs#16810
Closes openzfs#16834
lundman pushed a commit to openzfsonwindows/openzfs that referenced this issue Jan 26, 2025
The pages in the array may become valid after this initial unbusying,
so the assertion only holds during the first iteration of the outer
loop.

Later in zfs_getpages(), the dmu_read_pages() loop handles already-valid
pages.  Just drop the assertion, it's not terribly useful.

Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Brian Atkinson <batkinson@lanl.gov>
Reported-by: Peter Holm <pho@FreeBSD.org>
Signed-off-by: Mark Johnston <markj@FreeBSD.org>
Sponsored-by: Klara, Inc.
Closes openzfs#16810
Closes openzfs#16834
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Defect Incorrect behavior (e.g. crash, hang)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants