[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150525174528.GG21577@sirena.org.uk>
Date: Mon, 25 May 2015 18:45:28 +0100
From: Mark Brown <broonie@...nel.org>
To: Tomeu Vizoso <tomeu.vizoso@...labora.com>
Cc: linux-arm-kernel@...ts.infradead.org,
Stéphane Marchesin
<stephane.marchesin@...il.com>,
Thierry Reding <thierry.reding@...il.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Alexander Holler <holler@...oftware.de>,
Grant Likely <grant.likely@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Liam Girdwood <lgirdwood@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/21] regulator: core: Reduce critical area in
_regulator_get
On Mon, May 25, 2015 at 04:53:05PM +0200, Tomeu Vizoso wrote:
> ...by moving the locking to regulator_dev_lookup.
This breaks the locking.
> + mutex_lock(®ulator_list_mutex);
> list_for_each_entry(r, ®ulator_list, list)
> - if (strcmp(rdev_get_name(r), supply) == 0)
> + if (strcmp(rdev_get_name(r), supply) == 0) {
> + mutex_unlock(®ulator_list_mutex);
> return r;
> + }
> + mutex_unlock(®ulator_list_mutex);
This means that we hold the lock while we walk the list but then return
a pointer to a regulator device that we don't have a reference to. This
then means that something else can unregister the regulator we're
holding a pointer to which means that it is unsafe to use that pointer.
We need to ensure that any objects we look up via the list remain valid
while we're working with them.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists