Re: Kernel panic related to pipe

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Mon, 5 Oct 2026 12:02:16 +0200
> From: Martin Husemann <martin%duskware.de@localhost>
> 
> Taylor: it crashes in the
> 
> 	KASSERT(mutex_owned(pipe->pipe_lock));
> 
> with a NULL deref as apparently "pipe" is NULL.
> 
> [ 1791.9954315] uvm_fault(0xffff82fd6dde1c80, 0x0, 1) -> e
> [ 1792.0554307] fatal page fault in supervisor mode
> [ 1792.1054306] trap type 6 code 0 rip 0xffffffff80ed0d8f cs 0x8 rflags 0x10286$
> [ 1792.2354293] curlwp 0xffff82fc97ee3400 pid 10053.10053 lowest kstack 0xffffa$
> [uvermn_efla:u ltp(ag0xef ffafuf8l2tf ct3raccp,f4 c90od0,e =00
>  Stopped in pid 10053.10053 (nbmake) at  netbsd:pipeselwakeup+0x13:      movq  $
> 0(%rdi),%rdi
> pipeselwakeup() at netbsd:pipeselwakeup+0x13  
> pipe_read() at netbsd:pipe_read+0x253
> dofileread() at netbsd:dofileread+0xad
> sys_read() at netbsd:sys_read+0x49

Can you please try again with the latest sys_pipe.c (1.186)?

I haven't been able to reproduce this in a VM but maybe my tests don't
have enough parallelism to hit the problem; I hypothesize that it is a
use-after-free arising from the difficult synchronization between
pipe_read, pipe_write, and pipe_close, and I committed a candidate fix
for that use-after-free issue.