Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

stack_save_td needed for procstat #8

Open
emaste opened this issue Feb 9, 2015 · 1 comment
Open

stack_save_td needed for procstat #8

emaste opened this issue Feb 9, 2015 · 1 comment

Comments

@emaste
Copy link
Member

emaste commented Feb 9, 2015

root@:/usr/src # procstat -kka
PID TID COMM TDNAME KSTACK
panic: stack_save_td
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x30
pc = 0xffffff80003c41a8 lr = 0xffffff8000014b08
sp = 0xffffff8056fc14e0 fp = 0xffffff8056fc1610

db_trace_self_wrapper() at vpanic+0xc8
pc = 0xffffff8000014b08 lr = 0xffffff800015445c
sp = 0xffffff8056fc1620 fp = 0xffffff8056fc1690

vpanic() at panic+0x4c
pc = 0xffffff800015445c lr = 0xffffff800015456c
sp = 0xffffff8056fc16a0 fp = 0xffffff8056fc1720

panic() at stack_save_td+0x18
pc = 0xffffff800015456c lr = 0xffffff80003cf84c
sp = 0xffffff8056fc1730 fp = 0xffffff8056fc1730

stack_save_td() at sysctl_kern_proc_kstack+0x208
pc = 0xffffff80003cf84c lr = 0xffffff8000146cac
sp = 0xffffff8056fc1740 fp = 0xffffff8056fc1800

sysctl_kern_proc_kstack() at sysctl_root_handler_locked+0xe4
pc = 0xffffff8000146cac lr = 0xffffff80001609e4
sp = 0xffffff8056fc1810 fp = 0xffffff8056fc1850

sysctl_root_handler_locked() at sysctl_root+0x180
pc = 0xffffff80001609e4 lr = 0xffffff8000160110
sp = 0xffffff8056fc1860 fp = 0xffffff8056fc1890

sysctl_root() at userland_sysctl+0x1c4
pc = 0xffffff8000160110 lr = 0xffffff800016074c
sp = 0xffffff8056fc18a0 fp = 0xffffff8056fc1950

userland_sysctl() at sys___sysctl+0x68
pc = 0xffffff800016074c lr = 0xffffff8000160548
sp = 0xffffff8056fc1960 fp = 0xffffff8056fc19f0

sys___sysctl() at do_el0_sync+0x30c
pc = 0xffffff8000160548 lr = 0xffffff80003d02c4
sp = 0xffffff8056fc1a00 fp = 0xffffff8056fc1aa0

do_el0_sync() at handle_el0_sync+0x54
pc = 0xffffff80003d02c4 lr = 0xffffff80003c51b0
sp = 0xffffff8056fc1ab0 fp = 0x7ffffff610

handle_el0_sync() at 0x40466068
pc = 0xffffff80003c51b0 lr = 0x40466068
sp = 0x7ffffff620 fp = 0x7ffffff660

$d.6() at 0x403198
pc = 0x40466068 lr = 0x00403198
sp = 0x7ffffff670 fp = 0x7ffffffb00

$d.6() at 0x401cd8
pc = 0x00403198 lr = 0x00401cd8
sp = 0x7ffffffb10 fp = 0x7ffffffb90

$d.6() at 0x401880
pc = 0x00401cd8 lr = 0x00401880
sp = 0x7ffffffba0 fp = 0x7ffffffbd0

$d.6() at 0x404183d0
pc = 0x00401880 lr = 0x404183d0
sp = 0x7ffffffbe0 fp = 0x00000000

KDB: enter: panic
[ thread pid 12382 tid 100052 ]
Stopped at kdb_enter+0x6c:
db>
@emaste
Copy link
Member Author

emaste commented Apr 22, 2015

panic gone as of r281850 https://svnweb.freebsd.org/changeset/base/281850
but implementation is still needed

emaste pushed a commit that referenced this issue Jul 2, 2019
@bu7cher
Rework r348303 to reduce the time of holding global BPF lock.
4b4eed4 
It appeared that using NET_EPOCH_WAIT() while holding global BPF lock
can lead to another panic:

spin lock 0xfffff800183c9840 (turnstile lock) held by 0xfffff80018e2c5a0 (tid 100325) too long
panic: spin lock held too long
...
#0  sched_switch (td=0xfffff80018e2c5a0, newtd=0xfffff8000389e000, flags=<optimized out>) at /usr/src/sys/kern/sched_ule.c:2133
#1  0xffffffff80bf9912 in mi_switch (flags=256, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:439
#2  0xffffffff80c21db7 in sched_bind (td=<optimized out>, cpu=<optimized out>) at /usr/src/sys/kern/sched_ule.c:2704
#3  0xffffffff80c34c33 in epoch_block_handler_preempt (global=<optimized out>, cr=0xfffffe00005a1a00, arg=<optimized out>)
    at /usr/src/sys/kern/subr_epoch.c:394
#4  0xffffffff803c741b in epoch_block (global=<optimized out>, cr=<optimized out>, cb=<optimized out>, ct=<optimized out>)
    at /usr/src/sys/contrib/ck/src/ck_epoch.c:416
#5  ck_epoch_synchronize_wait (global=0xfffff8000380cd80, cb=<optimized out>, ct=<optimized out>) at /usr/src/sys/contrib/ck/src/ck_epoch.c:465
#6  0xffffffff80c3475e in epoch_wait_preempt (epoch=0xfffff8000380cd80) at /usr/src/sys/kern/subr_epoch.c:513
#7  0xffffffff80ce970b in bpf_detachd_locked (d=0xfffff801d309cc00, detached_ifp=<optimized out>) at /usr/src/sys/net/bpf.c:856
#8  0xffffffff80ced166 in bpf_detachd (d=<optimized out>) at /usr/src/sys/net/bpf.c:836
#9  bpf_dtor (data=0xfffff801d309cc00) at /usr/src/sys/net/bpf.c:914

To fix this add the check to the catchpacket() that BPF descriptor was
not detached just before we acquired BPFD_LOCK().

Reported by:	slavash
Tested by:	slavash
MFC after:	1 week
emaste pushed a commit that referenced this issue Jan 6, 2020
@ppaeps
fuspi: Fix 'sleepable after non-sleepable' lock
4729f0c 
With WITNESS enabled we see the following warning:

    lock order reversal: (sleepable after non-sleepable)
     1st 0xffffffd0847c7210 fu540spi0 (fu540spi0) @
     /usr/home/kp/axiado/hornet-freebsd/src/sys/riscv/sifive/fu540_spi.c:297
      2nd 0xffffffc00372bb30 Clock topology lock (Clock topology lock) @
      /usr/home/kp/axiado/hornet-freebsd/src/sys/dev/extres/clk/clk.c:1137
      stack backtrace:
      #0 0xffffffc0002a579e at witness_checkorder+0xb72
      #1 0xffffffc0002a5556 at witness_checkorder+0x92a
      #2 0xffffffc000254c7a at _sx_slock_int+0x66
      #3 0xffffffc00025537a at _sx_slock+0x8
      #4 0xffffffc000123022 at clk_get_freq+0x38
      #5 0xffffffc0005463e4 at __clzdi2+0x2bb8
      #6 0xffffffc00014af58 at randomdev_getkey+0x76e
      #7 0xffffffc0001278b0 at simplebus_add_device+0x7ee
      #8 0xffffffc00027c9a8 at device_attach+0x2e6
      #9 0xffffffc00027c634 at device_probe_and_attach+0x7a
      #10 0xffffffc00027d76a at bus_generic_attach+0x10
      #11 0xffffffc00014aab0 at randomdev_getkey+0x2c6
      #12 0xffffffc00027c9a8 at device_attach+0x2e6
      #13 0xffffffc00027c634 at device_probe_and_attach+0x7a
      #14 0xffffffc00027d76a at bus_generic_attach+0x10
      #15 0xffffffc000278bd2 at config_intrhook_oneshot+0x52
      #16 0xffffffc000278b3e at config_intrhook_establish+0x146
      #17 0xffffffc000278cf2 at config_intrhook_disestablish+0xfe

The clock topology lock can sleep, which means we cannot attempt to
acquire it while holding the non-sleepable mutex.

Fix that by retrieving the clock speed once, during attach and not every
time during SPI transaction setup.

Submitted by:   kp
Sponsored by:   Axiado
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@emaste