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

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

From: chas williams - CONTRACTOR <hidden>
Date: 2012-11-28 15:19:08
Also in: lkml

On Wed, 28 Nov 2012 10:24:28 +0000
David Woodhouse [off-list ref] wrote:
On Wed, 2012-11-28 at 11:04 +0100, Krzysztof Mazur wrote:
quoted
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.
If it's been submitted to the hardware for DMA, it can't do that very
easily.

And if I can't be bothered to write code to go through the entire damn
queue and inspect every packet to see if it's a data packet and check
the VCI/VPI and try to steal it, it can't be done for the software queue
either :)

The queue ought to be short; if it isn't, then we already screwed up.
The close therefore should be quick, and it *doesn't* have to be
instant.

If someone wants to return immediately, there's always
vcc_release_async()...
i dont think that would be quite the right way to do it.
vcc_release_async() just mark's the vcc for deletion--you still need to
go through and close it eventually.  however, nothing would prevent you
from writing a close routine that could just reschedule something
periodically to check to see if the hardware finally finished closing
the vcc and can be reused.  the part that needs fixed for this would be
marking the vcc for reuse.  you would need to keep the vpi.vci marked
as busy so that someone else doesnt try to reuse it while it is
closing.  right now, vcc_destroy_socket() always removes the vcc from
the vcc list -- regardless of whether or not close fully succeeded.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help