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]

Date:	Thu, 09 May 2013 09:31:16 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Ming Lei <ming.lei@...onical.com>
Cc:	linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 1/3] firmware: Avoid superfluous usermodehelper lock

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
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
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.

I guess the same problem remains in the suspend/hibernation.

thanks,

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