New: Documenting if both /dev/ptmx and /dev/pts/ptmx can be accessed at the same time.
https://bugzilla.kernel.org/show_bug.cgi?id=221881
Bug ID: 221881
Summary: Documenting if both /dev/ptmx and /dev/pts/ptmx can be
accessed at the same time.
Product: Documentation
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: low
Priority: P3
Component: man-pages
Assignee: [email protected]
Reporter: [email protected]
Regression: No
Traditionally pseudoterminals are created through the device file /dev/ptmx. With the introduction of the devpts virtual filesystem, new slave pseudoterminals are created through /dev/pts/ptmx device file and allocated in /dev/pts/*. In order to mantain backward compatibility, the device file /dev/ptmx has not been dropped byt instead requests to /dev/ptmx are forwarded to /dev/pts/ptmx.
However, this is not preserved by bind mounts to /dev/ptmx: for example, after launching
"# mount --bind /dev/ptmx /dev/ptmx"
any attempt to opening /dev/ptmx will fail. Instead, bind mounting /dev/pts/ptmx works as expected (if devptsfs has previously been mounted with ptmxmode=0666). This is quite problematic if one wants to give access to /dev/ptmx inside a mount namespace. The solution provided in
https://docs.kernel.org/filesystems/devpts.html is to remount devptsfs with the mount option ptmxmode=0666, then remove /dev/ptmx and finally place a bind mount or a symlink pointing to /dev/pts/ptmx.
The issues involving documentations are the following:
1. man 4 pts only describes the old interface /dev/ptmx and the newer defice file /dev/pts/ptmx is never mentioned. /dev/pts/ptmx should at least be mentioned as an alternative for /dev/ptmx both to help software maintainers moving to the new interface and to provide access to pseudoterminals inside mount namespaces;
2. nowhere inside the documentation is explained if it is safe to provide access to both /dev/ptmx and /dev/pts/ptmx at the same time. All provided scenarios give access to exactly one of /dev/ptmx and /dev/pts/ptmx device files. If we have to avoid giving full access to both /dev/ptmx and /dev/pts/ptmx through ptmxmode=0666 (to avoid race conditions) then it should be explicitly stated. On the contrary, a note that says there are no problems in giving full access to both these device files at the same time should be added.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221881] Documenting if both /dev/ptmx and /dev/pts/ptmx can be accessed at the same time.
https://bugzilla.kernel.org/show_bug.cgi?id=221881
--- Comment #1 from Alejandro Colomar ([email protected]) --- Hi Paolo,
Quoted 52 lines
Date: 2026-08-13 14:20:33+0000
From: [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221881
Bug ID: 221881
Summary: Documenting if both/dev/ptmxand/dev/pts/ptmxcan be
accessed at the same time.
Product: Documentation
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: low
Priority: P3
Component: man-pages
Assignee: [email protected]
Reporter: [email protected]
Regression: NoTraditionally pseudoterminals are created through the device file
/dev/ptmx. With the introduction of the devpts virtual filesystem, new slave pseudoterminals are created through/dev/pts/ptmxdevice file and allocated in/dev/pts/*. In order to mantain backward compatibility, the device file/dev/ptmxhas not been dropped byt instead requests to/dev/ptmxare forwarded
to/dev/pts/ptmx.However, this is not preserved by bind mounts to
/dev/ptmx: for example, after
launching"# mount --bind
/dev/ptmx/dev/ptmx"any attempt to opening
/dev/ptmxwill fail. Instead, bind mounting/dev/pts/ptmxworks as expected (if devptsfs has previously been mounted with ptmxmode=0666). This is quite problematic if one wants to give access to/dev/ptmxinside a mount namespace. The solution provided in
https://docs.kernel.org/filesystems/devpts.html is to remount devptsfs with the
mount option ptmxmode=0666, then remove/dev/ptmxand finally place a bind mount or a symlink pointing to/dev/pts/ptmx.The issues involving documentations are the following:
1. man 4 pts only describes the old interface
/dev/ptmxand the newer defice file/dev/pts/ptmxis never mentioned./dev/pts/ptmxshould at least be mentioned as an alternative for/dev/ptmxboth to help software maintainers moving to the new interface and to provide access to pseudoterminals inside mount namespaces;
Quoted 8 lines
2. nowhere inside the documentation is explained if it is safe to provide access to both
/dev/ptmxand/dev/pts/ptmxat the same time. All provided scenarios give access to exactly one of/dev/ptmxand/dev/pts/ptmxdevice files. If we have to avoid giving full access to both/dev/ptmxand/dev/pts/ptmxthrough ptmxmode=0666 (to avoid race conditions) then it should be explicitly stated. On the contrary, a note that says there are no problems in giving full access to both these device files at the same time should be added.
If you know how to solve those issues, would you mind sending a patch? If so, plese have a look at
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING>
and
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING.d/>.
If you don't know these, you could maybe ask through email to the kernel maintainers of those features, and CC the linux-man@ mailing list, so we learn that information. (The links above will also help you.)
Have a lovely day!
Alex
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Alejandro Colomar
maintainerHi Paolo,
Quoted 48 lines
Date: 2026-08-13 14:20:33+0000
From: [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221881
Bug ID: 221881
Summary: Documenting if both/dev/ptmxand/dev/pts/ptmxcan be
accessed at the same time.
Product: Documentation
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: low
Priority: P3
Component: man-pages
Assignee: [email protected]
Reporter: [email protected]
Regression: NoTraditionally pseudoterminals are created through the device file
/dev/ptmx. With the introduction of the devpts virtual filesystem, new slave pseudoterminals are created through/dev/pts/ptmxdevice file and allocated in/dev/pts/*. In order to mantain backward compatibility, the device file/dev/ptmxhas not been dropped byt instead requests to/dev/ptmxare forwarded to/dev/pts/ptmx.However, this is not preserved by bind mounts to
/dev/ptmx: for example, after launching"# mount --bind
/dev/ptmx/dev/ptmx"any attempt to opening
/dev/ptmxwill fail. Instead, bind mounting/dev/pts/ptmxworks as expected (if devptsfs has previously been mounted with ptmxmode=0666). This is quite problematic if one wants to give access to/dev/ptmxinside a mount namespace. The solution provided in
https://docs.kernel.org/filesystems/devpts.html is to remount devptsfs with the mount option ptmxmode=0666, then remove/dev/ptmxand finally place a bind mount or a symlink pointing to/dev/pts/ptmx.The issues involving documentations are the following:
1. man 4 pts only describes the old interface
/dev/ptmxand the newer defice file/dev/pts/ptmxis never mentioned./dev/pts/ptmxshould at least be mentioned as an alternative for/dev/ptmxboth to help software maintainers moving to the new interface and to provide access to pseudoterminals inside mount namespaces;
Quoted 8 lines
2. nowhere inside the documentation is explained if it is safe to provide access to both
/dev/ptmxand/dev/pts/ptmxat the same time. All provided scenarios give access to exactly one of/dev/ptmxand/dev/pts/ptmxdevice files. If we have to avoid giving full access to both/dev/ptmxand/dev/pts/ptmxthrough ptmxmode=0666 (to avoid race conditions) then it should be explicitly stated. On the contrary, a note that says there are no problems in giving full access to both these device files at the same time should be added.
If you know how to solve those issues, would you mind sending a patch? If so, plese have a look at
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING>
and
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING.d/>.
If you don't know these, you could maybe ask through email to the kernel maintainers of those features, and CC the linux-man@ mailing list, so we learn that information. (The links above will also help you.)
Have a lovely day!
Alex
Signature · 1 line
<https://www.alejandro-colomar.es>