[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081001215244.GB2520@ami.dom.local>
Date: Wed, 1 Oct 2008 23:52:44 +0200
From: Jarek Poplawski <jarkao2@...il.com>
To: Daniel Lezcano <dlezcano@...ibm.com>
Cc: Benjamin Thery <benjamin.thery@...l.net>,
"David S. Miller" <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] net: deadlock during net device unregistration - V2
On Wed, Oct 01, 2008 at 11:06:22PM +0200, Daniel Lezcano wrote:
> Jarek Poplawski wrote:
>> On Wed, Oct 01, 2008 at 04:14:35PM +0200, Benjamin Thery wrote:
...
>>> --- net-next-2.6.orig/net/core/dst.c
>>> +++ net-next-2.6/net/core/dst.c
>>> @@ -328,6 +328,10 @@ static int dst_dev_event(struct notifier
>>> dst_ifdown(dst, dev, event != NETDEV_DOWN);
>>> }
>>> mutex_unlock(&dst_gc_mutex);
>>> +
>>> + if (event == NETDEV_UNREGISTER &&
>>> + cancel_delayed_work(&dst_gc_work))
>>> + dst_gc_task(&dst_gc_work.work);
>>
>> Hmm... It seems this shouldn't work yet: cancel_delayed_work() can only
>> kill this while on timer, but not when queued and maybe blocked already.
>
> Perhaps, I am misunderstanding but, dst_gc_work is always called with
> schedule_delayed_work. If the task is not running, we can cancel it and
> if the task is running, no need to trigger the gc, no ?
Right, but cancel_delayed_work() can't cancel it reliably even if the
task is not running (but e.g. queued already just after us - linkwatch).
Of course, this should be OK most of the time, especially with such long
schedule delays, but, on the other hand, not as sure as the first patch
with __rtnl_unlock. So doing this right could take more time.
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists