Message ID | 20240203023645.31105-36-quic_wcheng@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-50871-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:9bc1:b0:106:209c:c626 with SMTP id op1csp820671dyc; Fri, 2 Feb 2024 18:56:08 -0800 (PST) X-Google-Smtp-Source: AGHT+IERZuWzm4bPntfvzLol+lULpUxo+2mfeFoLkJ/jMIAJD7pTbjFho31DUKGqn7v7Q0tRjgXZ X-Received: by 2002:a19:f510:0:b0:511:2da1:583 with SMTP id j16-20020a19f510000000b005112da10583mr2176234lfb.37.1706928968781; Fri, 02 Feb 2024 18:56:08 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706928968; cv=pass; d=google.com; s=arc-20160816; b=wr/4vtcshvxQgcAuapfXVVTERFihvxHaQk5sBNNdlnJbazhr3AdeNfN6dwQS/en2Bc rL0mFoOjPOW7RSBDc20N3z3C0mYnhu5/ndLC3+vymA60OOEnM4JIWt55WCz8PG8MeGyK LA8ON5/AySyKqS6AaJYQ5SqGc0sWtqV/gjGBCFXn8hoy7yuwKM8bAxa3O5kGnP9Pb8ks p+ssiEJzxAXN8Z593JjbHQ4C6V7TPy+Pi3LiKTu8F8vkyDngghX9PtCox+zVhqnlgBZ+ pJQsKZlRyhPlrQ5H4RxYGZVocVvLkcgBLgy5sjMe14QnCcogk286ySGe2bXXg6xUazB6 rKoQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Mac5fYtyQT3/dFjHQIR20e2Ic8f2mGSavzPia8fsM5c=; fh=XkLNylMJ6yISw5CIXlCBaWGyLLflpsRjcVrav7t6SoQ=; b=wVNd4+W3ZBcV+XuHTpbsqW8qXU9jh1CxQ52SrWqBFmFGmStWyiOGkN7uWq1Uqz7ACO Zr0VwIEg3Uv7Q//fZnWFk/GJ0j3CYOeUn4BNSiM4Pm/fA1/5mTsGo0qvr1Uek62RIkEK lzQX+zfk0bQ2KbdaMQJUFDUSioCZvutFrE0z3aFOVAsAN4kMVBqAKWYXquwB/ga+zssV uJKjJTgONf1nMFZcPghTgK1+RrYzt3tiWJ/GAgjr9bFoFSrLK6ZKLi6g+vOcpVTm2qS6 vS2Pg4caCtd9kjxR47oq8EkgDXP2aSgiVSVCuo/vCSSqFwvLN+Lpwzs6fX0V/1paYVCb 5FmA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=KUR+MLTj; arc=pass (i=1 spf=pass spfdomain=quicinc.com dkim=pass dkdomain=quicinc.com dmarc=pass fromdomain=quicinc.com); spf=pass (google.com: domain of linux-kernel+bounces-50871-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-50871-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com X-Forwarded-Encrypted: i=1; AJvYcCUSKlrrxeKW5w6SPag+V93p8kK5utG9hkaP4TYnqC+3ZsK6ymanRyHwz2NjwsDabZy9Sc0aHk781fxeGTPNGI5nDeuC9w== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id a15-20020a1709066d4f00b00a3673c19b2esi1368660ejt.626.2024.02.02.18.56.08 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Feb 2024 18:56:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-50871-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=KUR+MLTj; arc=pass (i=1 spf=pass spfdomain=quicinc.com dkim=pass dkdomain=quicinc.com dmarc=pass fromdomain=quicinc.com); spf=pass (google.com: domain of linux-kernel+bounces-50871-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-50871-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 276AF1F27537 for <ouuuleilei@gmail.com>; Sat, 3 Feb 2024 02:56:08 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 502B35A106; Sat, 3 Feb 2024 02:38:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="KUR+MLTj" Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 01AFF48CDC; Sat, 3 Feb 2024 02:38:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706927887; cv=none; b=RQJHOXGUuwYCoJiI2kMLcLLRTJAR9npSeKp0+YTGLRsHbTt0ZEyPiUyouyx3xQkhChV3lKvPhKMBeia8T+J3KLY+Op8Opnn37g+OY5iMxRvVmlcX6dpHtC7urts1wE1RTABuFKgZ/5poJBGHhQSC/KzyerFMta38Co/Xvbi5mPI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706927887; c=relaxed/simple; bh=IS2mFSaOYw8NgJjI1LojZ65aEsKXdGK1aJu+0hEKs2Y=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Q7kRAbT8aR7AR2d+fyQdFWjwh8AKSHGNzVUyCveuRxhYvPmbXsXM+CSzQ5fk0s4MzUo0zbt1/EXpkIPXmWxgEtfKeuSK7H6gqfZt5XfuoaXjT7n5neG/j24WwEA21D4+cvVzI9jIQW0L7wmeVsaPjfH7euW62QYNq1MGuW+I0I4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=quicinc.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=KUR+MLTj; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=quicinc.com Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 4132ZjvE016519; Sat, 3 Feb 2024 02:37:48 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type; s=qcppdkim1; bh=Mac5fYtyQT3/dFjHQIR2 0e2Ic8f2mGSavzPia8fsM5c=; b=KUR+MLTjDvkWGWcn2LoIjixlumApNdQy38rg D20t3ShNqnvTuQQyAlrMIEtE8N4ZTehlMI9udFkB0ytY8n09ViUvZGedtLusuVXY 4ahPB0cv1jC3j47x36Yongtt+qJTbY6vwD0ToRRlTy52jqxGNfIDuq/1asaeWoww rAsXNl9RC9i2PUX6dJGEHuIIfdXpjTesfMjSSIoCIA/Zai0le1quaAgnwaB1H7M1 Sf6YP733jqCIamj2s77IRjrYXGP5cPpo/F/bBvMJUoYfVvGdsp6Fzv4EYJK1yeya UdqGwNslAmO8ddi/+MFODGx4ehw0/PL9tQ+/lAS7KSLLbxaSog== Received: from nalasppmta03.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3w1ctq003f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 03 Feb 2024 02:37:47 +0000 (GMT) Received: from nalasex01b.na.qualcomm.com (nalasex01b.na.qualcomm.com [10.47.209.197]) by NALASPPMTA03.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 4132bSY3012280 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 3 Feb 2024 02:37:28 GMT Received: from hu-wcheng-lv.qualcomm.com (10.49.16.6) by nalasex01b.na.qualcomm.com (10.47.209.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Fri, 2 Feb 2024 18:37:27 -0800 From: Wesley Cheng <quic_wcheng@quicinc.com> To: <srinivas.kandagatla@linaro.org>, <mathias.nyman@intel.com>, <perex@perex.cz>, <conor+dt@kernel.org>, <corbet@lwn.net>, <lgirdwood@gmail.com>, <andersson@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <gregkh@linuxfoundation.org>, <Thinh.Nguyen@synopsys.com>, <broonie@kernel.org>, <bgoswami@quicinc.com>, <tiwai@suse.com>, <robh+dt@kernel.org>, <konrad.dybcio@linaro.org> CC: <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-sound@vger.kernel.org>, <linux-usb@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>, <linux-doc@vger.kernel.org>, <alsa-devel@alsa-project.org>, Wesley Cheng <quic_wcheng@quicinc.com> Subject: [PATCH v13 35/53] ALSA: usb-audio: Prevent starting of audio stream if in use Date: Fri, 2 Feb 2024 18:36:27 -0800 Message-ID: <20240203023645.31105-36-quic_wcheng@quicinc.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20240203023645.31105-1-quic_wcheng@quicinc.com> References: <20240203023645.31105-1-quic_wcheng@quicinc.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: nalasex01b.na.qualcomm.com (10.47.209.197) To nalasex01b.na.qualcomm.com (10.47.209.197) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: iqg0zktgSxo5nqQJ3tV3Gn-j4SzJh51A X-Proofpoint-GUID: iqg0zktgSxo5nqQJ3tV3Gn-j4SzJh51A X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-02_16,2024-01-31_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 priorityscore=1501 lowpriorityscore=0 mlxscore=0 adultscore=0 clxscore=1015 bulkscore=0 suspectscore=0 spamscore=0 phishscore=0 mlxlogscore=999 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2401310000 definitions=main-2402030015 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789844750681201232 X-GMAIL-MSGID: 1789844750681201232 |
Series |
Introduce QC USB SND audio offloading support
|
|
Commit Message
Wesley Cheng
Feb. 3, 2024, 2:36 a.m. UTC
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.
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
---
sound/usb/card.h | 1 +
sound/usb/pcm.c | 19 +++++++++++++++++--
2 files changed, 18 insertions(+), 2 deletions(-)
Comments
On Sat, 03 Feb 2024 03:36:27 +0100, 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. > > Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Hm, I'm not sure whether it's safe to hold chip->mutex there for the long code path. It even kicks off the auto-resume, which may call various functions at resuming, and some of them may re-hold chip->mutex. If it's only about the open flag, protect only the flag access with the mutex, not covering the all open function. At least the re-entry can be avoided by that. thanks, Takashi > --- > sound/usb/card.h | 1 + > sound/usb/pcm.c | 19 +++++++++++++++++-- > 2 files changed, 18 insertions(+), 2 deletions(-) > > diff --git a/sound/usb/card.h b/sound/usb/card.h > index ed4a664e24e5..6d59995440c3 100644 > --- a/sound/usb/card.h > +++ b/sound/usb/card.h > @@ -165,6 +165,7 @@ struct snd_usb_substream { > unsigned int pkt_offset_adj; /* Bytes to drop from beginning of packets (for non-compliant devices) */ > unsigned int stream_offset_adj; /* Bytes to drop from beginning of stream (for non-compliant devices) */ > > + unsigned int opened:1; /* pcm device opened */ > unsigned int running: 1; /* running status */ > unsigned int period_elapsed_pending; /* delay period handling */ > > diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c > index 3adb09ce1702..c2cb52cd5d23 100644 > --- a/sound/usb/pcm.c > +++ b/sound/usb/pcm.c > @@ -1241,8 +1241,15 @@ static int snd_usb_pcm_open(struct snd_pcm_substream *substream) > struct snd_usb_stream *as = snd_pcm_substream_chip(substream); > struct snd_pcm_runtime *runtime = substream->runtime; > struct snd_usb_substream *subs = &as->substream[direction]; > + struct snd_usb_audio *chip = subs->stream->chip; > int ret; > > + mutex_lock(&chip->mutex); > + if (subs->opened) { > + mutex_unlock(&chip->mutex); > + return -EBUSY; > + } > + > runtime->hw = snd_usb_hardware; > /* need an explicit sync to catch applptr update in low-latency mode */ > if (direction == SNDRV_PCM_STREAM_PLAYBACK && > @@ -1259,13 +1266,17 @@ static int snd_usb_pcm_open(struct snd_pcm_substream *substream) > > ret = setup_hw_info(runtime, subs); > if (ret < 0) > - return ret; > + goto out; > ret = snd_usb_autoresume(subs->stream->chip); > if (ret < 0) > - return ret; > + goto out; > ret = snd_media_stream_init(subs, as->pcm, direction); > if (ret < 0) > snd_usb_autosuspend(subs->stream->chip); > + subs->opened = 1; > +out: > + mutex_unlock(&chip->mutex); > + > return ret; > } > > @@ -1274,6 +1285,7 @@ static int snd_usb_pcm_close(struct snd_pcm_substream *substream) > int direction = substream->stream; > struct snd_usb_stream *as = snd_pcm_substream_chip(substream); > struct snd_usb_substream *subs = &as->substream[direction]; > + struct snd_usb_audio *chip = subs->stream->chip; > int ret; > > snd_media_stop_pipeline(subs); > @@ -1287,6 +1299,9 @@ static int snd_usb_pcm_close(struct snd_pcm_substream *substream) > > subs->pcm_substream = NULL; > snd_usb_autosuspend(subs->stream->chip); > + mutex_lock(&chip->mutex); > + subs->opened = 0; > + mutex_unlock(&chip->mutex); > > return 0; > }
Hi Takashi, On 2/6/2024 5:07 AM, Takashi Iwai wrote: > On Sat, 03 Feb 2024 03:36:27 +0100, > 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. >> >> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > > Hm, I'm not sure whether it's safe to hold chip->mutex there for the > long code path. It even kicks off the auto-resume, which may call > various functions at resuming, and some of them may re-hold > chip->mutex. > That's a good point. > If it's only about the open flag, protect only the flag access with > the mutex, not covering the all open function. At least the re-entry > can be avoided by that. > Sure, let me re-order the check/assignment and the mutex locking. Since this is now checked here in USB PCM and the QC offload driver, we want to make sure that if there was some application attempting to open both at the same time, we prevent any possible races. I think the best way to address this would be something like: static int snd_usb_pcm_open(struct snd_pcm_substream *substream) { .. mutex_lock(&chip->mutex); if (subs->opened) { mutex_unlock(&chip->mutex); return -EBUSY; } subs->opened = 1; mutex_unlock(&chip->mutex); //Execute bulk of PCM open routine .. return 0; // If any errors are seen, unwind err_resume: snd_usb_autosuspend(subs->stream->chip); err_open: mutex_lock(&chip->mutex); subs->opened = 0; mutex_unlock(&chip->mutex); return ret; } Set the opened flag first, so that if QC offload checks it, it can exit early and vice versa. Otherwise, if we set the opened flag at the same position as the previous patch, we may be calling the other routines in parallel to the QC offload enable stream routine. The only thing with this patch is that we'd need some error handling unwinding. Thanks Wesley Cheng
On Wed, 07 Feb 2024 01:08:00 +0100, Wesley Cheng wrote: > > Hi Takashi, > > On 2/6/2024 5:07 AM, Takashi Iwai wrote: > > On Sat, 03 Feb 2024 03:36:27 +0100, > > 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. > >> > >> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > > > > Hm, I'm not sure whether it's safe to hold chip->mutex there for the > > long code path. It even kicks off the auto-resume, which may call > > various functions at resuming, and some of them may re-hold > > chip->mutex. > > > > That's a good point. > > > If it's only about the open flag, protect only the flag access with > > the mutex, not covering the all open function. At least the re-entry > > can be avoided by that. > > > > Sure, let me re-order the check/assignment and the mutex locking. > Since this is now checked here in USB PCM and the QC offload driver, > we want to make sure that if there was some application attempting to > open both at the same time, we prevent any possible races. > > I think the best way to address this would be something like: > > static int snd_usb_pcm_open(struct snd_pcm_substream *substream) > { > ... > mutex_lock(&chip->mutex); > if (subs->opened) { > mutex_unlock(&chip->mutex); > return -EBUSY; > } > subs->opened = 1; > mutex_unlock(&chip->mutex); > > //Execute bulk of PCM open routine > ... > return 0; > > // If any errors are seen, unwind > err_resume: > snd_usb_autosuspend(subs->stream->chip); > err_open: > mutex_lock(&chip->mutex); > subs->opened = 0; > mutex_unlock(&chip->mutex); > > return ret; > } > > Set the opened flag first, so that if QC offload checks it, it can > exit early and vice versa. Otherwise, if we set the opened flag at > the same position as the previous patch, we may be calling the other > routines in parallel to the QC offload enable stream routine. The > only thing with this patch is that we'd need some error handling > unwinding. The above is what I had in mind. But, thinking on this again, you might be able to get the same result by using the ALSA PCM core substream open_mutex and hw_opened flag. This is already held and set at snd_pcm_core() (the hw_opened flag is set after open callback, though). The offload driver can use those instead of the own lock and flag, too, although it's not really well-mannered behavior (hence you need proper comments). thanks, Takashi
Hi Takashi, On 2/6/2024 11:05 PM, Takashi Iwai wrote: > On Wed, 07 Feb 2024 01:08:00 +0100, > Wesley Cheng wrote: >> >> Hi Takashi, >> >> On 2/6/2024 5:07 AM, Takashi Iwai wrote: >>> On Sat, 03 Feb 2024 03:36:27 +0100, >>> 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. >>>> >>>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> >>> >>> Hm, I'm not sure whether it's safe to hold chip->mutex there for the >>> long code path. It even kicks off the auto-resume, which may call >>> various functions at resuming, and some of them may re-hold >>> chip->mutex. >>> >> >> That's a good point. >> >>> If it's only about the open flag, protect only the flag access with >>> the mutex, not covering the all open function. At least the re-entry >>> can be avoided by that. >>> >> >> Sure, let me re-order the check/assignment and the mutex locking. >> Since this is now checked here in USB PCM and the QC offload driver, >> we want to make sure that if there was some application attempting to >> open both at the same time, we prevent any possible races. >> >> I think the best way to address this would be something like: >> >> static int snd_usb_pcm_open(struct snd_pcm_substream *substream) >> { >> ... >> mutex_lock(&chip->mutex); >> if (subs->opened) { >> mutex_unlock(&chip->mutex); >> return -EBUSY; >> } >> subs->opened = 1; >> mutex_unlock(&chip->mutex); >> >> //Execute bulk of PCM open routine >> ... >> return 0; >> >> // If any errors are seen, unwind >> err_resume: >> snd_usb_autosuspend(subs->stream->chip); >> err_open: >> mutex_lock(&chip->mutex); >> subs->opened = 0; >> mutex_unlock(&chip->mutex); >> >> return ret; >> } >> >> Set the opened flag first, so that if QC offload checks it, it can >> exit early and vice versa. Otherwise, if we set the opened flag at >> the same position as the previous patch, we may be calling the other >> routines in parallel to the QC offload enable stream routine. The >> only thing with this patch is that we'd need some error handling >> unwinding. > > The above is what I had in mind. > > But, thinking on this again, you might be able to get the same result > by using the ALSA PCM core substream open_mutex and hw_opened flag. > This is already held and set at snd_pcm_core() (the hw_opened flag is > set after open callback, though). The offload driver can use those > instead of the own lock and flag, too, although it's not really > well-mannered behavior (hence you need proper comments). > I think I had looked into this as well previously, and it was difficult to achieve, because from the USB offloading perspective, we don't ever call: snd_usb_pcm_open() This is actually where we populate the pcm_substream parameter within struct snd_usb_substream based on when userspace opens the USB SND PCM device (which is not the case for offloading). So the offload driver doesn't have a way to fetch the struct snd_pcm that is allocated to the PCM device created by the USB SND card. Thanks Wesley Cheng
Hi Takashi, On 2/7/2024 4:02 PM, Wesley Cheng wrote: > Hi Takashi, > > On 2/6/2024 11:05 PM, Takashi Iwai wrote: >> On Wed, 07 Feb 2024 01:08:00 +0100, >> Wesley Cheng wrote: >>> >>> Hi Takashi, >>> >>> On 2/6/2024 5:07 AM, Takashi Iwai wrote: >>>> On Sat, 03 Feb 2024 03:36:27 +0100, >>>> 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. >>>>> >>>>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> >>>> >>>> Hm, I'm not sure whether it's safe to hold chip->mutex there for the >>>> long code path. It even kicks off the auto-resume, which may call >>>> various functions at resuming, and some of them may re-hold >>>> chip->mutex. >>>> >>> >>> That's a good point. >>> >>>> If it's only about the open flag, protect only the flag access with >>>> the mutex, not covering the all open function. At least the re-entry >>>> can be avoided by that. >>>> >>> >>> Sure, let me re-order the check/assignment and the mutex locking. >>> Since this is now checked here in USB PCM and the QC offload driver, >>> we want to make sure that if there was some application attempting to >>> open both at the same time, we prevent any possible races. >>> >>> I think the best way to address this would be something like: >>> >>> static int snd_usb_pcm_open(struct snd_pcm_substream *substream) >>> { >>> ... >>> mutex_lock(&chip->mutex); >>> if (subs->opened) { >>> mutex_unlock(&chip->mutex); >>> return -EBUSY; >>> } >>> subs->opened = 1; >>> mutex_unlock(&chip->mutex); >>> >>> //Execute bulk of PCM open routine >>> ... >>> return 0; >>> >>> // If any errors are seen, unwind >>> err_resume: >>> snd_usb_autosuspend(subs->stream->chip); >>> err_open: >>> mutex_lock(&chip->mutex); >>> subs->opened = 0; >>> mutex_unlock(&chip->mutex); >>> >>> return ret; >>> } >>> >>> Set the opened flag first, so that if QC offload checks it, it can >>> exit early and vice versa. Otherwise, if we set the opened flag at >>> the same position as the previous patch, we may be calling the other >>> routines in parallel to the QC offload enable stream routine. The >>> only thing with this patch is that we'd need some error handling >>> unwinding. >> >> The above is what I had in mind. >> >> But, thinking on this again, you might be able to get the same result >> by using the ALSA PCM core substream open_mutex and hw_opened flag. >> This is already held and set at snd_pcm_core() (the hw_opened flag is >> set after open callback, though). The offload driver can use those >> instead of the own lock and flag, too, although it's not really >> well-mannered behavior (hence you need proper comments). >> > > I think I had looked into this as well previously, and it was difficult > to achieve, because from the USB offloading perspective, we don't ever > call: snd_usb_pcm_open() > > This is actually where we populate the pcm_substream parameter within > struct snd_usb_substream based on when userspace opens the USB SND PCM > device (which is not the case for offloading). So the offload driver > doesn't have a way to fetch the struct snd_pcm that is allocated to the > PCM device created by the USB SND card. > Sorry, took a look at it again, and found a way. Although not pretty, we can access it using: subs->stream->pcm->streams[direction].substream->hw_opened Thanks Wesley Cheng
On Thu, 08 Feb 2024 02:12:00 +0100, Wesley Cheng wrote: > > Hi Takashi, > > On 2/7/2024 4:02 PM, Wesley Cheng wrote: > > Hi Takashi, > > > > On 2/6/2024 11:05 PM, Takashi Iwai wrote: > >> On Wed, 07 Feb 2024 01:08:00 +0100, > >> Wesley Cheng wrote: > >>> > >>> Hi Takashi, > >>> > >>> On 2/6/2024 5:07 AM, Takashi Iwai wrote: > >>>> On Sat, 03 Feb 2024 03:36:27 +0100, > >>>> 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. > >>>>> > >>>>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > >>>> > >>>> Hm, I'm not sure whether it's safe to hold chip->mutex there for the > >>>> long code path. It even kicks off the auto-resume, which may call > >>>> various functions at resuming, and some of them may re-hold > >>>> chip->mutex. > >>>> > >>> > >>> That's a good point. > >>> > >>>> If it's only about the open flag, protect only the flag access with > >>>> the mutex, not covering the all open function. At least the re-entry > >>>> can be avoided by that. > >>>> > >>> > >>> Sure, let me re-order the check/assignment and the mutex locking. > >>> Since this is now checked here in USB PCM and the QC offload driver, > >>> we want to make sure that if there was some application attempting to > >>> open both at the same time, we prevent any possible races. > >>> > >>> I think the best way to address this would be something like: > >>> > >>> static int snd_usb_pcm_open(struct snd_pcm_substream *substream) > >>> { > >>> ... > >>> mutex_lock(&chip->mutex); > >>> if (subs->opened) { > >>> mutex_unlock(&chip->mutex); > >>> return -EBUSY; > >>> } > >>> subs->opened = 1; > >>> mutex_unlock(&chip->mutex); > >>> > >>> //Execute bulk of PCM open routine > >>> ... > >>> return 0; > >>> > >>> // If any errors are seen, unwind > >>> err_resume: > >>> snd_usb_autosuspend(subs->stream->chip); > >>> err_open: > >>> mutex_lock(&chip->mutex); > >>> subs->opened = 0; > >>> mutex_unlock(&chip->mutex); > >>> > >>> return ret; > >>> } > >>> > >>> Set the opened flag first, so that if QC offload checks it, it can > >>> exit early and vice versa. Otherwise, if we set the opened flag at > >>> the same position as the previous patch, we may be calling the other > >>> routines in parallel to the QC offload enable stream routine. The > >>> only thing with this patch is that we'd need some error handling > >>> unwinding. > >> > >> The above is what I had in mind. > >> > >> But, thinking on this again, you might be able to get the same result > >> by using the ALSA PCM core substream open_mutex and hw_opened flag. > >> This is already held and set at snd_pcm_core() (the hw_opened flag is > >> set after open callback, though). The offload driver can use those > >> instead of the own lock and flag, too, although it's not really > >> well-mannered behavior (hence you need proper comments). > >> > > > > I think I had looked into this as well previously, and it was > > difficult to achieve, because from the USB offloading perspective, > > we don't ever call: snd_usb_pcm_open() > > > > This is actually where we populate the pcm_substream parameter > > within struct snd_usb_substream based on when userspace opens the > > USB SND PCM device (which is not the case for offloading). So the > > offload driver doesn't have a way to fetch the struct snd_pcm that > > is allocated to the PCM device created by the USB SND card. > > > > Sorry, took a look at it again, and found a way. Although not pretty, > we can access it using: > subs->stream->pcm->streams[direction].substream->hw_opened Yes, it's not easy to follow it. So if we want to this path, worth for a detailed comment. That said, I don't mind to introduce the new local mutex and flag as you did if the above became too messy in the end. thanks, Takashi
Hi Takashi, On 2/8/2024 12:33 AM, Takashi Iwai wrote: > On Thu, 08 Feb 2024 02:12:00 +0100, > Wesley Cheng wrote: >> >> Hi Takashi, >> >> On 2/7/2024 4:02 PM, Wesley Cheng wrote: >>> Hi Takashi, >>> >>> On 2/6/2024 11:05 PM, Takashi Iwai wrote: >>>> On Wed, 07 Feb 2024 01:08:00 +0100, >>>> Wesley Cheng wrote: >>>>> >>>>> Hi Takashi, >>>>> >>>>> On 2/6/2024 5:07 AM, Takashi Iwai wrote: >>>>>> On Sat, 03 Feb 2024 03:36:27 +0100, >>>>>> 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. >>>>>>> >>>>>>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> >>>>>> >>>>>> Hm, I'm not sure whether it's safe to hold chip->mutex there for the >>>>>> long code path. It even kicks off the auto-resume, which may call >>>>>> various functions at resuming, and some of them may re-hold >>>>>> chip->mutex. >>>>>> >>>>> >>>>> That's a good point. >>>>> >>>>>> If it's only about the open flag, protect only the flag access with >>>>>> the mutex, not covering the all open function. At least the re-entry >>>>>> can be avoided by that. >>>>>> >>>>> >>>>> Sure, let me re-order the check/assignment and the mutex locking. >>>>> Since this is now checked here in USB PCM and the QC offload driver, >>>>> we want to make sure that if there was some application attempting to >>>>> open both at the same time, we prevent any possible races. >>>>> >>>>> I think the best way to address this would be something like: >>>>> >>>>> static int snd_usb_pcm_open(struct snd_pcm_substream *substream) >>>>> { >>>>> ... >>>>> mutex_lock(&chip->mutex); >>>>> if (subs->opened) { >>>>> mutex_unlock(&chip->mutex); >>>>> return -EBUSY; >>>>> } >>>>> subs->opened = 1; >>>>> mutex_unlock(&chip->mutex); >>>>> >>>>> //Execute bulk of PCM open routine >>>>> ... >>>>> return 0; >>>>> >>>>> // If any errors are seen, unwind >>>>> err_resume: >>>>> snd_usb_autosuspend(subs->stream->chip); >>>>> err_open: >>>>> mutex_lock(&chip->mutex); >>>>> subs->opened = 0; >>>>> mutex_unlock(&chip->mutex); >>>>> >>>>> return ret; >>>>> } >>>>> >>>>> Set the opened flag first, so that if QC offload checks it, it can >>>>> exit early and vice versa. Otherwise, if we set the opened flag at >>>>> the same position as the previous patch, we may be calling the other >>>>> routines in parallel to the QC offload enable stream routine. The >>>>> only thing with this patch is that we'd need some error handling >>>>> unwinding. >>>> >>>> The above is what I had in mind. >>>> >>>> But, thinking on this again, you might be able to get the same result >>>> by using the ALSA PCM core substream open_mutex and hw_opened flag. >>>> This is already held and set at snd_pcm_core() (the hw_opened flag is >>>> set after open callback, though). The offload driver can use those >>>> instead of the own lock and flag, too, although it's not really >>>> well-mannered behavior (hence you need proper comments). >>>> >>> >>> I think I had looked into this as well previously, and it was >>> difficult to achieve, because from the USB offloading perspective, >>> we don't ever call: snd_usb_pcm_open() >>> >>> This is actually where we populate the pcm_substream parameter >>> within struct snd_usb_substream based on when userspace opens the >>> USB SND PCM device (which is not the case for offloading). So the >>> offload driver doesn't have a way to fetch the struct snd_pcm that >>> is allocated to the PCM device created by the USB SND card. >>> >> >> Sorry, took a look at it again, and found a way. Although not pretty, >> we can access it using: >> subs->stream->pcm->streams[direction].substream->hw_opened > > Yes, it's not easy to follow it. So if we want to this path, worth > for a detailed comment. That said, I don't mind to introduce the new > local mutex and flag as you did if the above became too messy in the > end. > If you don't mind, I prefer to keep it the way it was with the local mutex and flag. It makes it a lot easier to follow, and for other users to adopt as well compared to the long equation above :). Thanks Wesley Cheng
diff --git a/sound/usb/card.h b/sound/usb/card.h index ed4a664e24e5..6d59995440c3 100644 --- a/sound/usb/card.h +++ b/sound/usb/card.h @@ -165,6 +165,7 @@ struct snd_usb_substream { unsigned int pkt_offset_adj; /* Bytes to drop from beginning of packets (for non-compliant devices) */ unsigned int stream_offset_adj; /* Bytes to drop from beginning of stream (for non-compliant devices) */ + unsigned int opened:1; /* pcm device opened */ unsigned int running: 1; /* running status */ unsigned int period_elapsed_pending; /* delay period handling */ diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 3adb09ce1702..c2cb52cd5d23 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -1241,8 +1241,15 @@ static int snd_usb_pcm_open(struct snd_pcm_substream *substream) struct snd_usb_stream *as = snd_pcm_substream_chip(substream); struct snd_pcm_runtime *runtime = substream->runtime; struct snd_usb_substream *subs = &as->substream[direction]; + struct snd_usb_audio *chip = subs->stream->chip; int ret; + mutex_lock(&chip->mutex); + if (subs->opened) { + mutex_unlock(&chip->mutex); + return -EBUSY; + } + runtime->hw = snd_usb_hardware; /* need an explicit sync to catch applptr update in low-latency mode */ if (direction == SNDRV_PCM_STREAM_PLAYBACK && @@ -1259,13 +1266,17 @@ static int snd_usb_pcm_open(struct snd_pcm_substream *substream) ret = setup_hw_info(runtime, subs); if (ret < 0) - return ret; + goto out; ret = snd_usb_autoresume(subs->stream->chip); if (ret < 0) - return ret; + goto out; ret = snd_media_stream_init(subs, as->pcm, direction); if (ret < 0) snd_usb_autosuspend(subs->stream->chip); + subs->opened = 1; +out: + mutex_unlock(&chip->mutex); + return ret; } @@ -1274,6 +1285,7 @@ static int snd_usb_pcm_close(struct snd_pcm_substream *substream) int direction = substream->stream; struct snd_usb_stream *as = snd_pcm_substream_chip(substream); struct snd_usb_substream *subs = &as->substream[direction]; + struct snd_usb_audio *chip = subs->stream->chip; int ret; snd_media_stop_pipeline(subs); @@ -1287,6 +1299,9 @@ static int snd_usb_pcm_close(struct snd_pcm_substream *substream) subs->pcm_substream = NULL; snd_usb_autosuspend(subs->stream->chip); + mutex_lock(&chip->mutex); + subs->opened = 0; + mutex_unlock(&chip->mutex); return 0; }