Re: firewire panic

On 14/11/2016 11:58, Gary Jennejohn wrote:
> On Sun, 13 Nov 2016 23:56:09 +0200
> Andriy Gapon <avg_at_FreeBSD.org> wrote:
> 
>> On 11/11/2016 14:25, Andriy Gapon wrote:
>>> panic: mutex sbp not owned at /usr/src/sys/dev/firewire/sbp.c:967
>>> cpuid = 2
>>> curthread: 0xfffff8000ada5000
>>> stack: 0xfffffe0504ded000 - 0xfffffe0504df1000
>>> stack pointer: 0xfffffe0504df0a00
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper() at 0xffffffff80420bbb = db_trace_self_wrapper+0x2b/frame
>>> 0xfffffe0504df0930
>>> kdb_backtrace() at 0xffffffff80670359 = kdb_backtrace+0x39/frame 0xfffffe0504df09e0
>>> vpanic() at 0xffffffff8063986c = vpanic+0x14c/frame 0xfffffe0504df0a20
>>> panic() at 0xffffffff806395b3 = panic+0x43/frame 0xfffffe0504df0a80
>>> __mtx_assert() at 0xffffffff8061c40d = __mtx_assert+0xed/frame 0xfffffe0504df0ac0
>>> sbp_cam_scan_lun() at 0xffffffff80474667 = sbp_cam_scan_lun+0x37/frame
>>> 0xfffffe0504df0af0
>>> xpt_done_process() at 0xffffffff802aacfa = xpt_done_process+0x2da/frame
>>> 0xfffffe0504df0b30
>>> xpt_done_td() at 0xffffffff802ac2e5 = xpt_done_td+0xd5/frame 0xfffffe0504df0b80  
>>
>> So, it's pretty obvious that the sbp mutex can not be held when
>> sbp_cam_scan_lun() is called.
>>
> 
> The code seems to assume that the scan_callout callout is still
> holding the mutex when sbp_cam_scan_lun() is entered.
> 
> Seems reasonable, since the man page claims that the callout routine
> keeps the mutex locked until the callout function, in this case that's
> sbp_cam_scan_target(), returns.  Since sbp_cam_scan_target() invokes
> xpt_action() with sbp_cam_scan_lun() as its callback, it seems like
> the assumption should be true.

The wrong assumption in your reasoning is that the callback is executed in the
same thread.

> Pehaps there's some asynchronous action happening with the
> firewire code which is releasing the mutex prematurely.
> 
> Or maybe the sbp used in sbp_cam_scan_lun() is wrong?  Dunno.


-- 
Andriy Gapon