linux-kernel - Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.

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:	Mon, 14 Jul 2008 18:44:18 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	akpm@...ux-foundation.org
Cc:	dwmw2@...radead.org, torvalds@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, linux-kernel@...r.kernel.org,
	jgarzik@...ox.com, mchan@...adcom.com
Subject: Re: [GIT *] Allow request_firmware() to be satisfied from
 in-kernel, use it in more drivers.

From: Andrew Morton <akpm@...ux-foundation.org>
Date: Mon, 14 Jul 2008 16:41:19 -0700

> On Mon, 14 Jul 2008 16:23:26 -0700
> David Woodhouse <dwmw2@...radead.org> wrote:
> 
> > Linus, please pull from the for-2.6.27 branch of:
> > 	git://git.infradead.org/users/dwmw2/firmware-2.6.git for-2.6.27
> 
> The firmware flamewars seem to have subsided lately.  Is everyone happy
> with this now?

I'm not happy for network drivers, although I'm happy to see that
David respected out NACKs on tg3/bnx2/etc. and didn't include those
bits.

I still haven't seen an answer to the chip reset issues.  The argument
has been that this stuff is going to save kernel memory when the
driver isn't loading firmware, but that's not really possible.

When a lot of these network drivers reset, due to a transmit timeout
or other exception, we need to load the firmware again.

So this means, that if request_firmware() dies or fails for some
reason in these scenerios, we can't reset the network card.  Something
as simple as a memory or other allocation failure deep inside of
request_firmware() means we lose the networking interface.

To me this seems like a very non-resilient setup.  It makes sense
to just keep the firmware in-core so we can load it without having
to even think about possible failures.

And that to me basically makes this transformation pointless.  It's
in fact a regression.

Furthermore, the issue of suspend and resume was brought up.  What if
request_firmware() fails then?  And can request_firmware() even be
allowed in that context?  What if the disk on which the firmware
resides hasn't been resumed yet?

In response to the suspend/resume queries, a lot of special voodoo was
mentioned that perhaps would allow request_firmware() to get invoked
in the correct context and with the firmware partition's block device
resumed already.

But who the heck is going to write all of that code and fix up all
of these drivers so that they can resume reliably again?

And for what?

None of the people who wrote and maintain these effected networking
drivers want these changes installed.  And they are the ones who will
have to diagnose strange request_firmware() failures that lead to
non-functioning devices during resume or after a transmit timeout.
--
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/