linux-kernel - Re: [PATCH 5/5] gpiolib: notify user-space about in-kernel line state changes

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: <CAMRc=MesxXkwQtDHX4vuE+W3KAboM0PNWy6ezScrc_i10=x2=g@mail.gmail.com>
Date: Sat, 5 Oct 2024 20:45:17 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Kent Gibson <warthog618@...il.com>
Cc: Linus Walleij <linus.walleij@...aro.org>, linux-gpio@...r.kernel.org, 
	linux-kernel@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH 5/5] gpiolib: notify user-space about in-kernel line state changes

On Sat, Oct 5, 2024 at 11:54 AM Kent Gibson <warthog618@...il.com> wrote:
>
> On Sat, Oct 05, 2024 at 11:42:34AM +0200, Bartosz Golaszewski wrote:
> > On Sat, Oct 5, 2024 at 9:46 AM Kent Gibson <warthog618@...il.com> wrote:
> > >
> > > On Fri, Oct 04, 2024 at 04:43:26PM +0200, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> > > >
> > > > There is a problem with gpiod_direction_output/input(), namely the fact
> > > > that they can be called both from sleeping as well as atomic context. We
> > > > cannot call the blocking notifier from atomic and we cannot switch to
> > > > atomic notifier because the pinctrl functions we call higher up the stack
> > > > take a mutex. Let's instead use a workqueue and schedule a task to emit
> > > > the event from process context on the unbound system queue for minimal
> > > > latencies.
> > > >
> > >
> > > So now there is a race between the state of the desc changing and the
> > > notified reading it?
> > >
> >
> > Theoretically? Well, yes... In practice I don't think this would
> > matter. But I understand the concern and won't insist if it's a
> > deal-breaker for you.
> >
>
> I don't like that correctness depends on timing, so this is a deal
> breaker for me as it stands.  I would like to see the relevant state passed
> via the notifier chain, rather than assuming it can be pulled from the desc
> when the notifier is eventually called.
>

We could potentially still use the workqueue but atomically allocate
the work_struct in any context, store the descriptor data, timestamp
etc. (except the info from pinctrl which is rarely modified and would
be retrieved just before emitting the event in process context) in it
and pass it to the workqueue which would then put the data into the
kfifo and free the work_struct. We can enforce ordering of work
execution so we wouldn't mangle them, userspace would still see the
events with correct timestamps and in the right order. Does this sound
like something viable?

Bart