From: Fan Du <fan.du@windriver.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: <serge.hallyn@canonical.com>, <davem@davemloft.net>,
<netdev@vger.kernel.org>
Subject: Re: [PATCH] net namespace: wrap for_each_net with rtnl_lock
Date: Thu, 4 Jul 2013 15:57:14 +0800 [thread overview]
Message-ID: <51D52ADA.5020905@windriver.com> (raw)
In-Reply-To: <87txkaolfo.fsf@xmission.com>
Hi, Eric
Thanks for your reply!
On 2013年07月04日 15:04, Eric W. Biederman wrote:
> Fan Du<fan.du@windriver.com> writes:
>
>> The read access to net_namespace_list with for_each_net should always
>> be protected with rtnl_lock agiast any adding/removing operation from
>> the list.
>
> That is not correct. The rtnl_lock does not protect the
> net_namespace_list. The net_mutex provides that protection.
>
> Modifications to the net_namespace_list are under both the rtnl_lock
> and the net_mutex which removes the need of grabbing the net_mutex when
> you just need to traverse the list of network namespaces. This avoids a
> lock ordering problem as most places it is desirable to traverse the
> net namespace list the rtnl_lock is already held.
By my understanding, net_mutex protects operations on pernet_list, and rtln_lock
protects net_namespace_list. net_mutex has side effects on net_namespace_list,
because we try to hold rtnl_lock to modify net_namespace_list after already holding
net_mutex(copy_net_ns). Sorry, I cann't understand the necessity by doing so.
(1)
mutex_lock(&net_mutex);
rv = setup_net(net, user_ns);
if (rv == 0) {
rtnl_lock();
list_add_tail_rcu(&net->list, &net_namespace_list);
rtnl_unlock();
}
mutex_unlock(&net_mutex);
why could we do it separately as below?
(2)
mutex_lock(&net_mutex);
rv = setup_net(net, user_ns);
mutex_unlock(&net_mutex);
if (rv == 0) {
rtnl_lock();
list_add_tail_rcu(&net->list, &net_namespace_list);
rtnl_unlock();
}
>
> In general the init methods will deadlock if you call them with the
> rtnl_lock held, as they grab the rtnl_lock when creating network devices
> etc.
Yes, I understand. This is reason why we do it in (1) style.
> The methods you change are protected by the net_mutex so I don't see any
> problems here.
> Was this patch inspired by code review or was there an actual problem
> that inspired it?
It's code review, no real alarm :)
>> Signed-off-by: Fan Du<fan.du@windriver.com>
>> ---
>> net/core/net_namespace.c | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
>> index f976520..f3808ff 100644
>> --- a/net/core/net_namespace.c
>> +++ b/net/core/net_namespace.c
>> @@ -445,12 +445,14 @@ static int __register_pernet_operations(struct list_head *list,
>>
>> list_add_tail(&ops->list, list);
>> if (ops->init || (ops->id&& ops->size)) {
>> + rtnl_lock();
>> for_each_net(net) {
>> error = ops_init(ops, net);
>> if (error)
>> goto out_undo;
>> list_add_tail(&net->exit_list,&net_exit_list);
>> }
>> + rtnl_unlock();
>> }
>> return 0;
>>
>> @@ -468,8 +470,10 @@ static void __unregister_pernet_operations(struct pernet_operations *ops)
>> LIST_HEAD(net_exit_list);
>>
>> list_del(&ops->list);
>> + rtnl_lock();
>> for_each_net(net)
>> list_add_tail(&net->exit_list,&net_exit_list);
>> + rtnl_unlock();
>> ops_exit_list(ops,&net_exit_list);
>> ops_free_list(ops,&net_exit_list);
>> }
>
--
浮沉随浪只记今朝笑
--fan
prev parent reply other threads:[~2013-07-04 7:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-04 6:20 [PATCH] net namespace: wrap for_each_net with rtnl_lock Fan Du
2013-07-04 7:04 ` Eric W. Biederman
2013-07-04 7:57 ` Fan Du [this message]
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=51D52ADA.5020905@windriver.com \
--to=fan.du@windriver.com \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=netdev@vger.kernel.org \
--cc=serge.hallyn@canonical.com \
/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.