Messages in this thread | | | Date | Fri, 30 Nov 2012 12:12:56 -0500 | From | chas williams - CONTRACTOR <> | Subject | Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc |
| |
On Fri, 30 Nov 2012 16:23:46 +0000 David Woodhouse <dwmw2@infradead.org> wrote:
> On Fri, 2012-11-30 at 12:10 +0000, David Woodhouse wrote: > > In that case I think we're fine. I'll just do the same thing in > > br2684_push(), fix up the comment you just corrected, and we're all > > good. > > OK, here's an update to me my patch 8/17 'br2684: don't send frames on > not-ready vcc'. It takes the socket lock and does fairly much the same > thing as your pppoatm version. It returns NETDEV_TX_BUSY and stops the > queue if the socket is locked, and it gets woken from the ->release_cb > callback. > > I've dropped your Acked-By: since it's mostly new, but feel free to give > me a fresh one. With this I think we're done. > > Unless Chas has any objections, I'll ask Dave to pull it...
no objections. i think this deals with my concerns. as for splitting the close functions, from one of your previous messages:
>Really, what we're saying is that *one* of the driver or protocol close >functions needs to be split, and we need to do DPD or PDP. Since the >device driver *can* abort/flush the TX queue and also any pending RX >being handled by a tasklet, I think it makes most sense to keep it in >the middle, with the protocol being handled first and last... which is >the current order, as long as we consider setting ATM_VF_CLOSE to be the >first part.
i believe this is essentially already done with the release_cb() implementation right? that is splitting the protocol detach/shutdown into two parts.
| |