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] [day] [month] [year] [list]
Message-ID: <20140218145334.GA5438@opensource.wolfsonmicro.com>
Date:	Tue, 18 Feb 2014 14:53:34 +0000
From:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	alsa-devel@...a-project.org, lars@...afoo.de,
	eric.y.miao@...il.com, patches@...nsource.wolfsonmicro.com,
	lgirdwood@...il.com, haojian.zhuang@...il.com,
	linux-kernel@...r.kernel.org, peter.ujfalusi@...com,
	cw00.choi@...sung.com, broonie@...nel.org,
	myungjoo.ham@...sung.com, linux@....linux.org.uk,
	jarkko.nikula@...mer.com
Subject: Re: [alsa-devel] [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:
> HI Charles,
> 
> 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...
> 
> 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().

Having looked over this again I would prefer to go with the
current fix. It means the fix can be sent to the stable trees and
the haptics driver has no requirement for multiple pin updates to
be done atomically, so there is not a huge amount to be gained
from bundling things under an external lock.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ