netdev
[Top] [All Lists]

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

To: Francois Romieu <romieu@xxxxxxxxxxxxx>
Subject: Re: [PATCH][ATM]: [clip] fix race between modifying entry->vccs and clip_start_xmit()
From: chas williams <chas@xxxxxxxxxxxxxxxx>
Date: Mon, 15 Sep 2003 17:59:02 -0400
Cc: davem@xxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: Message from Francois Romieu <romieu@xxxxxxxxxxxxx> of "Mon, 15 Sep 2003 22:59:01 +0200." <20030915225901.A22239@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
In message <20030915225901.A22239@xxxxxxxxxxxxxxxxxxxxxxxxxx>,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.

<Prev in Thread] Current Thread [Next in Thread>