Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7CFD0C433F5 for ; Thu, 18 Nov 2021 06:56:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6721761B5E for ; Thu, 18 Nov 2021 06:56:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243489AbhKRG66 (ORCPT ); Thu, 18 Nov 2021 01:58:58 -0500 Received: from smtp-out2.suse.de ([195.135.220.29]:51390 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242647AbhKRG64 (ORCPT ); Thu, 18 Nov 2021 01:58:56 -0500 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 79C1F1FD35; Thu, 18 Nov 2021 06:55:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1637218556; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ppnCc0JM0M6aGCgbVH0SLi1aFypkBUETP8zEkQ1ZtMs=; b=ccJu5fVN/yOpgLvFJou00wPiHjwzYzWyg3/r16oc1Zxymvsiz19+vI0Idofa7GkrWfrB98 iKXww+71jjBnJwj+5Mo8MGiwMnntVjFSjGufjBbkwtPxLTKe+suINWLE/Cuw65M4xBxtuH FU34nWEALVn2x2bh2JK2I1r9H3zuZy8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1637218556; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ppnCc0JM0M6aGCgbVH0SLi1aFypkBUETP8zEkQ1ZtMs=; b=3O9uGyzYQB13jsYcsRXU0rMNWipCmEZLgo79VJkgpF0WfxmHdW1c67nqGEFYNaFkWvio0a BsNSGEQZ3X7TzyAw== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id 6ECE7A3B81; Thu, 18 Nov 2021 06:55:56 +0000 (UTC) Date: Thu, 18 Nov 2021 07:55:56 +0100 Message-ID: From: Takashi Iwai To: Vaibhav Agarwal Cc: Alex Elder , Takashi Iwai , "moderated list:GREYBUS SUBSYSTEM" , Alex Elder , Johan Hovold , open list Subject: Re: [greybus-dev] [PATCH] staging: greybus: Add missing rwsem around snd_ctl_remove() calls In-Reply-To: References: <20211116072027.18466-1-tiwai@suse.de> <07e228eb-676a-bdb1-c2ec-a96f691f5a18@linaro.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 18 Nov 2021 04:32:40 +0100, Vaibhav Agarwal wrote: > > On Thu, Nov 18, 2021 at 3:25 AM Alex Elder wrote: > > > > On 11/17/21 3:02 PM, Takashi Iwai wrote: > > > On Wed, 17 Nov 2021 20:56:14 +0100, > > > Alex Elder wrote: > > >> > > >> On 11/16/21 1:20 AM, Takashi Iwai wrote: > > >>> snd_ctl_remove() has to be called with card->controls_rwsem held (when > > >>> called after the card instantiation). This patch adds the missing > > >>> rwsem calls around it. > > >> > > >> I see the comment above snd_ctl_remove() that says you must hold > > >> the write lock. And given that, this seems correct to me. > > >> > > >> I understand why you want to take the lock just once, rather > > >> than each time snd_ctl_remove() is called. > > >> > > >> However I believe the acquisition and release of the lock > > >> belongs inside gbaudio_remove_controls(), not in its caller. > > >> > > >> If you disagree, can you please explain why? > > > > > > In general if the function returns an error and has a loop inside, > > > taking a lock in the caller side avoids the forgotten unlock. > > > > But taking the lock in the called function makes the > > caller not need to take the lock (which would be even > > more valuable if there were more than one caller). > > > > I prefer having the lock acquisition in the called > > function. Please send version 2, as I suggested. > > > Hi Takashi, > > Thanks for sharing this patch. In reference to the suggestion from Alex, > do you think replacing snd_ctl_find_id(), snd_ctl_remove() with > snd_ctl_remove_id() inside gbaudio_remove_controls() would be an even > better choice without worrying about locks? Yeah, that sounds like a better plan, indeed. Takashi