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"? > 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 vcc_destroy_socket()... but all the other ATM drivers also seem to clear it for themselves, and that would appear to be harmless. > 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. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
