Rebooting after removing a swap device caused a panic panic: vm_page_assert_unbusied: page 0xffffa000e7d451e0 busy_lock 0xd6ba02c2 owned by me (0xffff0000d6ba02c0) @ /usr/src/sys/vm/vm_object.c:897 Longer version: I unplugged a USB drive from an arm64 SBC (RockPro64). It contained the swap device so the system was not happy. I plugged it back in but the system did not understand that the device I plugged in was the same device I removed. I could not "swapoff" to get the data off the drive. I rebooted and got the panic above. I am running a recent 15.0-CURRENT based on c6a6ec85a70314b8270e25a06e77e2e7c95c7055. No crash dump. The kernel debugger hung when I asked it to dump. It probably could not figure out where to dump. Here is the text on the console: [unplugged swap device] # swapinfo Device 1K-blocks Used Avail Capacity /dev/#C:0xb2 8069120 26852 8042268 0% [plugged device back in] # swapinfo Device 1K-blocks Used Avail Capacity /dev/#C:0xb2 8069120 26852 8042268 0% root@variegatus:~ # reboot Mar 6 20:03:25 variegatus reboot[80617]: rebooted by root swap_pager: I/O error - pagein failed; blkno 3033084,size 4096, error 6 vm_fault: pager read error, pid 50404 (sshd) swap_pager: I/O error - pagein failed; blkno 3033109,size 4096, error 6 vm_fault: pager read error, pid 50402 (sshd) swap_pager: I/O error - pagein failed; blkno 2793364,size 8192, error 6 swap_pager: I/O error - pagein failed; blkno 2793378,size 8192, error 6 swap_pager: I/O error - pagein failed; blkno 2793340,size 8192, error 6 vm_fault: pager read error, pid 2600 (getty) vm_fault: pager read error, pid 2602 (getty) swap_pager: I/O error - pagein failed; blkno 2797106,size 8192, error 6 swap_pager: I/O error - pagein failed; blkno 2793206,size 8192, error 6 swap_pager: I/O error - pagein failed; blkno 2793359,size 20480, error 6 vm_fault: pager read error, pid 87805 (sshd) vm_fault: pager read error, pid 2599 (getty) vm_fault: pager read error, pid 2601 (getty) vm_fault: pager read error, pid 2600 (getty) panic: vm_page_assert_unbusied: page 0xffffa000e7d451e0 busy_lock 0xd6ba02c2 owned by me (0xffff0000d6ba02c0) @ /usr/src/sys/vm/vm_object.c:897 cpuid = 4 time = 1709755406 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x38 vpanic() at vpanic+0x1a8 panic() at panic+0x48 vm_object_terminate() at vm_object_terminate+0x2a4 vm_object_deallocate() at vm_object_deallocate+0x2cc vm_map_process_deferred() at vm_map_process_deferred+0xa8 vm_map_remove() at vm_map_remove+0xc8 vmspace_exit() at vmspace_exit+0x138 exit1() at exit1+0x4e8 sigexit() at sigexit+0x154 postsig() at postsig+0x11c ast_sig() at ast_sig+0x128 ast_handler() at ast_handler+0xc8 ast() at ast+0x24 handle_el0_sync() at handle_el0_sync+0x6c --- exception, esr 0x56000000 KDB: enter: panic [ thread pid 87805 tid 100300 ]
If an error occured during page-in, swap pager leaves the page invalid and busy. This is reasonable approach. If something is paged out, and we cannot page it in, system is going to be unhappy. I am not sure it would help add more code that is almost never executed and very hard to test, to try to slightly soften the consequences.
(In reply to Konstantin Belousov from comment #1) I think there is still a bug in that swap_pager_iodone() does not unbusy readahead/behind pages in the error case.
https://reviews.freebsd.org/D44646
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4696650782e2e5cf7ae5823f1de04550c05b5b75 commit 4696650782e2e5cf7ae5823f1de04550c05b5b75 Author: Mark Johnston <markj@FreeBSD.org> AuthorDate: 2024-04-08 13:02:48 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2024-04-08 13:02:48 +0000 swap_pager: Unbusy readahead pages after an I/O error The swap pager itself allocates readahead pages, so should take care to unbusy them after a read error, just as it does in the non-error case. PR: 277538 Reviewed by: olce, dougm, alc, kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D44646 sys/vm/swap_pager.c | 3 +++ 1 file changed, 3 insertions(+)
I believe that this commit will prevent that particular panic, but indeed, we're not going to recover well from a swap device being removed.
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5128c8948b4e56d20dfd623aeb030fb39c8f95b0 commit 5128c8948b4e56d20dfd623aeb030fb39c8f95b0 Author: Mark Johnston <markj@FreeBSD.org> AuthorDate: 2024-04-08 13:02:48 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2024-04-15 14:05:13 +0000 swap_pager: Unbusy readahead pages after an I/O error The swap pager itself allocates readahead pages, so should take care to unbusy them after a read error, just as it does in the non-error case. PR: 277538 Reviewed by: olce, dougm, alc, kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D44646 (cherry picked from commit 4696650782e2e5cf7ae5823f1de04550c05b5b75) sys/vm/swap_pager.c | 3 +++ 1 file changed, 3 insertions(+)
Closing this since the bug causing the panic is fixed, at least.