Re: [sysctl] New sysctl LoR today

From: Sean Bruno <sean.bruno_at_dsl-only.net>
Date: Tue, 10 Feb 2009 22:09:28 -0800
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) _at_ dev/firewire/sbp.c:2253
>  2nd 0xc0d3aea4 sysctl lock (sysctl lock) _at_ 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
Received on Wed Feb 11 2009 - 05:09:29 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:42 UTC