OpenVZ Forum


Home » Mailing lists » Devel » Namespaces exhausted CLONE_XXX bits problem
Re: Namespaces exhausted CLONE_XXX bits problem [message #26065 is a reply to message #26030] Tue, 15 January 2008 07:53 Go to previous messageGo to previous message
Cedric Le Goater is currently offline  Cedric Le Goater
Messages: 443
Registered: February 2006
Senior Member
Serge E. Hallyn wrote:
> Quoting Cedric Le Goater (clg@fr.ibm.com):
>> to be more precise :
>>
>> 	long sys_clone_something(struct clone_something_args args) 
>>
>> and 
>>
>> 	long sys_unshare_something(struct unshare_something_args args) 
>>
>> The arg passing will be slower bc of the copy_from_user() but we will 
>> still have the sys_clone syscall for the fast path.
>>
>> C.
> 
> I'm fine with the direction you're going, but just as one more option,
> we could follow more of the selinux/lsm approach of first requesting
> clone/unshare options, then doing the actual clone/unshare.  So
> something like
> 
> 	sys_clone_request(extended_64bit_clone_flags)
> 	sys_clone(usual args)
> 
> or
> 
> 	echo pid,mqueue,user,ipc,uts,net > /proc/self/clone_unshare
> 	clone()

For my information, why selinux/lsm chose that 2 steps approach ?
What kind of issues are they trying to solve ?

Thanks,

C. 
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: [RFC PATCH 0/4] [RESEND] Change default MSGMNI tunable to scale with lowmem
Next Topic: [patch 0/9] mount ownership and unprivileged mount syscall (v6)
Goto Forum:
  


Current Time: Thu Jul 03 19:16:03 GMT 2025

Total time taken to generate the page: 0.02575 seconds