From: Pavel Emelyanov <xemul@openvz•org>
To: paulmck@linux•vnet.ibm.com
Cc: Linux Netdev List <netdev@vger•kernel.org>,
Daniel Lezcano <dlezcano@fr•ibm.com>,
Denis Lunev <den@openvz•org>,
Linux Containers <containers@lists•osdl.org>,
Benjamin Thery <benjamin.thery@bull•net>
Subject: Re: [PATCH 3/14][TUN]: Introduce the tun_net structure.
Date: Fri, 11 Apr 2008 19:45:06 +0400 [thread overview]
Message-ID: <47FF8782.6010006@openvz.org> (raw)
In-Reply-To: <20080411150440.GA8354@linux.vnet.ibm.com>
Paul E. McKenney wrote:
> On Fri, Apr 11, 2008 at 11:55:59AM +0400, Pavel Emelyanov wrote:
>> Paul E. McKenney wrote:
>>> On Thu, Apr 10, 2008 at 07:06:24PM +0400, Pavel Emelyanov wrote:
>>>> This is the first step in making tuntap devices work in net
>>>> namespaces. The structure mentioned is pointed by generic
>>>> net pointer with tun_net_id id, and tun driver fills one on
>>>> its load. It will contain only the tun devices list.
>>>>
>>>> So declare this structure and introduce net init and exit hooks.
>>> OK, I have to ask... What prevents someone else from invoking
>>> net_generic() concurrently with a call to tun_exit_net(), potentially
>>> obtaining a pointer to the structure that tun_exit_net() is about
>>> to kfree()?
>> It's the same as if the tun_net was directly pointed by the struct
>> net. Nobody can grant, that the pointer got by you from the struct
>> net is not going to become free, unless you provide this security
>> by yourself.
>
> So tun_net acquires some lock before calling net_generic(), and that
> same lock is held when calling tun_exit_net()? Or is there but a
No.
> single tun_net task, so that it will never call tun_net_exit()
> at the same time that it calls net_generic() for the tun_net pointer?
tun_net_exit is called only when a struct net is no longer referenced
and is going to be kfree-ed itself, so it's impossible (or BUGy by its
own) that someone still has a pointer on this net.
Providing the struct net is alive (!), the net->gen array is alive (or
is scheduled for kfree after RCU grace period). Thus, if your code
holds the net and uses the net_generic() call, then it will get alive
net->gen array and alive tun_net pointer.
Next, what happens after net_generic() completes and leaves the RCU-read
section? Simple - the struct net is (should be) still referenced, so the
tun_net_exit cannot yet be called and thus the tun_net pointer obtained
earlier is alive. Unlike the (possibly) former instance of the net_generic
array, but nobody references this one in my code (and should not do so,
hm... I think I'll add this rule to the comments).
>> But if you call net_generic to get some pointer other than tun_net,
>> then you're fine (due to RCU), providing you play the same rules with
>> the pointer you're getting.
>
> Agreed, RCU protects the net_generic structure, but not the structures
> pointed to by that structure.
They are protected by struct net reference counting.
>> Maybe I'm missing something in your question, can you provide some
>> testcase, that you suspect may cause an OOPS?
>
> Just trying to understand what prevents one task from calling
> net_generic() to pick up the tun_net pointer at the same time some other
> task calls tun_net_exit().
If this task dereferences a "held" struct net, then should be OK. If
this task does not, this will OOPs in any case.
Consider the struct net to look like
struct net {
...
void *ptrs[N];
}
and the net_generic to be just
static inline void net_generic(struct net *net, int id)
{
BUG_ON(id >= N);
return net->ptrs[id - 1];
}
That's the same to what I propose, except for the ptrs array is on the
RCU protected memory.
> Thanx, Pau
Thanks,
Pavel
next prev parent reply other threads:[~2008-04-11 15:21 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-10 14:57 [PATCH 0/14 (3 subsets)] Make tuns and vlans devices work per-net Pavel Emelyanov
2008-04-10 15:01 ` [PATCH 1/14][NETNS]: Introduce the net-subsys id generator Pavel Emelyanov
2008-04-10 17:37 ` [Devel] " Paul Menage
2008-04-10 20:52 ` Daniel Lezcano
2008-04-11 7:56 ` Pavel Emelyanov
2008-04-10 15:06 ` [PATCH 3/14][TUN]: Introduce the tun_net structure Pavel Emelyanov
2008-04-11 1:01 ` Paul E. McKenney
2008-04-11 7:55 ` Pavel Emelyanov
2008-04-11 15:04 ` Paul E. McKenney
2008-04-11 15:45 ` Pavel Emelyanov [this message]
2008-04-11 16:27 ` Paul E. McKenney
2008-04-12 8:44 ` Pavel Emelyanov
2008-04-15 7:44 ` David Miller
2008-04-15 10:31 ` Pavel Emelyanov
[not found] ` <48048411.5030506-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-04-15 10:06 ` David Miller
2008-04-10 15:07 ` [PATCH 4/14][TUN]: Actually make the tun_dev_list per-net Pavel Emelyanov
2008-04-10 15:09 ` [PATCH 5/14][TUN]: Allow to register tun devices in namespace Pavel Emelyanov
2008-04-10 15:10 ` [PATCH 6/14][RTNL]: Introduce the rtnl_kill_links call Pavel Emelyanov
[not found] ` <47FE2E01.6030000-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-04-10 22:09 ` Daniel Hokka Zakrisson
2008-04-11 8:01 ` Pavel Emelyanov
2008-04-11 12:48 ` Patrick McHardy
2008-04-10 15:13 ` [PATCH 7/14][VLAN]: Tag vlan_group with device, not ifindex Pavel Emelyanov
2008-04-10 15:16 ` [PATCH 9/14][VLAN]: Add net argument to proc init/cleanup calls Pavel Emelyanov
[not found] ` <47FE2AD4.9080609-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-04-10 15:04 ` [PATCH 2/14][NETNS]: Generic per-net pointers Pavel Emelyanov
2008-04-11 13:43 ` Daniel Lezcano
[not found] ` <47FF6B1B.5090106-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-04-11 14:29 ` Pavel Emelyanov
2008-04-10 15:14 ` [PATCH 8/14][VLAN]: Introduce the vlan_net structure Pavel Emelyanov
2008-04-10 15:18 ` [PATCH 10/14][VLAN]: Create proc files in proper net Pavel Emelyanov
2008-04-10 15:23 ` [PATCH 14/14][VLAN]: Migrate proc files when vlan device is moved to namespace Pavel Emelyanov
2008-04-10 15:19 ` [PATCH 11/14][VLAN]: Make /proc/net/vlan/conf file show per-net info Pavel Emelyanov
2008-04-10 15:20 ` [PATCH 12/14][VLAN]: Make vlan_name_type per-net Pavel Emelyanov
2008-04-10 15:22 ` [PATCH 13/14][VLAN]: Allows vlan devices registration in net namespace Pavel Emelyanov
2008-04-11 15:42 ` [PATCH 0/14 (3 subsets)] Make tuns and vlans devices work per-net Daniel Lezcano
2008-04-11 15:57 ` Pavel Emelyanov
2008-04-11 18:11 ` 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=47FF8782.6010006@openvz.org \
--to=xemul@openvz$(echo .)org \
--cc=benjamin.thery@bull$(echo .)net \
--cc=containers@lists$(echo .)osdl.org \
--cc=den@openvz$(echo .)org \
--cc=dlezcano@fr$(echo .)ibm.com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=paulmck@linux$(echo .)vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox