From: Martin Pieuchot Subject: Re: Fix nested copy(9) for btrace's ustack To: Theo de Raadt Cc: Christian Ludwig , tech@openbsd.org Date: Mon, 10 Mar 2025 20:52:23 +0100 On 07/03/25(Fri) 09:14, Theo de Raadt wrote: > It seems like a huge change in behaviour to have nested operations here. > > I'm suspicious that it only requires these two changes, and anticipate > the entire mechanism can't be moved from singular to nested with just > this. That prompts the questions: How did we get here, and is this > viable recursion??? I strongly suspect no. I believe we get there because some ddb/dtrace code is now relying on copyin(9) which overrides `pcb_onfault'. I don't think using copyin(9) inside ddb/dtrace code is viable. We cannot inspect the kernel it we rely on its APIs. Christian, could we use a ddb/dtrace version of copyin(9) that would not mess with `pcb_onfault'?