From: Kay Sievers <kay@vrfy.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Mauro Carvalho Chehab <mchehab@redhat.com>,
Lennart Poettering <lennart@poettering.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Kay Sievers <kay@redhat.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Michael Krufky <mkrufky@linuxtv.org>,
Tom Gundersen <tomegun@archlinux.org>
Subject: Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
Date: Wed, 3 Oct 2012 19:24:34 +0200 [thread overview]
Message-ID: <CAPXgP120SFAV4ZF_fYC3EdW0P6ZfaHFuLFFeNArgM5C9K7WXqA@mail.gmail.com> (raw)
In-Reply-To: <20121003165726.GA24577@kroah.com>
On Wed, Oct 3, 2012 at 6:57 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> It's the same in the current release, we still haven't wrapped our
>> head around how to fix it/work around it.
>
> Ick, as this is breaking people's previously-working machines, shouldn't
> this be resolved quickly?
Nothing really "breaks", It's "slow" and it will surely be fixed when
we know what's the right fix, which we haven't sorted out at this
moment.
> module_init() can do lots of "bad" things, sleeping, asking for
> firmware, and lots of other things. To have userspace block because of
> this doesn't seem very wise.
Not saying that it is right or nice, but it's the kernel itself that
blocks. Run init=/bin/sh and do a modprobe of one of these drivers and
it hangs un-interruptible until the kernel's internal firmware loading
request times out, just because userspace is not there.
> But previously this all "just worked" as we ran 'modprobe' in a new
> thread/process right?
No, we used to un-queue events which had a timeout specified in the
environment, that code caused other issues and was removed.
> it can do without worrying about stopping anything else in the system that might
> want to happen at the same time (like load multiple modules in a row).
It should not be an issue, the serialization is strictly parent <->
child, everything else runs in parallel.
>> If that unfortunate module_init() lockup can't be solved properly in
>> the kernel, we need to find out if we need to make the modprobe
>> handling in udev async, or let firmware events bypass dependency
>> resolving. As mentioned, we haven't decided as of now which road to
>> take here.
>
> It's not a lockup, there have never been rules about what a driver could
> and could not do in its module_init() function. Sure, there are some
> not-nice drivers out there, but don't halt the whole system just because
> of them.
It is a kind of lock up, just try modprobe with the init=/bin/sh boot.
> I recommend making module loading async, like it used to be, and then
> all should be fine, right?
That's the current idea, and Tom is looking into it how it could look like.
I also have no issues at all if the kernel does load the firmware from
the filesystem on its own; it sounds like the simplest and most robust
solution from a general look at the problem. It would also make the
difference between in-kernel firmware and out-of-kernel firmware less
visible, which sounds good.
Honestly, requiring firmware-loading userspace-transactions to
successfully link a module into the kernel sounds like a pretty bad
idea to start with. Unlike module loading which needs the depmod alias
database and userspace configuration; with firmware loading, there is
no policy involved where userspace would add any single additional
value to that step.
Thanks,
Kay
next prev parent reply other threads:[~2012-10-03 17:24 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1340285798-8322-1-git-send-email-mchehab@redhat.com>
[not found] ` <4FE37194.30407@redhat.com>
[not found] ` <4FE8B8BC.3020702@iki.fi>
[not found] ` <4FE8C4C4.1050901@redhat.com>
[not found] ` <4FE8CED5.104@redhat.com>
[not found] ` <20120625223306.GA2764@kroah.com>
[not found] ` <4FE9169D.5020300@redhat.com>
2012-10-02 13:03 ` udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() Mauro Carvalho Chehab
2012-10-02 16:33 ` Linus Torvalds
2012-10-02 21:03 ` Ivan Kalvachev
2012-10-02 22:37 ` Linus Torvalds
2012-10-03 22:15 ` Lucas De Marchi
2012-10-11 18:33 ` Shea Levy
2012-10-12 1:55 ` Ming Lei
2012-10-02 22:12 ` Greg KH
2012-10-02 22:23 ` Greg KH
2012-10-02 22:47 ` Linus Torvalds
2012-10-03 0:01 ` Jiri Kosina
2012-10-03 0:12 ` Linus Torvalds
2012-10-04 14:36 ` Jiri Kosina
2012-10-03 15:13 ` Mauro Carvalho Chehab
2012-10-03 16:38 ` Linus Torvalds
2012-10-03 17:00 ` Linus Torvalds
2012-10-03 17:09 ` Al Viro
2012-10-03 17:32 ` Linus Torvalds
2012-10-03 19:26 ` Al Viro
2012-10-04 0:57 ` udev breakages - Nix
2012-10-04 10:35 ` Nix
2012-10-03 19:50 ` udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() Greg KH
2012-10-03 20:39 ` Linus Torvalds
2012-10-03 21:04 ` Kay Sievers
2012-10-03 21:05 ` Greg KH
2012-10-03 21:18 ` Kay Sievers
2012-10-03 21:45 ` Alan Cox
2012-10-03 21:58 ` Lucas De Marchi
2012-10-03 22:17 ` Linus Torvalds
2012-10-03 22:48 ` Andy Walls
2012-10-03 22:58 ` Linus Torvalds
2012-10-04 2:39 ` Kay Sievers
2012-10-04 17:29 ` udev breakages - Eric W. Biederman
2012-10-04 17:42 ` Greg KH
2012-10-04 19:17 ` Alan Cox
2012-10-10 3:19 ` Felipe Contreras
2012-10-10 16:08 ` Geert Uytterhoeven
2012-10-11 3:32 ` Eric W. Biederman
2012-10-04 13:39 ` udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() Josh Boyer
2012-10-04 13:58 ` Greg KH
2012-10-03 22:53 ` Stephen Rothwell
2012-10-03 21:10 ` Andy Walls
2012-10-03 19:48 ` Access files from kernel Kirill A. Shutemov
2012-10-03 20:32 ` Linus Torvalds
[not found] ` <CACVXFVNTZmG+zTQNi9mCn9ynsCjkM084TmHKDcYYggtqLfhqNQ@mail.gmail.com>
2012-10-04 1:42 ` udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() Linus Torvalds
2012-10-03 14:12 ` Mauro Carvalho Chehab
2012-10-03 14:36 ` Kay Sievers
2012-10-03 14:44 ` Linus Torvalds
2012-10-03 16:57 ` Greg KH
2012-10-03 17:24 ` Kay Sievers [this message]
2012-10-03 18:07 ` Linus Torvalds
2012-10-03 19:46 ` Mauro Carvalho Chehab
[not found] <fa.90I1W/wmSTgRFXVG67o7Pp3+rKA@ifi.uio.no>
[not found] ` <fa.Oszo+r/ZqdTxC2FHqqg+CRVMJ5Y@ifi.uio.no>
[not found] ` <fa.CoxzZZId9dJONv353c+pFG/HO8E@ifi.uio.no>
[not found] ` <fa.ixJ/7D7BnMK8xp7CwikX7jbmnKU@ifi.uio.no>
[not found] ` <fa./ubRQE7P/T+ateohnOKdDxOFhL4@ifi.uio.no>
[not found] ` <fa.lpiFTa5CtuIkUf2Z5eJ0YlsNwYI@ifi.uio.no>
2012-10-04 14:50 ` Kurt H Maier
2012-10-05 8:03 ` Emmanuel Benisty
2012-10-05 20:17 ` david
2012-10-05 21:43 ` Henrique de Moraes Holschuh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPXgP120SFAV4ZF_fYC3EdW0P6ZfaHFuLFFeNArgM5C9K7WXqA@mail.gmail.com \
--to=kay@vrfy.org \
--cc=gregkh@linuxfoundation.org \
--cc=kay@redhat.com \
--cc=lennart@poettering.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@redhat.com \
--cc=mkrufky@linuxtv.org \
--cc=tomegun@archlinux.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).