Re: [RFC] fs: add userspace critical mounts event support

On Tue, 2016-11-29 at 22:37 +0100, Luis R. Rodriguez wrote: > On Tue, Nov 29, 2016 at 10:10:56PM +0100, Tom Gundersen wrote: > > > > On Tue, Nov 15, 2016 at 10:28 AM, Johannes Berg > > wrote: > > > > > > My argument basically goes like this: > > > > > > First, given

Re: [RFC] fs: add userspace critical mounts event support

On Wed, Nov 09, 2016 at 03:21:07AM -0800, Andy Lutomirski wrote: > On Wed, Nov 9, 2016 at 1:13 AM, Daniel Wagner > wrote: > > [CC: added Harald] > > > > As Harald pointed out over a beer yesterday evening, there is at least > > one more reason why UMH isn't obsolete.

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Nov 29, 2016 at 10:10:56PM +0100, Tom Gundersen wrote: > On Tue, Nov 15, 2016 at 10:28 AM, Johannes Berg > wrote: > > My argument basically goes like this: > > > > First, given good drivers (i.e. using request_firmware_nowait()) > > putting firmware even for a

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Nov 15, 2016 at 10:28 AM, Johannes Berg wrote: > My argument basically goes like this: > > First, given good drivers (i.e. using request_firmware_nowait()) > putting firmware even for a built-in driver into initramfs or not > should be a system integrator

Re: [RFC] fs: add userspace critical mounts event support

On Tue, 2016-11-08 at 23:47 +0100, Luis R. Rodriguez wrote: > This issue still stands. At Plumbers Johannes Berg did indicate to me > he had a simple elegant solution in mind. He suggested that since the > usermode helper was available, he had added support to be able to > differentiate async

Re: [RFC] fs: add userspace critical mounts event support

On Wed, Nov 9, 2016 at 3:21 AM, Andy Lutomirski wrote: > On Wed, Nov 9, 2016 at 1:13 AM, Daniel Wagner > wrote: >> [CC: added Harald] >> >> As Harald pointed out over a beer yesterday evening, there is at least >> one more reason why UMH isn't

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Nov 8, 2016 at 2:47 PM, Luis R. Rodriguez wrote: > Whatever the outcome of this discussion is -- Johannes seemed to *want* > to further use the UMH by default on *all* async alls... even if the > driver did not explicitly requested it -- I'm concerned about this given >

Re: [RFC] fs: add userspace critical mounts event support

On Wed, Nov 9, 2016 at 1:13 AM, Daniel Wagner wrote: > [CC: added Harald] > > As Harald pointed out over a beer yesterday evening, there is at least > one more reason why UMH isn't obsolete. The ordering of the firmware loading > might be of important. Say you want to

Re: [RFC] fs: add userspace critical mounts event support

[CC: added Harald] On 11/08/2016 11:47 PM, Luis R. Rodriguez wrote: On Wed, Oct 05, 2016 at 09:46:33PM +0200, Luis R. Rodriguez wrote: On Wed, Oct 05, 2016 at 11:08:06AM -0700, Linus Torvalds wrote: On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez wrote: On Tue, Sep 13,

Re: [RFC] fs: add userspace critical mounts event support

On Wed, Oct 05, 2016 at 09:46:33PM +0200, Luis R. Rodriguez wrote: > On Wed, Oct 05, 2016 at 11:08:06AM -0700, Linus Torvalds wrote: > > On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez > > wrote: > > > On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > > > > >

Re: [RFC] fs: add userspace critical mounts event support

On Wed, Oct 05, 2016 at 11:08:06AM -0700, Linus Torvalds wrote: > On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez wrote: > > On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > > > >> I did some shuffling around of those code to make initmpfs work, does > >>

Re: [RFC] fs: add userspace critical mounts event support

On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez wrote: > On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > >> I did some shuffling around of those code to make initmpfs work, does >> anybody know why initramfs extraction _before_ we initialize drivers >> would

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > On 09/02/2016 07:20 PM, Luis R. Rodriguez wrote: > > kernel_read_file_from_path() can try to read a file from > > the system's filesystem. This is typically done for firmware > > for instance, which lives in /lib/firmware. One issue

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Oct 04, 2016 at 05:32:22PM -0700, Linus Torvalds wrote: > On Tue, Oct 4, 2016 at 5:24 PM, Luis R. Rodriguez wrote: > > > > Note that the races are beyond firmware, so all > > kernel_read_file_from_path() users, as such re-using such old /sys/ > > interafeces for

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Oct 4, 2016 at 6:48 PM, Josh Triplett wrote: > >I definitely don't think it > should be a system-wide "mount event"; it should be a per-device "go > direct-load your firmware" poke from userspace. I don't disagree with that kind of interface. We already have

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Oct 04, 2016 at 05:12:58PM -0700, Linus Torvalds wrote: > On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez wrote: > > I am not sure how/why a firmware loading daemon would be a better > > idea now. What Marc describes that Josh proposed with signals for > > userspcae

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Oct 4, 2016 at 5:24 PM, Luis R. Rodriguez wrote: > > Note that the races are beyond firmware, so all > kernel_read_file_from_path() users, as such re-using such old /sys/ > interafeces for firmware will not suffice to cover all ground now for > the same race for other

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Oct 4, 2016 at 5:12 PM, Linus Torvalds wrote: > On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez wrote: >> >> I am not sure how/why a firmware loading daemon would be a better >> idea now. What Marc describes that Josh proposed with

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez wrote: > > I am not sure how/why a firmware loading daemon would be a better > idea now. What Marc describes that Josh proposed with signals for > userspcae seems more aligned with what we likely need Quite frankly, I doubt you

Re: [RFC] fs: add userspace critical mounts event support

On Sat, Sep 24, 2016 at 10:41:46AM -0700, Dmitry Torokhov wrote: > On Fri, Sep 23, 2016 at 6:37 PM, Herbert, Marc wrote: > > On 03/09/2016 11:10, Dmitry Torokhov wrote: > >> I was thinking if we kernel could post > >> "conditions" (maybe simple stings) that it waits for,

Re: [RFC] fs: add userspace critical mounts event support

On Fri, Sep 23, 2016 at 6:37 PM, Herbert, Marc wrote: > On 03/09/2016 11:10, Dmitry Torokhov wrote: >> I was thinking if we kernel could post >> "conditions" (maybe simple stings) that it waits for, and userspace >> could unlock these "conditions". One of them might be

Re: [RFC] fs: add userspace critical mounts event support

On 03/09/2016 11:10, Dmitry Torokhov wrote: > I was thinking if we kernel could post > "conditions" (maybe simple stings) that it waits for, and userspace > could unlock these "conditions". One of them might be "firmware > available". On idea offered by Josh Triplett that seems to overlap with

Re: [RFC] fs: add userspace critical mounts event support

On 09/02/2016 07:20 PM, Luis R. Rodriguez wrote: > kernel_read_file_from_path() can try to read a file from > the system's filesystem. This is typically done for firmware > for instance, which lives in /lib/firmware. One issue with > this is that the kernel cannot know for sure when the real >

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Sep 06, 2016 at 03:28:47PM -0700, Bjorn Andersson wrote: > On Tue 06 Sep 14:52 PDT 2016, Luis R. Rodriguez wrote: > > > We already have MODULE_FIRMWARE(), we could have MODULE_FIRMWARE_REQ() or > > something like it to help annotate the the driver was only functional with > > the > >

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Sep 06, 2016 at 02:50:51PM -0700, Linus Torvalds wrote: > On Tue, Sep 6, 2016 at 2:11 PM, Bjorn Andersson > wrote: > > On Tue 06 Sep 11:32 PDT 2016, Linus Torvalds wrote: > > > >> On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson > >> Nobody has actually

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Sep 06, 2016 at 11:32:05AM -0700, Linus Torvalds wrote: > On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson > wrote: > > > > Linus, I reversed the order of your questions/answers to fit my answer > > better. > > Nobody has actually answered the "why don't we

Re: [RFC] fs: add userspace critical mounts event support

On Tue 06 Sep 14:52 PDT 2016, Luis R. Rodriguez wrote: > We already have MODULE_FIRMWARE(), we could have MODULE_FIRMWARE_REQ() or > something like it to help annotate the the driver was only functional with the > firmware, punt things to kmod to deal with the requirements. That implies that a

Re: [RFC] fs: add userspace critical mounts event support

On Sat, Sep 03, 2016 at 11:10:02AM -0700, Dmitry Torokhov wrote: > On Sat, Sep 3, 2016 at 11:01 AM, Linus Torvalds > wrote: > > On Sat, Sep 3, 2016 at 10:49 AM, Dmitry Torokhov > > wrote: > >> > >> Unfortunately module loading and

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Sep 6, 2016 at 2:11 PM, Bjorn Andersson wrote: > On Tue 06 Sep 11:32 PDT 2016, Linus Torvalds wrote: > >> On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson >> Nobody has actually answered the "why don't we just tie the firmware >> and module together" question.

Re: [RFC] fs: add userspace critical mounts event support

On Tue 06 Sep 11:32 PDT 2016, Linus Torvalds wrote: > On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson > wrote: > > > > Linus, I reversed the order of your questions/answers to fit my answer > > better. > > Nobody has actually answered the "why don't we just tie the

Re: [RFC] fs: add userspace critical mounts event support

On Fri 02 Sep 21:11 PDT 2016, Linus Torvalds wrote: Linus, I reversed the order of your questions/answers to fit my answer better. > On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez wrote: > > > > Thoughts ? > What are the drivers that need this, and why can't those drivers

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson wrote: > > Linus, I reversed the order of your questions/answers to fit my answer > better. Nobody has actually answered the "why don't we just tie the firmware and module together" question. Really. If the driver

Re: [RFC] fs: add userspace critical mounts event support

On Sat, Sep 3, 2016 at 11:01 AM, Linus Torvalds wrote: > On Sat, Sep 3, 2016 at 10:49 AM, Dmitry Torokhov > wrote: >> >> Unfortunately module loading and availability of firmware is very >> loosely coupled. > > The whole "let's add a new

Re: [RFC] fs: add userspace critical mounts event support

On Sat, Sep 3, 2016 at 10:49 AM, Dmitry Torokhov wrote: > > Unfortunately module loading and availability of firmware is very > loosely coupled. The whole "let's add a new magical proc entry to say that all filesystems are mounted" is all about the user space coupling

Re: [RFC] fs: add userspace critical mounts event support

On Fri, Sep 02, 2016 at 09:41:18PM -0700, Linus Torvalds wrote: > On Sep 2, 2016 9:20 PM, "Dmitry Torokhov" wrote: > > > > Like what? Some devices do need to have firmware loaded so we know > > their capabilities, so we really can't push the firmware loading into > >

Re: [RFC] fs: add userspace critical mounts event support

On Sep 2, 2016 9:20 PM, "Dmitry Torokhov" wrote: > > Like what? Some devices do need to have firmware loaded so we know > their capabilities, so we really can't push the firmware loading into > "open". So you (a) document that (b) make the driver only build as a module

Re: [RFC] fs: add userspace critical mounts event support

On Fri, Sep 2, 2016 at 9:11 PM, Linus Torvalds wrote: > On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez wrote: >> >> Thoughts ? > > I really think this is a horrible hack. > > It's basically the kernel giving up, and relying on user space to

Re: [RFC] fs: add userspace critical mounts event support

On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez wrote: > > Thoughts ? I really think this is a horrible hack. It's basically the kernel giving up, and relying on user space to give a single flag, and it's broken nasty crap. Worse, it's broken nasty crap with a user