linux-kernel - Re: [PATCH 1/2] mfd: core: Add the option to order destruction of MFD cells

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]

Date:	Tue, 3 Jun 2014 11:35:01 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
Cc:	lee.jones@...aro.org, sameo@...ux.intel.com,
	patches@...nsource.wolfsonmicro.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] mfd: core: Add the option to order destruction of
 MFD cells

On Tue, Jun 03, 2014 at 10:49:32AM +0100, Charles Keepax wrote:
> On Mon, Jun 02, 2014 at 10:01:17PM +0100, Mark Brown wrote:

> > Probe deferral is supposed to handle removal too, we're supposed to be
> > able to walk the device list in reverse order and everything just work.

> I had considered this approach but was perhaps incorrectly too
> nervous about it. I was slightly concerned about breaking other
> MFD devices by changing the order things destroy in. Also the way

It seems vastly more likely that there's other drivers out there with
poorly tested removal paths than drivers relying on the current
behaviour.

> the child devices are iterated with device_for_each_child, there is
> lack of helpers to process the klist in reverse and it felt like
> code I probably shouldn't be modifying.

> I am happy to do a version that removes devices in reverse probe
> order, if that is preferrable? But any pointers if I am missing
> the obvious way to do that would be appreciated.

You probably need to write the helpers but I'd expect they should be
relatively straightforward.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)