[lkml]   [2008]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: use of preempt_count instead of in_atomic() at leds-gpio.c
    Andrew Morton wrote:
    > ./drivers/ieee1394/ieee1394_transactions.c
    > Possibly buggy: deadlockable

    That's in hpsb_get_tlabel(), an exported symbol of the ieee1394 core.

    The in_atomic() there didn't cause problems yet and is unlikely to do so
    in the future, because there are no plans for substantial changes to the
    whole drivers/ieee1394/ anymore (because of drivers/firewire/).

    Nevertheless I shall look into replacing the in_atomic() by in_softirq()
    or something like that. Touching this legacy code is dangerous though.

    Some background:

    This in_atomic() is just one symptom of one of the fundamental design
    flaws of the ieee1394 stack: The "tlabels" (transaction labels, a
    limited resource) are acquired not only in process context but also in
    soft IRQ context --- but they are released only in process context.
    Unsurprisingly (in hindsight), the stack used to run out of tlabels
    simply because the tlabel consumers were scheduled more frequently than
    the tlabel recycler. This resulted in IO failures in sbp2 and eth1394.

    This is one of the design problems which inspired the submission of a
    new alternative driver stack. (Though this particular one of the
    ieee1394 stack's problems could of course also be solved by a rework of
    the stack --- with a respective need of resources for testing and some
    danger of regressions.)

    In the meantime (Linux 2.6.19 and 2.6.22) I added workarounds in sbp2
    and eth1394 to deal with temporary lack of of tlabels. Alas I just
    recently received a report that eth1394's workaround is unsuccessful on
    non-preemptible uniprocessor kernels. I suspect the same issue exists
    with sbp2's workaround, it just isn't as likely to happen there.

    The new drivers/firewire/ recycle tlabels in bottom halves context and
    in timer context, which is the appropriate approach. Alas
    drivers/firewire/ don't have an eth1394 equivalent yet...
    Stefan Richter
    -=====-==--- --== =-=-=

     \ /
      Last update: 2008-03-21 10:25    [W:4.260 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site