linux-kernel - Re: pull request: bluetooth-next 2014-11-07

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <546C5241.6080903@samsung.com>
Date:	Wed, 19 Nov 2014 17:18:09 +0900
From:	Chan-yeol Park <chanyeol.park@...sung.com>
To:	"Kirill A. Shutemov" <kirill@...temov.name>,
	linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
	Kyungmin Park <kyungmin.park@...sung.com>,
	linville@...driver.com, linux-wireless@...r.kernel.org
Subject: Re: pull request: bluetooth-next 2014-11-07

Hi All

On 11/19/2014 03:09 AM, Johan Hedberg wrote:
> Hi Kirill,
>
> On Tue, Nov 18, 2014, Kirill A. Shutemov wrote:
>> On Fri, Nov 07, 2014 at 11:27:54AM +0200, Johan Hedberg wrote:
>>> Chan-yeol Park (1):
>>>        Bluetooth: Fix hci_sync missing wakeup interrupt
>> Look like this commit causes problem for me:
>>
>> [    2.018671] ------------[ cut here ]------------
>> [    2.022836] WARNING: CPU: 2 PID: 109 at /home/kas/git/public/linux/kernel/sched/core.c:7323 __might_sleep+0xbd/0xd0()
>> [    2.023166] Freeing unused kernel memory: 944K (ffff880001b14000 - ffff880001c00000)
>> [    2.030362] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff819ab67b>] __hci_req_sync+0x7b/0x2a0
>> [    2.034193] Modules linked in:
>> [    2.036133] CPU: 2 PID: 109 Comm: kworker/u17:0 Not tainted 3.18.0-rc4-next-20141117-07404-g9dad2ab6df8b #66
>> [    2.036383] Freeing unused kernel memory: 1404K (ffff8800020a1000 - ffff880002200000)
>> [    2.038940] Hardware name: LENOVO 3460CC6/3460CC6, BIOS G6ET93WW (2.53 ) 02/04/2013
>> [    2.040233] Workqueue: hci0 hci_power_on
>> [    2.041517]  ffffffff81f51d50 ffff8800d3ecfb28 ffffffff81afc316 0000000000000000
>> [    2.042811]  ffff8800d3ecfb78 ffff8800d3ecfb68 ffffffff810fc11a ffff880000000000
>> [    2.042812]  ffffffff81f52a28 000000000000026d 0000000000000000 ffff8800d3ec9200
>> [    2.042813] Call Trace:
>> [    2.042818]  [<ffffffff81afc316>] dump_stack+0x4c/0x6e
>> [    2.042821]  [<ffffffff810fc11a>] warn_slowpath_common+0x8a/0xc0
>> [    2.042823]  [<ffffffff810fc196>] warn_slowpath_fmt+0x46/0x50
>> [    2.042825]  [<ffffffff819ab67b>] ? __hci_req_sync+0x7b/0x2a0
>> [    2.042827]  [<ffffffff819ab67b>] ? __hci_req_sync+0x7b/0x2a0
>> [    2.042830]  [<ffffffff811295ed>] __might_sleep+0xbd/0xd0
>> [    2.042832]  [<ffffffff81b04b8f>] mutex_lock_nested+0x2f/0x450
>> [    2.042835]  [<ffffffff81b0812b>] ? _raw_spin_unlock+0x2b/0x50
>> [    2.042837]  [<ffffffff81131db0>] ? wake_up_process+0x50/0x50
>> [    2.042840]  [<ffffffff813b9ea1>] __create_file+0x71/0x2c0
>> [    2.042842]  [<ffffffff813ba10f>] debugfs_create_file+0x1f/0x30
>> [    2.042844]  [<ffffffff819ac461>] hci_dev_do_open+0x431/0xa70
>> [    2.042846]  [<ffffffff8111a72c>] ? process_one_work+0x13c/0x810
>> [    2.042847]  [<ffffffff819ad2b1>] hci_power_on+0x31/0x1e0
>> [    2.042849]  [<ffffffff8111a7c8>] process_one_work+0x1d8/0x810
>> [    2.042850]  [<ffffffff8111a72c>] ? process_one_work+0x13c/0x810
>> [    2.042851]  [<ffffffff8111b2db>] worker_thread+0x6b/0x4b0
>> [    2.042852]  [<ffffffff8111b270>] ? init_pwq+0xf0/0xf0
>> [    2.042854]  [<ffffffff81120ef9>] kthread+0x119/0x130
>> [    2.042855]  [<ffffffff8112923d>] ? finish_task_switch+0x4d/0x140
>> [    2.042857]  [<ffffffff81120de0>] ? kthread_create_on_node+0x240/0x240
>> [    2.042859]  [<ffffffff81b08cfc>] ret_from_fork+0x7c/0xb0
>> [    2.042861]  [<ffffffff81120de0>] ? kthread_create_on_node+0x240/0x240
>> [    2.042863] ---[ end trace 3a40e80ec4ca7159 ]---
> At least one obvious bug that the patch in question seems to have is
> that it fails to set the state back to TASK_RUNNING in case
> hci_req_run() fails and we never call schedule_timeout(). This would
> also seem to match the error you're getting.
>
> The attached patch fixes the missing set_current_state() calls - could
> you please check if it fixes the issue for you? Out of curiosity, which
> HW are you reproducing this with and are there any special steps
> involved? Looking at the code it seems that at least some older
> Bluetooth adapters could cause some hci_req_run() calls to return
> ENODATA, however I wasn't able to get the warning with any of my own
> adapters (I have one for pretty much every Bluetooth version).
>
> Johan
I agree I made a bug in the previous commit and I think we need to apply 
Johan's patch.
It is working fine on my machine.

Thanks
Chanyeol


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/