linux-kernel - Re: [PATCH v9 34/34] ASoC: usb: Rediscover USB SND devices on USB port add

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, 23 Oct 2023 14:54:50 -0700
From:   Wesley Cheng <quic_wcheng@...cinc.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        <mathias.nyman@...el.com>, <gregkh@...uxfoundation.org>,
        <lgirdwood@...il.com>, <broonie@...nel.org>, <perex@...ex.cz>,
        <tiwai@...e.com>, <agross@...nel.org>, <andersson@...nel.org>,
        <konrad.dybcio@...aro.org>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <srinivas.kandagatla@...aro.org>, <bgoswami@...cinc.com>,
        <Thinh.Nguyen@...opsys.com>
CC:     <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <alsa-devel@...a-project.org>, <linux-arm-msm@...r.kernel.org>,
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH v9 34/34] ASoC: usb: Rediscover USB SND devices on USB
 port add

Hi Pierre,

On 10/17/2023 4:11 PM, Pierre-Louis Bossart wrote:
> 
> 
> On 10/17/23 15:01, Wesley Cheng wrote:
>> In case the USB backend device has not been initialized/probed, USB SND
>> device connections can still occur.  When the USB backend is eventually
>> made available, previous USB SND device connections are not communicated to
>> the USB backend.  Call snd_usb_rediscover_devices() to generate the connect
>> callbacks for all USB SND devices connected.  This will allow for the USB
>> backend to be updated with the current set of devices available.
>>
>> The chip array entries are all populated and removed while under the
>> register_mutex, so going over potential race conditions:
>>
>> Thread#1:
>>    q6usb_component_probe()
>>      --> snd_soc_usb_add_port()
>>        --> snd_usb_rediscover_devices()
>>          --> mutex_lock(register_mutex)
>>
>> Thread#2
>>    --> usb_audio_disconnect()
>>      --> mutex_lock(register_mutex)
>>
>> So either thread#1 or thread#2 will complete first.  If
>>
>> Thread#1 completes before thread#2:
>>    SOC USB will notify DPCM backend of the device connection.  Shortly
>>    after, once thread#2 runs, we will get a disconnect event for the
>>    connected device.
>>
>> Thread#2 completes before thread#1:
>>    Then during snd_usb_rediscover_devices() it won't notify of any
>>    connection for that particular chip index.
> Looks like you are assuming the regular USB audio stuff is probed first?
> 
> What if it's not the case? Have you tested with a manual 'blacklist' and
> "modprobe" sequence long after all the DSP stuff is initialized?
> 
> It really reminds me of audio+display issues, and the same opens apply IMHO.

Not necessarily...if the USB audio driver is not probed, then that is 
the same scenario as when there is no USB audio capable device plugged 
in, while the offload path is waiting for the connect event. I think 
this is the standard scenario.

In the situation where the platform sound card hasn't probed yet and USB 
audio devices are being identified, then that is basically the scenario 
that would be more of an issue, since its USB SND that notifies of the 
connection state (at the time of connect/disconnect).

I've tried with building these drivers as modules and probing them at 
different times/sequences, and I haven't seen an issue so far.

Thanks
Wesley Cheng