- 10 4月, 2013 2 次提交
-
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Al Viro 提交于
The only part of proc_dir_entry the code outside of fs/proc really cares about is PDE(inode)->data. Provide a helper for that; static inline for now, eventually will be moved to fs/proc, along with the knowledge of struct proc_dir_entry layout. Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 15 3月, 2013 1 次提交
-
-
由 Vinicius Costa Gomes 提交于
With deferred setup for SCO, it is possible that userspace closes the socket when it is in the BT_CONNECT2 state, after the Connect Request is received but before the Accept Synchonous Connection is sent. If this happens the following crash was observed, when the connection is terminated: [ +0.000003] hci_sync_conn_complete_evt: hci0 status 0x10 [ +0.000005] sco_connect_cfm: hcon ffff88003d1bd800 bdaddr 40:98:4e:32:d7:39 status 16 [ +0.000003] sco_conn_del: hcon ffff88003d1bd800 conn ffff88003cc8e300, err 110 [ +0.000015] BUG: unable to handle kernel NULL pointer dereference at 0000000000000199 [ +0.000906] IP: [<ffffffff810620dd>] __lock_acquire+0xed/0xe82 [ +0.000000] PGD 3d21f067 PUD 3d291067 PMD 0 [ +0.000000] Oops: 0002 [#1] SMP [ +0.000000] Modules linked in: rfcomm bnep btusb bluetooth [ +0.000000] CPU 0 [ +0.000000] Pid: 1481, comm: kworker/u:2H Not tainted 3.9.0-rc1-25019-gad82cdd1 #1 Bochs Bochs [ +0.000000] RIP: 0010:[<ffffffff810620dd>] [<ffffffff810620dd>] __lock_acquire+0xed/0xe82 [ +0.000000] RSP: 0018:ffff88003c3c19d8 EFLAGS: 00010002 [ +0.000000] RAX: 0000000000000001 RBX: 0000000000000246 RCX: 0000000000000000 [ +0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88003d1be868 [ +0.000000] RBP: ffff88003c3c1a98 R08: 0000000000000002 R09: 0000000000000000 [ +0.000000] R10: ffff88003d1be868 R11: ffff88003e20b000 R12: 0000000000000002 [ +0.000000] R13: ffff88003aaa8000 R14: 000000000000006e R15: ffff88003d1be850 [ +0.000000] FS: 0000000000000000(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000 [ +0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ +0.000000] CR2: 0000000000000199 CR3: 000000003c1cb000 CR4: 00000000000006b0 [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ +0.000000] Process kworker/u:2H (pid: 1481, threadinfo ffff88003c3c0000, task ffff88003aaa8000) [ +0.000000] Stack: [ +0.000000] ffffffff81b16342 0000000000000000 0000000000000000 ffff88003d1be868 [ +0.000000] ffffffff00000000 00018c0c7863e367 000000003c3c1a28 ffffffff8101efbd [ +0.000000] 0000000000000000 ffff88003e3d2400 ffff88003c3c1a38 ffffffff81007c7a [ +0.000000] Call Trace: [ +0.000000] [<ffffffff8101efbd>] ? kvm_clock_read+0x34/0x3b [ +0.000000] [<ffffffff81007c7a>] ? paravirt_sched_clock+0x9/0xd [ +0.000000] [<ffffffff81007fd4>] ? sched_clock+0x9/0xb [ +0.000000] [<ffffffff8104fd7a>] ? sched_clock_local+0x12/0x75 [ +0.000000] [<ffffffff810632d1>] lock_acquire+0x93/0xb1 [ +0.000000] [<ffffffffa0022339>] ? spin_lock+0x9/0xb [bluetooth] [ +0.000000] [<ffffffff8105f3d8>] ? lock_release_holdtime.part.22+0x4e/0x55 [ +0.000000] [<ffffffff814f6038>] _raw_spin_lock+0x40/0x74 [ +0.000000] [<ffffffffa0022339>] ? spin_lock+0x9/0xb [bluetooth] [ +0.000000] [<ffffffff814f6936>] ? _raw_spin_unlock+0x23/0x36 [ +0.000000] [<ffffffffa0022339>] spin_lock+0x9/0xb [bluetooth] [ +0.000000] [<ffffffffa00230cc>] sco_conn_del+0x76/0xbb [bluetooth] [ +0.000000] [<ffffffffa002391d>] sco_connect_cfm+0x2da/0x2e9 [bluetooth] [ +0.000000] [<ffffffffa000862a>] hci_proto_connect_cfm+0x38/0x65 [bluetooth] [ +0.000000] [<ffffffffa0008d30>] hci_sync_conn_complete_evt.isra.79+0x11a/0x13e [bluetooth] [ +0.000000] [<ffffffffa000cd96>] hci_event_packet+0x153b/0x239d [bluetooth] [ +0.000000] [<ffffffff814f68ff>] ? _raw_spin_unlock_irqrestore+0x48/0x5c [ +0.000000] [<ffffffffa00025f6>] hci_rx_work+0xf3/0x2e3 [bluetooth] [ +0.000000] [<ffffffff8103efed>] process_one_work+0x1dc/0x30b [ +0.000000] [<ffffffff8103ef83>] ? process_one_work+0x172/0x30b [ +0.000000] [<ffffffff8103e07f>] ? spin_lock_irq+0x9/0xb [ +0.000000] [<ffffffff8103fc8d>] worker_thread+0x123/0x1d2 [ +0.000000] [<ffffffff8103fb6a>] ? manage_workers+0x240/0x240 [ +0.000000] [<ffffffff81044211>] kthread+0x9d/0xa5 [ +0.000000] [<ffffffff81044174>] ? __kthread_parkme+0x60/0x60 [ +0.000000] [<ffffffff814f75bc>] ret_from_fork+0x7c/0xb0 [ +0.000000] [<ffffffff81044174>] ? __kthread_parkme+0x60/0x60 [ +0.000000] Code: d7 44 89 8d 50 ff ff ff 4c 89 95 58 ff ff ff e8 44 fc ff ff 44 8b 8d 50 ff ff ff 48 85 c0 4c 8b 95 58 ff ff ff 0f 84 7a 04 00 00 <f0> ff 80 98 01 00 00 83 3d 25 41 a7 00 00 45 8b b5 e8 05 00 00 [ +0.000000] RIP [<ffffffff810620dd>] __lock_acquire+0xed/0xe82 [ +0.000000] RSP <ffff88003c3c19d8> [ +0.000000] CR2: 0000000000000199 [ +0.000000] ---[ end trace e73cd3b52352dd34 ]--- Cc: stable@vger.kernel.org [3.8] Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Tested-by: NFrederic Dalleau <frederic.dalleau@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 28 2月, 2013 1 次提交
-
-
由 Sasha Levin 提交于
I'm not sure why, but the hlist for each entry iterators were conceived list_for_each_entry(pos, head, member) The hlist ones were greedy and wanted an extra parameter: hlist_for_each_entry(tpos, pos, head, member) Why did they need an extra pos parameter? I'm not quite sure. Not only they don't really need it, it also prevents the iterator from looking exactly like the list iterator, which is unfortunate. Besides the semantic patch, there was some manual work required: - Fix up the actual hlist iterators in linux/list.h - Fix up the declaration of other iterators based on the hlist ones. - A very small amount of places were using the 'node' parameter, this was modified to use 'obj->member' instead. - Coccinelle didn't handle the hlist_for_each_entry_safe iterator properly, so those had to be fixed up manually. The semantic patch which is mostly the work of Peter Senna Tschudin is here: @@ iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host; type T; expression a,c,d,e; identifier b; statement S; @@ -T b; <+... when != b ( hlist_for_each_entry(a, - b, c, d) S | hlist_for_each_entry_continue(a, - b, c) S | hlist_for_each_entry_from(a, - b, c) S | hlist_for_each_entry_rcu(a, - b, c, d) S | hlist_for_each_entry_rcu_bh(a, - b, c, d) S | hlist_for_each_entry_continue_rcu_bh(a, - b, c) S | for_each_busy_worker(a, c, - b, d) S | ax25_uid_for_each(a, - b, c) S | ax25_for_each(a, - b, c) S | inet_bind_bucket_for_each(a, - b, c) S | sctp_for_each_hentry(a, - b, c) S | sk_for_each(a, - b, c) S | sk_for_each_rcu(a, - b, c) S | sk_for_each_from -(a, b) +(a) S + sk_for_each_from(a) S | sk_for_each_safe(a, - b, c, d) S | sk_for_each_bound(a, - b, c) S | hlist_for_each_entry_safe(a, - b, c, d, e) S | hlist_for_each_entry_continue_rcu(a, - b, c) S | nr_neigh_for_each(a, - b, c) S | nr_neigh_for_each_safe(a, - b, c, d) S | nr_node_for_each(a, - b, c) S | nr_node_for_each_safe(a, - b, c, d) S | - for_each_gfn_sp(a, c, d, b) S + for_each_gfn_sp(a, c, d) S | - for_each_gfn_indirect_valid_sp(a, c, d, b) S + for_each_gfn_indirect_valid_sp(a, c, d) S | for_each_host(a, - b, c) S | for_each_host_safe(a, - b, c, d) S | for_each_mesh_entry(a, - b, c, d) S ) ...+> [akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c] [akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c] [akpm@linux-foundation.org: checkpatch fixes] [akpm@linux-foundation.org: fix warnings] [akpm@linux-foudnation.org: redo intrusive kvm changes] Tested-by: NPeter Senna Tschudin <peter.senna@gmail.com> Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: NSasha Levin <sasha.levin@oracle.com> Cc: Wu Fengguang <fengguang.wu@intel.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Cc: Gleb Natapov <gleb@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 19 2月, 2013 2 次提交
-
-
由 Gao feng 提交于
proc_net_remove is only used to remove proc entries that under /proc/net,it's not a general function for removing proc entries of netns. if we want to remove some proc entries which under /proc/net/stat/, we still need to call remove_proc_entry. this patch use remove_proc_entry to replace proc_net_remove. we can remove proc_net_remove after this patch. Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Gao feng 提交于
Right now, some modules such as bonding use proc_create to create proc entries under /proc/net/, and other modules such as ipv4 use proc_net_fops_create. It looks a little chaos.this patch changes all of proc_net_fops_create to proc_create. we can remove proc_net_fops_create after this patch. Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 05 2月, 2013 1 次提交
-
-
由 Ying Xue 提交于
As in del_timer() there has already placed a timer_pending() function to check whether the timer to be deleted is pending or not, it's unnecessary to check timer pending state again before del_timer() is called. Signed-off-by: NYing Xue <ying.xue@windriver.com> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 02 2月, 2013 14 次提交
-
-
由 Andre Guedes 提交于
This patch does a trivial refactor in mgmt_pending_foreach function. It replaces list_for_each_safe by list_for_each_entry_safe, simplifying the function. Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andre Guedes 提交于
This patch removes unneeded locking in hci_le_adv_report_evt. There is no need to lock hdev before calling mgmt_device_found. Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andre Guedes 提交于
This patch reduces the critical section protected by sco_conn_lock in sco_conn_ready function. The lock is acquired only when it is really needed. This patch fixes the following lockdep warning which is generated when the host terminates a SCO connection. Today, this warning is a false positive. There is no way those two threads reported by lockdep are running at the same time since hdev->workqueue (where rx_work is queued) is single-thread. However, if somehow this behavior is changed in future, we will have a potential deadlock. ====================================================== [ INFO: possible circular locking dependency detected ] 3.8.0-rc1+ #7 Not tainted ------------------------------------------------------- kworker/u:1H/1018 is trying to acquire lock: (&(&conn->lock)->rlock){+.+...}, at: [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth] but task is already holding lock: (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at: [<ffffffffa0033d5a>] sco_conn_del+0x8a/0xe0 [bluetooth] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}: [<ffffffff81083011>] lock_acquire+0xb1/0xe0 [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80 [<ffffffffa003436e>] sco_connect_cfm+0xbe/0x350 [bluetooth] [<ffffffffa0015d6c>] hci_event_packet+0xd3c/0x29b0 [bluetooth] [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth] [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0 [<ffffffff81050022>] worker_thread+0x2b2/0x3e0 [<ffffffff81056021>] kthread+0xd1/0xe0 [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0 -> #0 (&(&conn->lock)->rlock){+.+...}: [<ffffffff81082215>] __lock_acquire+0x1465/0x1c70 [<ffffffff81083011>] lock_acquire+0xb1/0xe0 [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80 [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth] [<ffffffffa0033d6d>] sco_conn_del+0x9d/0xe0 [bluetooth] [<ffffffffa0034653>] sco_disconn_cfm+0x53/0x60 [bluetooth] [<ffffffffa000fef3>] hci_disconn_complete_evt.isra.54+0x363/0x3c0 [bluetooth] [<ffffffffa00150f7>] hci_event_packet+0xc7/0x29b0 [bluetooth] [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth] [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0 [<ffffffff81050022>] worker_thread+0x2b2/0x3e0 [<ffffffff81056021>] kthread+0xd1/0xe0 [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(slock-AF_BLUETOOTH-BTPROTO_SCO); lock(&(&conn->lock)->rlock); lock(slock-AF_BLUETOOTH-BTPROTO_SCO); lock(&(&conn->lock)->rlock); *** DEADLOCK *** 4 locks held by kworker/u:1H/1018: #0: (hdev->name#2){.+.+.+}, at: [<ffffffff8104d5f8>] process_one_work+0x258/0x4f0 #1: ((&hdev->rx_work)){+.+.+.}, at: [<ffffffff8104d5f8>] process_one_work+0x258/0x4f0 #2: (&hdev->lock){+.+.+.}, at: [<ffffffffa000fbe9>] hci_disconn_complete_evt.isra.54+0x59/0x3c0 [bluetooth] #3: (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at: [<ffffffffa0033d5a>] sco_conn_del+0x8a/0xe0 [bluetooth] stack backtrace: Pid: 1018, comm: kworker/u:1H Not tainted 3.8.0-rc1+ #7 Call Trace: [<ffffffff813e92f9>] print_circular_bug+0x1fb/0x20c [<ffffffff81082215>] __lock_acquire+0x1465/0x1c70 [<ffffffff81083011>] lock_acquire+0xb1/0xe0 [<ffffffffa0033ba6>] ? sco_chan_del+0x66/0x190 [bluetooth] [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80 [<ffffffffa0033ba6>] ? sco_chan_del+0x66/0x190 [bluetooth] [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth] [<ffffffffa0033d6d>] sco_conn_del+0x9d/0xe0 [bluetooth] [<ffffffffa0034653>] sco_disconn_cfm+0x53/0x60 [bluetooth] [<ffffffffa000fef3>] hci_disconn_complete_evt.isra.54+0x363/0x3c0 [bluetooth] [<ffffffffa000fbd0>] ? hci_disconn_complete_evt.isra.54+0x40/0x3c0 [bluetooth] [<ffffffffa00150f7>] hci_event_packet+0xc7/0x29b0 [bluetooth] [<ffffffff81202e90>] ? __dynamic_pr_debug+0x80/0x90 [<ffffffff8133ff7d>] ? kfree_skb+0x2d/0x40 [<ffffffffa0021644>] ? hci_send_to_monitor+0x1a4/0x1c0 [bluetooth] [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth] [<ffffffff8104d5f8>] ? process_one_work+0x258/0x4f0 [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0 [<ffffffff8104d5f8>] ? process_one_work+0x258/0x4f0 [<ffffffff8104fdc1>] ? worker_thread+0x51/0x3e0 [<ffffffffa0004450>] ? hci_tx_work+0x800/0x800 [bluetooth] [<ffffffff81050022>] worker_thread+0x2b2/0x3e0 [<ffffffff8104fd70>] ? busy_worker_rebind_fn+0x100/0x100 [<ffffffff81056021>] kthread+0xd1/0xe0 [<ffffffff81055f50>] ? flush_kthread_worker+0xc0/0xc0 [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0 [<ffffffff81055f50>] ? flush_kthread_worker+0xc0/0xc0 Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
This patch increments the management interface revision due to the various fixes, improvements and other changes that have gone in lately. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
If a controller is powered on while the HCI_AUTO_OFF flag is set the link security setting (HCI_LINK_SECURITY) might not be in sync with the actual state of the controller (HCI_AUTH). This patch fixes the issue by checking for inequality between the intended and actual settings and sends a HCI_Write_Auth_Enable command if necessary. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
This patch adds the necessary code for encoding a list of 128-bit UUIDs into the EIR data. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
This patch adds the necessary code for inserting a list of 32-bit UUIDs into the EIR data. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
We will need to create three separate UUID lists in the EIR data (for 16, 32 and 128 bit UUIDs) so the code is easier to follow if each list is generated in their own function. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The amount of data encoded so far in the create_eir() function can be calculated simply through the difference between the data and ptr pointer variables. The eir_len variable then becomes essentially useless. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
There's no need to use two separate loops to generate a UUID list for the EIR data. This patch merges the two loops previously used for the 16-bit UUID list generation into a single loop, thus simplifying the code a great deal. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The UUID removal code can be simplified by using list_for_each_entry_safe instead of list_for_each_safe. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The primary purpose of the UUIDs is to enable generation of EIR and AD data. In these data formats the UUIDs are split into separate fields based on whether they're 16, 32 or 128 bit UUIDs. To make the generation of these data fields simpler this patch adds a type member to the bt_uuid struct and assigns a value to it as soon as the UUID is added to the kernel. This way the type doesn't need to be calculated each time the UUID list is later iterated. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The code for clearing the UUIDs list can be simplified by using list_for_each_entry_safe instead of list_for_each_safe. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
We should be encoding UUIDs to the EIR data in the same order that they were added to the kernel, i.e. each UUID should be added to the end of the UUIDs list. This patch fixes the issue by using list_add_tail instead of list_add for storing the UUIDs. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 01 2月, 2013 2 次提交
-
-
由 Andre Guedes 提交于
If occurs a LE or SCO hci_conn timeout and the connection is already established (BT_CONNECTED state), the connection is not terminated as expected. This bug can be reproduced using l2test or scotest tool. Once the connection is established, kill l2test/scotest and the connection won't be terminated. This patch fixes hci_conn_disconnect helper so it is able to terminate LE and SCO connections, as well as ACL. Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The conn->smp_chan pointer can be NULL if SMP PDUs arrive at unexpected moments. To avoid NULL pointer dereferences the code should be checking for this and disconnect if an unexpected SMP PDU arrives. This patch fixes the issue by adding a check for conn->smp_chan for all other PDUs except pairing request and security request (which are are the first PDUs to come to initialize the SMP context). Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> CC: stable@vger.kernel.org Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 23 1月, 2013 14 次提交
-
-
由 Johan Hedberg 提交于
The LE supported states indicate the states and state combinations that the link layer supports. This is important information for knowing what operations are possible when dealing with multiple connected devices. This patch adds reading of the supported states to the HCI init sequence. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The LE White List Size is necessary to be known before attempting to feed the controller with any addresses intended for the white list. This patch adds the necessary HCI command sending to the HCI init sequence. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
To be able to make the appropriate decisions for some LE procedures we need to know the LE features that the local controller supports. Therefore, it's important to have the LE Read Local Supported Features HCI comand as part of the HCI init sequence. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The Block/Unblock Device Management commands should return Command Complete instead of Command Status whenever possible so that user space can distinguish exactly which command failed in the case of multiple commands. This patch does the necessary changes in the command handler to return the right event to user space. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The Disconnect Management command should return Command Complete instead of Command Status whenever possible so that user space can distinguish exactly which command failed in the case of multiple commands. This patch does the necessary changes in the disconnect command handler to return the right event to user space. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The valid values for the Disconnect parameter in the Unpair Device command are 0x00 and 0x01. If any other value is encountered the command should fail with the appropriate invalid params response. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
This patch adds checks for valid address type values passed to mgmt commands. If an invalid address type is encountered the code will return a proper invalid params response. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
This patch adds necessary checks for the two allowed values of the authenticated parameter of each Long Term Key, i.e. 0x00 and 0x01. If any other value is encountered the valid response is to return invalid params to user space. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
This patch refactors valid LTK data testing into its own function. This will help keep the code readable since there are several tests still missing that need to be done on the LTK data. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The allowed values for the key->master parameter in the Load LTKs command are 0x00 and 0x01. If there is a key in the list with some other value the command should fail with a proper invalid params response. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
Failures of mgmt commands should be indicated with valid mgmt status codes, and EINVAL is not one of them. Instead MGMT_STATUS_INVALID_PARAMS should be returned. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The debug_keys parameter is only allowed to have the values 0x00 and 0x01. Any other value should result in a proper command status with MGMT_STATUS_INVALID_PARAMS. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Szymon Janc 提交于
According to Bluetooth Management API specification Pair Device Command should generate command complete event on both success and failure. This fix replying with command status (which lacks address info) when adapter is powered off. Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Acked-by: NJohan Hedberg <johan.hedberg@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
When a HCI device is powered off the Management interface specification dictates that the class of device value is indicated as zero. This patch fixes sending of the appropriate class of device changed event when a HCI device is powered off. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 19 1月, 2013 1 次提交
-
-
由 Joe Millenbach 提交于
The option allows you to remove TTY and compile without errors. This saves space on systems that won't support TTY interfaces anyway. bloat-o-meter output is below. The bulk of this patch consists of Kconfig changes adding "depends on TTY" to various serial devices and similar drivers that require the TTY layer. Ideally, these dependencies would occur on a common intermediate symbol such as SERIO, but most drivers "select SERIO" rather than "depends on SERIO", and "select" does not respect dependencies. bloat-o-meter output comparing our previous minimal to new minimal by removing TTY. The list is filtered to not show removed entries with awk '$3 != "-"' as the list was very long. add/remove: 0/226 grow/shrink: 2/14 up/down: 6/-35356 (-35350) function old new delta chr_dev_init 166 170 +4 allow_signal 80 82 +2 static.__warned 143 142 -1 disallow_signal 63 62 -1 __set_special_pids 95 94 -1 unregister_console 126 121 -5 start_kernel 546 541 -5 register_console 593 588 -5 copy_from_user 45 40 -5 sys_setsid 128 120 -8 sys_vhangup 32 19 -13 do_exit 1543 1526 -17 bitmap_zero 60 40 -20 arch_local_irq_save 137 117 -20 release_task 674 652 -22 static.spin_unlock_irqrestore 308 260 -48 Signed-off-by: NJoe Millenbach <jmillenbach@gmail.com> Reviewed-by: NJamey Sharp <jamey@minilop.net> Reviewed-by: NJosh Triplett <josh@joshtriplett.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 18 1月, 2013 2 次提交
-
-
由 Johan Hedberg 提交于
There's a per-HCI device workqueue (hdev->workqueue) that should be used for general per-HCI device work (except hdev->req_workqueue that's for hci_request() related work). This patch fixes places using the system-global work queue and makes them use the hdev->workqueue instead. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
This patch converts work assignment relying on hci_request() from the system-global work queue to the per-HCI device specific work queue (hdev->req_workqueue) intended for hci_request() related tasks. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-