Quoting Eric W. Biederman (ebied...@xmission.com): > Serge Hallyn <serge.hal...@ubuntu.com> writes: > > > Quoting Eric W. Biederman (ebied...@xmission.com): > >> > >> Serge Hallyn <serge.hal...@ubuntu.com> writes: > >> > Quoting Carlos O'Donell (car...@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 _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
