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: <CAAs364-thiqACMRwT++JMxkMd7qa_stFApjK-4SmrEJetX6oyw@mail.gmail.com>
Date:   Thu, 18 Nov 2021 09:02:40 +0530
From:   Vaibhav Agarwal <vaibhav.sr@...il.com>
To:     Alex Elder <elder@...aro.org>
Cc:     Takashi Iwai <tiwai@...e.de>,
        "moderated list:GREYBUS SUBSYSTEM" <greybus-dev@...ts.linaro.org>,
        Alex Elder <elder@...nel.org>, Johan Hovold <johan@...nel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [greybus-dev] [PATCH] staging: greybus: Add missing rwsem around
 snd_ctl_remove() calls

On Thu, Nov 18, 2021 at 3:25 AM Alex Elder <elder@...aro.org> 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?

--
vaibhav

 >
>
>                                         -Alex
>
> > Takashi
> >
> >
> >> Otherwise, will you please submit version two, taking the
> >> lock inside gbaudio_remove_controls()?
> >>
> >> Thanks.
> >>
> >>                                      -Alex
> >>
> >>> Fixes: 510e340efe0c ("staging: greybus: audio: Add helper APIs for dynamic audio modules")
> >>> Signed-off-by: Takashi Iwai <tiwai@...e.de>
> >>> ---
> >>>    drivers/staging/greybus/audio_helper.c | 8 ++++++--
> >>>    1 file changed, 6 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/staging/greybus/audio_helper.c b/drivers/staging/greybus/audio_helper.c
> >>> index 1ed4772d2771..843760675876 100644
> >>> --- a/drivers/staging/greybus/audio_helper.c
> >>> +++ b/drivers/staging/greybus/audio_helper.c
> >>> @@ -192,7 +192,11 @@ int gbaudio_remove_component_controls(struct snd_soc_component *component,
> >>>                                   unsigned int num_controls)
> >>>    {
> >>>     struct snd_card *card = component->card->snd_card;
> >>> +   int err;
> >>>    -        return gbaudio_remove_controls(card, component->dev, controls,
> >>> -                                  num_controls, component->name_prefix);
> >>> +   down_write(&card->controls_rwsem);
> >>> +   err = gbaudio_remove_controls(card, component->dev, controls,
> >>> +                                 num_controls, component->name_prefix);
> >>> +   up_write(&card->controls_rwsem);
> >>> +   return err;
> >>>    }
> >>>
> >>
>
> _______________________________________________
> greybus-dev mailing list
> greybus-dev@...ts.linaro.org
> https://lists.linaro.org/mailman/listinfo/greybus-dev

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ