linux-kernel - Re: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"

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]

Date:	Mon, 14 Jan 2013 15:15:21 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	Alex Riesen <raa.lkml@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Jens Axboe <axboe@...nel.dk>, linux-usb@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: USB device cannot be reconnected and khubd "blocked for more than
 120 seconds"

On Mon, Jan 14, 2013 at 11:47 AM, Ming Lei <ming.lei@...onical.com> wrote:
> On Mon, Jan 14, 2013 at 1:42 AM, Alex Riesen <raa.lkml@...il.com> wrote:
> [   86.901367] io scheduler deadline registered (default)
> [  181.168487] INFO: task modprobe:2462 blocked for more than 90 seconds.
> [  181.175323] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [  181.183624] modprobe        D c04f1920     0  2462   2461 0x00000000
> [  181.183685] [<c04f1920>] (__schedule+0x5fc/0x6d4) from [<c005eba4>]
> (async_synchronize_cookie_domain+0xdc/0x168)
> [  181.183715] [<c005eba4>] (async_synchronize_cookie_domain+0xdc/0x168) from [<c005ed04>] (async_synchronize_full+0x3c/0x60)
> [  181.183776] [<c005ed04>] (async_synchronize_full+0x3c/0x60) from [<c0085610>] (load_module+0x1aac/0x1cdc)
> [  181.183807] [<c0085610>] (load_module+0x1aac/0x1cdc) from [<c0085944>] (sys_init_module+0x104/0x110)
> [  181.183837] [<c0085944>] (sys_init_module+0x104/0x110) from
> [<c000dfe0>] (ret_fast_syscall+0x0/0x48)

The deadlock problem is caused by calling request_module() inside
async function of do_scan_async(), and it was introduced by Linus's
below commit:

commit d6de2c80e9d758d2e36c21699117db6178c0f517
Author: Linus Torvalds <torvalds@...ux-foundation.org>
Date:   Fri Apr 10 12:17:41 2009 -0700

    async: Fix module loading async-work regression

IMO, maybe the commit isn't a proper fix, considered the
below fact:

- it isn't good to allow async function to be marked as __init

- any user mode shouldn't expect that the device is ready just
after completing of 'insmod', and drivers should make
the device ready for user mode just after its async probing or
other kind of async initialization(done in work or kthread)
completes.

- from view of driver, introducing async_synchronize_full() after
do_one_initcall() inside do_init_module() is like a sync probe
for drivers built as module, and cause this kind of deadlock easily.

So could we revert the commit and fix the previous problems just
case by case? or other better fix?


Thanks,
--
Ming Lei
--
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/