Re: [PATCH 0/9] Multiple devpts instances

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> 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