linux-kernel - Re: gpiochip_lock_as_irq on pins without FLAG

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdY4bU=bEAyA5ZCx7PVF7nKoPSR7iv6x0t-QM6Bc6bc99Q@mail.gmail.com>
Date:   Fri, 2 Jul 2021 02:09:17 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Vincent Pelletier <plr.vincent@...il.com>
Cc:     Bartosz Golaszewski <bgolaszewski@...libre.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: gpiochip_lock_as_irq on pins without FLAG_REQUESTED: bug or
 feature ?

On Mon, Jun 28, 2021 at 5:37 AM Vincent Pelletier <plr.vincent@...il.com> wrote:

> gpiolib (gpiochip_irq_reqres, gpiochip_reqres_irq, gpiochip_lock_as_irq)
> does not call gpiod_request_{,commit}, resulting in a pin which is available
> for use.

Nope and they should not.

> Is this intentional ?

Yes.

The basic reason is that gpiochips and irqchips are orthogonal.
You can request an IRQ on a GPIO line without requesting the
GPIO line for anything else.

This is also used when drivers want to inspect the state of a GPIO
line (read the value) while the same line triggers IRQs. This is
perfectly legal. An extreme example is:
drivers/media/cec/platform/cec-gpio/cec-gpio.c

There is sometimes confusion around gpiod_to_irq().
This is just a convenience function locating the IRQ for a certain
GPIO. Both resources still have to be requested separately
and there is no dependency between them, they are just
often implemented in the same driver, using two different
subsystem APIs, in the end.

sysfs can't be used as any guide here since it conflates GPIO lines
and IRQs and provides several dangerous ways to shoot oneself
in the foot. The chardev does a better job at keeping this in
order.

> Also, I notice that both gpiochip_hierarchy_add_domain and
> gpiochip_reqres_irq call gpiochip_lock_as_irq, and I am surprised I do not
> get any error about this: in my understanding only the first call on a given pin
> should succeed, but with my WARN_ON I am seeing both stack traces and
> no other warning.

Hm that may be a subtle bug.

The state is just a bool so the first to leave will turn out the lights
for whoever is left in the room :P

Yours,
Linus Walleij