Re: [PATCH] devpts: Sensible /dev/ptmx & force newinstance

From: H. Peter Anvin
Date: Sat Dec 19 2015 - 23:37:36 EST


On December 19, 2015 8:11:50 PM PST, ebiederm@xxxxxxxxxxxx wrote:
>ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes:
>
>>>> In that system ptys simply did not work after boot when I tested
>>>> associating /dev/ptmx with the first mount of the devpts
>filesystem.
>>>
>>> Assuming userspace isn't broken by that patch, is a fixed
>association
>>> with first mount otherwise an acceptable solution for magic
>/dev/ptmx
>>> (where /dev/ptmx is not a symlink to /dev/pts/ptmx)?
>>
>> I do not believe a fixed association with the first mount is an
>> acceptable solution for implementing /dev/ptmx in association with
>> a change to cause mount of devpts to be an independent filesystem.
>> Such an association fails to be backwards compatible with existing
>> userspace, and it is extremely fragile.
>
>Ugh. After reviewing the userspace code that mounts devpts we have
>to do use a magic /dev/ptmx to solve the issue we are trying to solve.
>
>The fragility of detecting the primary system devpts seems solvable.
>
>CentOS5 and openwrt-15.05 mount devpts, unmount devpts,
>then mount devpts again. So a rule of mouting the internal devpts if
>it
>isn't mounted would work for those.
>
>CentOS6 uses switch_root and moves it's early mount of devpts onto the
>primary root, and then because devpts is also in /etc/fstab tries and
>fails to mount devpts once more at the same location. Implying
>newinstance will make that mounting devpts twice. That sounds solvable
>but I don't see a clean way of detecting that case yet.
>
>Ugh.
>
>I am going to pound my head up against what is needed to find the
>primary system mount of devpts for a bit more and see if I can solve
>that. Otherwise this exercise is pointless.
>
>Eric

Does it matter if it mounts devpts twice? It seems like a waste of a minuscule amount of memory, and nothing else.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/