Re: [PATCH RESEND libgpiod v2 10/18] dbus: add the API definitions

["Sverdlin, Alexander" <alexander.sverdlin@siemens.com>]

Hi Bartosz, Thiago!

On Tue, 2024-07-02 at 11:15 +0200, Bartosz Golaszewski wrote:
> > > > What's the point of this property? It looks racy, as the user (whichever
> > > > it
> > > > is) can stop using it soon after a true read, or the line can become used
> > > > right after a false read? The latter could lead to TOCTOU problems.

Actually I don't think those users who are going to request the line will
look into "busy" flag, they just need to request directly and [possibly] fail.

But for displaying the status the racy flag is perfectly fine, because the
information is anyway outdated by the time it appears on the terminal.

> > > > Wouldn't it be better to force users to RequestLine and get an error if
> > > > the
> > > > line is busy? Because if it wasn't busy, now the calling application knows
> > > > nothing else can grab it.
> > > 
> > > this approach would make the inspection itself racy, isn't it?
> > > I'm thinking about two instances of "gpiocli info" running in parallel, they
> > > would display GPIO lines randomly "busy" even in case none of them actually
> > > is?
> > 
> > Correct, but the race time would be very small. The status application need
> > not keep the line requested for long, only enough to get the current state.
> > 
> > In any case, my argument is for everything *except* for the status / info
> > application. That's an outlier application, of which there's likely to be a
> > single one in the system. However, there will likely be multiple applications
> > that need lines for actual uses. The argument is that the presence of the
> > property can lead application authors to check before RequestLine in order to
> > present a message to their users, possibly because their code is simpler for
> > reading a property than dealing with an error.
> > 
> > Therefore, my advice is to not have the API that can lead to TOCTOU, even if
> > by accident.
> 
> Unfortunately there's one issue with the above: requesting a line
> (even as input) may result in the kernel driver triggering a physical
> change in hardware which may be undesirable. Inspecting the "Used"
> property only results in fetching a flag from the kernel and will
> never make the driver act upon HW.

And this is very true, barely anyone wants their "input pull-up" or
"input pull-down" to become simply "input" just by observing the status.

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com