linux-kernel - Re: [PATCH 1/3] firmware: Avoid superfluous usermodehelper lock

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: <CACVXFVPRLiP3wFL6CZbKxS73JRDybtig83vhjQ6q-yoM8uLPyg@mail.gmail.com>
Date:	Thu, 9 May 2013 16:43:28 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 1/3] firmware: Avoid superfluous usermodehelper lock

On Thu, May 9, 2013 at 3:31 PM, Takashi Iwai <tiwai@...e.de> wrote:
> At Thu, 9 May 2013 09:25:35 +0800,
> Ming Lei wrote:
>>
>> On Thu, May 9, 2013 at 1:51 AM, Takashi Iwai <tiwai@...e.de> wrote:
>> >> In other words, the first patch is no essential part of the fix.
>> >> I can revisit the second patch without this one and resend if
>> >> preferred.
>> >
>> > FWIW, below is the revised patch.
>> > It's alone without the patch 1 in the previous series.
>>
>> The root cause is that your user space loader doesn't follow the
>> current firmware loader interface.
>
> There is not necessarily a user space "loader".  It's declared as
> non-hotplug, thus it can be a manual operation by human.
>
>> IMO, the patch is unnecessary since we already have the timeout
>> abort(just need one patch to enable it for nowait api)
>
> Well, you cannot know any sane value for such human's operation.
> If it's a system response, then we can assume something.  But the
> invocation of request_firmware_nowait() with non-hotplug means that
> you can never know the actual use case, thus you cannot know any sane

I think the use case should be driver specific, and the loading is triggered
from user space in dell_rbu(write sysfs file to trigger BIOS update), so the
user has been ready for loading the image.

For another usage(lattice-ecp3-config.c), it is merged recently and very
specific(maybe only for personal use), and can be easily to change to
trigger loading from user space like dell.

I think both the two usages choose FW_ACTION_NOHOTPLUG
because they have out of tree firmware images.  So looks enabling
timeout won't be a big deal for them.

> timeout, too.
>
> And secondly, I don't think it's good to rely on the timeout.  Why
> does the system have to wait for minute for shutdown?  The system is

It won't if the user space follows the rules.

> in shutdown, and it's triggered by user.  It's more natural to abort
> the pending f/w loading because you don't want to handle it any
> longer after the system shuts down.

There is still risk to force killing the loader before shutdown or
suspend.  Maybe some devices depend its firmware in shutdown
or suspend callback to configure power setting.

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/