1. 27 2月, 2015 2 次提交
  2. 28 8月, 2014 2 次提交
  3. 28 5月, 2014 1 次提交
  4. 25 4月, 2014 1 次提交
    • J
      USB: serial: fix sysfs-attribute removal deadlock · 10164c2a
      Johan Hovold 提交于
      Fix driver new_id sysfs-attribute removal deadlock by making sure to
      not hold any locks that the attribute operations grab when removing the
      attribute.
      
      Specifically, usb_serial_deregister holds the table mutex when
      deregistering the driver, which includes removing the new_id attribute.
      This can lead to a deadlock as writing to new_id increments the
      attribute's active count before trying to grab the same mutex in
      usb_serial_probe.
      
      The deadlock can easily be triggered by inserting a sleep in
      usb_serial_deregister and writing the id of an unbound device to new_id
      during module unload.
      
      As the table mutex (in this case) is used to prevent subdriver unload
      during probe, it should be sufficient to only hold the lock while
      manipulating the usb-serial driver list during deregister. A racing
      probe will then either fail to find a matching subdriver or fail to get
      the corresponding module reference.
      
      Since v3.15-rc1 this also triggers the following lockdep warning:
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.15.0-rc2 #123 Tainted: G        W
      -------------------------------------------------------
      modprobe/190 is trying to acquire lock:
       (s_active#4){++++.+}, at: [<c0167aa0>] kernfs_remove_by_name_ns+0x4c/0x94
      
      but task is already holding lock:
       (table_lock){+.+.+.}, at: [<bf004d84>] usb_serial_deregister+0x3c/0x78 [usbserial]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (table_lock){+.+.+.}:
             [<c0075f84>] __lock_acquire+0x1694/0x1ce4
             [<c0076de8>] lock_acquire+0xb4/0x154
             [<c03af3cc>] _raw_spin_lock+0x4c/0x5c
             [<c02bbc24>] usb_store_new_id+0x14c/0x1ac
             [<bf007eb4>] new_id_store+0x68/0x70 [usbserial]
             [<c025f568>] drv_attr_store+0x30/0x3c
             [<c01690e0>] sysfs_kf_write+0x5c/0x60
             [<c01682c0>] kernfs_fop_write+0xd4/0x194
             [<c010881c>] vfs_write+0xbc/0x198
             [<c0108e4c>] SyS_write+0x4c/0xa0
             [<c000f880>] ret_fast_syscall+0x0/0x48
      
      -> #0 (s_active#4){++++.+}:
             [<c03a7a28>] print_circular_bug+0x68/0x2f8
             [<c0076218>] __lock_acquire+0x1928/0x1ce4
             [<c0076de8>] lock_acquire+0xb4/0x154
             [<c0166b70>] __kernfs_remove+0x254/0x310
             [<c0167aa0>] kernfs_remove_by_name_ns+0x4c/0x94
             [<c0169fb8>] remove_files.isra.1+0x48/0x84
             [<c016a2fc>] sysfs_remove_group+0x58/0xac
             [<c016a414>] sysfs_remove_groups+0x34/0x44
             [<c02623b8>] driver_remove_groups+0x1c/0x20
             [<c0260e9c>] bus_remove_driver+0x3c/0xe4
             [<c026235c>] driver_unregister+0x38/0x58
             [<bf007fb4>] usb_serial_bus_deregister+0x84/0x88 [usbserial]
             [<bf004db4>] usb_serial_deregister+0x6c/0x78 [usbserial]
             [<bf005330>] usb_serial_deregister_drivers+0x2c/0x4c [usbserial]
             [<bf016618>] usb_serial_module_exit+0x14/0x1c [sierra]
             [<c009d6cc>] SyS_delete_module+0x184/0x210
             [<c000f880>] ret_fast_syscall+0x0/0x48
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(table_lock);
                                     lock(s_active#4);
                                     lock(table_lock);
        lock(s_active#4);
      
       *** DEADLOCK ***
      
      1 lock held by modprobe/190:
       #0:  (table_lock){+.+.+.}, at: [<bf004d84>] usb_serial_deregister+0x3c/0x78 [usbserial]
      
      stack backtrace:
      CPU: 0 PID: 190 Comm: modprobe Tainted: G        W     3.15.0-rc2 #123
      [<c0015e10>] (unwind_backtrace) from [<c0013728>] (show_stack+0x20/0x24)
      [<c0013728>] (show_stack) from [<c03a9a54>] (dump_stack+0x24/0x28)
      [<c03a9a54>] (dump_stack) from [<c03a7cac>] (print_circular_bug+0x2ec/0x2f8)
      [<c03a7cac>] (print_circular_bug) from [<c0076218>] (__lock_acquire+0x1928/0x1ce4)
      [<c0076218>] (__lock_acquire) from [<c0076de8>] (lock_acquire+0xb4/0x154)
      [<c0076de8>] (lock_acquire) from [<c0166b70>] (__kernfs_remove+0x254/0x310)
      [<c0166b70>] (__kernfs_remove) from [<c0167aa0>] (kernfs_remove_by_name_ns+0x4c/0x94)
      [<c0167aa0>] (kernfs_remove_by_name_ns) from [<c0169fb8>] (remove_files.isra.1+0x48/0x84)
      [<c0169fb8>] (remove_files.isra.1) from [<c016a2fc>] (sysfs_remove_group+0x58/0xac)
      [<c016a2fc>] (sysfs_remove_group) from [<c016a414>] (sysfs_remove_groups+0x34/0x44)
      [<c016a414>] (sysfs_remove_groups) from [<c02623b8>] (driver_remove_groups+0x1c/0x20)
      [<c02623b8>] (driver_remove_groups) from [<c0260e9c>] (bus_remove_driver+0x3c/0xe4)
      [<c0260e9c>] (bus_remove_driver) from [<c026235c>] (driver_unregister+0x38/0x58)
      [<c026235c>] (driver_unregister) from [<bf007fb4>] (usb_serial_bus_deregister+0x84/0x88 [usbserial])
      [<bf007fb4>] (usb_serial_bus_deregister [usbserial]) from [<bf004db4>] (usb_serial_deregister+0x6c/0x78 [usbserial])
      [<bf004db4>] (usb_serial_deregister [usbserial]) from [<bf005330>] (usb_serial_deregister_drivers+0x2c/0x4c [usbserial])
      [<bf005330>] (usb_serial_deregister_drivers [usbserial]) from [<bf016618>] (usb_serial_module_exit+0x14/0x1c [sierra])
      [<bf016618>] (usb_serial_module_exit [sierra]) from [<c009d6cc>] (SyS_delete_module+0x184/0x210)
      [<c009d6cc>] (SyS_delete_module) from [<c000f880>] (ret_fast_syscall+0x0/0x48)
      Signed-off-by: NJohan Hovold <jhovold@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      10164c2a
  5. 13 3月, 2014 3 次提交
  6. 04 1月, 2014 1 次提交
  7. 24 7月, 2013 1 次提交
  8. 18 6月, 2013 2 次提交
  9. 11 6月, 2013 1 次提交
    • G
      USB: serial: ports: add minor and port number · 1143832e
      Greg Kroah-Hartman 提交于
      The usb_serial_port structure had the number field, which was the minor
      number for the port, which almost no one really cared about.  They
      really wanted the number of the port within the device, which you had to
      subtract from the minor of the parent usb_serial_device structure.  To
      clean this up, provide the real minor number of the port, and the number
      of the port within the serial device separately, as these numbers might
      not be related in the future.
      
      Bonus is that this cleans up a lot of logic in the drivers, and saves
      lines overall.
      Tested-by: NTobias Winter <tobias@linuxdingsda.de>
      Reviewed-by: NJohan Hovold <jhovold@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      --
       drivers/staging/serqt_usb2/serqt_usb2.c |   21 +++--------
       drivers/usb/serial/ark3116.c            |    2 -
       drivers/usb/serial/bus.c                |    6 +--
       drivers/usb/serial/console.c            |    2 -
       drivers/usb/serial/cp210x.c             |    2 -
       drivers/usb/serial/cypress_m8.c         |    4 +-
       drivers/usb/serial/digi_acceleport.c    |    6 ---
       drivers/usb/serial/f81232.c             |    5 +-
       drivers/usb/serial/garmin_gps.c         |    6 +--
       drivers/usb/serial/io_edgeport.c        |   58 ++++++++++++--------------------
       drivers/usb/serial/io_ti.c              |   21 ++++-------
       drivers/usb/serial/keyspan.c            |   29 +++++++---------
       drivers/usb/serial/metro-usb.c          |    4 +-
       drivers/usb/serial/mos7720.c            |   37 +++++++++-----------
       drivers/usb/serial/mos7840.c            |   52 +++++++++-------------------
       drivers/usb/serial/opticon.c            |    2 -
       drivers/usb/serial/pl2303.c             |    2 -
       drivers/usb/serial/quatech2.c           |    7 +--
       drivers/usb/serial/sierra.c             |    2 -
       drivers/usb/serial/ti_usb_3410_5052.c   |   10 ++---
       drivers/usb/serial/usb-serial.c         |    7 ++-
       drivers/usb/serial/usb_wwan.c           |    2 -
       drivers/usb/serial/whiteheat.c          |   20 +++++------
       include/linux/usb/serial.h              |    6 ++-
       24 files changed, 133 insertions(+), 180 deletions(-)
      1143832e
  10. 05 6月, 2013 1 次提交
  11. 17 5月, 2013 3 次提交
  12. 29 3月, 2013 1 次提交
  13. 27 3月, 2013 1 次提交
  14. 26 3月, 2013 14 次提交
  15. 22 3月, 2013 1 次提交
  16. 19 3月, 2013 1 次提交
  17. 16 3月, 2013 1 次提交
  18. 14 2月, 2013 1 次提交
    • J
      USB: serial: fix null-pointer dereferences on disconnect · b2ca6990
      Johan Hovold 提交于
      Make sure serial-driver dtr_rts is called with disc_mutex held after
      checking the disconnected flag.
      
      Due to a bug in the tty layer, dtr_rts may get called after a device has
      been disconnected and the tty-device unregistered. Some drivers have had
      individual checks for disconnect to make sure the disconnected interface
      was not accessed, but this should really be handled in usb-serial core
      (at least until the long-standing tty-bug has been fixed).
      
      Note that the problem has been made more acute with commit 0998d063
      ("device-core: Ensure drvdata = NULL when no driver is bound") as the
      port data is now also NULL when dtr_rts is called resulting in further
      oopses.
      Reported-by: NChris Ruehl <chris.ruehl@gtsys.com.hk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <jhovold@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2ca6990
  19. 19 1月, 2013 1 次提交
  20. 16 11月, 2012 1 次提交
    • J
      TTY: call tty_port_destroy in the rest of drivers · 191c5f10
      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.
      
      To be sure, the TTY buffers (and later some stuff) are gone along with
      the tty_port, we have to call tty_port_destroy at tear-down places.
      This is mostly where the structure containing a tty_port is freed.
      This patch does exactly that -- put tty_port_destroy at those places.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      191c5f10