Re: [PATCH][ATM]: [clip] fix race between modifying entry->vccs and clip_start_xmit()

In message [ref],Francois Romieu w
rites:

Afaik unlink_clip_vcc() can be called from a clip_push() issued in IRQ
context through vcc->push() in a device driver as well as from user-space
through vcc_ioctl()/ATMARP_SETENTRY. If the lock is taken by user-space
first, what avoids that unlink_clip_vcc(IRQ) deadlocks on it ?

i believe you are talking about:

        if (!skb) {
                DPRINTK("removing VCC %p\n",clip_vcc);
                if (clip_vcc->entry) unlink_clip_vcc(clip_vcc);
                clip_vcc->old_push(vcc,NULL); /* pass on the bad news */
                kfree(clip_vcc);
                return;
        }

this is triggered by vcc_destroy_sock(), which is part of vcc_release()
which is always going to be in user context.  its a bit subtle but
there is no path to unlink_clip_vcc() that isnt in user context.

No comment for the clip_start_xmit() part btw.

actually, you dont need to modify that part.