From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Kent Gibson <warthog618@gmail.com>,
Linus Walleij <linus.walleij@linaro.org>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH v4 2/2] gpiolib: protect the GPIO device against being dropped while in use by user-space
Date: Wed, 30 Nov 2022 14:01:59 +0200 [thread overview]
Message-ID: <Y4dGNy4vlDEUUFlw@smile.fi.intel.com> (raw)
In-Reply-To: <20221130090556.40280-3-brgl@bgdev.pl>
On Wed, Nov 30, 2022 at 10:05:56AM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> While any of the GPIO cdev syscalls is in progress, the kernel can call
> gpiochip_remove() (for instance, when a USB GPIO expander is disconnected)
> which will set gdev->chip to NULL after which any subsequent access will
> cause a crash.
>
> To avoid that: use an RW-semaphore in which the syscalls take it for
> reading (so that we don't needlessly prohibit the user-space from calling
> syscalls simultaneously) while gpiochip_remove() takes it for writing so
> that it can only happen once all syscalls return.
Bikeshedding below and one question.
(As per tag I'm fine with this version anyway)
...
> +typedef __poll_t (*poll_fn)(struct file *, struct poll_table_struct *);
> +typedef long (*ioctl_fn)(struct file *, unsigned int, unsigned long);
> +typedef ssize_t (*read_fn)(struct file *, char __user *,
> + size_t count, loff_t *);
<bikeshedding>
It's only 84 is on a single line.
Dunno if it's better to have typedef followed by wrapper pairs rather than
all typedefs and wrappers grouped.
</bikeshedding>
> +static __poll_t call_poll_locked(struct file *file,
> + struct poll_table_struct *wait,
> + struct gpio_device *gdev, poll_fn func)
> +{
> + __poll_t ret;
> + down_read(&gdev->sem);
Thinking more about this, wouldn't be better to actually
ret = down_read_trylock(&gdev->sem);
if (ret)
return ret;
?
> + ret = func(file, wait);
> + up_read(&gdev->sem);
> +
> + return ret;
> +}
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2022-11-30 12:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-30 9:05 [PATCH v4 0/2] gpiolib: don't allow user-space to crash the kernel with hot-unplugs Bartosz Golaszewski
2022-11-30 9:05 ` [PATCH v4 1/2] gpiolib: cdev: fix NULL-pointer dereferences Bartosz Golaszewski
2022-11-30 9:05 ` [PATCH v4 2/2] gpiolib: protect the GPIO device against being dropped while in use by user-space Bartosz Golaszewski
2022-11-30 12:01 ` Andy Shevchenko [this message]
2022-11-30 12:05 ` Bartosz Golaszewski
2022-11-30 12:31 ` Andy Shevchenko
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=Y4dGNy4vlDEUUFlw@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=bartosz.golaszewski@linaro.org \
--cc=brgl@bgdev.pl \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=warthog618@gmail.com \
/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.