netdev
[Top] [All Lists]

Re: [RFC] locking changes for lec.c

To: chas3@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [RFC] locking changes for lec.c
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Fri, 14 Jan 2005 20:33:51 -0800
Cc: chas@xxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <200501150232.j0F2Wovr010942@xxxxxxxxxxxxxxxxxxxxxxx>
References: <20050114135612.0edc180d.davem@xxxxxxxxxxxxx> <200501150232.j0F2Wovr010942@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Fri, 14 Jan 2005 21:32:51 -0500
"chas williams - CONTRACTOR" <chas@xxxxxxxxxxxxxxxx> wrote:

> In message <20050114135612.0edc180d.davem@xxxxxxxxxxxxx>,"David S. Miller" 
> writes:
> >Can HW interrupt paths ever call into this ARP stuff?
> >If not, probably should just use BH disabled locking
> >instead of the heavy handed IRQ disabling locks.
> 
> yes, lec_push() could be run in hw interrupt context from one of of the
> atm drivers recv path.  in fact, this is the path where i "noticed" the
> race condition.

Ok.  As a future thought, if you make the ATM driver receive path
NAPI in style or run always from softint processing, you can
undo all the IRQ based locking.


<Prev in Thread] Current Thread [Next in Thread>