24 May, 2019
1 commit
-
Based on 1 normalized pattern(s):
this file is part of the linux kernel and is made available under
the terms of the gnu general public license version 2 or at your
option any later version incorporated herein by referenceextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 18 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Richard Fontana
Reviewed-by: Allison Randal
Reviewed-by: Armijn Hemel
Reviewed-by: Kate Stewart
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190520075211.321157221@linutronix.de
Signed-off-by: Greg Kroah-Hartman
25 Aug, 2017
1 commit
-
The implementation of TIOCGPTPEER has two issues.
When /dev/ptmx (as opposed to /dev/pts/ptmx) is opened the wrong
vfsmount is passed to dentry_open. Which results in the kernel displaying
the wrong pathname for the peer.The second is simply by caching the vfsmount and dentry of the peer it leaves
them open, in a way they were not previously Which because of the inreased
reference counts can cause unnecessary behaviour differences resulting in
regressions.To fix these move the ioctl into tty_io.c at a generic level allowing
the ioctl to have access to the struct file on which the ioctl is
being called. This allows the path of the slave to be derived when
opening the slave through TIOCGPTPEER instead of requiring the path to
the slave be cached. Thus removing the need for caching the path.A new function devpts_ptmx_path is factored out of devpts_acquire and
used to implement a function devpts_mntget. The new function devpts_mntget
takes a filp to perform the lookup on and fsi so that it can confirm
that the superblock that is found by devpts_ptmx_path is the proper superblock.v2: Lots of fixes to make the code actually work
v3: Suggestions by Linus
- Removed the unnecessary initialization of filp in ptm_open_peer
- Simplified devpts_ptmx_path as gotos are no longer required[ This is the fix for the issue that was reverted in commit
143c97cc6529, but this time without breaking 'pbuilder' due to
increased reference counts - Linus ]Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl")
Reported-by: Christian Brauner
Reported-and-tested-by: Stefan Lippers-Hollmann
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Linus Torvalds
24 Aug, 2017
1 commit
-
This reverts commit c8c03f1858331e85d397bacccd34ef409aae993c.
It turns out that while fixing the ptmx file descriptor to have the
correct 'struct path' to the associated slave pty is a really good
thing, it breaks some user space tools for a very annoying reason.The problem is that /dev/ptmx and its associated slave pty (/dev/pts/X)
are on different mounts. That was what caused us to have the wrong path
in the first place (we would mix up the vfsmount of the 'ptmx' node,
with the dentry of the pty slave node), but it also means that now while
we use the right vfsmount, having the pty master open also keeps the pts
mount busy.And it turn sout that that makes 'pbuilder' very unhappy, as noted by
Stefan Lippers-Hollmann:"This patch introduces a regression for me when using pbuilder
0.228.7[2] (a helper to build Debian packages in a chroot and to
create and update its chroots) when trying to umount /dev/ptmx (inside
the chroot) on Debian/ unstable (full log and pbuilder configuration
file[3] attached).[...]
Setting up build-essential (12.3) ...
Processing triggers for libc-bin (2.24-15) ...
I: unmounting dev/ptmx filesystem
W: Could not unmount dev/ptmx: umount: /var/cache/pbuilder/build/1340/dev/ptmx: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)"apparently pbuilder tries to unmount the /dev/pts filesystem while still
holding at least one master node open, which is arguably not very nice,
but we don't break user space even when fixing other bugs.So this commit has to be reverted.
I'll try to figure out a way to avoid caching the path to the slave pty
in the master pty. The only thing that actually wants that slave pty
path is the "TIOCGPTPEER" ioctl, and I think we could just recreate the
path at that time.Reported-by: Stefan Lippers-Hollmann
Cc: Eric W Biederman
Cc: Christian Brauner
Cc: Al Viro
Signed-off-by: Linus Torvalds
18 Aug, 2017
1 commit
-
Christian Brauner reported that if you use the TIOCGPTPEER ioctl() to
get a slave pty file descriptor, the resulting file descriptor doesn't
look right in /proc//fd/. In particular, he wanted to use
readlink() on /proc/self/fd/ to get the pathname of the slave pty
(basically implementing "ptsname{_r}()").The reason for that was that we had generated the wrong 'struct path'
when we create the pty in ptmx_open().In particular, the dentry was correct, but the vfsmount pointed to the
mount of the ptmx node. That _can_ be correct - in case you use
"/dev/pts/ptmx" to open the master - but usually is not. The normal
case is to use /dev/ptmx, which then looks up the pts/ directory, and
then the vfsmount of the ptmx node is obviously the /dev directory, not
the /dev/pts/ directory.We actually did have the right vfsmount available, but in the wrong
place (it gets looked up in 'devpts_acquire()' when we get a reference
to the pts filesystem), and so ptmx_open() used the wrong mnt pointer.The end result of this confusion was that the pty worked fine, but when
if you did TIOCGPTPEER to get the slave side of the pty, end end result
would also work, but have that dodgy 'struct path'.And then when doing "d_path()" on to get the pathname, the vfsmount
would not match the root of the pts directory, and d_path() would return
an empty pathname thinking that the entry had escaped a bind mount into
another mount.This fixes the problem by making devpts_acquire() return the vfsmount
for the pts filesystem, allowing ptmx_open() to trivially just use the
right mount for the pts dentry, and create the proper 'struct path'.Reported-by: Christian Brauner
Cc: Al Viro
Acked-by: Eric Biederman
Signed-off-by: Linus Torvalds
06 Jun, 2016
1 commit
-
The /dev/ptmx device node is changed to lookup the directory entry "pts"
in the same directory as the /dev/ptmx device node was opened in. If
there is a "pts" entry and that entry is a devpts filesystem /dev/ptmx
uses that filesystem. Otherwise the open of /dev/ptmx fails.The DEVPTS_MULTIPLE_INSTANCES configuration option is removed, so that
userspace can now safely depend on each mount of devpts creating a new
instance of the filesystem.Each mount of devpts is now a separate and equal filesystem.
Reserved ttys are now available to all instances of devpts where the
mounter is in the initial mount namespace.A new vfs helper path_pts is introduced that finds a directory entry
named "pts" in the directory of the passed in path, and changes the
passed in path to point to it. The helper path_pts uses a function
path_parent_directory that was factored out of follow_dotdot.In the implementation of devpts:
- devpts_mnt is killed as it is no longer meaningful if all mounts of
devpts are equal.
- pts_sb_from_inode is replaced by just inode->i_sb as all cached
inodes in the tty layer are now from the devpts filesystem.
- devpts_add_ref is rolled into the new function devpts_ptmx. And the
unnecessary inode hold is removed.
- devpts_del_ref is renamed devpts_release and reduced to just a
deacrivate_super.
- The newinstance mount option continues to be accepted but is now
ignored.In devpts_fs.h definitions for when !CONFIG_UNIX98_PTYS are removed as
they are never used.Documentation/filesystems/devices.txt is updated to describe the current
situation.This has been verified to work properly on openwrt-15.05, centos5,
centos6, centos7, debian-6.0.2, debian-7.9, debian-8.2, ubuntu-14.04.3,
ubuntu-15.10, fedora23, magia-5, mint-17.3, opensuse-42.1,
slackware-14.1, gentoo-20151225 (13.0?), archlinux-2015-12-01. With the
caveat that on centos6 and on slackware-14.1 that there wind up being
two instances of the devpts filesystem mounted on /dev/pts, the lower
copy does not end up getting used.Signed-off-by: "Eric W. Biederman"
Cc: Greg KH
Cc: Peter Hurley
Cc: Peter Anvin
Cc: Andy Lutomirski
Cc: Al Viro
Cc: Serge Hallyn
Cc: Willy Tarreau
Cc: Aurelien Jarno
Cc: One Thousand Gnomes
Cc: Jann Horn
Cc: Jiri Slaby
Cc: Florian Weimer
Cc: Konstantin Khlebnikov
Signed-off-by: Linus Torvalds
27 Apr, 2016
1 commit
-
This is more prep-work for the upcoming pty changes. Still just code
cleanup with no actual semantic changes.This removes a bunch pointless complexity by just having the slave pty
side remember the dentry associated with the devpts slave rather than
the inode. That allows us to remove all the "look up the dentry" code
for when we want to remove it again.Together with moving the tty pointer from "inode->i_private" to
"dentry->d_fsdata" and getting rid of pointless inode locking, this
removes about 30 lines of code. Not only is the end result smaller,
it's simpler and easier to understand.The old code, for example, depended on the d_find_alias() to not just
find the dentry, but also to check that it is still hashed, which in
turn validated the tty pointer in the inode.That is a _very_ roundabout way to say "invalidate the cached tty
pointer when the dentry is removed".The new code just does
dentry->d_fsdata = NULL;
in devpts_pty_kill() instead, invalidating the tty pointer rather more
directly and obviously. Don't do something complex and subtle when the
obvious straightforward approach will do.The rest of the patch (ie apart from code deletion and the above tty
pointer clearing) is just switching the calling convention to pass the
dentry or file pointer around instead of the inode.Cc: Eric Biederman
Cc: Peter Anvin
Cc: Andy Lutomirski
Cc: Al Viro
Cc: Peter Hurley
Cc: Serge Hallyn
Cc: Willy Tarreau
Cc: Aurelien Jarno
Cc: Alan Cox
Cc: Jann Horn
Cc: Greg KH
Cc: Jiri Slaby
Cc: Florian Weimer
Signed-off-by: Linus Torvalds
19 Apr, 2016
1 commit
-
This gets rid of the horrible notion of having that
struct inode *ptmx_inode
be the linchpin of the interface between the pty code and devpts.
By de-emphasizing the ptmx inode, a lot of things actually get cleaner,
and we will have a much saner way forward. In particular, this will
allow us to associate with any particular devpts instance at open-time,
and not be artificially tied to one particular ptmx inode.The patch itself is actually fairly straightforward, and apart from some
locking and return path cleanups it's pretty mechanical:- the interfaces that devpts exposes all take "struct pts_fs_info *"
instead of "struct inode *ptmx_inode" now.NOTE! The "struct pts_fs_info" thing is a completely opaque structure
as far as the pty driver is concerned: it's still declared entirely
internally to devpts. So the pty code can't actually access it in any
way, just pass it as a "cookie" to the devpts code.- the "look up the pts fs info" is now a single clear operation, that
also does the reference count increment on the pts superblock.So "devpts_add/del_ref()" is gone, and replaced by a "lookup and get
ref" operation (devpts_get_ref(inode)), along with a "put ref" op
(devpts_put_ref()).- the pty master "tty->driver_data" field now contains the pts_fs_info,
not the ptmx inode.- because we don't care about the ptmx inode any more as some kind of
base index, the ref counting can now drop the inode games - it just
gets the ref on the superblock.- the pts_fs_info now has a back-pointer to the super_block. That's so
that we can easily look up the information we actually need. Although
quite often, the pts fs info was actually all we wanted, and not having
to look it up based on some magical inode makes things more
straightforward.In particular, now that "devpts_get_ref(inode)" operation should really
be the *only* place we need to look up what devpts instance we're
associated with, and we do it exactly once, at ptmx_open() time.The other side of this is that one ptmx node could now be associated
with multiple different devpts instances - you could have a single
/dev/ptmx node, and then have multiple mount namespaces with their own
instances of devpts mounted on /dev/pts/. And that's all perfectly sane
in a model where we just look up the pts instance at open time.This will eventually allow us to get rid of our odd single-vs-multiple
pts instance model, but this patch in itself changes no semantics, only
an internal binding model.Cc: Eric Biederman
Cc: Peter Anvin
Cc: Andy Lutomirski
Cc: Al Viro
Cc: Peter Hurley
Cc: Serge Hallyn
Cc: Willy Tarreau
Cc: Aurelien Jarno
Cc: Alan Cox
Cc: Jann Horn
Cc: Greg KH
Cc: Jiri Slaby
Cc: Florian Weimer
Signed-off-by: Linus Torvalds
07 Feb, 2016
1 commit
-
Considering current pty code and multiple devpts instances, it's possible
to umount a devpts file system while a program still has /dev/tty opened
pointing to a previosuly closed pty pair in that instance. In the case all
ptmx and pts/N files are closed, umount can be done. If the program closes
/dev/tty after umount is done, devpts_kill_index will use now an invalid
super_block, which was already destroyed in the umount operation after
running ->kill_sb. This is another "use after free" type of issue, but now
related to the allocated super_block instance.To avoid the problem (warning at ida_remove and potential crashes) for
this specific case, I added two functions in devpts which grabs additional
references to the super_block, which pty code now uses so it makes sure
the super block structure is still valid until pty shutdown is done.
I also moved the additional inode references to the same functions, which
also covered similar case with inode being freed before /dev/tty final
close/shutdown.Signed-off-by: Herton R. Krzesinski
Cc: stable@vger.kernel.org # 2.6.29+
Reviewed-by: Peter Hurley
Signed-off-by: Greg Kroah-Hartman
23 Oct, 2012
3 commits
-
The goal is to stop setting and using tty->driver_data in devpts code.
It should be used solely by the driver's code, pty in this case.Now driver_data are managed only in the pty driver. devpts_pty_new is
switched to accept what we used to dig out of tty_struct, i.e. device
node number and index.This also removes a note about driver_data being set outside of the
driver.Signed-off-by: Jiri Slaby
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
The goal is to stop setting and using tty->driver_data in devpts code.
It should be used solely by the driver's code, pty in this case.For the cleanup of layering, we will need the inode created in
devpts_pty_new to be stored into slave's driver_data. So we convert
devpts_pty_new to return the inode or an ERR_PTR-encoded error in case
of failure.The move of 'inode = new_inode(sb);' from declarators to the code is
only cosmetical, but it makes the code easier to read.Signed-off-by: Jiri Slaby
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
The goal is to stop setting and using tty->driver_data in devpts code.
It should be used solely by the driver's code, pty in this case.First, here we remove TTY from devpts_get_tty and rename it to
devpts_get_priv. Note we do not remove type safety, we just shift the
[implicit] (void *) cast one layer up.index was unused in devpts_get_tty, so remove that from the prototype
too.Signed-off-by: Jiri Slaby
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman
14 Oct, 2008
1 commit
-
Pass-in 'inode' or 'tty' parameter to devpts interfaces. With multiple
devpts instances, these parameters will be used in subsequent patches
to identify the instance of devpts mounted. The parameters also help
simplify devpts implementation.Changelog[v3]:
- minor changes due to merge with ttydev updates
- rename parameters to emphasize they are ptmx or pts inodes
- pass-in tty_struct * to devpts_pty_kill() (this will help
cleanup the get_node() call in a subsequent patch)Signed-off-by: Sukadev Bhattiprolu
Signed-off-by: Alan Cox
Signed-off-by: Linus Torvalds
30 Apr, 2008
1 commit
-
Factor out the code used to allocate/free a pts index into new interfaces,
devpts_new_index() and devpts_kill_index(). This localizes the external data
structures used in managing the pts indices.[akpm@linux-foundation.org: undo accidental mutex2sem conversion]
Signed-off-by: Sukadev Bhattiprolu
Signed-off-by: Serge Hallyn
Signed-off-by: Matt Helsley
Acked-by: H. Peter Anvin
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
