All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kent Gibson <warthog618@gmail.com>
To: brgl@bgdev.pl
Cc: linux-gpio@vger.kernel.org
Subject: Re: [BUG] gpiolib: cdev: can't read RELEASED event for last line
Date: Thu, 25 May 2023 15:09:26 +0800	[thread overview]
Message-ID: <ZG8Jpjq/N97plOGe@sol> (raw)
In-Reply-To: <ZG7RgGasxXz4/pwl@sol>

On Thu, May 25, 2023 at 11:09:52AM +0800, Kent Gibson wrote:
> Hi Bart,
> 
> In testing I'm finding that I can't read the RELEASED event from the
> chip fd when the last line on the chip is released.
> The chip fd becomes readable, but when I try to read it I get ENODEV.
> 
> I suspect this change is the likely culprit:
> 
> 533aae7c94db gpiolib: cdev: fix NULL-pointer dereferences
> 
> @@ -2425,6 +2449,9 @@ static ssize_t lineinfo_watch_read(struct file *file, char __user *buf,
>         int ret;
>         size_t event_size;
> 
> +       if (!cdev->gdev->chip)
> +               return -ENODEV;
> +
> 
> though I haven't bisected it yet to be sure.
> 
> Btw, that is testing on 6.4.0-rc3 mainline.
> 

To be clear, I happened to spot the problem with 6.4.0-rc3, but the
problem was almost certainly introduced earlier.

The problem ican be repeated with the info_change_events test from [1]

e.g.

$ cargo test --all-features chip

.... 

failures:

---- chip::uapi_v1::info_change_events stdout ----
read: Err(UapiError(ReadEvent, Os(Errno { code: 19, description: Some("No such device") })))
thread 'chip::uapi_v1::info_change_events' panicked at 'assertion failed: res.is_ok()', lib/tests/chip.rs:719:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- chip::uapi_v2::info_change_events stdout ----
read: Err(UapiError(ReadEvent, Os(Errno { code: 19, description: Some("No such device") })))
thread 'chip::uapi_v2::info_change_events' panicked at 'assertion failed: res.is_ok()', lib/tests/chip.rs:719:9


I haven't done a complete bisection, but the tests do pass with 6.1.0-rc1
- the previous kernel I was testing with.

I can also confirm that receiving the event using a blocking read() on the
fd still works, it is a poll() on the fd followed by a read() that fails.

I only ran across the bug by pure chance while debugging that test case
- previously it only did the blocking read.
So there is probably limited real world impact, but something additional
to test for, and fix, of course.

Cheers,
Kent.
[1] https://github.com/warthog618/gpiocdev-rs/blob/36e9c1640e2ae5c6e08d43cd0c254a2e7cec2d63/lib/tests/chip.rs ~line 649

  reply	other threads:[~2023-05-25  7:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-25  3:09 [BUG] gpiolib: cdev: can't read RELEASED event for last line Kent Gibson
2023-05-25  7:09 ` Kent Gibson [this message]
2023-05-25  7:46   ` Kent Gibson
2023-05-25 13:21     ` Kent Gibson
2023-05-26  0:45       ` Kent Gibson
2023-05-26  6:51         ` Kent Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZG8Jpjq/N97plOGe@sol \
    --to=warthog618@gmail.com \
    --cc=brgl@bgdev.pl \
    --cc=linux-gpio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.