In message [off-list 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.
On Mon, 15 Sep 2003 17:59:02 -0400
chas williams [off-list ref] wrote:
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.
Are you really totally sure that no interrupt path can release
a VCC? That's not how I understood this stuff to work last time
I looked at it.
On Mon, 15 Sep 2003 15:30:48 -0700
Mitchell Blank Jr [off-list ref] wrote:
David S. Miller wrote:
quoted
Are you really totally sure that no interrupt path can release
a VCC?
That should be the case at least for any VCC on a real interface[*].
Some ATM cards have ->close() methods that can take a while so connection
teardown has to happen with some sort of sleepable context. So if there
are cases where an interrupt causes the VCC to die they would need to be
fixed anyways.
Ok, I'm convinced. :)
I'll apply Chas's patch then, thanks.
David S. Miller wrote:
quoted
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.
Are you really totally sure that no interrupt path can release
a VCC?
That should be the case at least for any VCC on a real interface[*].
Some ATM cards have ->close() methods that can take a while so connection
teardown has to happen with some sort of sleepable context. So if there
are cases where an interrupt causes the VCC to die they would need to be
fixed anyways.
-Mitch
[*] some protocols use psuedo-interfaces for their control connections - in
theory I guess they could be different but I don't believe there are
any cases where they are. They wouldn't affect this issue anyways though.