[lkml]   [2010]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: lockdep false positive? -- firewire-core transaction timer vs. scsi-core host lock
    On Mon, 2010-08-16 at 23:42 +0200, Peter Zijlstra wrote:

    > Which means that it now worries the following can happen:
    > softirq:
    > spin_lock(&t->split_timeout_timer);
    > IRQ:
    > spin_lock(&(shost->host_lock)->rlock);
    > spin_lock(&t->split_timeout_timer);
    > Now, the thing is that split_timeout_timer is a fake lock used to
    > annotate timers, its use is to connect lock chains from within the timer
    > callback to del_timer_sync() callers, to detect deadlocks.
    > Now, I can't seem to remember why del_timer_sync() explicitly disables
    > IRQs but call_timer_fn() does not, Johill, happen to remember?

    Err, sorry, no. I do remember that we had long discussions and initially
    I had wanted to disable the context checking for these fake locks
    completely. I think it was just the minimal thing needed not to make it
    warn always. Also, we can't do the same thing in call_timer_fn() since
    we need to hold it across fn()? Wouldn't it complain if we held that
    lock then while enabling IRQs again? Not sure.

    I don't fully understand the scenario above yet though. Why does it
    think we could ever take the fake lock in an IRQ to start with? That
    must not happen. Or is that just preemptive worrying?


     \ /
      Last update: 2010-08-17 00:11    [W:2.288 / U:0.336 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site