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

[Eric W. Biederman]

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
complications.  I suspect in some cases that gets people to call
syscall(SYS_clone) and thus run into the pid caching of glibc.

Eric