linux-kernel - Re: [RFC] firmware loader: retry _nowait requests when userhelper is not yet available

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: <201203040250.02790.chunkeey@googlemail.com>
Date:	Sun, 4 Mar 2012 02:50:02 +0100
From:	Christian Lamparter <chunkeey@...glemail.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org
Subject: Re: [RFC] firmware loader: retry _nowait requests when userhelper is not yet available

On Sunday 04 March 2012 00:57:04 Alan Cox wrote:
> On Sat, 3 Mar 2012 21:22:36 +0100
> Christian Lamparter <chunkeey@...glemail.com> wrote:
> 
> > During resume, the userhelper might not be available. However for
> > drivers which use the request_firmware_nowait interface, this will
> > only lead to a pointless WARNING and a device which no longer works
> > after the resume [since it couldn't get the firmware, because the
> > userhelper was not available to take the request].
> 
> Can you not load the firmware on the suspend path ?
>
If I could, I would fetch the firmware "open" as it is supposed to be.
But, but the driver's "remove" op is called during resume by the "bus".
So, everything will vanish with it.

But see for yourself: In my case I have to deal with a pci-chip [isl3886,
p54pci driver] that comes on board of a cardbus card. The code that
does the "unbind/rebind" is in drivers/pcmcia/cs.c, function: socket_late_resume

>	if (skt->state & SOCKET_CARDBUS) {
>		/* We can't be sure the CardBus card is the same
>		 * as the one previously inserted. Therefore, remove
>		 * and re-add... */
>		cb_free(skt);
>		cb_alloc(skt);
>		return 0;
>	}
Of course cb_free(...) is just a elaborate way of saying:
	pci_remove_behind_bridge(pcmcia_socket);
[And cb_alloc obviously just re-"probe"s the device in the
cardbus socket again...]

Of course, in my case, I could tuck the firmware away in a some
static const struct firmware* somewhere within the driver code.
But then someone [like you :-D] will yell at me for hiding it in a
file-global stash of ugliness.

Regards,
	Christian
--
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/