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: <519F8B02.1080000@wwwdotorg.org>
Date:	Fri, 24 May 2013 09:45:06 -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/24/2013 02:04 AM, Linus Walleij wrote:
> On Mon, May 20, 2013 at 10:40 PM, Stephen Warren <swarren@...dotorg.org> wrote:
> 
>> This seems fine on the surface, but I do have one question:
>>
>> I think the pinctrl lock serves a couple of purposes:
>>
>> 1) Basic protection for accesses to the pinctrldev_list itself.
>>
>> This patch seems just fine w.r.t. this point.
>>
>> 2) Preventing pinctrl drivers from being unregistered (and their modules
>> unloaded) when some operation is being performed on/to them.
> 
> 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.

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?

In other words, I can accept that we know that we can't unload pinctrl
drivers, but given that, I think the kernel should make sure the user
/actually/ can't unload them.
--
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/