linux-kernel - Re: [PATCH] pinctrl: sink pinctrldev_list

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: <51A4C9BA.40903@wwwdotorg.org>
Date:	Tue, 28 May 2013 09:14:02 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	ext Tony Lindgren <tony@...mide.com>,
	Haojian Zhuang <haojian.zhuang@...aro.org>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Stephen Warren <swarren@...dia.com>,
	Anmar Oueja <anmar.oueja@...aro.org>
Subject: Re: [PATCH] pinctrl: sink pinctrldev_list_mutex

On 05/25/2013 03:09 AM, Linus Walleij wrote:
> On Fri, May 24, 2013 at 5:45 PM, Stephen Warren <swarren@...dotorg.org> wrote:
>> On 05/24/2013 02:04 AM, Linus Walleij wrote:
> 
>>> Prevention of module unloading of pin controllers has never
>>> been working properly, as there is no way to release the
>>> pinctrl handles taken by different drivers.
>>>
>>> I think that is why most pin controller drivers are bool rather
>>> than tristate.
>>
>> Once we get to multi-platform distro kernels, we will probably want all
>> the pinctrl drivers to be modules so only the correct one gets loaded
>> from an initrd. Hence, we'll want to move things to tristate rather than
>> away from it.
> 
> OK ... As some kind of excuse I think the current situation is an
> outgrowth of the fact that all the custom set-up used to be in machines
> down in arch/arm/* and inevitably done at machine init.
> 
>> If we know the pinctrl subsystem doesn't yet work correctly with module
>> unloads, should we modify pinctrl_register() to simply take a lock on
>> the driver module and never drop it, so that we guarantee we don't try
>> to unload the module later? Or, is this effectively already in place?
> 
> Hm, it won't happen with anything but pinctrl-single for sure.
> But I know that Tony used it at one point, however I still
> suspect that he was only using hogs.
> 
> We should maybe take the lock at the instant we instatiate a
> pinctrl handle from something else than a hog, so as to mark
> that we then have external dependencies that make unloading
> impossible.

Yes.

> But it'd be even cooler to actually just iterate over the
> pinctrl_list och handles and orphan them, and later recouple
> them if a driver is loaded back in.

Hmm. What happens if the client driver wants to select a different state
while the pinctrl driver itself isn't loaded? I'm not sure how workable
that is. I think the only way to make it work would be to cache enough
information in the struct pinctrl that it could be activated even if the
driver wasn't loaded. That seems a little scary.

I'd be fine if there was a requirement to unload all drives that were
clients of the pinctrl driver before you could unload the pinctrl
driver, just like any other driver/subsystem. This would work fine at
least for testing with just hogs, which while not great for full-system
testing would surely be fine at least when first developing the pinctrl
driver.
--
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/