Martin Pieuchot <mpi@grenadille.net> wrote:

> 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'?

Most likely way will be queue the output, and have something in normal
context get caught up.  Not exactly like bpf does it, but similar in
principle I guess.