OpenVZ Forum


Home » Mailing lists » Devel » Re: [RFC][PATCH] Make access to taks's nsproxy liter
Re: [RFC][PATCH] Make access to taks's nsproxy liter [message #19604] Wed, 08 August 2007 16:29 Go to next message
ebiederm is currently offline  ebiederm
Messages: 1354
Registered: February 2006
Senior Member
Pavel Emelyanov <xemul@openvz.org> writes:

> When someone wants to deal with some other taks's namespaces
> it has to lock the task and then to get the desired namespace
> if the one exists. This is slow on read-only paths and may be
> impossible in some cases.
>
> E.g. Oleg recently noticed a race between unshare() and the
> (just sent for review) pid namespaces - when the task notifies
> the parent it has to know the parent's namespace, but taking
> the task_lock() is impossible there - the code is under write
> locked tasklist lock.
>
> On the other hand switching the namespace on task (daemonize)
> and releasing the namespace (after the last task exit) is rather
> rare operation and we can sacrifice its speed to solve the
> issues above.


Looks pretty decent but we need to clearly say what lock
you have to have to assign to the nsproxy pointer.

In this case it isn't so much of a lock as simply you must
be the process so I think the code is ok.  But it sufficiently
subtle it probably needs to be spelled out.

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
Re: [RFC][PATCH] Make access to taks's nsproxy liter [message #19669 is a reply to message #19604] Thu, 09 August 2007 07:10 Go to previous message
Pavel Emelianov is currently offline  Pavel Emelianov
Messages: 1149
Registered: September 2006
Senior Member
Eric W. Biederman wrote:
> Pavel Emelyanov <xemul@openvz.org> writes:
> 
>> When someone wants to deal with some other taks's namespaces
>> it has to lock the task and then to get the desired namespace
>> if the one exists. This is slow on read-only paths and may be
>> impossible in some cases.
>>
>> E.g. Oleg recently noticed a race between unshare() and the
>> (just sent for review) pid namespaces - when the task notifies
>> the parent it has to know the parent's namespace, but taking
>> the task_lock() is impossible there - the code is under write
>> locked tasklist lock.
>>
>> On the other hand switching the namespace on task (daemonize)
>> and releasing the namespace (after the last task exit) is rather
>> rare operation and we can sacrifice its speed to solve the
>> issues above.
> 
> 
> Looks pretty decent but we need to clearly say what lock
> you have to have to assign to the nsproxy pointer.

no locks - only current is allowed to change its nsproxy!

> In this case it isn't so much of a lock as simply you must
> be the process so I think the code is ok.  But it sufficiently
> subtle it probably needs to be spelled out.
> 
> Eric
> 

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
Previous Topic: Re: [RFC][PATCH] Make access to taks's nsproxy liter
Next Topic: Re: [RFC][PATCH] Make access to taks's nsproxy liter
Goto Forum:
  


Current Time: Sun Jul 21 03:41:25 GMT 2024

Total time taken to generate the page: 0.02280 seconds