linux-kernel - Re: [RFC] Regulator: Add a voltage changed event to notify consumers

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: <4974C182.1090902@cam.ac.uk>
Date:	Mon, 19 Jan 2009 18:08:02 +0000
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Jonathan Cameron <Jonathan.Cameron@...il.com>
CC:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Regulator: Add a voltage changed event to notify consumers

Jonathan Cameron wrote:
> Mark Brown wrote:
>> On Sun, Jan 18, 2009 at 06:47:25PM +0000, Jonathan Cameron wrote:
>>
>>> -out:
>>> +	mutex_unlock(&rdev->mutex);
>>> +	_notifier_call_chain(rdev, REGULATOR_EVENT_VOLTAGE_CHANGE, NULL);
>>> +	return 0;
>>> +out_unlock:
>> It'd be nice if we could modify _notifier_call_chain() to push the 
>> locking out a bit so we don't need to drop the lock before calling the
>> notifier.  On the other hand, for anything that isn't memory mapped or
>> GPIO controlled (most regulators are in this category) the cost of the
>> I/O is going to make this a non-issue.
> Agreed.  On that note, isn't any call to regulator_force_disable
> currently going to deadlock? (lock held in regulator_force_disable,
> then re-called in _notifier_call_chain.)
> 
> I'll have a look into moving the locks out of _notifier_call_chain.
Having had a quick look at this, it comes down to a question of
whether we want to hold the lock on one regulator whilst notifying
any regulators it supplies.

I personally can't see that this would be a problem, but it has definitely
been structured to avoid doing so.

Trying to come up with scenarios that may make this a problem:

Parent notifies child of a voltage change. This change results in 
some complex problem (not covered by constraints - I'm stretching here)
that in turn causes a the child regulator to request a forced disable
from the parent and causes deadlock.

Can anyone come up with a non contrived reason not to move constraints clean
out of _notifier_call_chain and rely on caller holding the lock?
Clearly this also requires applying locks to child regulators in 
the loop at the end of _notifier_call_chain.

Next email contains a patch combing this change with the voltage
notification patch.

Cheers,

Jonathan
--
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/