Kernel panic observed during sco-connection-disconnection

Refresh

This website lore-kernel.gnuweeb.org/all/20151023083319.GA31574@t440s.lan/t/ is currently offline. Cloudflare\'s Always Online™ shows a snapshot of this web page from the Internet Archive\'s Wayback Machine. To check for the live version, click Refresh.

* Kernel panic observed during sco-connection-disconnection @ 2015-10-23 8:28 s.syam 2015-10-23 8:33 ` Johan Hedberg 0 siblings, 1 reply; 3+ messages in thread From: s.syam @ 2015-10-23 8:28 UTC (permalink / raw) To: linux-bluetooth Cc: Anurag B, Sreeraj Mohan, Nagaraj DR, '박찬열', jy0214.kim, '서호철' Hi All, We have observed one kernel panic during the sco close. The panic logs has been given below. Further analysis we could see that invalid memory access is happening at sco_pi(sk)->conn->hcon = NULL; in __sco_sock_close(). It will be great if someone analyses and provide the fix/clue for this issue. Thanks for your time. Code: static void __sco_sock_close(struct sock *sk) { BT_DBG("sk %p state %d socket %p", sk, sk->sk_state, sk->sk_socket); switch (sk->sk_state) { case BT_LISTEN: sco_sock_cleanup_listen(sk); break; case BT_CONNECTED: case BT_CONFIG: if (sco_pi(sk)->conn->hcon) { sk->sk_state = BT_DISCONN; sco_sock_set_timer(sk, SCO_DISCONN_TIMEOUT); hci_conn_drop(sco_pi(sk)->conn->hcon); sco_pi(sk)->conn->hcon = NULL; //Invalid memory access happen here. } else sco_chan_del(sk, ECONNRESET); break; case BT_CONNECT2: case BT_CONNECT: case BT_DISCONN: ... ... } } Logs: Oct 21 23:35:12 alert Kernel: [ 175.323507] Unable to handle kernel NULL pointer dereference at virtual address 00000000 ..... Oct 21 23:35:12 warn Kernel: [ 175.338344] [<c0866be4>] (__sco_sock_close+0x1ec/0x230) from [<c0866d20>] (sco_sock_close+0x20/0x34) Oct 21 23:35:12 warn Kernel: [ 175.338478] [<c0866d20>] (sco_sock_close+0x20/0x34) from [<c0866d78>] (sco_sock_release+0x44/0x100) Oct 21 23:35:12 warn Kernel: [ 175.338614] [<c0866d78>] (sco_sock_release+0x44/0x100) from [<c0721ad0>] (sock_release+0x20/0xc4) Oct 21 23:35:12 warn Kernel: [ 175.338745] [<c0721ad0>] (sock_release+0x20/0xc4) from [<c07221e4>] (sock_close+0x20/0x2c) Oct 21 23:35:12 warn Kernel: [ 175.338874] [<c07221e4>] (sock_close+0x20/0x2c) from [<c02741d0>] (fput+0x11c/0x230) Oct 21 23:35:12 warn Kernel: [ 175.338994] [<c02741d0>] (fput+0x11c/0x230) from [<c0270fa8>] (filp_close+0x70/0x7c) Oct 21 23:35:12 warn Kernel: [ 175.339110] [<c0270fa8>] (filp_close+0x70/0x7c) from [<c0271064>] (sys_close+0xb0/0xf0) Oct 21 23:35:12 warn Kernel: [ 175.339232] [<c0271064>] (sys_close+0xb0/0xf0) from [<c0105d9c>] (__sys_trace_return+0x0/0x24) Regards, Syam ^ permalink raw reply [flat|nested] 3+ messages in thread

* Re: Kernel panic observed during sco-connection-disconnection 2015-10-23 8:28 Kernel panic observed during sco-connection-disconnection s.syam @ 2015-10-23 8:33 ` Johan Hedberg 2015-10-26 0:54 ` Syam Sidhardhan 0 siblings, 1 reply; 3+ messages in thread From: Johan Hedberg @ 2015-10-23 8:33 UTC (permalink / raw) To: s.syam Cc: linux-bluetooth, Anurag B, Sreeraj Mohan, Nagaraj DR, '박찬열', jy0214.kim, '서호철', kubax.t.pawlak Hi Syam, On Fri, Oct 23, 2015, s.syam@samsung.com wrote: > We have observed one kernel panic during the sco close. > The panic logs has been given below. Further analysis we could see that invalid memory access is happening at > sco_pi(sk)->conn->hcon = NULL; in __sco_sock_close(). > > It will be great if someone analyses and provide the fix/clue for this issue. > Thanks for your time. > > > Code: > static void __sco_sock_close(struct sock *sk) > { > BT_DBG("sk %p state %d socket %p", sk, sk->sk_state, sk->sk_socket); > > switch (sk->sk_state) { > case BT_LISTEN: > sco_sock_cleanup_listen(sk); > break; > > case BT_CONNECTED: > case BT_CONFIG: > if (sco_pi(sk)->conn->hcon) { > sk->sk_state = BT_DISCONN; > sco_sock_set_timer(sk, SCO_DISCONN_TIMEOUT); > hci_conn_drop(sco_pi(sk)->conn->hcon); > sco_pi(sk)->conn->hcon = NULL; //Invalid memory access happen here. > } else > sco_chan_del(sk, ECONNRESET); > break; > > case BT_CONNECT2: > case BT_CONNECT: > case BT_DISCONN: > ... > ... > } > } > > Logs: > Oct 21 23:35:12 alert Kernel: [ 175.323507] Unable to handle kernel NULL pointer dereference at virtual address 00000000 > ..... > Oct 21 23:35:12 warn Kernel: [ 175.338344] [<c0866be4>] (__sco_sock_close+0x1ec/0x230) from [<c0866d20>] (sco_sock_close+0x20/0x34) > Oct 21 23:35:12 warn Kernel: [ 175.338478] [<c0866d20>] (sco_sock_close+0x20/0x34) from [<c0866d78>] (sco_sock_release+0x44/0x100) > Oct 21 23:35:12 warn Kernel: [ 175.338614] [<c0866d78>] (sco_sock_release+0x44/0x100) from [<c0721ad0>] (sock_release+0x20/0xc4) > Oct 21 23:35:12 warn Kernel: [ 175.338745] [<c0721ad0>] (sock_release+0x20/0xc4) from [<c07221e4>] (sock_close+0x20/0x2c) > Oct 21 23:35:12 warn Kernel: [ 175.338874] [<c07221e4>] (sock_close+0x20/0x2c) from [<c02741d0>] (fput+0x11c/0x230) > Oct 21 23:35:12 warn Kernel: [ 175.338994] [<c02741d0>] (fput+0x11c/0x230) from [<c0270fa8>] (filp_close+0x70/0x7c) > Oct 21 23:35:12 warn Kernel: [ 175.339110] [<c0270fa8>] (filp_close+0x70/0x7c) from [<c0271064>] (sys_close+0xb0/0xf0) > Oct 21 23:35:12 warn Kernel: [ 175.339232] [<c0271064>] (sys_close+0xb0/0xf0) from [<c0105d9c>] (__sys_trace_return+0x0/0x24) You'll probably want to take a look at the SCO socket patch set that Kuba sent in the beginning of this month: [PATCH 0/5] Few proposed fixes to stop crashes on fast SCO disconnec Particularly his second patch looks like something that could be related to this. Johan ^ permalink raw reply [flat|nested] 3+ messages in thread

* Re: Kernel panic observed during sco-connection-disconnection 2015-10-23 8:33 ` Johan Hedberg @ 2015-10-26 0:54 ` Syam Sidhardhan 0 siblings, 0 replies; 3+ messages in thread From: Syam Sidhardhan @ 2015-10-26 0:54 UTC (permalink / raw) To: Syam Sidhardhan, User Name, Anurag B, Sreeraj Mohan, Nagaraj DR, 박찬열, jy0214.kim, 서호철, kubax.t.pawlak, Sang-Ki Park, ravi.g Hi Johan/Kuba, On Fri, Oct 23, 2015 at 2:03 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote: > Hi Syam, > > On Fri, Oct 23, 2015, s.syam@samsung.com wrote: >> We have observed one kernel panic during the sco close. >> The panic logs has been given below. Further analysis we could see that invalid memory access is happening at >> sco_pi(sk)->conn->hcon = NULL; in __sco_sock_close(). >> >> It will be great if someone analyses and provide the fix/clue for this issue. >> Thanks for your time. >> >> >> Code: >> static void __sco_sock_close(struct sock *sk) >> { >> BT_DBG("sk %p state %d socket %p", sk, sk->sk_state, sk->sk_socket); >> >> switch (sk->sk_state) { >> case BT_LISTEN: >> sco_sock_cleanup_listen(sk); >> break; >> >> case BT_CONNECTED: >> case BT_CONFIG: >> if (sco_pi(sk)->conn->hcon) { >> sk->sk_state = BT_DISCONN; >> sco_sock_set_timer(sk, SCO_DISCONN_TIMEOUT); >> hci_conn_drop(sco_pi(sk)->conn->hcon); >> sco_pi(sk)->conn->hcon = NULL; //Invalid memory access happen here. >> } else >> sco_chan_del(sk, ECONNRESET); >> break; >> >> case BT_CONNECT2: >> case BT_CONNECT: >> case BT_DISCONN: >> ... >> ... >> } >> } >> >> Logs: >> Oct 21 23:35:12 alert Kernel: [ 175.323507] Unable to handle kernel NULL pointer dereference at virtual address 00000000 >> ..... >> Oct 21 23:35:12 warn Kernel: [ 175.338344] [<c0866be4>] (__sco_sock_close+0x1ec/0x230) from [<c0866d20>] (sco_sock_close+0x20/0x34) >> Oct 21 23:35:12 warn Kernel: [ 175.338478] [<c0866d20>] (sco_sock_close+0x20/0x34) from [<c0866d78>] (sco_sock_release+0x44/0x100) >> Oct 21 23:35:12 warn Kernel: [ 175.338614] [<c0866d78>] (sco_sock_release+0x44/0x100) from [<c0721ad0>] (sock_release+0x20/0xc4) >> Oct 21 23:35:12 warn Kernel: [ 175.338745] [<c0721ad0>] (sock_release+0x20/0xc4) from [<c07221e4>] (sock_close+0x20/0x2c) >> Oct 21 23:35:12 warn Kernel: [ 175.338874] [<c07221e4>] (sock_close+0x20/0x2c) from [<c02741d0>] (fput+0x11c/0x230) >> Oct 21 23:35:12 warn Kernel: [ 175.338994] [<c02741d0>] (fput+0x11c/0x230) from [<c0270fa8>] (filp_close+0x70/0x7c) >> Oct 21 23:35:12 warn Kernel: [ 175.339110] [<c0270fa8>] (filp_close+0x70/0x7c) from [<c0271064>] (sys_close+0xb0/0xf0) >> Oct 21 23:35:12 warn Kernel: [ 175.339232] [<c0271064>] (sys_close+0xb0/0xf0) from [<c0105d9c>] (__sys_trace_return+0x0/0x24) > > You'll probably want to take a look at the SCO socket patch set that > Kuba sent in the beginning of this month: > > [PATCH 0/5] Few proposed fixes to stop crashes on fast SCO disconnec > > Particularly his second patch looks like something that could be related > to this. > Thanks for your guidance. We will try with Kuba's patch sets. Few of them has already applied to bluetooth-next a couple of hours back. Look like his Patch 1/5 fixes the one time issue which I reported 3 months back with subject "Sco connection disconnection panic happen". Thanks Johan & Kuba. Regards, Syam. ^ permalink raw reply [flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-10-26 0:54 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-10-23 8:28 Kernel panic observed during sco-connection-disconnection s.syam 2015-10-23 8:33 ` Johan Hedberg 2015-10-26 0:54 ` Syam Sidhardhan