How is supposed to be protected the units list?

[Attilio Rao]

2010/3/4 Matthew Jacob <mj at feral.com>:
> On 3/3/2010 1:57 PM, Attilio Rao wrote:
>>
>> 2010/3/3 Matthew Jacob<mj at feral.com>:
>>
>>>
>>> On static review, the only code that makes me nervous are
>>> ata_shutdown/da_shutdown.
>>> Those are the only places where you hold that lock across an uncertain
>>> interval.
>>>
>>
>> Please note that a def mutex is already held (the cam_periph_lock),
>> so, unless LORs I'm not thinking about, I don't expect too much
>> surprises for that codepath.
>>
>> Thanks,
>> Attilio
>>
>>
>>
>
> The only potential operational difference was on reattach (power SAN disks
> on, they attach. Power them off. Wait for 60 seconds. The deattach. Power
> them on again). I've run this test many times before and haven't seen this.
>
> da7: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C)
> (da7:isp0:0:6:0): removing device entry
> panic: Bad link elm 0xffffff0018fbbc00 next->prev != elm
> cpuid = 0
> KDB: enter: panic
> [ thread pid 0 tid 100044 ]
> Stopped at      kdb_enter+0x3d: movq    $0,0x6b02d0(%rip)
> db> bt
> Tracing pid 0 tid 100044 td 0xffffff0002fbe000
> kdb_enter() at kdb_enter+0x3d
> panic() at panic+0x17b
> camperiphfree() at camperiphfree+0x1c2
> cam_periph_release_locked() at cam_periph_release_locked+0x48
> cam_periph_release() at cam_periph_release+0x53
> dasysctlinit() at dasysctlinit+0x153
> taskqueue_run() at taskqueue_run+0x91
> taskqueue_thread_loop() at taskqueue_thread_loop+0x3f
> fork_exit() at fork_exit+0x12a
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffff8000188d30, rbp = 0 ---

Is this with the patch or without?

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein