1. 16 10月, 2013 2 次提交
  2. 15 10月, 2013 2 次提交
  3. 14 10月, 2013 4 次提交
  4. 13 10月, 2013 2 次提交
    • M
      Bluetooth: Return the correct address type for L2CAP sockets · 4f1654e0
      Marcel Holtmann 提交于
      The L2CAP sockets can use BR/EDR public, LE public and LE random
      addresses for various combinations of source and destination
      devices. So make sure that getsockname(), getpeername() and
      accept() return the correct address type.
      
      For this the address type of the source and destination is stored
      with the L2CAP channel information. The stored address type is
      not the one specific for the HCI protocol. It is the address
      type used for the L2CAP sockets and the management interface.
      
      The underlying HCI connections store the HCI address type. If
      needed, it gets converted to the socket address type.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      4f1654e0
    • M
      Bluetooth: Store address information in L2CAP channel structure · 7eafc59e
      Marcel Holtmann 提交于
      With the effort of abstracting the L2CAP socket from the underlying
      L2CAP channel it is important to store the source and destination
      address information directly in the L2CAP channel structure.
      
      Direct access to the HCI connection address information is not
      possible since they might not be avaiable at L2CAP channel
      creation time. The address information will be updated when
      the underlying BR/EDR or LE connection status changes.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      7eafc59e
  5. 12 10月, 2013 2 次提交
  6. 11 10月, 2013 1 次提交
  7. 08 10月, 2013 1 次提交
  8. 02 10月, 2013 1 次提交
  9. 26 9月, 2013 1 次提交
  10. 19 9月, 2013 1 次提交
  11. 23 6月, 2013 1 次提交
  12. 10 4月, 2013 1 次提交
  13. 06 4月, 2013 1 次提交
  14. 08 3月, 2013 1 次提交
  15. 24 10月, 2012 1 次提交
  16. 15 10月, 2012 2 次提交
  17. 12 10月, 2012 1 次提交
  18. 11 10月, 2012 1 次提交
  19. 09 10月, 2012 1 次提交
    • S
      Bluetooth: don't attempt to free a channel that wasn't created · 23d3a869
      Sasha Levin 提交于
      We may currently attempt to free a channel which wasn't created due to
      an error in the initialization path, this would cause a NULL ptr deref.
      
      This would cause the following oops:
      
      [   12.919073] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      [   12.919131] IP: [<ffffffff836645c4>] l2cap_chan_put+0x34/0x50
      [   12.919135] PGD 0
      [   12.919138] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      [   12.919193] Dumping ftrace buffer:
      [   12.919242]    (ftrace buffer empty)
      [   12.919314] Modules linked in:
      [   12.919318] CPU 1
      [   12.919319] Pid: 6210, comm: krfcommd Tainted: G        W    3.6.0-next-20121004-sasha-00005-gb010653-dirty #30
      [   12.919374] RIP: 0010:[<ffffffff836645c4>]  [<ffffffff836645c4>] l2cap_chan_put+0x34/0x50
      [   12.919377] RSP: 0000:ffff880066933c38  EFLAGS: 00010246
      [   12.919378] RAX: ffffffff8366c780 RBX: 0000000000000000 RCX: 6666666666666667
      [   12.919379] RDX: 0000000000000fa0 RSI: ffffffff84d3f79e RDI: 0000000000000010
      [   12.919381] RBP: ffff880066933c48 R08: ffffffff859989f8 R09: 0000000000000001
      [   12.919382] R10: 0000000000000000 R11: 7fffffffffffffff R12: 0000000000000000
      [   12.919383] R13: ffff88009b00a200 R14: ffff88009b00a200 R15: 0000000000000001
      [   12.919385] FS:  0000000000000000(0000) GS:ffff880033600000(0000) knlGS:0000000000000000
      [   12.919437] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   12.919440] CR2: 0000000000000010 CR3: 0000000005026000 CR4: 00000000000406e0
      [   12.919446] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   12.919451] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [   12.919504] Process krfcommd (pid: 6210, threadinfo ffff880066932000, task ffff880065c4b000)
      [   12.919506] Stack:
      [   12.919510]  ffff88009b00a200 ffff880032084000 ffff880066933c68 ffffffff8366c7bc
      [   12.919513]  7fffffffffffffff ffff880032084000 ffff880066933c98 ffffffff833ae0ae
      [   12.919516]  ffff880066933ca8 0000000000000000 0000000000000000 ffff88009b00a200
      [   12.919517] Call Trace:
      [   12.919522]  [<ffffffff8366c7bc>] l2cap_sock_destruct+0x3c/0x80
      [   12.919527]  [<ffffffff833ae0ae>] __sk_free+0x1e/0x1f0
      [   12.919530]  [<ffffffff833ae2f7>] sk_free+0x17/0x20
      [   12.919585]  [<ffffffff8366ca4e>] l2cap_sock_alloc.constprop.5+0x9e/0xd0
      [   12.919591]  [<ffffffff8366cb9e>] l2cap_sock_create+0x7e/0x100
      [   12.919652]  [<ffffffff83a4f32a>] ? _raw_read_lock+0x6a/0x80
      [   12.919658]  [<ffffffff836402c4>] ? bt_sock_create+0x74/0x110
      [   12.919660]  [<ffffffff83640308>] bt_sock_create+0xb8/0x110
      [   12.919664]  [<ffffffff833aa232>] __sock_create+0x282/0x3b0
      [   12.919720]  [<ffffffff833aa0b0>] ? __sock_create+0x100/0x3b0
      [   12.919725]  [<ffffffff836785b0>] ? rfcomm_process_sessions+0x17e0/0x17e0
      [   12.919779]  [<ffffffff833aa37f>] sock_create_kern+0x1f/0x30
      [   12.919784]  [<ffffffff83675714>] rfcomm_l2sock_create+0x44/0x70
      [   12.919787]  [<ffffffff836785b0>] ? rfcomm_process_sessions+0x17e0/0x17e0
      [   12.919790]  [<ffffffff836785fe>] rfcomm_run+0x4e/0x1f0
      [   12.919846]  [<ffffffff836785b0>] ? rfcomm_process_sessions+0x17e0/0x17e0
      [   12.919852]  [<ffffffff81138ee3>] kthread+0xe3/0xf0
      [   12.919908]  [<ffffffff8117b12e>] ? put_lock_stats.isra.14+0xe/0x40
      [   12.919914]  [<ffffffff81138e00>] ? flush_kthread_work+0x1f0/0x1f0
      [   12.919968]  [<ffffffff83a5077c>] ret_from_fork+0x7c/0x90
      [   12.919973]  [<ffffffff81138e00>] ? flush_kthread_work+0x1f0/0x1f0
      [   12.920161] Code: 83 ec 08 f6 05 ff 58 44 02 04 74 1b 8b 4f 10 48 89 fa 48 c7 c6 d9 d7 d4 84 48 c7 c7 80 9e aa 85 31 c0 e8 80
      ac 3a fe 48 8d 7b 10 <f0> 83 6b 10 01 0f 94 c0 84 c0 74 05 e8 8b e0 ff ff 48 83 c4 08
      [   12.920165] RIP  [<ffffffff836645c4>] l2cap_chan_put+0x34/0x50
      [   12.920166]  RSP <ffff880066933c38>
      [   12.920167] CR2: 0000000000000010
      [   12.920417] ---[ end trace 5a9114e8a158ab84 ]---
      
      Introduced in commit 61d6ef3e ("Bluetooth: Make better use of l2cap_chan
      reference counting").
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      23d3a869
  20. 08 10月, 2012 1 次提交
  21. 27 8月, 2012 1 次提交
  22. 16 8月, 2012 1 次提交
  23. 07 8月, 2012 3 次提交
  24. 05 6月, 2012 7 次提交