local_bh_enable & hard_start_xmit

[Ben Greear <greearb@xxxxxxxxxxxxxxx>]

This pertains to kernel 2.6.11.

I seem to have backed myself into a corner with network devices
and locking...again.

I have a thread that grabs a read lock with read_lock_irqsave,
loops through a list, making calls to dev->hard_start_xmit.

Before today, I was not messing with local_bh_enable/disable, and
I was seeing badness messages due to this call path:

Badness in local_bh_enable at kernel/softirq.c:140
 [<c01266f2>] local_bh_enable+0x92/0xa0
 [<c02b6b35>] dev_queue_xmit+0x165/0x280
 [<c0110364>] get_offset_pmtmr+0x14/0xcb0
 [<f89e2372>] vlan_dev_hwaccel_hard_start_xmit+0x62/0x70 [8021q]
 [<f89a89b2>] do_task+0x642/0x61e0 [wanlink]
...

The warning is due to this line:
void local_bh_enable(void)
{
        WARN_ON(irqs_disabled());


So, I decided to wrap my calls to dev->hard_start_xmit with 
local_bh_disable/enable.

That does not actually fix my problem because I still have the read-lock 
acquired.
I am going to try putting the disable/enable outside of that, but then I will be
potentially disabling the bh for a long time.


So, two questions:

1)  Why is it bad to have interrupts disabled when calling
    the local_bh_enable() method?

2)  Should there be a hard requirement that one must never have IRQs disabled
    when calling dev->hard_start_xmit  (this requirement seems to currently
    be in effect because VLANs can call dev_queue_xmit from their 
hard_start_xmit
    method, and it appears that dev_queue_xmit must not be called with IRQs 
disabled).


Thanks,
Ben


--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com