All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@kernel.org
To: linux-man@vger.kernel.org
Subject: [Bug 221881] New: Documenting if both /dev/ptmx and /dev/pts/ptmx can be accessed at the same time.
Date: Thu, 13 Aug 2026 14:20:33 +0000	[thread overview]
Message-ID: <bug-221881-11311@https.bugzilla.kernel.org/> (raw)

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: documentation_man-pages@kernel-bugs.osdl.org
          Reporter: dedo.paolo.24+linux@proton.me
        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.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

             reply	other threads:[~2026-08-13 14:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13 14:20 bugzilla-daemon [this message]
2026-08-13 14:56 ` [Bug 221881] New: Documenting if both /dev/ptmx and /dev/pts/ptmx can be accessed at the same time Alejandro Colomar
2026-08-13 14:56 ` [Bug 221881] " bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-221881-11311@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@kernel.org \
    --cc=linux-man@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.