[Devel] Re: [PATCH 11/11][v3]: Enable multiple instances of devpts
[EMAIL PROTECTED] wrote: Agree in general. Not sure if you are implying remount is necessary just to change permissions of pts/ptmx. Why not chmod 0666 /dev/pts/ptmx ? The remount changes the 'ptmxmode' setting, but since the node exists, the 'ptmxmode' setting is never used again and we need to chmod. A chmod requires bigger changes to existing scripts than an option which can be set in /etc/fstab. ptmx node in multi-instance mounts continue to get PTMX_DEFAULT_MODE permissions (not 000) right ? (unless -o ptmxmode is specified) It's probably easier to always default it to zero and expect that the mode is set explicitly. -hpa ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 11/11][v3]: Enable multiple instances of devpts
H. Peter Anvin [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Agree in general. Not sure if you are implying remount is necessary just to change permissions of pts/ptmx. Why not chmod 0666 /dev/pts/ptmx ? The remount changes the 'ptmxmode' setting, but since the node exists, the 'ptmxmode' setting is never used again and we need to chmod. A chmod requires bigger changes to existing scripts than an option which can be set in /etc/fstab. Ok. From implementation pov, we can cache the ptmx dentry in s_fs_info and use it during remount to change the permissions. We could lookup ptmx during remount, but caching is simpler ? ptmx node in multi-instance mounts continue to get PTMX_DEFAULT_MODE permissions (not 000) right ? (unless -o ptmxmode is specified) It's probably easier to always default it to zero and expect that the mode is set explicitly. Ok. BTW, I have added CONFIG_DEVPTS_MULTIPLE_INSTANCES and moved the usage info from 11/11 to Documentation/fs/devpts.txt. Will make above ptmx changes, port to recent ttydev tree and send updated patchset in a couple of days. Thanks, suka ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 11/11][v3]: Enable multiple instances of devpts
[EMAIL PROTECTED] wrote: 2. To effectively use the multi-instance mode, applications/libraries should, open /dev/pts/ptmx instead of /dev/ptmx but obviously this would fail in the legacy mode. NOT SO! /dev/ptmx is required by Unix98 (which is arguably obsolete, but still.) Applications SHOULD NOT try to open /dev/pts/pmtx. This should be considered strictly an internal implementation detail. Applications should use posix_openpt(), openpty() or forkpty(); libraries should use /dev/ptmx. -hpa ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 11/11][v3]: Enable multiple instances of devpts
[EMAIL PROTECTED] wrote: Ah, ok. Well, I will remove that para from the patch description. If the -o newinstance is NOT followed by the bind mount, ptys won't work and would be nice if we can print a useful message when opening /dev/ptmx. We can't, really, because it will open the global ptmx. This is an unfortunate side effect of the backwards-compatibility code. This is also why I don't like the bind mount; the symlink option has the nice property that f*ckups are more obvious. The non-legacy option should be as follows, IMNSHO: - ALL mounts of devpts use -o newinstance; - /dev/ptmx - pts/ptmx symlink. -hpa ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 11/11][v3]: Enable multiple instances of devpts
O We can't, really, because it will open the global ptmx. This is an unfortunate side effect of the backwards-compatibility code. This is also why I don't like the bind mount; the symlink option has the nice property that f*ckups are more obvious. It's asking for trouble with existing systems and users that upgrade. /dev/ptmx should remain a proper device file for the non container case. Should /dev/ptmx give you a node in the 'master' pty namespace or a node in your current containers pty namespace ? ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 11/11][v3]: Enable multiple instances of devpts
Alan Cox wrote: O We can't, really, because it will open the global ptmx. This is an unfortunate side effect of the backwards-compatibility code. This is also why I don't like the bind mount; the symlink option has the nice property that f*ckups are more obvious. It's asking for trouble with existing systems and users that upgrade. /dev/ptmx should remain a proper device file for the non container case. I did say that as being the desired *eventual* goal. Should /dev/ptmx give you a node in the 'master' pty namespace or a node in your current containers pty namespace ? Well, since there is no current containers pty namespace per se, it will give you a node in the default (initial) pty namespace unless the bind mount is set up. -hpa ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 11/11][v3]: Enable multiple instances of devpts
H. Peter Anvin [EMAIL PROTECTED] wrote: Alan Cox wrote: O We can't, really, because it will open the global ptmx. This is an unfortunate side effect of the backwards-compatibility code. This is also why I don't like the bind mount; the symlink option has the nice property that f*ckups are more obvious. It's asking for trouble with existing systems and users that upgrade. /dev/ptmx should remain a proper device file for the non container case. I did say that as being the desired *eventual* goal. Should /dev/ptmx give you a node in the 'master' pty namespace or a node in your current containers pty namespace ? Well, since there is no current containers pty namespace per se, it will give you a node in the default (initial) pty namespace unless the bind mount is set up. But that node will not be accessible if there is a newinstance mount without the bind mount ? IOW 1. mount -t devpts -o newinstance lxcpts /dev/pts 2. mount -o bind /dev/pts/ptmx /dev/ptmx If both #1 and #2 or neither happen there is no problem. If #1 is NOT followed by #2, ptys break in new namespace. An open of /dev/ptmx in this case will allocate a pty in the initial namespace, but since #1 is complete, we lookup the pty (/dev/pts/7) in the new namespace and fail. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 11/11][v3]: Enable multiple instances of devpts
[EMAIL PROTECTED] wrote: But that node will not be accessible if there is a newinstance mount without the bind mount ? IOW 1. mount -t devpts -o newinstance lxcpts /dev/pts 2. mount -o bind /dev/pts/ptmx /dev/ptmx If both #1 and #2 or neither happen there is no problem. If #1 is NOT followed by #2, ptys break in new namespace. An open of /dev/ptmx in this case will allocate a pty in the initial namespace, but since #1 is complete, we lookup the pty (/dev/pts/7) in the new namespace and fail. That is correct. -hpa ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 11/11][v3]: Enable multiple instances of devpts
H. Peter Anvin [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: But that node will not be accessible if there is a newinstance mount without the bind mount ? IOW 1. mount -t devpts -o newinstance lxcpts /dev/pts 2. mount -o bind /dev/pts/ptmx /dev/ptmx If both #1 and #2 or neither happen there is no problem. If #1 is NOT followed by #2, ptys break in new namespace. An open of /dev/ptmx in this case will allocate a pty in the initial namespace, but since #1 is complete, we lookup the pty (/dev/pts/7) in the new namespace and fail. That is correct. So afaics, we don't have any issues when operating only in one mode (single-instance or multi-instance). When both modes are used simultaneously, we have following options: 1. Let container-startup deal with it i.e use above bind-mount approach or, as Serge mentioned, have containers chroot and make ptmx-pts/ptmx symlink or another option ? 2. Have the ptmx-node even in the initial mount and a permanent ptmx symlink - Did we fully rule it out :-) 3. Choose #2 with a (yet-another) config token. Not sure if it adds value or further complicates the matrix. Both #1 and #2 have their pros/cons. Long term, one advantage I see with #2 is that we don't force container-scripts do something now that they can/should potentially undo later if we ever want to remove the single-instance semantics. Does presence of /dev/pts/ptmx in single-instance case break userspace ? If it only surprises, will adding notes to pts(4) man page help ? Or are there other options ? Thanks, Suka ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 11/11][v3]: Enable multiple instances of devpts
[EMAIL PROTECTED] wrote: When both modes are used simultaneously, we have following options: 1. Let container-startup deal with it i.e use above bind-mount approach or, as Serge mentioned, have containers chroot and make ptmx-pts/ptmx symlink or another option ? 2. Have the ptmx-node even in the initial mount and a permanent ptmx symlink - Did we fully rule it out :-) 3. Choose #2 with a (yet-another) config token. Not sure if it adds value or further complicates the matrix. Both #1 and #2 have their pros/cons. Long term, one advantage I see with #2 is that we don't force container-scripts do something now that they can/should potentially undo later if we ever want to remove the single-instance semantics. Does presence of /dev/pts/ptmx in single-instance case break userspace ? If it only surprises, will adding notes to pts(4) man page help ? Well, userspaces which implement the #2 option should add the newinstance mount option to ALL mounts of devpts, including the first one. That way the default pts instance is never actually exposed. Container scripts which need to work in both modes can trivially determine if they need to do the bind-mount, simply by seeing if /dev/ptmx is already a symlink. -hpa ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
