Re: [PATCH 14/16] vfs: Implement mount_super_once

[H. Peter Anvin]

On April 19, 2016 11:22:24 AM PDT, ebiederm@xxxxxxxxxxxx wrote:
>Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
>
>> On Fri, Apr 15, 2016 at 8:35 AM, Eric W. Biederman
>> <ebiederm@xxxxxxxxxxxx> wrote:
>>> The devpts filesystem has a notion of a system or primary instance
>of
>>> devpts.  To retain the notion of a primary system instance of devpts
>>> the code needs a way to allow userspace to mount the internally
>>> mounted instance of devpts when it is not currently mounted by
>>> userspace.  The new helper mount_super_once allows that.
>>
>> This is where I stopped reading this patch series.
>>
>> No.
>>
>> We want to get *rid* of the idiotic "primary instance" crap.
>
>That is actually pretty much the opposite of what you said last time,
>but having looked at the cost to maintian a "primary instance" notion
>and what will break if we don't I am happy to remove such a notion
>from devpts.
>
>> The whole and only point of doing the "which pts filesystem am I
>> associated with" for ptmx is to stop the idiotic "one devpts is
>> pecial".
>>
>> I don't want to see 16 random patches.
>>
>> I want to see *one* patch that makes /dev/ptmx look up the pts
>> filesystem, and be done with it.
>
>Now that I know where most of the landmines are in userspace I
>performed
>some limited testing to see to see what the implications are:
>
>Causing every userspace mount of devpts to use mount_nodev means the
>following:
>
>- Support for reserving ptys for the system devpts instance using
>  /proc/sys/kernel/pty/reserve needs to be removed.
>
>- On CentOS6 devpts will wind up mounted twice /dev/pts.
>
>- Open of /dev/ptmx can use devpts_mnt to find the devpts filesystem.
>
>In my cursory testing userspace still boots and works desipite those
>changes so I am quite happy to go down this path.
>
>Eric

On a totally different subject: I'm still quite unhappy with the pty number assignment policy.  We had to move away from a completely circular policy because of glibc issues in the handling of utmp, which may or may not have been fixed since, but the current policy of always allocating the lowest number is absolutely pessimal for accidental references to a stale pty.

At the time, I suggested that we'd go with a circular policy within the used high water mark, which would still work around the glibc problem; another option would be to quarantine a pty number for a time before reallocation.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.