Thread (89 messages) 89 messages, 6 authors, 2012-12-03

Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc

From: Krzysztof Mazur <hidden>
Date: 2012-11-28 10:04:15
Also in: lkml

On Wed, Nov 28, 2012 at 09:21:37AM -0000, David Laight wrote:
quoted
On Tue, 27 Nov 2012 18:02:29 +0000
David Woodhouse [off-list ref] wrote:
quoted
In solos-pci at least, the ops->close() function doesn't flush all
pending skbs for this vcc before returning. So can be a tasklet
somewhere which has loaded the address of the vcc->pop function from one
of them, and is going to call it in some unspecified amount of time.

Should we make the device's ->close function wait for all TX and RX skbs
for this vcc to complete?
the driver's close routine should wait for any of the pending tx and rx
to complete.  take a look at the he.c in driver/atm
I'm not sure that sleeping for long periods in close() is always a
good idea. If the process is event driven it will be unable to
handle events on other fd until the close completes.
This may be known not to be true in this case, but is more generally
a problem.
In this case the close should probably (IMHO at least) only sleep
while pending tx and rx are aborted/discarded.

Even when it might make sense to sleep in close until tx drains
there needs to be a finite timeout before it become abortive.
The ->close() routine can just abort any pending rx/tx and just wait
for completion of currently running rx/tx code. That shouldn't take
long.

Krzysiek
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help