[lxc-devel] Working with glibc (PID/TID caches).

[Serge Hallyn]

Quoting Eric W. Biederman (ebiederm at xmission.com):
> Serge Hallyn <serge.hallyn at ubuntu.com> writes:
> 
> > Quoting Eric W. Biederman (ebiederm at xmission.com):
> >> 
> >> Serge Hallyn <serge.hallyn at ubuntu.com> writes:
> >> > Quoting Carlos O'Donell (carlos at redhat.com):
> >> >> There was a complaint a while back from someone working
> >> >> on containers about glibc PID caching. I recently received
> >> >> another request to provide userspace with a way to reset
> >> >> any PID or TID caches to make clone-based sandboxing easier
> >> >> (CLONE_NEWPID).
> >> >> 
> >> >> How did lxc workaround the PID cache in glibc? What APIs
> >> >> could glibc provide to help the implementation of containers?
> 
> >> That said clone(3) is a cumbersome API to use when you don't want to
> >> share the same address space (it sucks to have to allocate an extra
> >> stack just to call fork(2)), and that probably gets people resorting to
> >> calling syscall(SYS_clone,...) and then having pid problems.
> 
> > So, the long and short of it is, we're all happy with what we've got?
> >
> > Or did I as usual misread your main point?
> 
> clone(3) sucks to use for creating namespaces.  Having to create a stack
> when you don't pass CLONE_MM adds all sorts of unnecessary

Ah, yes.  Well at least there are enough examples of boilerplate out
there for ppl to cut-paste, but agreed it would be nice to have a
simpler to use api.  Could clone3(3) simply calculate 10*native page
size and allocate that much space, or something like that?

> complications.  I suspect in some cases that gets people to call
> syscall(SYS_clone) and thus run into the pid caching of glibc.
> 
> Eric