linux-kernel - Re: [RFC PATCH v2 20/22] sound: usb: Prevent starting of audio stream if in use

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: <b26c9e4c-5a9c-a2ff-19a7-78419c6b81df@quicinc.com>
Date:   Mon, 6 Feb 2023 17:15:49 -0800
From:   Wesley Cheng <quic_wcheng@...cinc.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        <srinivas.kandagatla@...aro.org>, <mathias.nyman@...el.com>,
        <perex@...ex.cz>, <lgirdwood@...il.com>, <andersson@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <gregkh@...uxfoundation.org>,
        <Thinh.Nguyen@...opsys.com>, <broonie@...nel.org>,
        <bgoswami@...cinc.com>, <tiwai@...e.com>, <robh+dt@...nel.org>,
        <agross@...nel.org>
CC:     <devicetree@...r.kernel.org>, <alsa-devel@...a-project.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-usb@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <quic_jackp@...cinc.com>,
        <quic_plai@...cinc.com>
Subject: Re: [RFC PATCH v2 20/22] sound: usb: Prevent starting of audio stream
 if in use

Hi Pierre,

On 1/26/2023 8:12 AM, Pierre-Louis Bossart wrote:
> 
> 
> On 1/25/23 21:14, Wesley Cheng wrote:
>> With USB audio offloading, an audio session is started from the ASoC
>> platform sound card and PCM devices.  Likewise, the USB SND path is still
>> readily available for use, in case the non-offload path is desired.  In
>> order to prevent the two entities from attempting to use the USB bus,
>> introduce a flag that determines when either paths are in use.
>>
>> If a PCM device is already in use, the check will return an error to
>> userspace notifying that the stream is currently busy.  This ensures that
>> only one path is using the USB substream.
> 
> It's good to maintain mutual exclusion, but it's still very hard for an
> application to figure out which card can be used when.
> 
> Returning -EBUSY is not super helpful. There should be something like a
> notification or connection status so that routing decisions can be made
> without trial-and-error.
> 

The USB offload driver does have access to the USB substream that is 
being utilized/offloaded.  Maybe in addition to this check, we can also 
set the PCM runtime state as well (for that particular substream)?  That 
way userspace can fetch information about if the stream is busy or not.

Thanks
Wesley Cheng