linux-kernel - Re: [PATCH] ASoC: soc-pcm: Fix and cleanup DPCM locking

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: <2023051045-ransack-lullaby-a127@gregkh>
Date:   Wed, 10 May 2023 23:39:57 +0900
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Yixuan Jiang <yixuanjiang@...gle.com>
Cc:     tiwai@...e.com, lgirdwood@...il.com, broonie@...nel.org,
        linux-kernel@...r.kernel.org, alsa-devel@...a-project.org,
        Takashi Iwai <tiwai@...e.de>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
        Bard Liao <yung-chuan.liao@...ux.intel.com>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        stable@...r.kernel.org
Subject: Re: [PATCH] ASoC: soc-pcm: Fix and cleanup DPCM locking

On Wed, May 10, 2023 at 07:59:49PM +0800, Yixuan Jiang wrote:
> Greg KH <greg@...ah.com> 於 2023年5月6日 週六 下午1:56寫道：
> >
> > On Thu, May 04, 2023 at 05:21:42PM +0800, yixuanjiang wrote:
> > > From: Takashi Iwai <tiwai@...e.de>
> > >
> > > The existing locking for DPCM has several issues
> > > a) a confusing mix of card->mutex and card->pcm_mutex.
> > > b) a dpcm_lock spinlock added inconsistently and on paths that could
> > > be recursively taken. The use of irqsave/irqrestore was also overkill.
> > >
> > > The suggested model is:
> > >
> > > 1) The pcm_mutex is the top-most protection of BE links in the FE. The
> > > pcm_mutex is applied always on either the top PCM callbacks or the
> > > external call from DAPM, not taken in the internal functions.
> > >
> > > 2) the FE stream lock is taken in higher levels before invoking
> > > dpcm_be_dai_trigger()
> > >
> > > 3) when adding and deleting a BE, both the pcm_mutex and FE stream
> > > lock are taken.
> > >
> > > Signed-off-by: Takashi Iwai <tiwai@...e.de>
> > > [clarification of commit message by plbossart]
> > > Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
> > > Reviewed-by: Kai Vehmanen <kai.vehmanen@...ux.intel.com>
> > > Reviewed-by: Bard Liao <yung-chuan.liao@...ux.intel.com>
> > > Reviewed-by: Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>
> > > Link: https://lore.kernel.org/r/20211207173745.15850-4-pierre-louis.bossart@linux.intel.com
> > > Cc: stable@...r.kernel.org # 5.15.x
> > > Signed-off-by: Mark Brown <broonie@...nel.org>
> > > ---
> >
> > What is the git commit id of this patch in Linus's tree?
> >
> > thanks,
> >
> > greg k-h
> 
> Hi Greg,
> For this patch I think it is [3/6] b7898396f4bbe160f546d0c5e9fa17cca9a7d153
> 
> >From https://lore.kernel.org/all/163953384515.1515253.13641477106348913835.b4-ty@kernel.org/
> Seems there are total 6 patches.
> 
> [1/6] ASoC: soc-pcm: use GFP_ATOMIC for dpcm structure
>       commit: d8a9c6e1f6766a16cf02b4e99a629f3c5512c183
> [2/6] ASoC: soc-pcm: align BE 'atomicity' with that of the FE
>       commit: bbf7d3b1c4f40eb02dd1dffb500ba00b0bff0303
> [3/6] ASoC: soc-pcm: Fix and cleanup DPCM locking
>       commit: b7898396f4bbe160f546d0c5e9fa17cca9a7d153
> [4/6] ASoC: soc-pcm: serialize BE triggers
>       commit: b2ae80663008a7662febe7d13f14ea1b2eb0cd51
> [5/6] ASoC: soc-pcm: test refcount before triggering
>       commit: 848aedfdc6ba25ad5652797db9266007773e44dd
> [6/6] ASoC: soc-pcm: fix BE handling of PAUSE_RELEASE
>       commit: 3aa1e96a2b95e2ece198f8dd01e96818971b84df
> 
> These 6 patches could directly cherry-pick to in 5.15 without conflict.

Then please submit them for stable inclusion after you have tested that
they all work properly.  But first, what bug is actually needed to be
fixed here?  What is not working that this patch series fixes?

thanks,

greg k-h