1. 18 10月, 2015 3 次提交
    • P
      tty: Remove tty_port::close_wait · cc2aaabf
      Peter Hurley 提交于
      With the removal of tty_wait_until_sent_from_close(), tty drivers
      no longer wait during open for parallel closes to complete (instead,
      the tty core waits before calling the driver open() method). Thus,
      the close_wait waitqueue is no longer used for waiting.
      
      Remove struct tty_port::close_wait.
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc2aaabf
    • P
      tty: Remove ASYNC_CLOSING checks in open()/hangup() methods · fef062cb
      Peter Hurley 提交于
      Since at least before 2.6.30, tty drivers that do not drop the tty lock
      while closing cannot observe ASYNC_CLOSING set while holding the
      tty lock; this includes the tty driver's open() and hangup() methods,
      since the tty core calls these methods holding the tty lock.
      
      For these drivers, waiting for ASYNC_CLOSING to clear while opening
      is not required, since this condition cannot occur. Similarly, even
      when the open() method drops and reacquires the tty lock after
      blocking, ASYNC_CLOSING cannot be set (again, for drivers that
      do not drop the tty lock while closing).
      
      Now that tty port drivers no longer drop the tty lock while closing
      (since 'tty: Remove tty_wait_until_sent_from_close()'), the same
      conditions apply: waiting for ASYNC_CLOSING to clear while opening
      is not required, nor is re-checking ASYNC_CLOSING after dropping and
      reacquiring the tty lock while blocking (eg., in *_block_til_ready()).
      
      Note: The ASYNC_CLOSING flag state is still maintained since several
      bitrotting drivers use it for (dubious) other purposes.
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fef062cb
    • P
      tty: Remove tty_wait_until_sent_from_close() · 79c1faa4
      Peter Hurley 提交于
      tty_wait_until_sent_from_close() drops the tty lock while waiting
      for the tty driver to finish sending previously accepted data (ie.,
      data remaining in its write buffer and transmit fifo).
      
      tty_wait_until_sent_from_close() was added by commit a57a7bf3
      ("TTY: define tty_wait_until_sent_from_close") to prevent the entire
      tty subsystem from being unable to open new ttys while waiting for
      one tty to close while output drained.
      
      However, since commit 0911261d ("tty: Don't take tty_mutex for tty
      count changes"), holding a tty lock while closing does not prevent other
      ttys from being opened/closed/hung up, but only prevents lifetime event
      changes for the tty under lock.
      
      Holding the tty lock while waiting for output to drain does prevent
      parallel non-blocking opens (O_NONBLOCK) from advancing or returning
      while the tty lock is held. However, all parallel opens _already_
      block even if the tty lock is dropped while closing and the parallel
      open advances. Blocking in open has been in mainline since at least 2.6.29
      (see tty_port_block_til_ready(); note the test for O_NONBLOCK is _after_
      the wait while ASYNC_CLOSING).
      
      IOW, before this patch a non-blocking open will sleep anyway for the
      _entire_ duration of a parallel hardware shutdown, and when it wakes, the
      error return will cause a release of its tty, and it will restart with
      a fresh attempt to open. Similarly with a blocking open that is already
      waiting; when it's woken, the hardware shutdown has already completed
      to ASYNC_INITIALIZED is not set, which forces a release and restart as
      well.
      
      So, holding the tty lock across the _entire_ close (which is what this
      patch does), even while waiting for output to drain, is equivalent to
      the current outcome wrt parallel opens.
      
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: David Laight <David.Laight@aculab.com>
      CC: Arnd Bergmann <arnd@arndb.de>
      CC: Karsten Keil <isdn@linux-pingi.de>
      CC: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      79c1faa4
  2. 27 11月, 2014 1 次提交
  3. 07 11月, 2014 2 次提交
  4. 11 7月, 2014 6 次提交
    • P
      tty: Remove tty_hung_up_p() tests from tty drivers' open() · e359a4e3
      Peter Hurley 提交于
      Since at least before 2.6.30, it has not been possible to observe
      a hung up file pointer in a tty driver's open() method unless/until
      the driver open() releases the tty_lock() (eg., before blocking).
      
      This is because tty_open() adds the file pointer while holding
      the tty_lock() _and_ doesn't release the lock until after calling
      the tty driver's open() method. [ Before tty_lock(), this was
      lock_kernel(). ]
      
      Since __tty_hangup() first waits on the tty_lock() before
      enumerating and hanging up the open file pointers, either
      __tty_hangup() will wait for the tty_lock() or tty_open() will
      not yet have added the file pointer. For example,
      
      CPU 0                          |  CPU 1
                                     |
      tty_open                       |  __tty_hangup
        ..                           |    ..
        tty_lock                     |    ..
        tty_reopen                   |    tty_lock  / blocks
        ..                           |
        tty_add_file(tty, filp)      |
        ..                           |
        tty->ops->open(tty, filp)    |
          tty_port_open              |
            tty_port_block_til_ready |
              ..                     |
              while (1)              |
                ..                   |
                tty_unlock           |    / unblocks
                schedule             |    for each filp on tty->tty_files
                                     |      f_ops = tty_hung_up_fops;
                                     |    ..
                                     |    tty_unlock
                tty_lock             |
        ..                           |
        tty_unlock                   |
      
      Note that since tty_port_block_til_ready() and similar drop
      the tty_lock while blocking, when woken, the file pointer
      must then be tested for having been hung up.
      
      Also, fix bit-rotted drivers that used extra_count to track the
      port->count bump.
      
      CC: Mikael Starvik <starvik@axis.com>
      CC: Samuel Ortiz <samuel@sortiz.org>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e359a4e3
    • P
      tty: Move tty->closing from port lock critical section · ddc7b758
      Peter Hurley 提交于
      tty->closing informs the line discipline that the hardware will
      be shutting down imminently, and to disable further input other
      than soft flow control (but to still allow additional output).
      
      However, the tty lock is the necessary lock for preventing
      concurrent changes to tty->closing. As shown by the call-tree
      audit [1] of functions that modify tty->closing, the tty lock
      is already held for those functions.
      
      [1]
      Call-tree audit of functions that modify tty->closing
      * does not include call tree to tty_port_close(), tty_port_close_start(),
        or tty_port_close_end() which is already documented in
        'tty: Document locking for tty_port_close{,start,end}' that shows
        callers to those 3 functions hold the tty lock
      
      tty_release()
        tty->ops->close() --+
                            |
      __tty_hangup()        |
        tty->ops->close() --+
                            |
              mp_close():drivers/staging/sb105x/sb_pci_mp.c
              dngc_tty_close():drivers/staging/dgnc/dgnc_tty.c
              dgap_tty_close():drivers/staging/dgap/dgap_tty.c
              dgrp_tty_close():drivers/staging/dgrp/dgrp_tty.c
              rp_close():drivers/tty/rocket.c
              hvsi_close():drivers/tty/hvc/hvsi.c
              rs_close():drivers/tty/serial/68328serial.c
              rs_close():drivers/tty/serial/crisv10.c
              uart_close():drivers/tty/serial/serial_core.c
              isdn_tty_close():drivers/isdn/i4l/isdn_tty.c
              tty3215_close():drivers/s390/char/con3215.c
      
      tty_open()
        tty_ldisc_setup() ----+
                              |
      __tty_hangup()          |
        tty_ldisc_hangup() ---+
                              |
      tty_set_ldisc() --------+
        tty_ldisc_restore() --+
                              |
                              +- tty_ldisc_open()
                                   ld->ops->open() --+
                                                     |
                                                     +- n_tty_open()
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ddc7b758
    • P
      tty: Document locking for tty_port_hangup() · 9c9928bd
      Peter Hurley 提交于
      The tty lock is held when the tty driver's hangup() method is called
      (from the lone call-site, __tty_hangup()). The call-tree audit [1]
      of tty_port_hangup() is a closed graph of the callers of
      tty_port_hangup(); ie., all callers originate only from __tty_hangup().
      
      Of these callers, none drop the tty lock prior to calling
      tty_port_hangup().
      
      [1]
      Call-tree audit of tty_port_hangup()
      
      __tty_hangup()
        tty->ops->hangup() --+
                             |
              rs_hangup():arch/ia64/hp/sim/simserial.c
              line_hangup():arch/um/drivers/line.c
              gdm_tty_hangup():drivers/staging/gdm724x/gdm_tty.c
              fwtty_hangup():drivers/staging/fwserial/fwserial.c
              acm_tty_hangup():drivers/usb/class/cdc-acm.c
              serial_hangup():drivers/usb/serial/usb-serial.c
              ipoctal_hangup():drivers/ipack/devices/ipoctal.c
              cy_hangup():drivers/tty/cyclades.c
              isicom_hangup():drivers/tty/isicom.c
              rp_hangup():drivers/tty/rocket.c
              dashtty_hangup():drivers/tty/metag_da.c
              moxa_hangup():drivers/tty/moxa.c
              gsmtty_hangup():drivers/tty/n_gsm.c
              goldfish_tty_hangup():drivers/tty/goldfish.c
              ehv_bc_tty_hangup():drivers/tty/ehv_bytechan.c
              mxser_hangup():drivers/tty/mxser.c
              kgdb_nmi_tty_hangup():drivers/tty/serial/kgdb_nmi.c
              ifx_spi_hangup():drivers/tty/serial/ifx6x60.c
              ntty_hangup():drivers/tty/nozomi.c
              capinc_tty_hangup():drivers/isdn/capi/capi.c
              mgslpc_hangup():drivers/char/pcmcia/synclink_cs.c
              sdio_uart_hangup():drivers/mmc/card/sdio_uart.c
              rfcomm_tty_hangup():net/bluetooth/rfcomm/tty.c
                             |
                             +- tty_port_hangup()
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9c9928bd
    • P
      tty: Document locking for tty_port_block_til_ready() · c590f6b6
      Peter Hurley 提交于
      The tty lock is held when the tty driver's open() method is called
      (from tty_open()). The call-tree audit [1] of tty_port_block_til_ready()
      is a closed graph of the callers of tty_port_block_til_ready();
      ie., all callers originate only from tty_open().
      
      Of these callers, none drop the tty lock.
      
      Also, document tty_port_block_til_ready() may drop and reacquire
      the tty lock when blocking, which means the tty or tty_port may have
      changed state.
      
      [1]
      Call-tree audit of tty_port_block_til_ready()
      * does not include call tree of tty_port_open() which is already
        documented in 'tty: Document locking from tty_port_open()'
      
      tty_open()
        tty->ops->open() --+
                           |
              cy_open():drivers/tty/cyclades.c
              rp_open():drivers/tty/rocket.c
              rs_open():drivers/tty/amiserial.c
              moxa_open():drivers/tty/moxa.c
              gsmtty_open():drivers/tty/n_gsm.c
              rs_open():drivers/tty/serial/68328serial.c
              uart_open():drivers/tty/serial/serial_core.c
              isdn_tty_open():drivers/isdn/i4l/isdn_tty.c
              mgslpc_open():drivers/char/pcmcia/synclink_cs.c
                           |
                           +- tty_port_block_til_ready()
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c590f6b6
    • P
      tty: Document locking for tty_port_open() · addd4672
      Peter Hurley 提交于
      The tty lock is held when the tty driver's open method is called
      (from the lone call-site, tty_open()). The call-tree audit [1] of
      tty_port_open() is a closed graph of the callers of tty_port_open();
      ie., all callers originate from only tty_open().
      
      Of these callers, none drop the tty lock.
      
      Also, document that tty_port_block_til_ready() may drop and reacquire
      the tty lock when blocking, which means the tty or tty_port may have
      changed state.
      
      [1]
      Call-tree audit of tty_port_open()
      
      tty_open()
        tty->ops->open() --+
                           |
              rs_open():arch/ia64/hp/sim/simserial.c
             *line_open():arch/um/drivers/line.c
              gdm_tty_open():drivers/staging/gdm724x/gdm_tty.c
              fwtty_open():drivers/staging/fwserial/fwserial.c
              acm_tty_open():drivers/usb/class/cdc-acm.c
              serial_open():drivers/usb/serial/usb-serial.c
              pti_tty_driver_open():drivers/misc/pti.c
              ipoctal_open():drivers/ipack/devices/ipoctal.c
              isicom_open():drivers/tty/isicom.c
              dashtty_open():drivers/tty/metag_da.c
              goldfish_tty_open():drivers/tty/goldfish.c
              ehv_bc_tty_open():drivers/tty/ehv_bytechan.c
              mxser_open():drivers/tty/mxser.c
              kgdb_nmi_tty_open():drivers/tty/serial/kgdb_nmi.c
              ifx_spi_open():drivers/tty/serial/ifx6x60.c
              smd_tty_open():drivers/tty/serial/msm_smd_tty.c
              ntty_open():drivers/tty/nozomi.c
              capinc_tty_open():drivers/isdn/capi/capi.c
              tpk_open():drivers/char/ttyprintk.c
              sdio_uart_open():drivers/mmc/card/sdio_uart.c
              rfcomm_tty_open():net/bluetooth/rfcomm/tty.c
                           |
                           +- tty_port_open()
      
      * line_open() is the .open method for 2 um drivers
        declared in ./arch/um/drivers/stdio_console.c and
        in ./arch/um/drivers/ssl.c, and not called directly
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      addd4672
    • P
      tty: Document locking for tty_port_close{,start,end}() · 0733db91
      Peter Hurley 提交于
      The tty lock is held when the tty driver's .close method is called
      (from the two lone call-sites of tty_release() and __tty_hangup()).
      The call-tree audit[1] of tty_port_close(), tty_port_close_start,
      and tty_port_close_end() is a closed graph of the callers of these
      3 functions; ie., all callers originate from only tty_release()
      or __tty_hangup().
      
      Of these callers, none drop the tty lock.
      
      Also, document tty_port_close_start() may drop and reacquire the
      tty lock in tty_wait_until_sent_from_close(), which means the tty
      or tty_port may have changed state (but not reopened or hung up).
      
      [1]
      Call-tree audit of tty_port_close, tty_port_close_start, and tty_port_close_end()
      
      tty_release()
        tty->ops->close() --+
                            |
      __tty_hangup()        |
        tty->ops->close() --+
                            |
                            +- rp_close():drivers/tty/rocket.c -------------------+
                            +- uart_close():drivers/tty/serial/serial_core.c -----+
                            |                                                     +- tty_port_close_start()
                            |
                            |
                            +- close():drivers/tty/synclinkmp.c ------------------+
                            +- rs_close():drivers/tty/amiserial.c ----------------+
                            +- gsmtty_close():drivers/tty/n_gsm.c ----------------+
                            +- mxser_close():drivers/tty/mxser.c -----------------+
                            +- close():drivers/tty/synclink_gt.c -----------------+
                            +- mgsl_close():drivers/tty/synclink.c ---------------+
                            +- isdn_tty_close():drivers/isdn/i4l/isdn_tty.c ------+
                            +- mgslpc_close():drivers/char/pcmcia/synclink_cs.c --+
                            +- ircomm_tty_close():net/irda/ircomm/ircomm_tty.c ---+
                            |                                                     |
              rs_close():arch/ia64/hp/sim/simserial.c                             |
             *line_close():arch/um/drivers/line.c                                 |
              gdm_tty_close():drivers/staging/gdm724x/gdm_tty.c
              fwtty_close():drivers/staging/fwserial/fwserial.c
              acm_tty_close():drivers/usb/class/cdc-acm.c
              serial_close():drivers/usb/serial/usb-serial.c
              pti_tty_driver_close():drivers/misc/pti.c
              ipoctal_close():drivers/ipack/devices/ipoctal.c
              cy_close():drivers/tty/cyclades.c
              isicom_close():drivers/tty/isicom.c
              dashtty_close():drivers/tty/metag_da.c
              moxa_close():drivers/tty/moxa.c
              goldfish_tty_close():drivers/tty/goldfish.c
              ehv_bc_tty_close():drivers/tty/ehv_bytechan.c
              kgdb_nmi_tty_close():drivers/tty/serial/kgdb_nmi.c
              ifx_spi_close():drivers/tty/serial/ifx6x60.c
              smd_tty_close():drivers/tty/serial/msm_smd_tty.c
              ntty_close():drivers/tty/nozomi.c
              capinc_tty_close():drivers/isdn/capi/capi.c
              tpk_close():drivers/char/ttyprintk.c
              sdio_uart_close():drivers/mmc/card/sdio_uart.c                      |
              rfcomm_tty_close():net/bluetooth/rfcomm/tty.c                       |
                            |                                                     |
                            +- tty_port_close():drivers/tty/tty_port.c -----------+
                                                                                  |
                                                                                  +- tty_port_close_start()
                                                                                  +- tty_port_close_end()
      
      * line_close() is the .close method for 2 um drivers,
        declared in ./arch/um/drivers/stdio_console.c and
        in ./arch/um/drivers/ssl.c, and not called directly
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0733db91
  5. 08 1月, 2014 1 次提交
  6. 26 9月, 2013 2 次提交
  7. 27 7月, 2013 1 次提交
  8. 19 3月, 2013 9 次提交
  9. 16 11月, 2012 2 次提交
    • J
      TTY: introduce tty_port_destroy · de274bfe
      Jiri Slaby 提交于
      After commit "TTY: move tty buffers to tty_port", the tty buffers are
      not freed in some drivers. This is because tty_port_destructor is not
      called whenever a tty_port is freed. This was an assumption I counted
      with but was unfortunately untrue.
      
      Those using refcounting are safe now, but for those which do not we
      introduce a function to be called right before the tty_port is freed
      by the drivers.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de274bfe
    • J
      TTY: pty, fix tty buffers leak · 81c79838
      Jiri Slaby 提交于
      After commit "TTY: move tty buffers to tty_port", the tty buffers are
      not freed in some drivers. This is because tty_port_destructor is not
      called whenever a tty_port is freed. This was an assumption I counted
      with but was unfortunately untrue. So fix the drivers to fulfil this
      assumption.
      
      PTY is one of those, here we just need to use tty_port_put instead of
      kfree. (Assuming tty_port_destructor does not need port->ops to be set
      which we change here too.)
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81c79838
  10. 23 10月, 2012 1 次提交
  11. 07 9月, 2012 1 次提交
  12. 14 8月, 2012 2 次提交
  13. 11 8月, 2012 1 次提交
    • A
      tty: localise the lock · 89c8d91e
      Alan Cox 提交于
      The termios and other changes mean the other protections needed on the driver
      tty arrays should be adequate. Turn it all back on.
      
      This contains pieces folded in from the fixes made to the original patches
      
      | From: Geert Uytterhoeven <geert@linux-m68k.org>	(fix m68k)
      | From: Paul Gortmaker <paul.gortmaker@windriver.com>	(fix cris)
      | From: Jiri Kosina <jkosina@suze.cz>			(lockdep)
      | From: Eric Dumazet <eric.dumazet@gmail.com>		(lockdep)
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89c8d91e
  14. 17 7月, 2012 2 次提交
  15. 07 7月, 2012 1 次提交
    • A
      tty: localise the lock · f5e3bcc5
      Alan Cox 提交于
      The termios and other changes mean the other protections needed on the driver
      tty arrays should be adequate. Turn it all back on.
      
      This contains pieces folded in from the fixes made to the original patches
      
      | From: Geert Uytterhoeven <geert@linux-m68k.org>	(fix m68k)
      | From: Paul Gortmaker <paul.gortmaker@windriver.com>	(fix cris)
      | From: Jiri Kosina <jkosina@suze.cz>			(lockdep)
      | From: Eric Dumazet <eric.dumazet@gmail.com>		(lockdep)
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5e3bcc5
  16. 14 6月, 2012 2 次提交
  17. 03 6月, 2012 1 次提交
    • L
      tty: Revert the tty locking series, it needs more work · f309532b
      Linus Torvalds 提交于
      This reverts the tty layer change to use per-tty locking, because it's
      not correct yet, and fixing it will require some more deep surgery.
      
      The main revert is d29f3ef3 ("tty_lock: Localise the lock"), but
      there are several smaller commits that built upon it, they also get
      reverted here. The list of reverted commits is:
      
        fde86d31 - tty: add lockdep annotations
        8f6576ad - tty: fix ldisc lock inversion trace
        d3ca8b64 - pty: Fix lock inversion
        b1d679af - tty: drop the pty lock during hangup
        abcefe5f - tty/amiserial: Add missing argument for tty_unlock()
        fd11b42e - cris: fix missing tty arg in wait_event_interruptible_tty call
        d29f3ef3 - tty_lock: Localise the lock
      
      The revert had a trivial conflict in the 68360serial.c staging driver
      that got removed in the meantime.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f309532b
  18. 05 5月, 2012 1 次提交
  19. 25 1月, 2012 1 次提交
    • J
      TTY: fix UV serial console regression · 0eee50af
      Jiri Slaby 提交于
      Commit 74c21077 (serial: Use block_til_ready helper) and its fixup
      3f582b8c (serial: fix termios settings in open) introduced a
      regression on UV systems. The serial eventually freezes while being
      used. It's completely unpredictable and sometimes needs a heap of
      traffic to happen first.
      
      To reproduce this, yast installation was used as it turned out to be
      pretty reliable in reproducing. Especially during installation process
      where one doesn't have an SSH daemon running. And no monitor as the HW
      is completely headless. So this was fun to find. Given the machine
      doesn't boot on vanilla before 2.6.36 final. (And the commits above
      are older.)
      
      Unless there is some bad race in the code, the hardware seems to be
      pretty broken. Otherwise pure MSR read should not cause such a bug,
      or?
      
      So to prevent the bug, revert to the old behavior. I.e. read modem
      status only if we really have to -- for non-CLOCAL set serials.
      Non-CLOCAL works on this hardware OK, I tried. See? I don't.
      
      And document that shit.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: stable <stable@vger.kernel.org>
      References: https://lkml.org/lkml/2011/12/6/573
      References: https://bugzilla.novell.com/show_bug.cgi?id=718518Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0eee50af