"H. Peter Anvin" <hpa@xxxxxxxxx> writes: > Daniel Lezcano wrote: >>> >>> Resource limit partitioning is a much bigger and orthogonal problem. >>> >> In this case we don't have the pty allocated independently, no ? >> I mean one container can allocate 4095 pty, making a pty starvation for others >> containers. Or imagine I am a vilain and I want to mess the other containers, >> I can do echo 0 > /proc/sys/kernel/pty/max. >> AFAIR, we said people making isolation of a resource is in charge (if it is >> relevant), to take into account the /proc/sys part. >> >> For example, making the network per namespace all the network configuration >> variable located in /proc/sys/net are per namespace too. When it is irrelevant >> the file is read-only or just not displayed. Such as for global limits like /proc/sys/kernel/pty/max. The design is a little different here because we do this at a filesystem level. >> IMHO, pty/max and pty/nr is part of the "multiple devpts instances" feature. >> > > Naming and resource partitioning are two orthogonal issues, regardless of what's > IYHO. > > Really. You have the same classes of issues with ANY allocatable > resource in the system. Period. Furthermore, there are quite a few > applications which want one and not the other. Trying to entangle > them is broken. Peter they are entangled issues because the limits frequently show up in the naming. pids are a good example of that. That said with the approach we have taken with ptys, is to move all of the relevant files and state into the pty filesystem. That is a very good model for new development, especially because it does not require magic systems calls or magic glue elsewhere in the kernel. Using that model if we are to add limits on the names generated by a particular devpts instance those control files should likely live in devpts itself. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers