On Thu, 29 Nov 2012 15:59:08 +0000 David Woodhouse <dw...@infradead.org> wrote:
> On Thu, 2012-11-29 at 10:37 -0500, chas williams - CONTRACTOR wrote: > > you shouldnt clear ATM_VF_ADDR until the vpi/vci is actually closed and > > ready for reuse. at this point, it isnt. > > So I should always wait for the completion of my PKT_CLOSE and only > clear ATM_VF_ADDR when it's actually done? > > But can you define 'ready for reuse'? From the moment I clear > ATM_VF_ADDR, another CPU may enter my popen() function to set up another > VCC with the same parameters, and everything should work fine. The > PKT_POPEN will end up on the queue *after* my PKT_PCLOSE for the old > VCC. Any received packets will be dropped until the new VCC gets > ATM_VF_READY set (by the popen function). > > What's the actual failure mode, caused by me clearing ATM_VF_ADDR "too > early"? there may not be one (due to serialization from other parts of the atm stack) but you "shouldn't" clear ATM_VF_ADDR until the vpi/vci pair is ready for reuse. by reuse, i mean that any previous rx/tx data in the vpi/vci segmentation hardware has been removed/cleared. > > ATM_VF_READY should already be clear at this point but you should set > > it before you queue your PKT_CLOSE. > > I should *set* it? Do you mean clear it? Yes, I see it's cleared by sorry, i did mean clear it. > vcc_destroy_socket()... but all the other ATM drivers also seem to clear > it for themselves, and that would appear to be harmless. yeah, like i said, it is spuriously cleared in the drivers and should probably just be moved to under the control of the next layer up completely. drivers/atm should just handle the hardware side, not the software side. > > checking for ATM_VF_READY in find_vcc() is probably going to give you > > grief as well since ATM_VF_READY isnt entirely under your control. > > That's fine. If *anyone* has cleared ATM_VF_READY, I stop sending > packets up it. Or, more to the point, I stop using the damn thing at > all. See commit 1f6ea6e511e5ec730d8e88651da1b7b6e8fd1333. > > > you need to be able to find the vcc until after pclose() is finished since > > your tasklet might have a few packets it is still processing? > > The whole point of that check is that the tasklet *won't* be able to > find it any more, and it'll just discard incoming packets for the > obsolescent VCC. that's fine as long as you understand this. in the case of the he, i needed to be able to find the vcc until close() is finished so that i can wakeup the sleeper in the close() routine that is waiting for the reassembly queue to be cleared/reset. also, i still needed to find the vcc for the tx side during close() since i still might need to pop() skb's that are being sent during the close() while i am still trying to get the hardware to shutdown the transmit dma engine. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
