| 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
| ||
|
Message-ID: <4CD29C7D.4050500@stericsson.com> Date: Thu, 4 Nov 2010 12:43:57 +0100 From: Mattias Wallin <mattias.wallin@...ricsson.com> To: Liam Girdwood <lrg@...mlogic.co.uk> Cc: "broonie@...nsource.wolfsonmicro.com" <broonie@...nsource.wolfsonmicro.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Linus WALLEIJ <linus.walleij@...ricsson.com>, Bengt JONSSON <bengt.g.jonsson@...ricsson.com> Subject: Re: [PATCH] regulator: lock supply in regulator enable > Sorry, got a busy schedule atm. Can you give us your reasoning behind > why you think we need a lock here ? Yes, when we enter regulator_enable() we take the lock only for that specific regulator rdev->mutex and calls the locked function _regulator_enable(). This locked function then checks if we have a supply and recursively calls the locked _regulator_enable() again but with the supply rdev as argument. The supply rdev regulator is however not locked at this stage, only the "original" supplied regulator is locked. So if we have two regulators with the same supply regulator trying to enable at approx. the same time they will both enter the _regulator_enable without locks and we could get a race condition. This would probably result in reference counting error and unbalanced regulator warnings. In our system we make use the regulator hierarchy quite heavily. > > Thanks > > Liam /Mattias Wallin -- 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