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
-=====-==--- --== =-=-=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
