linux-kernel - Re: udev 182: response timeout for request_firmware in module

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:	Sat, 25 Aug 2012 11:59:59 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Kay Sievers <kay@...y.org>
Cc:	Ming Lei <tom.leiming@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Johannes Berg <johannes@...solutions.net>,
	Larry Finger <Larry.Finger@...inger.net>,
	systemd-devel@...ts.freedesktop.org
Subject: Re: udev 182: response timeout for request_firmware in module_probe path

On Thu, Aug 23, 2012 at 8:31 AM, Kay Sievers <kay@...y.org> wrote:
>
> Calling out from inside the kernel and blocking in a firmware loading
> userspace transaction during module_init() is kind of weird.

It's *very* common.

I personally would prefer if drivers did their firmware loading not at
probe time, but at device open time, but that's not always necessarily
possible. More importantly, it's not actually how things are done.

So udev had better be fixed. The whole "no regressions" should be the
rule not just for the kernel, but it damn well should be the rule at
*least* also for projects like udev that are so closely related to the
kernel.

The "I wish things were otherwise than they are" mindset is wishful
thinking. Reality is that probing - and firmware loading - happens
from the module init routines quite often, and it clearly used to
work. So udev broke. Fix it, don't argue that you wish things were
otherwise.

            Linus
--
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/