[Devel] [RFC][PATCH 4/4]: Enable cloning PTY namespaces
Cedric Le Goater
clg at fr.ibm.com
Wed Feb 6 10:00:22 PST 2008
>>>>>>
>>>>>> +struct pts_namespace *new_pts_ns(void)
>>>>>> +{
>>>>>> + struct pts_namespace *ns;
>>>>>> +
>>>>>> + ns = kmalloc(sizeof(*ns), GFP_KERNEL);
>>>>>> + if (!ns)
>>>>>> + return ERR_PTR(-ENOMEM);
>>>>>> +
>>>>>> + ns->mnt = kern_mount_data(&devpts_fs_type, ns);
>>>>> You create a circular references here - the namespace
>>>>> holds the vfsmnt, the vfsmnt holds a superblock, a superblock
>>>>> holds the namespace.
>>>> Hmm, yeah, good point. That was probably in my original version last
>>>> year, so my fault not Suka's. Suka, would it work to have the
>>>> sb->s_info point to the namespace but not grab a reference, than have
>>> If you don't then you may be in situation, when this devpts
>>> is mounted from userspace and in case the namespace is dead
>>> superblock will point to garbage... Superblock MUST hold the
>>> namespace :)
>> But when the ns is freed sb->s_info would be NULL. Surely the helpers
>> can be made to handle that safely?
>
> Hm... How do we find the proper superblock? Have a reference on
> it from the namespace? I'm afraid it will be easy to resolve the
> locking issues here.
>
> I propose another scheme - we simply don't have ANY references
> from namespace to superblock/vfsmount, but get the current
> namespace in devpts_get_sb() and put in devpts_free_sb().
I've choosen another path in mq_ns.
I also don't take any refcount on superblock/vfsmount of the new mq_ns
bc of the circular ref. I've considered that namespaces only apply to
processes : the refcount of a namespace is incremented each time a new
task is cloned and the namespace (in my case mq_ns) is released when
the last tasks exists. But this becomes an issue with user mounts which
survives task death. you end up having a user mount pointing to a bogus
mq_ns.
unless you require to have CLONE_NEWNS at the sametime.
Now, this CLONE_NEWNS enforcement seems to be an issue with bind mount.
... jumping to the other thread :)
C.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list