1. 08 4月, 2015 12 次提交
  2. 02 4月, 2015 1 次提交
  3. 26 3月, 2015 1 次提交
  4. 12 7月, 2014 1 次提交
  5. 11 7月, 2014 2 次提交
  6. 25 4月, 2014 1 次提交
  7. 06 3月, 2014 1 次提交
  8. 11 10月, 2013 2 次提交
  9. 04 4月, 2013 2 次提交
  10. 23 10月, 2012 1 次提交
  11. 19 9月, 2012 1 次提交
  12. 18 7月, 2012 3 次提交
  13. 05 6月, 2012 1 次提交
  14. 09 5月, 2012 1 次提交
  15. 28 3月, 2012 1 次提交
    • J
      Bluetooth: hci_ldisc: fix NULL-pointer dereference on tty_close · 33b69bf8
      Johan Hovold 提交于
      Do not close protocol driver until device has been unregistered.
      
      This fixes a race between tty_close and hci_dev_open which can result in
      a NULL-pointer dereference.
      
      The line discipline closes the protocol driver while we may still have
      hci_dev_open sleeping on the req_lock mutex resulting in a NULL-pointer
      dereference when lock is acquired and hci_init_req called.
      
      Bug is 100% reproducible using hciattach and a disconnected serial port:
      
      0. # hciattach -n ttyO1 any noflow
      
      1. hci_dev_open called from hci_power_on grabs req lock
      2. hci_init_req executes but device fails to initialise (times out
         eventually)
      3. hci_dev_open is called from hci_sock_ioctl and sleeps on req lock
      4. hci_uart_tty_close detaches protocol driver and cancels init req
      5. hci_dev_open (1) releases req lock
      6. hci_dev_open (3) grabs req lock, calls hci_init_req, which triggers oops
         when request is prepared in hci_uart_send_frame
      
      [  137.201263] Unable to handle kernel NULL pointer dereference at virtual address 00000028
      [  137.209838] pgd = c0004000
      [  137.212677] [00000028] *pgd=00000000
      [  137.216430] Internal error: Oops: 17 [#1]
      [  137.220642] Modules linked in:
      [  137.223846] CPU: 0    Tainted: G        W     (3.3.0-rc6-dirty #406)
      [  137.230529] PC is at __lock_acquire+0x5c/0x1ab0
      [  137.235290] LR is at lock_acquire+0x9c/0x128
      [  137.239776] pc : [<c0071490>]    lr : [<c00733f8>]    psr: 20000093
      [  137.239776] sp : cf869dd8  ip : c0529554  fp : c051c730
      [  137.251800] r10: 00000000  r9 : cf8673c0  r8 : 00000080
      [  137.257293] r7 : 00000028  r6 : 00000002  r5 : 00000000  r4 : c053fd70
      [  137.264129] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000001
      [  137.270965] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      [  137.278717] Control: 10c5387d  Table: 8f0f4019  DAC: 00000015
      [  137.284729] Process kworker/u:1 (pid: 7, stack limit = 0xcf8682e8)
      [  137.291229] Stack: (0xcf869dd8 to 0xcf86a000)
      [  137.295776] 9dc0:                                                       c0529554 00000000
      [  137.304351] 9de0: cf8673c0 cf868000 d03ea1ef cf868000 000001ef 00000470 00000000 00000002
      [  137.312927] 9e00: cf8673c0 00000001 c051c730 c00716ec 0000000c 00000440 c0529554 00000001
      [  137.321533] 9e20: c051c730 cf868000 d03ea1f3 00000000 c053b978 00000000 00000028 cf868000
      [  137.330078] 9e40: 00000000 00000000 00000002 00000000 00000000 c00733f8 00000002 00000080
      [  137.338684] 9e60: 00000000 c02a1d50 00000000 00000001 60000013 c0969a1c 60000093 c053b96c
      [  137.347259] 9e80: 00000002 00000018 20000013 c02a1d50 cf0ac000 00000000 00000002 cf868000
      [  137.355834] 9ea0: 00000089 c0374130 00000002 00000000 c02a1d50 cf0ac000 0000000c cf0fc540
      [  137.364410] 9ec0: 00000018 c02a1d50 cf0fc540 00000000 cf0fc540 c0282238 c028220c cf178d80
      [  137.372985] 9ee0: 127525d8 c02821cc 9a1fa451 c032727c 9a1fa451 127525d8 cf0fc540 cf0ac4ec
      [  137.381561] 9f00: cf0ac000 cf0fc540 cf0ac584 c03285f4 c0328580 cf0ac4ec cf85c740 c05510cc
      [  137.390136] 9f20: ce825400 c004c914 00000002 00000000 c004c884 ce8254f5 cf869f48 00000000
      [  137.398712] 9f40: c0328580 ce825415 c0a7f914 c061af64 00000000 c048cf3c cf8673c0 cf85c740
      [  137.407287] 9f60: c05510cc c051a66c c05510ec c05510c4 cf85c750 cf868000 00000089 c004d6ac
      [  137.415863] 9f80: 00000000 c0073d14 00000001 cf853ed8 cf85c740 c004d558 00000013 00000000
      [  137.424438] 9fa0: 00000000 00000000 00000000 c00516b0 00000000 00000000 cf85c740 00000000
      [  137.433013] 9fc0: 00000001 dead4ead ffffffff ffffffff c0551674 00000000 00000000 c0450aa4
      [  137.441589] 9fe0: cf869fe0 cf869fe0 cf853ed8 c005162c c0013b30 c0013b30 00ffff00 00ffff00
      [  137.450164] [<c0071490>] (__lock_acquire+0x5c/0x1ab0) from [<c00733f8>] (lock_acquire+0x9c/0x128)
      [  137.459503] [<c00733f8>] (lock_acquire+0x9c/0x128) from [<c0374130>] (_raw_spin_lock_irqsave+0x44/0x58)
      [  137.469360] [<c0374130>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c02a1d50>] (skb_queue_tail+0x18/0x48)
      [  137.479339] [<c02a1d50>] (skb_queue_tail+0x18/0x48) from [<c0282238>] (h4_enqueue+0x2c/0x34)
      [  137.488189] [<c0282238>] (h4_enqueue+0x2c/0x34) from [<c02821cc>] (hci_uart_send_frame+0x34/0x68)
      [  137.497497] [<c02821cc>] (hci_uart_send_frame+0x34/0x68) from [<c032727c>] (hci_send_frame+0x50/0x88)
      [  137.507171] [<c032727c>] (hci_send_frame+0x50/0x88) from [<c03285f4>] (hci_cmd_work+0x74/0xd4)
      [  137.516204] [<c03285f4>] (hci_cmd_work+0x74/0xd4) from [<c004c914>] (process_one_work+0x1a0/0x4ec)
      [  137.525604] [<c004c914>] (process_one_work+0x1a0/0x4ec) from [<c004d6ac>] (worker_thread+0x154/0x344)
      [  137.535278] [<c004d6ac>] (worker_thread+0x154/0x344) from [<c00516b0>] (kthread+0x84/0x90)
      [  137.543975] [<c00516b0>] (kthread+0x84/0x90) from [<c0013b30>] (kernel_thread_exit+0x0/0x8)
      [  137.552734] Code: e59f4e5c e5941000 e3510000 0a000031 (e5971000)
      [  137.559234] ---[ end trace 1b75b31a2719ed1e ]---
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <jhovold@gmail.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      33b69bf8
  16. 25 2月, 2012 2 次提交
  17. 13 2月, 2012 3 次提交
  18. 13 1月, 2012 1 次提交
  19. 04 6月, 2011 1 次提交
    • L
      Revert "tty: make receive_buf() return the amout of bytes received" · 55db4c64
      Linus Torvalds 提交于
      This reverts commit b1c43f82.
      
      It was broken in so many ways, and results in random odd pty issues.
      
      It re-introduced the buggy schedule_work() in flush_to_ldisc() that can
      cause endless work-loops (see commit a5660b41: "tty: fix endless
      work loop when the buffer fills up").
      
      It also used an "unsigned int" return value fo the ->receive_buf()
      function, but then made multiple functions return a negative error code,
      and didn't actually check for the error in the caller.
      
      And it didn't actually work at all.  BenH bisected down odd tty behavior
      to it:
        "It looks like the patch is causing some major malfunctions of the X
         server for me, possibly related to PTYs.  For example, cat'ing a
         large file in a gnome terminal hangs the kernel for -minutes- in a
         loop of what looks like flush_to_ldisc/workqueue code, (some ftrace
         data in the quoted bits further down).
      
         ...
      
         Some more data: It -looks- like what happens is that the
         flush_to_ldisc work queue entry constantly re-queues itself (because
         the PTY is full ?) and the workqueue thread will basically loop
         forver calling it without ever scheduling, thus starving the consumer
         process that could have emptied the PTY."
      
      which is pretty much exactly the problem we fixed in a5660b41.
      
      Milton Miller pointed out the 'unsigned int' issue.
      Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Reported-by: NMilton Miller <miltonm@bga.com>
      Cc: Stefan Bigler <stefan.bigler@keymile.com>
      Cc: Toby Gray <toby.gray@realvnc.com>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      55db4c64
  20. 23 4月, 2011 1 次提交
  21. 13 4月, 2011 1 次提交