From: Mark Brown <broonie@kernel.org>
To: Ashay Jaiswal <ashayj@codeaurora.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
Anirudh Ghayal <aghayal@codeaurora.org>
Subject: Re: [PATCH] regulator: core: fix race condition in regulator_put()
Date: Wed, 7 Jan 2015 17:06:46 +0000 [thread overview]
Message-ID: <20150107170646.GX2634@sirena.org.uk> (raw)
In-Reply-To: <1420638683-20216-1-git-send-email-ashayj@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]
On Wed, Jan 07, 2015 at 07:21:23PM +0530, Ashay Jaiswal wrote:
> The regulator framework maintains a list of consumer regulators
> for a regulator device and protects it from concurrent access
> using the regulator device's mutex lock.
> In the case of regulator_put() the consumer is removed without
> holding the regulator device's mutex, resulting in a race condition
> between any regulator operation which traverses the consumer list
> and regulator_put() which releases the consumer regulator.
> Fix this race condition by holding the regulator device's mutex while
> removing and releasing the consumer regulator.
This is a good spot thanks but I think your analysis here is missing a
bit - it's not just the list manipulation that affects the rdev, it's
also the reference count in the rdev and the exclusive flag. Indeed
some of this issue applies on the _get() side too, while we do add the
regulator to the list under the rdev mutex we don't have the mutex when
we update the reference count meaning that we've got a potential issue
with that. That *is* kind of separate though so could be dealt with in
a separate patch.
The lock region also seems too wide, the lock is only needed for the
operations that affect the rdev not for the operations only on the
object being freed - holding the lock for too long means impacting other
users and some of the cleanup is potentially expensive. The comment at
the top of the function needs updating too, it currently says that the
lock is held in the caller but this applies only to the regulator_list_mutex.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-01-07 17:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-07 13:51 Ashay Jaiswal
2015-01-07 17:06 ` Mark Brown [this message]
2015-01-08 12:58 ` ashayj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150107170646.GX2634@sirena.org.uk \
--to=broonie@kernel.org \
--cc=aghayal@codeaurora.org \
--cc=ashayj@codeaurora.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome