Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 11月, 2009 2 次提交
    • F
      USB: cdc_acm: Fix memory leak after hangup · 051522bb
      由 Francesco Lavra 提交于 
      Am Donnerstag, 10. September 2009 15:43:53 schrieb Dietmar Hilbrich:
> Hello,
>
> i have the following problem with the cdc-acm - driver:
>
> I'm using the driver with an "Ericsson F3507G" on a Thinkpad T400.
>
> If a disable the device (with the RFKill-Switch) while it is used by a
> programm like ppp, the driver doesn't seem to correctly clean up the tty,
> even after the program has been closed)
>
> The tty is still active (e.g. there still exists an entry in
> /sys/dev/char/166:0 if ttyACM0 was used) and if a reacticate the device,
> this device entry will be skipped and the Device-Nodes ttyACM1, ttyACM2
> and ttyACM3 will be used.
>
> This problem was introduced with the commit
> 10077d4a (before 2.6.31-rc1) and still
> exists in 2.6.31.
>
> I was able the fix this problem with the following patch:
>
> diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
> index 2bfc41e..0970d2f 100644
> --- a/drivers/usb/class/cdc-acm.c
> +++ b/drivers/usb/class/cdc-acm.c
> @@ -676,6 +676,7 @@ static void acm_tty_hangup(struct tty_struct *tty)
>         struct acm *acm = tty->driver_data;
>         tty_port_hangup(&acm->port);
>         acm_port_down(acm, 0);
> +       acm_tty_unregister(acm);
>  }

I have the same problem with cdc-acm (I'm using a Samsung SGH-U900): when I
unplug it from the USB port during a PPP connection, the ppp daemon gets the
hangup correctly (and closes the device), but the struct acm corresponding to
the device disconnected is not freed. Hence reconnecting the device results in
creation of /dev/ttyACM(x+1). The same happens when the system is hibernated
during a PPP connection.

This memory leak is due to the fact that when the tty is hung up,
tty_port_close_start() returns always zero, and acm_tty_close() never reaches
the point where acm_tty_unregister() is called.

Here is a fix for this.
Signed-off-by: NFrancesco Lavra <francescolavra@interfree.it>
Acked-by: NOliver Neukum <oliver@neukum.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      051522bb
    • H
      USB: cdc_acm: Fix race condition when opening tty · 18a77b5d
      由 Henry Gebhardt 提交于 
      If acm_rx_tasklet() gets called before tty_port_block_til_ready()
returns, then bulk IN urbs may not be sent. This fixes it.
Signed-off-by: NHenry Gebhardt <gebhardt@astro.uni-tuebingen.de>
Acked-by: NOliver Neukum <oliver@neukum.org>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      18a77b5d
  3. 23 9月, 2009 1 次提交
  5. 20 9月, 2009 1 次提交
  7. 08 8月, 2009 1 次提交
  9. 21 7月, 2009 1 次提交
  11. 13 7月, 2009 1 次提交
  13. 26 6月, 2009 2 次提交
  15. 16 6月, 2009 2 次提交
  17. 11 6月, 2009 3 次提交
  19. 29 5月, 2009 1 次提交
  21. 14 4月, 2009 1 次提交
  23. 07 4月, 2009 2 次提交
  25. 28 2月, 2009 2 次提交
  27. 10 2月, 2009 1 次提交
  29. 28 1月, 2009 3 次提交
  31. 08 1月, 2009 1 次提交
    • A
      USB: Enhance usage of pm_message_t · 65bfd296
      由 Alan Stern 提交于 
      This patch (as1177) modifies the USB core suspend and resume
routines.  The resume functions now will take a pm_message_t argument,
so they will know what sort of resume is occurring.  The new argument
is also passed to the port suspend/resume and bus suspend/resume
routines (although they don't use it for anything but debugging).

In addition, special pm_message_t values are used for user-initiated,
device-initiated (i.e., remote wakeup), and automatic suspend/resume.
By testing these values, drivers can tell whether or not a particular
suspend was an autosuspend.  Unfortunately, they can't do the same for
resumes -- not until the pm_message_t argument is also passed to the
drivers' resume methods.  That will require a bigger change.

IMO, the whole Power Management framework should have been set up this
way in the first place.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      65bfd296
  33. 14 11月, 2008 1 次提交
    • B
      USB: cdc-acm.c: fix recursive lock in acm_start_wb error path · ad0b65ef
      由 Brandon Philips 提交于 
      Fixes an obvious bug in cdc-acm by avoiding a recursive lock on
acm_start_wb()'s error path. Should apply towards 2.6.27 stable and
2.6.28.

=============================================
[ INFO: possible recursive locking detected ]
2.6.27-2-pae #109
---------------------------------------------
python/31449 is trying to acquire lock:
 (&acm->write_lock){++..}, at: [<f89a0348>] acm_start_wb+0x5c/0x7b [cdc_acm]

but task is already holding lock:
 (&acm->write_lock){++..}, at: [<f89a04fb>] acm_tty_write+0xe1/0x167 [cdc_acm]

other info that might help us debug this:
2 locks held by python/31449:
 #0:  (&tty->atomic_write_lock){--..}, at: [<c0260fae>] tty_write_lock+0x14/0x3b
 #1:  (&acm->write_lock){++..}, at: [<f89a04fb>] acm_tty_write+0xe1/0x167 [cdc_acm]

stack backtrace:
Pid: 31449, comm: python Not tainted 2.6.27-2-pae #109
 [<c030f42f>] ? printk+0xf/0x18
 [<c0149f33>] __lock_acquire+0xc7b/0x1316
 [<c014a63e>] lock_acquire+0x70/0x97
 [<f89a0348>] ? acm_start_wb+0x5c/0x7b [cdc_acm]
 [<c0312109>] _spin_lock_irqsave+0x37/0x47
 [<f89a0348>] ? acm_start_wb+0x5c/0x7b [cdc_acm]
 [<f89a0348>] acm_start_wb+0x5c/0x7b [cdc_acm]
 [<f89a055d>] acm_tty_write+0x143/0x167 [cdc_acm]
 [<c0262a98>] write_chan+0x1cd/0x297
 [<c012527e>] ? default_wake_function+0x0/0xd
 [<c026111e>] tty_write+0x149/0x1b9
 [<c02628cb>] ? write_chan+0x0/0x297
 [<c01912c5>] ? rw_verify_area+0x76/0x98
 [<c0260fd5>] ? tty_write+0x0/0x1b9
 [<c01919ba>] vfs_write+0x8c/0x136
 [<c0191afd>] sys_write+0x3b/0x60
 [<c0103beb>] sysenter_do_call+0x12/0x3f
 =======================
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ad0b65ef
  35. 23 10月, 2008 1 次提交
  37. 18 10月, 2008 2 次提交
  39. 22 8月, 2008 2 次提交
  41. 14 8月, 2008 4 次提交
  43. 23 7月, 2008 1 次提交
  45. 22 7月, 2008 3 次提交
  47. 04 7月, 2008 1 次提交