diff options
author | Ingo Molnar <mingo@elte.hu> | 2006-07-03 00:25:14 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-07-03 15:27:08 -0700 |
commit | d378834840907326ac9d448056d957d13cc3718f (patch) | |
tree | c3b75251c66ed9e9ea9a5af385a520f006f99d55 /drivers/crypto | |
parent | c63661848581a9842dfc72d9a400285dd284fc47 (diff) |
[PATCH] lockdep: annotate ieee1394 skb-queue-head locking
ieee1394 reuses the skb infrastructure of the networking code, and uses two
skb-head queues: ->pending_packet_queue and hpsbpkt_queue. The latter is used
in the usual fashion: processed from a kernel thread. The other one,
->pending_packet_queue is also processed from hardirq context (f.e. in
hpsb_bus_reset()), which is not what the networking code usually does (which
completes from softirq or process context). This locking assymetry can be
totally correct if done carefully, but it can also be dangerous if networking
helper functions are reused, which could assume traditional networking use.
It would probably be more robust to push this completion into a workqueue -
but technically the code can be 100% correct, and lockdep has to be taught
about it. The solution is to split the ->pending_packet_queue skb-head->lock
class from the networking lock-class by using a private lock-validator key.
Has no effect on non-lockdep kernels.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Jody McIntyre <scjody@modernduck.com>
Cc: Ben Collins <bcollins@debian.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'drivers/crypto')
0 files changed, 0 insertions, 0 deletions