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  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:   Tue, 26 May 2020 08:15:26 -0500
From:   Pierre-Louis Bossart <>
To:     Greg KH <>
Cc:     Jason Gunthorpe <>,
        Ranjani Sridharan <>,
        Jeff Kirsher <>,,,,,, Fred Oh <>,
        Takashi Iwai <>
Subject: Re: [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF

On 5/24/20 1:35 AM, Greg KH wrote:
> On Sat, May 23, 2020 at 02:41:51PM -0500, Pierre-Louis Bossart wrote:
>> On 5/23/20 1:23 AM, Greg KH wrote:
>>> On Fri, May 22, 2020 at 09:29:57AM -0500, Pierre-Louis Bossart wrote:
>>>> This is not an hypothetical case, we've had this recurring problem when a
>>>> PCI device creates an audio card represented as a platform device. When the
>>>> card registration fails, typically due to configuration issues, the PCI
>>>> probe still completes.
>>> Then fix that problem there.  The audio card should not be being created
>>> as a platform device, as that is not what it is.  And even if it was,
>>> the probe should not complete, it should clean up after itself and error
>>> out.
>> Did you mean 'the PCI probe should not complete and error out'?
> Yes.
>> If yes, that's yet another problem... During the PCI probe, we start a
>> workqueue and return success to avoid blocking everything.
> That's crazy.
>> And only 'later' do we actually create the card. So that's two levels
>> of probe that cannot report a failure. I didn't come up with this
>> design, IIRC this is due to audio-DRM dependencies and it's been used
>> for 10+ years.
> Then if the probe function fails, it needs to unwind everything itself
> and unregister the device with the PCI subsystem so that things work
> properly.  If it does not do that today, that's a bug.
> What kind of crazy dependencies cause this type of "requirement"?

I think it is related to the request_module("i915") in 
snd_hdac_i915_init(), and possibly other firmware download.

Adding Takashi for more details.

Powered by blists - more mailing lists