linux-kernel - Re: [PATCH 1/2] firmware, fix request_firmware

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: <5267D85D.5030505@redhat.com>
Date:	Wed, 23 Oct 2013 10:08:29 -0400
From:	Prarit Bhargava <prarit@...hat.com>
To:	Ming Lei <ming.lei@...onical.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	x86@...nel.org,
	Andreas Herrmann <herrmann.der.user@...glemail.com>,
	tigran@...azian.fsnet.co.uk
Subject: Re: [PATCH 1/2] firmware, fix request_firmware_nowait() freeze with
 no uevent



On 10/23/2013 09:21 AM, Ming Lei wrote:
> On Wed, Oct 23, 2013 at 8:02 PM, Prarit Bhargava <prarit@...hat.com> wrote:
> 
>>
>> After all this I completely forgot the problem I'm trying to solve here.  The
>> issue is that with HOTPLUG & request_microcode_nowait(), if the microcode image
>> is not found (that is the file is not found on disk), then EACH cpu waits 1
>> minute and it takes 2 hours for a 120 cpu box to load the microcode module.
>>
>> Which is terrible... so HOTPLUG doesn't work here.
>>
>> Let me back up Ming and see if you have a better solution for me.  I have a
>> system that does not have the x86 microcode loaded on disk.  I use the microcode
>> module which calls request_firmware_nowait() to load the microcode image and I
>> want it done as fast as possible.  The microcode loader does not have a uevent
>> so I'm not waiting on userspace for completion.
>>
>> How do I avoid the 60 second delay/cpu introduced in the microcode path?  I
>> don't see one.  If I use HOTPLUG I'm waiting 60 seconds.  If I use NOHOTPLUG
>> AFAICT the loading function never will return.  AFAICT the same issue arises
>> with the dell_rbu code -- it appears to never load the dell_rbu firmware.
> 
> As I said, the 60 second delay is from udev, so that is the root cause.

Okay, so then my other option is to use NOHOTPLUG.  I've correctly modified it
to return and not wait for a NULL uevent.  The synchronization between the cont
function return and the actual application of the firmware is done in the driver
(in my 2/2 patch) where I've used a completion struct.  ... Am I still missing
something at this point?

I also have to make that change to the dell_rbu code because it too, is broken
the same way.  That is, I can load the dell_rbu module and it just hangs without
applying the firmware.

I'll submit a new version of these patches and we can continue from there.

P.
> 
> There are some workarounds for your reference:
> 

These are workarounds for an issue that arises in the kernel.

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