netdev - Re: [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF client

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: <fe44419b-924c-b183-b761-78771b7d506d@linux.intel.com>
Date:   Tue, 26 May 2020 08:15:26 -0500
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Jason Gunthorpe <jgg@...pe.ca>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        davem@...emloft.net, netdev@...r.kernel.org,
        linux-rdma@...r.kernel.org, nhorman@...hat.com,
        sassmann@...hat.com, Fred Oh <fred.oh@...ux.intel.com>,
        Takashi Iwai <tiwai@...e.de>
Subject: Re: [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF
 client



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.