linux-kernel - Re: Re: PINCTRL:We May need mutex protect in pinctrl API

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>] [day] [month] [year] [list]

Date:	Mon, 18 Nov 2013 14:22:09 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	"xulinuxkernel@...il.com" <xulinuxkernel@...il.com>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Re: PINCTRL:We May need mutex protect in pinctrl API

On Thu, Nov 7, 2013 at 10:48 AM, xulinuxkernel@...il.com
<xulinuxkernel@...il.com> wrote:

> sorry,our code is not upstream.
> But if two threads come in pinctrl_select_state()  at the same time,
> Is that okay?

Why would two threads come in there at the same time?

We have exactly one pinctrl* handle per device, and we
select the state on it. This is like for example the device
driver would have one thread telling it to go to "default"
state and another thread telling it to go to "idle" or "sleep"
state for example.

If we really have a device driver doing such things
for a good reason, then we need to protect it, but I
want to see that device driver first.

I am quite sure that it's safe to say that the upstream
kernel does not contain a device that will ask the hardware
to move around between different states like this from
different threads, such calls will be serialized by the
nature of sequencing in e.g. runtime PM.

I need to see the device driver and the use case so I
can understand why this would be needed.

I think the need from this arise from an abuse of the
pin controller states.

Yours,
Linus Walleij
--
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/