linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 28 Jun 2021 12:36:53 +0900
From:   Vincent Pelletier <plr.vincent@...il.com>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        linux-gpio@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: gpiochip_lock_as_irq on pins without FLAG_REQUESTED: bug or feature ?

Hello,

While trying to debug an IRQ handling issue on a sifive-unmatched board
(which is a very recent board on a recent architecture, so I would not
be overly surprised if there were bugs in hiding), I realised that I was able
to claim via sysfs GPIO pins which are being actively used as IRQ sources.

Checking drivers/gpio/gpiolib.c and kernel/irq/chip.c, I believe this is because
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. I could confirm this by adding (just as a debugging aid):
  WARN_ON(!test_bit(FLAG_REQUESTED, &desc->flags));
early in gpiochip_lock_as_irq, and this statement gets triggered.

Is this intentional ?
Does this requesting belong to something else in the codepath from
request_threaded_irq (and similar) ?
Could it be something missing in the devicetree for this board ?

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.

FWIW, my builds are based on vanilla 5.13-rc6.

Regards,
-- 
Vincent Pelletier