linux-kernel - Re: bluetooth related firmware loader spew on resume.

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:	Wed, 26 Nov 2014 23:08:22 +0900
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	Oliver Neukum <oneukum@...e.de>, Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	pgynther@...gle.com, linux-bluetooth@...r.kernel.org
Subject: Re: bluetooth related firmware loader spew on resume.

Hi Takashi,

>>>> On Wed, 2014-11-26 at 09:52 +0100, Takashi Iwai wrote:
>>>>> At Wed, 26 Nov 2014 14:15:27 +0900,
>>>> 
>>>>> In order to paper over this, we may also remember the failing firmware
>>>>> and avoid loading it.  This might be an easer way than the endless
>>>>> fight against UMH race...
>>>> 
>>>> Hi,
>>>> 
>>>> the full fix would be to implement reset_resume() for btusb.
>>>> It seems to me that setup() should be split in two methods,
>>>> one to request the firmware from user space and the second
>>>> to transfer it to the device. reset_resume() would just need
>>>> to repeat the second operation.
>>> 
>>> I'm not against it, but one slight drawback is that you'll have to
>>> remember the firmware content to transfer by the driver itself in this
>>> scenario.   In the firmware loader framework, the content is re-read
>>> at resume so that the largish content isn't kept unnecessarily during
>>> the whole operation. 
>> 
>> That isn't a drawback but an advantage. Firmware for devices that
>> do power management needs to be in RAM. The right time to free it
>> is in disconnect(). But why does that mean that the driver has to
>> manage the firmware? Can't the firmware layer do it?
> 
> The f/w loader remembers the f/w names of the successful loads, and
> retries to load them automatically at the suspend time.  But it
> doesn't remember/cache the failed loads.  So, when the driver retires
> request_firmware() for a non-existing file in the resume path, it
> actually reaches to the f/w loading part again unexpectedly.

I think this should be indeed fixed. The firmware loader needs to remember the information. Since sometimes the firmware is optional. No point in re-loading it. And realistically, if the firmware was not present before suspend, it will not magically appear during resume.

Regards

Marcel

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