Messages in this thread | | | Subject | Re: [PATCH] devpts: Sensible /dev/ptmx & force newinstance | From | "H. Peter Anvin" <> | Date | Mon, 14 Dec 2015 11:55:06 -0800 |
| |
On 12/14/15 11:47, Peter Hurley wrote: > On 12/11/2015 11:40 AM, Eric W. Biederman wrote: >> Forcing newinstance for every mount of the devpts filesystem actually >> requires the association between /dev/ptmx and the currently mounted >> instance of devpts at /dev/pts. Simply remembering the first mount of >> the devpts filesystem and associating that with /dev/ptmx is not >> enough. I am aware of at least one instance where an initramfs mounts >> devpts before the main system instance of devpts is mounted. > > Can you point me to that usage please? > > I ask because there's a patch to move devpts init from module initcall > up to fs initcall (neither devpts nor the pty driver is actually built > as a module anyway), and I'd like to look at what the consequences > might be for that userspace configuration. > > >> 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)? >
The problem is containers, I would think, if they create a new /dev/ptmx and then mount a separate devpts instance instead of doing a bind mount.
-hpa
| |