- 13 2月, 2012 5 次提交
-
-
由 Szymon Janc 提交于
There is no need to send RNR immediately when entring local busy. Also upper layer might clear local busy condition before ack timer expires saving few cycles for sending RNR. This also prevents sending two RNRs in some cases where sending one would be enough i.e received N I-frame can trigger local busy (sending RNR acking up to N-1 I-frame) and later sending ack (RNR acking up to N I-frame). This was affecting TC_ERM_BV_07_C and TC_ERM_BV_22_C with some non default channel parameters (tx window and receiving buffer sizes). Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Szymon Janc 提交于
ack_timer should be cleared when sending ACK to avoid acking I-frames twice. This commit introduces helper function (only send ack, not clearing timer) which is used by l2cap_send_ack and l2cap_ack_timeout. This is to avoid clearing ack timer in timer function. Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Szymon Janc 提交于
SREJ frame with P-bit set acknowledges I-frames numbered up to (ReqSeq - 1). With this patch P-bit in SREJ is set only when there are some I-frames to ack. This fixes ambiguous situation when lost of I-frame with TxSeq=0 would result in sending SREJ acking all previous I-frames. Consider following scenario: TxWindow=3 HostA: sent I-frame TxSeq=0 HostA: sent I-frame TxSeq=1 HostA: sent I-frame TxSeq=2 HostB: missed I-frame TxSeq=0 HostB: received I-frame TxSeq=1 HostB: sent SREJ ReqSeq=0 Pbit=1 HostA: received SREJ ReqSeq=0 Pbit=1 <- All I-frames acked or not? ... Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Johan Hedberg 提交于
As reported by Dan Carpenter this function causes a Sparse warning and shouldn't be declared inline: include/net/bluetooth/l2cap.h:837:30 error: marked inline, but without a definition" Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Andrzej Kaczmarek 提交于
After moving L2CAP timers to workqueues l2cap_set_timer expects timeout value to be specified in jiffies but constants defined in miliseconds are used. This makes timeouts unreliable when CONFIG_HZ is not set to 1000. __set_chan_timer macro still uses jiffies as input to avoid multiple conversions from/to jiffies for sk_sndtimeo value which is already specified in jiffies. Signed-off-by: NAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Ackec-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
- 03 1月, 2012 2 次提交
-
-
由 Gustavo F. Padovan 提交于
Those locks are not shared between interrupt and process context anymore, so remove the part that disable interrupts. We are still safe because preemption is disabled. Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Gustavo F. Padovan 提交于
It should be the dst in the copy not src. 03a00194 introduced this bug. Reported-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
- 23 12月, 2011 3 次提交
-
-
由 Gustavo F. Padovan 提交于
Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Ulisses Furquim 提交于
When cancelling a delayed work (timer) in L2CAP we can not sleep holding the sock mutex otherwise we might deadlock with an L2CAP timer handler. This is possible because RX/TX and L2CAP timers run in different workqueues. The scenario below illustrates the problem. Thus we are now avoiding to sleep on the timers locks. ====================================================== [ INFO: possible circular locking dependency detected ] 3.1.0-05270-ga978dc7-dirty #239 ------------------------------------------------------- kworker/1:1/873 is trying to acquire lock: (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}, at: [<ffffffffa002ceac>] l2cap_chan_timeout+0x3c/0xe0 [bluetooth] but task is already holding lock: ((&(&chan->chan_timer)->work)){+.+...}, at: [<ffffffff81051a86>] process_one_work+0x126/0x450 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 ((&(&chan->chan_timer)->work)){+.+...}: [<ffffffff8106b276>] check_prevs_add+0xf6/0x170 [<ffffffff8106b903>] validate_chain+0x613/0x790 [<ffffffff8106dfee>] __lock_acquire+0x4be/0xac0 [<ffffffff8106ec2d>] lock_acquire+0x8d/0xb0 [<ffffffff81052a6f>] wait_on_work+0x4f/0x160 [<ffffffff81052ca3>] __cancel_work_timer+0x73/0x80 [<ffffffff81052cbd>] cancel_delayed_work_sync+0xd/0x10 [<ffffffffa002f2ed>] l2cap_chan_connect+0x22d/0x470 [bluetooth] [<ffffffffa002fb51>] l2cap_sock_connect+0xb1/0x140 [bluetooth] [<ffffffff8130811b>] kernel_connect+0xb/0x10 [<ffffffffa00cf98a>] rfcomm_session_create+0x12a/0x1c0 [rfcomm] [<ffffffffa00cfbe7>] __rfcomm_dlc_open+0x1c7/0x240 [rfcomm] [<ffffffffa00d07c2>] rfcomm_dlc_open+0x42/0x70 [rfcomm] [<ffffffffa00d3b03>] rfcomm_sock_connect+0x103/0x150 [rfcomm] [<ffffffff8130bd7e>] sys_connect+0xae/0xc0 [<ffffffff813368d2>] compat_sys_socketcall+0xb2/0x220 [<ffffffff813b2089>] sysenter_dispatch+0x7/0x30 -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}: [<ffffffff8106b16d>] check_prev_add+0x6cd/0x6e0 [<ffffffff8106b276>] check_prevs_add+0xf6/0x170 [<ffffffff8106b903>] validate_chain+0x613/0x790 [<ffffffff8106dfee>] __lock_acquire+0x4be/0xac0 [<ffffffff8106ec2d>] lock_acquire+0x8d/0xb0 [<ffffffff8130d91a>] lock_sock_nested+0x8a/0xa0 [<ffffffffa002ceac>] l2cap_chan_timeout+0x3c/0xe0 [bluetooth] [<ffffffff81051ae4>] process_one_work+0x184/0x450 [<ffffffff8105276e>] worker_thread+0x15e/0x340 [<ffffffff81057bb6>] kthread+0x96/0xa0 [<ffffffff813b1ef4>] kernel_thread_helper+0x4/0x10 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((&(&chan->chan_timer)->work)); lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock((&(&chan->chan_timer)->work)); lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); *** DEADLOCK *** 2 locks held by kworker/1:1/873: #0: (events){.+.+.+}, at: [<ffffffff81051a86>] process_one_work+0x126/0x450 #1: ((&(&chan->chan_timer)->work)){+.+...}, at: [<ffffffff81051a86>] process_one_work+0x126/0x450 stack backtrace: Pid: 873, comm: kworker/1:1 Not tainted 3.1.0-05270-ga978dc7-dirty #239 Call Trace: [<ffffffff813a0f6e>] print_circular_bug+0xd2/0xe3 [<ffffffff8106b16d>] check_prev_add+0x6cd/0x6e0 [<ffffffff8106b276>] check_prevs_add+0xf6/0x170 [<ffffffff8106b903>] validate_chain+0x613/0x790 [<ffffffff8106dfee>] __lock_acquire+0x4be/0xac0 [<ffffffff8130d8f6>] ? lock_sock_nested+0x66/0xa0 [<ffffffff8106ea30>] ? lock_release_nested+0x100/0x110 [<ffffffff8130d8f6>] ? lock_sock_nested+0x66/0xa0 [<ffffffff8106ec2d>] lock_acquire+0x8d/0xb0 [<ffffffffa002ceac>] ? l2cap_chan_timeout+0x3c/0xe0 [bluetooth] [<ffffffff8130d91a>] lock_sock_nested+0x8a/0xa0 [<ffffffffa002ceac>] ? l2cap_chan_timeout+0x3c/0xe0 [bluetooth] [<ffffffff81051a86>] ? process_one_work+0x126/0x450 [<ffffffffa002ceac>] l2cap_chan_timeout+0x3c/0xe0 [bluetooth] [<ffffffff81051ae4>] process_one_work+0x184/0x450 [<ffffffff81051a86>] ? process_one_work+0x126/0x450 [<ffffffffa002ce70>] ? l2cap_security_cfm+0x4e0/0x4e0 [bluetooth] [<ffffffff8105276e>] worker_thread+0x15e/0x340 [<ffffffff81052610>] ? manage_workers+0x110/0x110 [<ffffffff81057bb6>] kthread+0x96/0xa0 [<ffffffff813b1ef4>] kernel_thread_helper+0x4/0x10 [<ffffffff813af69d>] ? retint_restore_args+0xe/0xe [<ffffffff81057b20>] ? __init_kthread_worker+0x70/0x70 [<ffffffff813b1ef0>] ? gs_change+0xb/0xb Signed-off-by: NUlisses Furquim <ulisses@profusion.mobi> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Ulisses Furquim 提交于
The struct hci_proto and all related register/unregister and dispatching code was removed. HCI core code now call directly the SCO and L2CAP event functions. Signed-off-by: NUlisses Furquim <ulisses@profusion.mobi> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
- 21 12月, 2011 3 次提交
-
-
由 Gustavo F. Padovan 提交于
It makes more sense this way, since info_timer is a timer using delayed work API. Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Gustavo F. Padovan 提交于
This one also needs to run in process context Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Gustavo F. Padovan 提交于
It is the only place where it is used. Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
- 20 12月, 2011 1 次提交
-
-
由 Rusty Russell 提交于
module_param(bool) used to counter-intuitively take an int. In fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy trick. It's time to remove the int/unsigned int option. For this version it'll simply give a warning, but it'll break next kernel version. (Thanks to Joe Perches for suggesting coccinelle for 0/1 -> true/false). Cc: "David S. Miller" <davem@davemloft.net> Cc: netdev@vger.kernel.org Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 19 12月, 2011 10 次提交
-
-
由 Mat Martineau 提交于
When configuring an ERTM or streaming mode connection, remote devices are expected to send an RFC option in a successful config response. A misbehaving remote device might not send an RFC option, and the L2CAP code should not access uninitialized data in this case. Signed-off-by: NMat Martineau <mathewm@codeaurora.org> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Gustavo F. Padovan 提交于
Add ProFUSION's copyright to some files I've been touching recently. Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Gustavo F. Padovan 提交于
This list has much more reads than writes, so RCU makes senses here, also it avoid deadlock against the socket lock. Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Gustavo F. Padovan 提交于
This move some checking code that was in l2cap_sock_connect() to l2cap_chan_connect(). Thus we can invert the lock calls, i.e., call lock_sock() before hci_dev_lock() to avoid a deadlock scenario. Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Gustavo F. Padovan 提交于
Another step of remove interrupt context from Bluetooth Core. Use the system workqueue. Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Gustavo F. Padovan 提交于
spin lock doesn't fit ok anymore on the new code based on workqueues. Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Gustavo F. Padovan 提交于
We run everything in the same lock now. The backlog queue is useless now Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Gustavo F. Padovan 提交于
We now run everything in process context, so the mutex lock is the best option. But in some places we still need the bh_lock_sock() Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Gustavo F. Padovan 提交于
L2CAP timers also need to run in process context. As the works in l2cap are small we are using the system worqueue. Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Gustavo F. Padovan 提交于
Now we run everything in HCI in process context, so it's a better idea use mutex instead spin_lock. The macro remains hci_dev_lock() (and I got rid of hci_dev_lock_bh()), of course. Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
- 24 11月, 2011 1 次提交
-
-
由 Gustavo F. Padovan 提交于
I did this as a part of a testing course at university, but it might be useful upstream as well. Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
- 22 11月, 2011 1 次提交
-
-
由 Andrei Emeltchenko 提交于
Fixes bluetooth compiling when CONFIG_BT_L2CAP is not enabled net/built-in.o: In function `hci_dev_open': (.text+0xdce9a): undefined reference to `enable_hs' Reported-by: NRandy Dunlap <rdunlap@xenotime.net> Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
- 17 11月, 2011 5 次提交
-
-
由 Szymon Janc 提交于
Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Szymon Janc 提交于
Make __l2cap_global_chan_by_addr similar to other find functions. Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Szymon Janc 提交于
This make it easier to see what is the real reason for loop to exit. skb_queue_next return valid skb or garbage, not NULL. Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Szymon Janc 提交于
Make it easier to see what is loop break condition. skb_queue_next return valid skb or garbage, not NULL. Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Szymon Janc 提交于
Due to ERTM reliability L2CAP channel needs to be disconnected if adding to srej list failed. Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
- 11 11月, 2011 2 次提交
-
-
由 Gustavo F. Padovan 提交于
Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Gustavo F. Padovan 提交于
rename to l2cap_chan_check_security() to make it consistent with other l2cap_exported functions. This function will be exported in a later commit. Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
- 08 11月, 2011 7 次提交
-
-
由 Andrei Emeltchenko 提交于
Add parsing Extended Flow Specification in L2CAP Config Response. Based upon haijun.liu <haijun.liu@atheros.com> series of patches (sent Sun, 22 Aug 2010) Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Andrei Emeltchenko 提交于
Use HCI error reasons instead of magic numbers. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Szymon Janc 提交于
Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Mat Martineau 提交于
AMP channels can be moved between BR/EDR and AMP controllers using a sequence of signals. Every attempted channel move involves a series of four signals: Move Initiator Move Responder | | | Move Channel Request | | ----------------------------> | | | | Move Channel Response | | <---------------------------- | | | | Move Channel Confirm | | ----------------------------> | | | | Move Channel Confirm Response | | <---------------------------- | All four signals are sent even if the move fails. Signed-off-by: NMat Martineau <mathewm@codeaurora.org> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Acked-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Mat Martineau 提交于
The A2MP fixed channel bit is only set when high-speed mode is enabled. Signed-off-by: NMat Martineau <mathewm@codeaurora.org> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Acked-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Mat Martineau 提交于
Handle both "create channel request" and "create channel response". Signed-off-by: NMat Martineau <mathewm@codeaurora.org> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Acked-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Luiz Augusto von Dentz 提交于
This implement priority based scheduler using skbuffer priority set via SO_PRIORITY socket option. It introduces hci_chan_hash (list of HCI Channel/hci_chan) per connection, each item in this list refer to a L2CAP connection and it is used to queue the data for transmission. Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-