Patrick McHardy wrote:
> Jarek Poplawski wrote:
>> On 29-10-2008 01:08, Jay Cliburn wrote:
>>> [   27.779463] ------------[ cut here ]------------
>>> [   27.779509] WARNING: at kernel/softirq.c:136 
>>> local_bh_enable+0x37/0x81()
>> ...
>>> [   27.782520]  [<c0264755>] netif_nit_deliver+0x5b/0x75
>>> [   27.782590]  [<c02bba83>] __vlan_hwaccel_rx+0x79/0x162
>>> [   27.782664]  [<f8851c1d>] atl1_intr+0x9a9/0xa7c [atl1]
>>>>
>>> warn_on_slowpath stuff well enough to know what to look for. Can someone
>>> please take a quick look at drivers/net/atlx/atl1.c around line 2017
>>> and see if there's an obvious error?  I'd really appreciate it.
>>
>> It looks to me like vlan_hwaccel_rx() is to blame: I doubt we can do
>> netif_nit_deliver() in hard irq context. (Patrick Cc-ed.)
> 
> Crap, I didn't think of that, all drivers I tested with support
> NAPI. I can't think of a clean way to fix it right now, but I'll
> look into it.

This is the best I could come up with, short of simply restoring
the old behaviour for non-polling drivers.

The __vlan_hwaccel_rx function only does the device lookup and
stores it in the cb. The remaining processing is done in a new
function that is invoked by netif_receive_skb(), in the proper
context. Unfortunatly this needs vlan-specific handling in
netif_receive_skb().