<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/net/bluetooth, branch v4.5-rc2</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Bluetooth: avoid rebuilding hci_sock all the time</title>
<updated>2016-01-06T15:36:44+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2016-01-06T13:38:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=787b306cf3296bdce5c8559206b237c1ae107484'/>
<id>787b306cf3296bdce5c8559206b237c1ae107484</id>
<content type='text'>
Instead, allow using string formatting with send_monitor_note()
and access init_utsname().

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Instead, allow using string formatting with send_monitor_note()
and access init_utsname().

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Add support for Start Limited Discovery command</title>
<updated>2016-01-05T16:02:50+00:00</updated>
<author>
<name>Johan Hedberg</name>
<email>johan.hedberg@intel.com</email>
</author>
<published>2016-01-05T11:19:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=78b781ca0d35191ebf8d8cad8beec810270f0f2e'/>
<id>78b781ca0d35191ebf8d8cad8beec810270f0f2e</id>
<content type='text'>
This patch implements the mgmt Start Limited Discovery command. Most
of existing Start Discovery code is reused since the only difference
is the presence of a 'limited' flag as part of the discovery state.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch implements the mgmt Start Limited Discovery command. Most
of existing Start Discovery code is reused since the only difference
is the presence of a 'limited' flag as part of the discovery state.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Change eir_has_data_type() to more generic eir_get_data()</title>
<updated>2016-01-05T16:02:49+00:00</updated>
<author>
<name>Johan Hedberg</name>
<email>johan.hedberg@intel.com</email>
</author>
<published>2016-01-05T11:19:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0d3b7f64c84d53658daf28e2f9772e38acb9340d'/>
<id>0d3b7f64c84d53658daf28e2f9772e38acb9340d</id>
<content type='text'>
To make the EIR parsing helper more general purpose, make it return
the found data and its length rather than just saying whether the data
was present or not.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
To make the EIR parsing helper more general purpose, make it return
the found data and its length rather than just saying whether the data
was present or not.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: use list_for_each_entry*</title>
<updated>2015-12-20T07:11:10+00:00</updated>
<author>
<name>Geliang Tang</name>
<email>geliangtang@163.com</email>
</author>
<published>2015-12-18T15:33:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7eb7404f7ee4bf59cb034897ab678aba2755c5e0'/>
<id>7eb7404f7ee4bf59cb034897ab678aba2755c5e0</id>
<content type='text'>
Use list_for_each_entry*() instead of list_for_each*() to simplify
the code.

Signed-off-by: Geliang Tang &lt;geliangtang@163.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use list_for_each_entry*() instead of list_for_each*() to simplify
the code.

Signed-off-by: Geliang Tang &lt;geliangtang@163.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2015-12-18T03:08:28+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2015-12-18T03:08:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b3e0d3d7bab14f2544a3314bec53a23dc7dd2206'/>
<id>b3e0d3d7bab14f2544a3314bec53a23dc7dd2206</id>
<content type='text'>
Conflicts:
	drivers/net/geneve.c

Here we had an overlapping change, where in 'net' the extraneous stats
bump was being removed whilst in 'net-next' the final argument to
udp_tunnel6_xmit_skb() was being changed.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Conflicts:
	drivers/net/geneve.c

Here we had an overlapping change, where in 'net' the extraneous stats
bump was being removed whilst in 'net-next' the final argument to
udp_tunnel6_xmit_skb() was being changed.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bluetooth: Validate socket address length in sco_sock_bind().</title>
<updated>2015-12-15T20:39:08+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2015-12-15T20:39:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5233252fce714053f0151680933571a2da9cbfb4'/>
<id>5233252fce714053f0151680933571a2da9cbfb4</id>
<content type='text'>
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Do not filter multicast addresses by default</title>
<updated>2015-12-11T09:46:16+00:00</updated>
<author>
<name>Danny Schweizer</name>
<email>danny.schweizer@proofnet.de</email>
</author>
<published>2015-12-11T09:04:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4ada1282d86865671abdfcf9410b895af8491213'/>
<id>4ada1282d86865671abdfcf9410b895af8491213</id>
<content type='text'>
A Linux PC is connected with another device over Bluetooth PAN using a
BNEP interface.

Whenever a packet is tried to be sent over the BNEP interface, the
function "bnep_net_xmit()" in "net/bluetooth/bnep/netdev.c" is called.
This function calls "bnep_net_mc_filter()", which checks (if the
destination address is multicast) if the address is set in a certain
multicast filter (&amp;s-&gt;mc_filter). If it is not, then it is not sent out.

This filter is only changed in two other functions, found in
net/bluetooth/bnep/core.c": in "bnep_ctrl_set_mc_filter()", which is
only called if a message of type "BNEP_FILTER_MULTI_ADDR_SET" is
received. Otherwise, it is set in "bnep_add_connection()", where it is
set to a default value which only adds the broadcast address to the
filter:

set_bit(bnep_mc_hash(dev-&gt;broadcast), (ulong *) &amp;s-&gt;mc_filter);

To sum up, if the BNEP interface does not receive any message of type
"BNEP_FILTER_MULTI_ADDR_SET", it will not send out any messages with
multicast destination addresses except for broadcast.

However, in the BNEP specification (page 27 in
http://grouper.ieee.org/groups/802/15/Bluetooth/BNEP.pdf), it is said
that per default, all multicast addresses should not be filtered, i.e.
the BNEP interface should be able to send packets with any multicast
destination address.

It seems that the default case is wrong: the multicast filter should not
block almost all multicast addresses, but should not filter out any.

This leads to the problem that e.g. Neighbor Solicitation messages sent
with Bluetooth PAN over the BNEP interface to a multicast destination
address other than broadcast are blocked and not sent out.

Therefore, in the default case, we set the mc_filter to ~0LL to not
filter out any multicast addresses.

Signed-off-by: Danny Schweizer &lt;danny.schweizer@proofnet.de&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A Linux PC is connected with another device over Bluetooth PAN using a
BNEP interface.

Whenever a packet is tried to be sent over the BNEP interface, the
function "bnep_net_xmit()" in "net/bluetooth/bnep/netdev.c" is called.
This function calls "bnep_net_mc_filter()", which checks (if the
destination address is multicast) if the address is set in a certain
multicast filter (&amp;s-&gt;mc_filter). If it is not, then it is not sent out.

This filter is only changed in two other functions, found in
net/bluetooth/bnep/core.c": in "bnep_ctrl_set_mc_filter()", which is
only called if a message of type "BNEP_FILTER_MULTI_ADDR_SET" is
received. Otherwise, it is set in "bnep_add_connection()", where it is
set to a default value which only adds the broadcast address to the
filter:

set_bit(bnep_mc_hash(dev-&gt;broadcast), (ulong *) &amp;s-&gt;mc_filter);

To sum up, if the BNEP interface does not receive any message of type
"BNEP_FILTER_MULTI_ADDR_SET", it will not send out any messages with
multicast destination addresses except for broadcast.

However, in the BNEP specification (page 27 in
http://grouper.ieee.org/groups/802/15/Bluetooth/BNEP.pdf), it is said
that per default, all multicast addresses should not be filtered, i.e.
the BNEP interface should be able to send packets with any multicast
destination address.

It seems that the default case is wrong: the multicast filter should not
block almost all multicast addresses, but should not filter out any.

This leads to the problem that e.g. Neighbor Solicitation messages sent
with Bluetooth PAN over the BNEP interface to a multicast destination
address other than broadcast are blocked and not sent out.

Therefore, in the default case, we set the mc_filter to ~0LL to not
filter out any multicast addresses.

Signed-off-by: Danny Schweizer &lt;danny.schweizer@proofnet.de&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>6lowpan: add lowpan dev register helpers</title>
<updated>2015-12-10T00:25:25+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>alex.aring@gmail.com</email>
</author>
<published>2015-12-09T21:46:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=00f59314111a6b18ee65b238b38c470dbdbf3be5'/>
<id>00f59314111a6b18ee65b238b38c470dbdbf3be5</id>
<content type='text'>
This patch introduces register and unregister functionality for lowpan
interfaces. While register a lowpan interface there are several things
which need to be initialize by the 6lowpan subsystem. Upcoming
functionality need to register/unregister per interface components e.g.
debugfs entry.

Reviewed-by: Stefan Schmidt &lt;stefan@osg.samsung.com&gt;
Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch introduces register and unregister functionality for lowpan
interfaces. While register a lowpan interface there are several things
which need to be initialize by the 6lowpan subsystem. Upcoming
functionality need to register/unregister per interface components e.g.
debugfs entry.

Reviewed-by: Stefan Schmidt &lt;stefan@osg.samsung.com&gt;
Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Fix locking in bt_accept_dequeue after disconnection</title>
<updated>2015-12-09T23:51:51+00:00</updated>
<author>
<name>Yichen Zhao</name>
<email>zhaoyichen@google.com</email>
</author>
<published>2015-12-01T19:11:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1a11ec89dba7bcfb1cb502fc5945533f317ddd03'/>
<id>1a11ec89dba7bcfb1cb502fc5945533f317ddd03</id>
<content type='text'>
Fix a crash that may happen when bt_accept_dequeue is run after a
Bluetooth connection has been disconnected. bt_accept_unlink was called
after release_sock, permitting bt_accept_unlink to run twice on the same
socket and cause a NULL pointer dereference.

[50510.241632] BUG: unable to handle kernel NULL pointer dereference at 00000000000001a8
[50510.241694] IP: [&lt;ffffffffc01243f7&gt;] bt_accept_unlink+0x47/0xa0 [bluetooth]
[50510.241759] PGD 0
[50510.241776] Oops: 0002 [#1] SMP
[50510.241802] Modules linked in: rtl8192cu rtl_usb rtlwifi rtl8192c_common 8021q garp stp mrp llc rfcomm bnep nls_iso8859_1 intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp arc4 ath9k ath9k_common ath9k_hw ath kvm eeepc_wmi asus_wmi mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek sparse_keymap crct10dif_pclmul snd_hda_codec_generic crc32_pclmul snd_hda_intel snd_hda_controller cfg80211 snd_hda_codec i915 snd_hwdep snd_pcm ghash_clmulni_intel snd_timer snd soundcore serio_raw cryptd drm_kms_helper drm i2c_algo_bit shpchp ath3k mei_me lpc_ich btusb bluetooth 6lowpan_iphc mei lp parport wmi video mac_hid psmouse ahci libahci r8169 mii
[50510.242279] CPU: 0 PID: 934 Comm: krfcommd Not tainted 3.16.0-49-generic #65~14.04.1-Ubuntu
[50510.242327] Hardware name: ASUSTeK Computer INC. VM40B/VM40B, BIOS 1501 12/09/2014
[50510.242370] task: ffff8800d9068a30 ti: ffff8800d7a54000 task.ti: ffff8800d7a54000
[50510.242413] RIP: 0010:[&lt;ffffffffc01243f7&gt;]  [&lt;ffffffffc01243f7&gt;] bt_accept_unlink+0x47/0xa0 [bluetooth]
[50510.242480] RSP: 0018:ffff8800d7a57d58  EFLAGS: 00010246
[50510.242511] RAX: 0000000000000000 RBX: ffff880119bb8c00 RCX: ffff880119bb8eb0
[50510.242552] RDX: ffff880119bb8eb0 RSI: 00000000fffffe01 RDI: ffff880119bb8c00
[50510.242592] RBP: ffff8800d7a57d60 R08: 0000000000000283 R09: 0000000000000001
[50510.242633] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800d8da9eb0
[50510.242673] R13: ffff8800d74fdb80 R14: ffff880119bb8c00 R15: ffff8800d8da9c00
[50510.242715] FS:  0000000000000000(0000) GS:ffff88011fa00000(0000) knlGS:0000000000000000
[50510.242761] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[50510.242794] CR2: 00000000000001a8 CR3: 0000000001c13000 CR4: 00000000001407f0
[50510.242835] Stack:
[50510.242849]  ffff880119bb8eb0 ffff8800d7a57da0 ffffffffc0124506 ffff8800d8da9eb0
[50510.242899]  ffff8800d8da9c00 ffff8800d9068a30 0000000000000000 ffff8800d74fdb80
[50510.242949]  ffff8800d6f85208 ffff8800d7a57e08 ffffffffc0159985 000000000000001f
[50510.242999] Call Trace:
[50510.243027]  [&lt;ffffffffc0124506&gt;] bt_accept_dequeue+0xb6/0x180 [bluetooth]
[50510.243085]  [&lt;ffffffffc0159985&gt;] l2cap_sock_accept+0x125/0x220 [bluetooth]
[50510.243128]  [&lt;ffffffff810a1b30&gt;] ? wake_up_state+0x20/0x20
[50510.243163]  [&lt;ffffffff8164946e&gt;] kernel_accept+0x4e/0xa0
[50510.243200]  [&lt;ffffffffc05b97cd&gt;] rfcomm_run+0x1ad/0x890 [rfcomm]
[50510.243238]  [&lt;ffffffffc05b9620&gt;] ? rfcomm_process_rx+0x8a0/0x8a0 [rfcomm]
[50510.243281]  [&lt;ffffffff81091572&gt;] kthread+0xd2/0xf0
[50510.243312]  [&lt;ffffffff810914a0&gt;] ? kthread_create_on_node+0x1c0/0x1c0
[50510.243353]  [&lt;ffffffff8176e9d8&gt;] ret_from_fork+0x58/0x90
[50510.243387]  [&lt;ffffffff810914a0&gt;] ? kthread_create_on_node+0x1c0/0x1c0
[50510.243424] Code: 00 48 8b 93 b8 02 00 00 48 8d 83 b0 02 00 00 48 89 51 08 48 89 0a 48 89 83 b0 02 00 00 48 89 83 b8 02 00 00 48 8b 83 c0 02 00 00 &lt;66&gt; 83 a8 a8 01 00 00 01 48 c7 83 c0 02 00 00 00 00 00 00 f0 ff
[50510.243685] RIP  [&lt;ffffffffc01243f7&gt;] bt_accept_unlink+0x47/0xa0 [bluetooth]
[50510.243737]  RSP &lt;ffff8800d7a57d58&gt;
[50510.243758] CR2: 00000000000001a8
[50510.249457] ---[ end trace bb984f932c4e3ab3 ]---

Signed-off-by: Yichen Zhao &lt;zhaoyichen@google.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix a crash that may happen when bt_accept_dequeue is run after a
Bluetooth connection has been disconnected. bt_accept_unlink was called
after release_sock, permitting bt_accept_unlink to run twice on the same
socket and cause a NULL pointer dereference.

[50510.241632] BUG: unable to handle kernel NULL pointer dereference at 00000000000001a8
[50510.241694] IP: [&lt;ffffffffc01243f7&gt;] bt_accept_unlink+0x47/0xa0 [bluetooth]
[50510.241759] PGD 0
[50510.241776] Oops: 0002 [#1] SMP
[50510.241802] Modules linked in: rtl8192cu rtl_usb rtlwifi rtl8192c_common 8021q garp stp mrp llc rfcomm bnep nls_iso8859_1 intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp arc4 ath9k ath9k_common ath9k_hw ath kvm eeepc_wmi asus_wmi mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek sparse_keymap crct10dif_pclmul snd_hda_codec_generic crc32_pclmul snd_hda_intel snd_hda_controller cfg80211 snd_hda_codec i915 snd_hwdep snd_pcm ghash_clmulni_intel snd_timer snd soundcore serio_raw cryptd drm_kms_helper drm i2c_algo_bit shpchp ath3k mei_me lpc_ich btusb bluetooth 6lowpan_iphc mei lp parport wmi video mac_hid psmouse ahci libahci r8169 mii
[50510.242279] CPU: 0 PID: 934 Comm: krfcommd Not tainted 3.16.0-49-generic #65~14.04.1-Ubuntu
[50510.242327] Hardware name: ASUSTeK Computer INC. VM40B/VM40B, BIOS 1501 12/09/2014
[50510.242370] task: ffff8800d9068a30 ti: ffff8800d7a54000 task.ti: ffff8800d7a54000
[50510.242413] RIP: 0010:[&lt;ffffffffc01243f7&gt;]  [&lt;ffffffffc01243f7&gt;] bt_accept_unlink+0x47/0xa0 [bluetooth]
[50510.242480] RSP: 0018:ffff8800d7a57d58  EFLAGS: 00010246
[50510.242511] RAX: 0000000000000000 RBX: ffff880119bb8c00 RCX: ffff880119bb8eb0
[50510.242552] RDX: ffff880119bb8eb0 RSI: 00000000fffffe01 RDI: ffff880119bb8c00
[50510.242592] RBP: ffff8800d7a57d60 R08: 0000000000000283 R09: 0000000000000001
[50510.242633] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800d8da9eb0
[50510.242673] R13: ffff8800d74fdb80 R14: ffff880119bb8c00 R15: ffff8800d8da9c00
[50510.242715] FS:  0000000000000000(0000) GS:ffff88011fa00000(0000) knlGS:0000000000000000
[50510.242761] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[50510.242794] CR2: 00000000000001a8 CR3: 0000000001c13000 CR4: 00000000001407f0
[50510.242835] Stack:
[50510.242849]  ffff880119bb8eb0 ffff8800d7a57da0 ffffffffc0124506 ffff8800d8da9eb0
[50510.242899]  ffff8800d8da9c00 ffff8800d9068a30 0000000000000000 ffff8800d74fdb80
[50510.242949]  ffff8800d6f85208 ffff8800d7a57e08 ffffffffc0159985 000000000000001f
[50510.242999] Call Trace:
[50510.243027]  [&lt;ffffffffc0124506&gt;] bt_accept_dequeue+0xb6/0x180 [bluetooth]
[50510.243085]  [&lt;ffffffffc0159985&gt;] l2cap_sock_accept+0x125/0x220 [bluetooth]
[50510.243128]  [&lt;ffffffff810a1b30&gt;] ? wake_up_state+0x20/0x20
[50510.243163]  [&lt;ffffffff8164946e&gt;] kernel_accept+0x4e/0xa0
[50510.243200]  [&lt;ffffffffc05b97cd&gt;] rfcomm_run+0x1ad/0x890 [rfcomm]
[50510.243238]  [&lt;ffffffffc05b9620&gt;] ? rfcomm_process_rx+0x8a0/0x8a0 [rfcomm]
[50510.243281]  [&lt;ffffffff81091572&gt;] kthread+0xd2/0xf0
[50510.243312]  [&lt;ffffffff810914a0&gt;] ? kthread_create_on_node+0x1c0/0x1c0
[50510.243353]  [&lt;ffffffff8176e9d8&gt;] ret_from_fork+0x58/0x90
[50510.243387]  [&lt;ffffffff810914a0&gt;] ? kthread_create_on_node+0x1c0/0x1c0
[50510.243424] Code: 00 48 8b 93 b8 02 00 00 48 8d 83 b0 02 00 00 48 89 51 08 48 89 0a 48 89 83 b0 02 00 00 48 89 83 b8 02 00 00 48 8b 83 c0 02 00 00 &lt;66&gt; 83 a8 a8 01 00 00 01 48 c7 83 c0 02 00 00 00 00 00 00 f0 ff
[50510.243685] RIP  [&lt;ffffffffc01243f7&gt;] bt_accept_unlink+0x47/0xa0 [bluetooth]
[50510.243737]  RSP &lt;ffff8800d7a57d58&gt;
[50510.243758] CR2: 00000000000001a8
[50510.249457] ---[ end trace bb984f932c4e3ab3 ]---

Signed-off-by: Yichen Zhao &lt;zhaoyichen@google.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Don't treat connection timeout as a failure</title>
<updated>2015-12-09T23:51:51+00:00</updated>
<author>
<name>Johan Hedberg</name>
<email>johan.hedberg@intel.com</email>
</author>
<published>2015-12-03T10:45:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=acb9f911ea1f828822001d72b21f7cc06e6718c7'/>
<id>acb9f911ea1f828822001d72b21f7cc06e6718c7</id>
<content type='text'>
When we're doing background scanning and connection attempts it's
possible we timeout trying to connect and go back to scanning again.
The timeout triggers a HCI_LE_Create_Connection_Cancel which will
trigger a Connection Complete with "Unknown Connection Identifier"
error status. Since we go back to scanning this isn't really a failure
and shouldn't be presented as such to user space through mgmt.

The exception to this is if the connection attempt was due to an
explicit request on an L2CAP socket (indicated by
params-&gt;explicit_connect being true). Since the socket will get an
error it's consistent to also notify the failure on mgmt in this case.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When we're doing background scanning and connection attempts it's
possible we timeout trying to connect and go back to scanning again.
The timeout triggers a HCI_LE_Create_Connection_Cancel which will
trigger a Connection Complete with "Unknown Connection Identifier"
error status. Since we go back to scanning this isn't really a failure
and shouldn't be presented as such to user space through mgmt.

The exception to this is if the connection attempt was due to an
explicit request on an L2CAP socket (indicated by
params-&gt;explicit_connect being true). Since the socket will get an
error it's consistent to also notify the failure on mgmt in this case.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
