linux-kernel - Re: regression: gpiolib: switch the line state notifier to atomic unexpected impact on performance

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: <20250312090829.5de823b7@erd003.prtnl>
Date: Wed, 12 Mar 2025 09:08:29 +0100
From: David Jander <david@...tonic.nl>
To: Kent Gibson <warthog618@...il.com>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, Bartosz Golaszewski
 <bartosz.golaszewski@...aro.org>, Linus Walleij <linus.walleij@...aro.org>,
 linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: regression: gpiolib: switch the line state notifier to atomic
 unexpected impact on performance

On Wed, 12 Mar 2025 09:32:56 +0800
Kent Gibson <warthog618@...il.com> wrote:

> On Tue, Mar 11, 2025 at 12:03:46PM +0100, David Jander wrote:
> >
> > Indeed, it does. My application is written in python and uses the python gpiod
> > module. Even in such an environment the impact is killing.
> 
> Interesting - the only reason I could think of for an application
> requesting/releasing GPIOs at a high rate was it if was built on top of
> the libgpiod tools and so was unable to hold the request fd.

I didn't want to bother the list with the details, but this is during the
configuration phase of the application. It receives many configuration messages
for different IO objects at a fast pace. Most of those objects use one or more
GPIO lines identified by their label. So the application calls
gpiod.find_line(label) on each of them. Apparently libgiod (version 1.6.3 in
our case) isn't very efficient, since it will open and close each of the
gpiodev devices in order to query for each of the gpio lines. I wouldn't blame
libgpiod (python bindings) for doing it that way, since open()/close() of a
chardev are expected to be fast, and caching this information is probably
error prone anyway, since AFAIK user space cannot yet be informed of changes
to gpio chips from kernel space.

If this had been this slow always (even before 6.13), I would probably have
done things a bit differently and cached the config requests to then "find"
the lines in batches directly working on the character devices instead of
using gpiod, so I could open/close each one just once for finding many
different lines each time.

> Generally an application should request the lines it requires once and hold
> them for the duration.  Similarly functions such as find_line() should be
> performed once per line.

Of course it does that ;-)
This board has a large amount of GPIO lines, and like I said, it is during the
initial configuration phase of the application that I am seeing this problem.

> From a performance perspective, NOT having to re-request a line is
> considerably faster than requesting it - even with Bart's fix.
> 
> Is there something unusual about your app that requires the lines be
> released?

See above.

Best regards,

-- 
David Jander