Glauber Costa <glommer@xxxxxxxxxxxxx> writes: >> The twist of course is what does a boot mean. If we are really after >> machine boots than the current behavior is correct. >> >> Looking back in the archives the desired behavior appears to be a value >> that can be used to see if a pid value must be stale. >> >> As a stale pid detector boot_id is pretty lousy. Pids can still be >> reused. >> >> Still a role as a stale pid detector makes it clear which namespace >> boot_id should be in and how we should treat boot_id upon migration. >> >> You can only serve as a stale pid detector if you are in the pid >> namespace. >> >> So at this point patches are welcome. Hopefully with a summary >> of the discussion. >> >> Eric >> > > Your discussion about boot_id being a limited solution is totally valid. > But it is orthogonal to the question of whether or not a container > should have it. The important part is that boot_id as originally conceived is an identifier to be used in conjunction with pids. Therefore boot_id is a proper pid_namespace component, and there are no semantic problems with putting it in the kernel. > I took a look at this, and I think the kernel should be in perfect > position to do it. Agreed. > boot_id as a pid namespace id is a very well defined concept. Agreed. A reference to the history and the definition needs to be in the patch description. > We just > need an interface to set it up to make it stable across migration. Maybe > we can accept writes to this file as valid, provided the pid namespace > has only the init process. I think the easy solution is to take advantage of the fact that boot_id is initialized lazily. Don't allow writes if boot_id has already been read. > Then any tool could clone, mount proc, set this id, and continue > normally. Any objections ? My biggest concern is that creating multiple pid namespaces might allow a way to drain the entropy pool in a way that we don't allow normal users. This is important to look at as with a little luck we will have unprivileged creation of user namespaces and pid namespaces in the near future. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
