linux-kernel - Re: [PATCH 01/15] Input - arizona-haptics: Fix double lock of dapm

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]

Date:	Tue, 18 Feb 2014 09:28:07 +0900
From:	Mark Brown <broonie@...nel.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>,
	myungjoo.ham@...sung.com, cw00.choi@...sung.com,
	lgirdwood@...il.com, lars@...afoo.de, peter.ujfalusi@...com,
	jarkko.nikula@...mer.com, eric.y.miao@...il.com,
	haojian.zhuang@...il.com, linux-kernel@...r.kernel.org,
	patches@...nsource.wolfsonmicro.com, alsa-devel@...a-project.org,
	linux@....linux.org.uk
Subject: Re: [PATCH 01/15] Input - arizona-haptics: Fix double lock of
 dapm_mutex

On Mon, Feb 17, 2014 at 11:20:26AM -0800, Dmitry Torokhov wrote:
> On Mon, Feb 17, 2014 at 04:51:29PM +0000, Charles Keepax wrote:

> > snd_soc_dapm_sync takes the dapm_mutex internally, but we currently take
> > it externally as well. This patch fixes this.

> Hmm, from the first glance this needs to go into current release,
> however it seems that it has been broken by
> a73fb2df01866b772a48fab93401fe3edbe0b38d 2 years ago so nobody cares...

Please include plain text versions of commit message descriptions, in
this case you're referring to "ASoC: dapm: Use DAPM mutex for DAPM ops
instead of codec mutex".  I expect nobody noticed in part because a lot
of use has been out of tree on older kernels and in part because the
issue is a race - there's a good chance things will work just fine
without the locking.

> Looking at the series I am not sure that this is right direction. You
> actually do want unlocked versions of snd_soc_dapm_* functions so that
> callers can take dapm mutex and then perform sequence of operations. The
> currect callers that were taking the mutex should probbaly be changed so
> that they do not drop it until they called unlocked version of
> snd_soc_dapm_sync().

That's all more work than is in scope for a bug fix though.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)