From: ebiederm@xmission.com (Eric W. Biederman)
To: David Miller <davem@davemloft.net>
Cc: fruggeri@aristanetworks.com, edumazet@google.com,
jiri@resnulli.us, alexander.h.duyck@intel.com, amwang@redhat.com,
netdev@vger.kernel.org
Subject: Re: [CFT][PATCH] net: Delay default_device_exit_batch until no devices are unregistering
Date: Wed, 18 Sep 2013 01:19:58 -0700 [thread overview]
Message-ID: <871u4mh781.fsf@tw-ebiederman.twitter.com> (raw)
In-Reply-To: <20130917.235247.344101545141336143.davem@davemloft.net> (David Miller's message of "Tue, 17 Sep 2013 23:52:47 -0400 (EDT)")
David Miller <davem@davemloft.net> writes:
> From: Francesco Ruggeri <fruggeri@aristanetworks.com>
> Date: Tue, 17 Sep 2013 20:50:41 -0700
>> I am not sure that would work.
>> list_empty(&net_todo_list) does not guarantee that there are no
>> unregistering devices still in flight.
>> Another process may have copied net_todo_run into its local list, left
>> net_todo_list empty and still be in the middle of processing
>> unregistering devices (without the rtnl lock) when
>> default_device_exit_batch starts executing.
>
> Ok, now I understand.
>
> Eric B., when you get a chance can you resubmit your patch and perhaps
> elaborate on the situation in the commit message.
The code is on my computer at home so I won't be able to get back to
this until Sunday or Monday. This should give Francesco time to verify
I really have closed the holes he is seeing.
> If I was confused I'm sure other people will be if they look into
> this in the future.
Agreed. It is easy to get confused with this issue. And I was in a
rush so I expect my wording could be improved.
There is still the other part of this issue that dev_close reorders
devices in default_device_exit_batch.
With that reordering we can get the call chain:
netdev_run_todo
call_netdevice_notifiers(NETDEV_UNREGISTER_FINAL,...)
dst_dev_event
dst_ifdown(..., unregister == 1)
dst->dev = dev_net(dst->dev)->loopback_dev;
dev_hold(dst->dev);
With dev_net(dst->dev)->loopback_dev == NULL;
So my patch to split the close_list out of the unreg_list is also needed
(or something else to address that issue).
Hopefully my exaspearation with dev_close_many didn't obscure what is
happening there.
Eric
next prev parent reply other threads:[~2013-09-18 8:22 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1379008796-2121-1-git-send-email-fruggeri@aristanetworks.com>
2013-09-12 20:06 ` [PATCH 1/1] net: race condition when removing virtual net_device Eric W. Biederman
2013-09-12 21:48 ` Francesco Ruggeri
2013-09-12 22:02 ` Francesco Ruggeri
2013-09-13 5:50 ` Eric W. Biederman
2013-09-13 17:54 ` Francesco Ruggeri
2013-09-14 1:46 ` Eric W. Biederman
2013-09-16 2:54 ` Francesco Ruggeri
2013-09-16 10:45 ` Eric W. Biederman
2013-09-16 20:30 ` Francesco Ruggeri
2013-09-16 23:52 ` [PATCH net-next] net loopback: Set loopback_dev to NULL when freed Eric W. Biederman
2013-09-17 0:50 ` Eric Dumazet
2013-09-17 1:34 ` David Miller
2013-09-17 1:41 ` Eric Dumazet
2013-09-17 1:52 ` Eric W. Biederman
2013-09-17 23:05 ` David Miller
2013-09-17 0:25 ` [PATCH 1/1] net: race condition when removing virtual net_device Eric W. Biederman
2013-09-17 5:12 ` Francesco Ruggeri
2013-09-17 3:49 ` [CFT][PATCH] net: Delay default_device_exit_batch until no devices are unregistering Eric W. Biederman
2013-09-17 6:54 ` Francesco Ruggeri
2013-09-17 9:38 ` Eric W. Biederman
2013-09-17 17:14 ` Francesco Ruggeri
2013-09-17 23:21 ` David Miller
2013-09-17 23:41 ` Eric W. Biederman
2013-09-18 0:15 ` David Miller
2013-09-18 3:50 ` Francesco Ruggeri
2013-09-18 3:52 ` David Miller
2013-09-18 8:19 ` Eric W. Biederman [this message]
2013-09-20 16:34 ` Francesco Ruggeri
2013-09-24 4:19 ` [PATCH] net: Delay default_device_exit_batch until no devices are unregistering v2 Eric W. Biederman
2013-09-24 17:54 ` Francesco Ruggeri
2013-09-28 22:14 ` David Miller
2013-09-14 0:16 ` [PATCH 1/1] net: race condition when removing virtual net_device David Miller
2013-09-14 1:32 ` Eric W. Biederman
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=871u4mh781.fsf@tw-ebiederman.twitter.com \
--to=ebiederm@xmission.com \
--cc=alexander.h.duyck@intel.com \
--cc=amwang@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fruggeri@aristanetworks.com \
--cc=jiri@resnulli.us \
--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.