From: Benjamin Thery <benjamin.thery@bull.net>
To: Jarek Poplawski <jarkao2@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
Daniel Lezcano <dlezcano@fr.ibm.com>
Subject: Re: [PATCH] net: deadlock during net device unregistration
Date: Tue, 30 Sep 2008 13:52:31 +0200 [thread overview]
Message-ID: <48E212FF.1060409@bull.net> (raw)
In-Reply-To: <20080930063231.GA4792@ff.dom.local>
Jarek Poplawski wrote:
> On 29-09-2008 19:54, Benjamin Thery wrote:
>> This patch proposes to replace the rtnl_unlock() call in
>> linkwatch_event() by __rtnl_unlock(). The difference between the two
>> routines being that __rtnl_unlock() will not call netdev_run_todo()
>> after it unlocks rtnl_mutex.
>>
>> This is to fix a "deadlock" we observed when unregistering a net device.
>>
>> In some circumstances, linkwatch_event() blocks the whole "events"
>> workqueue while blocking in rtnl_unlock().
>>
>> Here is what happens:
>>
>> 1. Unregister a device, the following routines are called:
>>
>> -> unregister_netdev
>> -> rtnl_lock
>> -> unregister_netdevice
>> -> rtnl_unlock
>> -> netdev_run_todo
>> -> netdev_wait_allrefs
>>
>> 2. In netdev_wait_allrefs(), the device's refcount is greater than 0
>> because there are still some routes to be garbage collected later.
>>
>> 3. Also, some link watch events are pending. netdev_wait_allrefs()
>> will run the linkwatch event queue, calls linkwatch_run_queue().
>>
>>
>> Both the route garbage collector dst_gc_task() and the linkwatch task
>> linkwatch_event() are queued in the same generic workqueue: "events".
>>
>>
>> 4. linkwatch_event() is enqueued earlier in the queue. It will grab
>> rtnl_lock(), deliver the link watch events pending, and then call
>> rtnl_unlock().
>> rtnl_unlock() will then call netdev_run_todo() and block on
>> mutex_lock(&net_todo_run_mutex).
>>
>> At this point, the workqueue "events" is _blocked_ until the
>> netdev_wait_allrefs() call above returns when the device refcount
>> reaches 0.
>>
>> Problem: it will never happens if dst_gc_task() was enqueued behind
>> linkwatch_event() in the "events" workqueue as the queue is now
>> blocked.
> ...
>
> If it's really like this, I wonder if this can happen without linkwatch
> too in a non-preemptive config?
Um, not sure I fully understand what you mean... do you mean with
CONFIG_PREEMPT_NONE=y?
> So maybe this should be fixed somewhere
> else? According to a comment above netdev_wait_allrefs() it seems
> references should be rather put down on an UNREGISTER event, so this
> dst_gc_task() scheduling shouldn't bother us, I guess.
I saw this comment too. In our case, the UNREGISTER event is sent,
notifications are dispatched correctly, some routes are deleted
(dst_free()) but not destroyed (dst_destroy()) and the garbage collector
as to run to finish the work.
dst_entry's may hold a refcount on device until dst_destroy() is run on
them. Unfortunately dst_gc_task() won't have a chance to run
dst_destroy() on them later in this case because it is stuck in the
"events" workqueue behind linkwatch_event() who is blocking everyone
else in the queue.
I'm still looking at why the first dst_free() on those particular routes
doesn't call dst_destroy() immediately but defers it (another refcount
on the route itself).
BTW, in the past (last year) dst_gc_task() was run as a timer handler
and this situation (deadlock with linkwatch_event()) couldn't occur.
Thanks,
Benjamin
>
> Jarek P.
>
>
--
B e n j a m i n T h e r y - BULL/DT/Open Software R&D
http://www.bull.com
next prev parent reply other threads:[~2008-09-30 11:52 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080929175412.866679567@theryb.frec.bull.fr>
2008-09-29 17:54 ` [PATCH] net: deadlock during net device unregistration Benjamin Thery
2008-09-30 6:32 ` Jarek Poplawski
2008-09-30 11:52 ` Benjamin Thery [this message]
2008-09-30 13:58 ` David Miller
2008-09-30 14:07 ` Benjamin Thery
2008-09-30 14:42 ` Jarek Poplawski
2008-09-30 14:57 ` Jarek Poplawski
2008-09-30 15:18 ` Benjamin Thery
2008-10-01 9:59 ` David Miller
2008-10-01 10:10 ` Daniel Lezcano
2008-10-01 10:12 ` David Miller
2008-10-01 14:14 ` [PATCH] net: deadlock during net device unregistration - V2 Benjamin Thery
2008-10-01 19:48 ` Jarek Poplawski
2008-10-01 21:06 ` Daniel Lezcano
2008-10-01 21:52 ` Jarek Poplawski
2008-10-01 23:31 ` Jarek Poplawski
2008-10-02 15:23 ` Benjamin Thery
2008-10-02 18:38 ` Jarek Poplawski
2008-10-02 19:55 ` Benjamin Thery
2008-10-02 20:34 ` Jarek Poplawski
2008-10-04 7:42 ` Jarek Poplawski
2008-10-04 7:52 ` Jarek Poplawski
2008-10-03 0:41 ` [PATCH] net: deadlock during net device unregistration Eric W. Biederman
2008-10-05 4:26 ` Herbert Xu
2008-10-05 6:55 ` Jarek Poplawski
2008-10-05 6:56 ` Herbert Xu
2008-10-05 7:12 ` Jarek Poplawski
2008-10-05 7:28 ` Stephen Hemminger
2008-10-05 7:38 ` Herbert Xu
2008-10-05 7:39 ` Herbert Xu
2008-10-06 15:19 ` Benjamin Thery
2008-10-07 22:46 ` David Miller
2008-10-07 22:50 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48E212FF.1060409@bull.net \
--to=benjamin.thery@bull.net \
--cc=davem@davemloft.net \
--cc=dlezcano@fr.ibm.com \
--cc=jarkao2@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.