svn commit: r364946 - head/sys/kern

[Ian Lepore]

On Sat, 2020-08-29 at 05:02 -0600, Warner Losh wrote:
> >
> > sbuf_cpy() at _gone_in_dev+0x560
> >          pc = 0xffff0000003c1ff0  lr = 0xffff0000003a9078
> >          sp = 0xffff00006f21a510  fp = 0xffff00006f21a570
> >
> > _gone_in_dev() at sbuf_new_for_sysctl+0x170
> >          pc = 0xffff0000003a9078  lr = 0xffff00000037c1a8
> >          sp = 0xffff00006f21a580  fp = 0xffff00006f21a5a0
> >
> > sbuf_new_for_sysctl() at kernel_sysctl+0x36c
> >          pc = 0xffff00000037c1a8  lr = 0xffff00000037b63c
> >          sp = 0xffff00006f21a5b0  fp = 0xffff00006f21a630
> >
> 
> This traceback is all kinds of crazy. sbuf_new_for_sysctl doesn't call
> _gone_in_dev(), which doesn't do sbuf stuff at all. And neither does it
> call sbuf_cpy(). Though I get a crash that looks like:
> Tracing pid 66442 tid 101464 td 0xfffffe02f47b7c00
> kdb_enter() at kdb_enter+0x37/frame 0xfffffe02f4ae3740
> vpanic() at vpanic+0x19e/frame 0xfffffe02f4ae3790
> panic() at panic+0x43/frame 0xfffffe02f4ae37f0
> sbuf_clear() at sbuf_clear+0xac/frame 0xfffffe02f4ae3800
> sbuf_cpy() at sbuf_cpy+0x5a/frame 0xfffffe02f4ae3820
> device_sysctl_handler() at device_sysctl_handler+0x133/frame
> 0xfffffe02f4ae38a0
> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame
> 0xfffffe02f4ae38f0
> sysctl_root() at sysctl_root+0x20a/frame 0xfffffe02f4ae3970
> userland_sysctl() at userland_sysctl+0x17d/frame 0xfffffe02f4ae3a20
> sys___sysctl() at sys___sysctl+0x5f/frame 0xfffffe02f4ae3ad0
> amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe02f4ae3bf0
> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe02f4ae3bf0
> --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x80042d50a, rsp =
> 0x7fffffffd458, rbp = 0x7fffffffd490 ---
> 
> on a sysctl -a which I think makes more sense...  I'll see if I can track
> it down... I think it's because sbuf_cpy does an unconditional clear, which
> triggers this assert, which is likely bogus for this case. sbuf_cat doesn't
> seem to have this issue... I'll confirm and commit.
> 
> Warner

This kind of crazy happens when the traceback just reports the name of
the nearest global symbol it can find because static or other local
symbols aren't available to it.  The clue that that's what's going on
tends to be in things like:

  sbuf_cpy() at _gone_in_dev+0x560

It's almost certain that _gone_in_dev() isn't a big enough function
that an offset of 0x560 is still in that function, so it's really in
some static function that got linked nearby but the symbols for statics
got stripped.  Usually you can use addr2line on kernel.full to get the
real names for the pc and lr values.

-- Ian