linux.git/drivers/tty, branch v4.13

pty: Repair TIOCGPTPEER

2017-08-24T20:23:03+00:00

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

Revert "pty: fix the cached path of the pty slave file descriptor in the master"

2017-08-24T01:16:11+00:00

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

pty: fix the cached path of the pty slave file descriptor in the master

2017-08-17T16:10:48+00:00

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

Merge tag 'tty-4.13-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

2017-08-13T19:33:35+00:00

Pull tty/serial fixes from Greg KH:
 "Here are two tty serial driver fixes for 4.13-rc5. One is a revert of
  a -rc1 patch that turned out to not be a good idea, and the other is a
  fix for the pl011 serial driver.

  Both have been in linux-next with no reported issues"

* tag 'tty-4.13-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  Revert "serial: Delete dead code for CIR serial ports"
  tty: pl011: fix initialization order of QDF2400 E44

Revert "serial: Delete dead code for CIR serial ports"

2017-08-01T16:50:18+00:00

This reverts commit 1104321a7b3bb670dc614ffa7958c553e7b3b836.

The code is not dead at all and breaks winbond-cir.

Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
00:03: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a CIR port
lirc lirc0: lirc_dev: driver ir-lirc-codec (winbond-cir) registered at minor = 0
winbond-cir 00:03: Region 0x2f8-0x2ff already in use!
winbond-cir: probe of 00:03 failed with error -16

Signed-off-by: Sean Young 
Reviewed-by: Matthias Brugger 
Signed-off-by: Greg Kroah-Hartman

gpio: exar: Use correct property prefix and document bindings

2017-08-01T11:43:55+00:00

The device-specific property should be prefixed with the vendor name,
not "linux,", as Linus Walleij pointed out. Change this and document the
bindings of this platform device.

We didn't ship the old binding in a release yet. So we can still change
it without breaking an official API.

Fixes: 380b1e2f3a2f ("gpio-exar/8250-exar: Make set of exported GPIOs configurable")
Signed-off-by: Jan Kiszka 
Acked-by: Rob Herring 
Signed-off-by: Linus Walleij

tty: pl011: fix initialization order of QDF2400 E44

2017-07-30T14:53:44+00:00

The work-around for Qualcomm Technologies QDF2400 Erratum 44 hinges on a
global variable defined in the pl011 driver.  The ACPI SPCR parsing code
determines whether the work-around is needed, and if so, it changes the
console name from "pl011" to "qdf2400_e44".  The expectation is that
the pl011 driver will implement the work-around when it sees the console
name.  The global variable qdf2400_e44_present is set when that happens.

The problem is that work-around needs to be enabled when the pl011
driver probes, not when the console name is queried.  However, sbsa_probe()
is called before pl011_console_match().  The work-around appeared to work
previously because the default console on QDF2400 platforms was always
ttyAMA1.  The first time sbsa_probe() is called (for ttyAMA0),
qdf2400_e44_present is still false.  Then pl011_console_match() is called,
and it sets qdf2400_e44_present to true.  All subsequent calls to
sbsa_probe() enable the work-around.

The solution is to move the global variable into spcr.c and let the
pl011 driver query it during probe time.  This works because all QDF2400
platforms require SPCR, so parse_spcr() will always be called.
pl011_console_match still checks for the "qdf2400_e44" console name,
but it doesn't do anything else special.

Fixes: 5a0722b898f8 ("tty: pl011: use "qdf2400_e44" as the earlycon name for QDF2400 E44")
Tested-by: Jeffrey Hugo 
Signed-off-by: Timur Tabi 
Signed-off-by: Greg Kroah-Hartman

tty: hide unused pty_get_peer function

2017-07-17T15:04:41+00:00

TIOCGPTPEER is only used for unix98 PTYs, and we get a warning
when those are disabled:

drivers/tty/pty.c:466:12: error: 'pty_get_peer' defined but not used [-Werror=unused-function]

This moves the respective functions inside of the existing #ifdef.

Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl")
Signed-off-by: Arnd Bergmann 
Acked-by: Aleksa Sarai 
Reviewed-by: Kees Cook 
Signed-off-by: Greg Kroah-Hartman

tty: serial: lpuart: Fix the logic for detecting the 32-bit type UART

2017-07-17T12:14:24+00:00

Commit 0d6fce904452 ("tty: serial: lpuart: introduce lpuart_soc_data to
represent SoC property") introduced a buggy logic for detecting the 32-bit
type UART since the condition: "if (sport->port.iotype & UPIO_MEM32BE)"
is always true.

Performing such bitfield AND operation is not correct, because in the
case of Vybrid UART iotype is UPIO_MEM (2), so:

UPIO_MEM & UPIO_MEM32BE = 010 & 110 = 010, which is true.

Such logic tells the driver to always treat the UART operations as 32-bit,
leading to the driver misbehavior on Vybrid.

Fix the 32-bit type detection logic to avoid UART breakage on Vybrid.

While at it, introduce a lpuart_is_32() function to help readability.

Fixes: 0d6fce904452 ("tty: serial: lpuart: introduce lpuart_soc_data to represent SoC property")
Reported-by: Vivien Didelot 
Signed-off-by: Fabio Estevam 
Reviewed-by: Dong Aisheng 
Tested-by: Vivien Didelot 
Signed-off-by: Greg Kroah-Hartman

serial: imx: Prevent TX buffer PIO write when a DMA has been started

2017-07-17T12:14:24+00:00

Function imx_transmit_buffer starts a TX DMA if DMA is enabled, since
commit 91a1a909f921 ("serial: imx: Support sw flow control in DMA mode").
It also carries on and attempts to write the same TX buffer using PIO.
This results in TX data corruption and double-incrementing xmit->tail
with the knock-on effect of tail passing head and a page of garbage
being sent out.

This seems to be triggered mostly when using RS485 half duplex on SMP
systems, but is probably not limited to just those.

Tested locally on an i.MX6Q with an RS485 half duplex transceiver on
UART3, and also by Clemens Gruber.

Tested-by: Clemens Gruber 
Signed-off-by: Ian Jamison 
Reviewed-by: Fabio Estevam 
Signed-off-by: Greg Kroah-Hartman