What is wrong with dtrace's stack()?

[Lev Serebryakov]

On 22.10.2018 0:47, Alan Somers wrote:

>      I see a lot of stacks like this:
> 
>      kernel`lock_delay+0x42
>      kernel`soo_write+0x33
>      kernel`dofilewrite+0x79
>      kernel`sys_write+0xc3
>      kernel`amd64_syscall+0x332
>      kernel`0xffffffff8086c87d
> 
>      But event sosend() doesn't call lock_delay(), so it is impossible to
>     understand why do lock_delay() seen 41932 times in 60 seconds at top
>     of the
>     stack. Where are all call stack?! All these functions could not be
>     inlined,
>     as sosend() is located in other translation unit and it calls
>     function by
>     pointer, this call could not be inlined too.
> 
> 
> If you're sure that the function isn't inlined, then it might be using
> the tail-call optimization instead.  That would also explain the missing
> stack frames, too.
  I know about inlining at TCO, but it is not the case for sure. Problem
is, they can not be inlined it TCO'ed.

  soo_wrtite() calls sosend():

error = sosend(so, 0, uio, 0, 0, 0, uio->uio_td);
if (error == EPIPE && (so->so_options & SO_NOSIGPIPE) == 0) {
	PROC_LOCK(uio->uio_td->td_proc);
	tdsignal(uio->uio_td, SIGPIPE);
	PROC_UNLOCK(uio->uio_td->td_proc);
}

 It could not be TCO'ed and sosend() is in another translation unit, so
it could not be inlined.

sosend() calls protocol-specific handler via function pointer, so it
should be true call:

CURVNET_SET(so->so_vnet);
if (!SOLISTENING(so))
	error = so->so_proto->pr_usrreqs->pru_sosend(so, addr, uio,
	    top, control, flags, td);
else {
	m_freem(top);
	m_freem(control);
	error = ENOTCONN;
}
CURVNET_RESTORE();
return (error);

  These frames MUST be here...

> If you can manually narrow the options down to a few
> possible callers, then you could try adding a few SDT probes.  That's
> what I usually do in cases like this.  Or, for static functions that are
> inlined, you can remove the static keyword to (usually) prevent the
> inlining.
  Narrowing all paths, which leads to very generic lock_delay()... Uh-oh.

-- 
// Lev Serebryakov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20181022/03f395bf/attachment.sig>