I'd like to continue the previous thread on that Motorola S305 causes
kernel panic because I did find some clue here. Sorry for misleading
guess one month ago if any.
Recap the problem here so that you don't to read the first long post.
The pattern to reproduce the issue is:
1. Pair the S305 headset from the phone or the PC( I am using a Ubuntu)
2. Remove pairing on the phone or PC
3. Power off and then power on S305.
4. The S305 will try to connect and since link key removed on this
side it will try to pair. Input 0000.
5. Kernel panic happens. This can be observed on kernel version
2.6.29(on the Droid phone, yes, it's a modified version),
2.6.31-19-generic on a Ubuntu and a pretty latest 2.6.33-020633rc8
from Ubuntu official RC release.
The exact kernel crash point is
if (l2cap_check_security(sk)) {
if (bt_sk(sk)->defer_setup) {
struct sock *parent = bt_sk(sk)->parent;
rsp.result = cpu_to_le16(L2CAP_CR_PEND);
rsp.status = cpu_to_le16(L2CAP_CS_AUTHOR_PEND);
>>> parent->sk_data_ready(parent, 0)
} else {
After tracing the issue for a couple of weeks, I find the difference
between a normal flow and the panic one. If the user space process
accepts the L2CAP connection request before L2CAP_INFO_RSP received,
the following calls will be carried out:
l2cap_sock_accept-> bt_accept_dequeue->bt_accept_unlink(in the branch
bt_sk(parent)->defer_setup)-> set bt_sk(sk)->parent = NULL. Later when
L2CAP_INFO_RSP arrives, the l2cap_conn_start() will try to call the
marked line above and de-referring NULL happen.
To fix this, shall we consider checking if a pending socket can be
accepted in bt_accept_dequeue() prior to a pending L2CAP_INFO_REQ
responded? For example, adding a check to BT_CONNECT2 in
af_bluetooth.c.
215 if (sk->sk_state == BT_CONNECTED || !newsock ||
216 ( bt_sk(parent)->defer_setup &&
(sk->sk_state != BT_CONNECT2))) {
Again, I am not sure if this will bring a side-effect. Please advise
the most appropriate way. Thanks.
p.s: I attached partial trace files for those who're interested to the traces.
Trace when panic happended:
<3>[ 356.758483] l2cap_connect_req: psm 0x19 scid 0x0041
<3>[ 356.763854] l2cap_connect_req: parent c7e8f600
<3>[ 356.768829] __l2cap_chan_add: conn c7fa37c0, psm 0x19, dcid 0x0041
<3>[ 356.775482] l2cap_connect_req: before return, sk c5d66c00 parent c7e8f600
<3>[ 356.782897] l2cap_connect_req: psm 0x01 scid 0x0042
<3>[ 356.788177] l2cap_connect_req: parent c7e8fe00
<3>[ 356.793121] __l2cap_chan_add: conn c7fa37c0, psm 0x01, dcid 0x0042
<3>[ 356.799774] l2cap_connect_req: before return, sk c5d66a00 parent c7e8fe00
<3>[ 356.837158] l2cap_sock_accept: new socket c5d66c00
<3>[ 356.842590] l2cap_conn_start: BT_CONNECTE2, sk c5d66c00, parent (null)
Trace when everything goes on well.
<3>[ 641.393463] l2cap_connect_req: psm 0x19 scid 0x0041
<3>[ 641.398956] l2cap_connect_req: parent c7e91200
<3>[ 641.403778] __l2cap_chan_add: conn c9519440, psm 0x19, dcid 0x0041
<3>[ 641.410461] l2cap_connect_req: before return, sk c97e3a00 parent c7e91200
<3>[ 641.417877] l2cap_connect_req: psm 0x01 scid 0x0042
<3>[ 641.423156] l2cap_connect_req: parent c64b0c00
<3>[ 641.428131] __l2cap_chan_add: conn c9519440, psm 0x01, dcid 0x0042
<3>[ 641.434753] l2cap_connect_req: before return, sk c97e3400 parent c64b0c00
<3>[ 641.476165] l2cap_conn_start: BT_CONNECTE2, sk c97e3a00, parent c7e91200
<3>[ 641.483856] l2cap_sock_accept: new socket c97e3a00
<3>[ 641.551513] l2cap_sock_accept: new socket c97e3400
<3>[ 641.592742] l2cap_sock_shutdown: sock cea7a840, sk c97e3a00, how 2
<3>[ 641.607727] l2cap_sock_shutdown: sock cea7a0c0, sk c97e3400, how 2
<3>[ 644.055419] __l2cap_chan_add: conn c9519440, psm 0x01, dcid 0x0000
<3>[ 650.055816] l2cap_sock_shutdown: sock cea7a0c0, sk c97e3400, how 2
<3>[ 650.063018] l2cap_sock_shutdown: sk-shutdown = true
<3>[ 650.069427] __l2cap_sock_close: sk c97e3400 state 1 socket cea7a0c0 reason 0
