[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/55282: Race around UVM swapdum_getsdp() reported by KASAN
>Synopsis: Race around UVM swapdum_getsdp() reported by KASAN
>Arrival-Date: Thu May 21 14:50:00 +0000 2020
>Originator: Jaromir Dolecek
>Release: NetBSD 9.99.60
Kernel compiled with DIAGNOSTIC, DEBUG, LOCKDEBUG, KASAN, run under
[ 459.8858950] ASan: Unauthorized Access In 0xffffffff8065df50: Addr 0xffff940000b8f4c0 [4 bytes, read, PoolUseAfterFree]
[ 459.9059859] #0 0xffffffff8065df50 in uvm_swap_io <netbsd>
[ 459.9157787] #1 0xffffffff8065498f in swapcluster_flush.part.2 <netbsd>
[ 459.9157787] #2 0xffffffff80655726 in uvm_pageout <netbsd>
[ 459.9157787] #3 0xffffffff80208747 in lwp_trampoline <netbsd>
gdb claims this is on line uvm_swap.c:1181, which is this code:
KDASSERT(swapdrum_getsdp(s) == sdp);
Reading code, it seems that swapdrum_getsdp() should be always called with
uvm_swap_data_lock held, as is done e.g. in swstrategy().
Not clear, happens under QEMU with 'slow' devices, no idea
if slow disk device is required to trigger this.
Lock uvm_swap_data_lock around calls to swapdum_getsdp()?
Main Index |
Thread Index |