[sysctl] New sysctl LoR today

Sean Bruno sean.bruno at dsl-only.net
Tue Feb 10 22:09:30 PST 2009


On Tue, 2009-02-10 at 17:23 -0800, Sean Bruno wrote:
> I'm working on some items in the firewire stack and after a update, I
> was greeted with a new LoR against the SYSCTL lock.  I noted that some
> things were changing in that space.
> 
> Did I miss an interface change that I need to pickup in the firewire
> stack?
> 
> Sean
> 
> lock order reversal: (sleepable after non-sleepable)
>  1st 0xc471bbec sbp (sbp) @ dev/firewire/sbp.c:2253
>  2nd 0xc0d3aea4 sysctl lock (sysctl lock) @ kern/kern_sysctl.c:250
> KDB: stack backtrace:
> db_trace_self_wrapper(c0be8361,c42aa328,c087a355,4,c0be39e8,...) at
> db_trace_self_wrapper+0x26
> kdb_backtrace(4,c0be39e8,c4524e00,c4521ad0,c42aa384,...) at
> kdb_backtrace+0x29
> _witness_debugger(c0beb056,c0d3aea4,c0be5e30,c4521ad0,c0be5d4f,...) at
> _witness_debugger+0x25
> witness_checkorder(c0d3aea4,9,c0be5d46,fa,0,...) at witness_checkorder
> +0x839
> _sx_xlock(c0d3aea4,0,c0be5d46,fa,c471a000,...) at _sx_xlock+0x85
> sysctl_ctx_free(c471a2c0,c0b8f786,c0d0696c,0,c469fa0c,...) at
> sysctl_ctx_free+0x30
> dacleanup(c4c54700,c0b900bb,c480e000,c42aa410,246,...) at dacleanup+0x35
> camperiphfree(c4c54700,c4c54700,c42aa694,c047763d,c4c54700,...) at
> camperiphfree+0xc2
> cam_periph_invalidate(c4c54700,c0bb6c60,c42aa6c8,c048ba73,c4c54700,...)
> at cam_periph_invalidate+0x3e
> cam_periph_async(c4c54700,100,c4a03450,0,c480e000,c42aa70c,c087ada8,c480e0a4,c0e7b688,c0ccf6a4) at cam_periph_async+0x2d
> daasync(c4c54700,100,c4a03450,0,c4a26000,...) at daasync+0xf3
> xpt_async_bcast(0,4,c0b88347,117f,c4736500,...) at xpt_async_bcast+0x32
> xpt_async(100,c4a03450,0,8cd,0,...) at xpt_async+0x194
> sbp_cam_detach_sdev(c471bbec,0,c0bb6c57,333,1,...) at
> sbp_cam_detach_sdev+0xa4
> sbp_post_explore(c471b800,c42aaca4,c42aaca0,1,3,...) at sbp_post_explore
> +0xed9
> fw_bus_probe_thread(c472f000,c42aad38,c0be11ff,32d,c472ea90,...) at
> fw_bus_probe_thread+0x88b
> fork_exit(c0636be0,c472f000,c42aad38) at fork_exit+0xb8
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0, eip = 0, esp = 0xc42aad70, ebp = 0 ---
> 

I spent some time dissecting the point at which this LoR occurred in
checkin history and hit this one as the culprit:

r188232 | jhb | 2009-02-06 06:51:32 -0800 (Fri, 06 Feb 2009) | 33 lines

Reverting these changes makes the LoR warning go away.

So, does the Firewire stack need an enhancement or did I stumble across
something more?

Sean



More information about the freebsd-current mailing list