All of lore.kernel.org
 help / color / mirror / Atom feed
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 v3 2/2] gpiolib: protect the GPIO device against being dropped while in use by user-space
Date: Tue, 29 Nov 2022 18:53:26 +0200	[thread overview]
Message-ID: <Y4Y5BjTwVCF5bAn5@smile.fi.intel.com> (raw)
In-Reply-To: <20221129123553.353410-3-brgl@bgdev.pl>

On Tue, Nov 29, 2022 at 01:35:53PM +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.

...

I would do

typedef __poll_t (*poll_fn)(struct file *, struct poll_table_struct *);

and so on and use that one in the respective parameters.

BUT. Since it's a fix, up to you which one to choose.

> +static __poll_t call_poll_locked(struct file *file,
> +				 struct poll_table_struct *wait,
> +				 struct gpio_device *gdev,
> +				 __poll_t (*func)(struct file *,
> +						  struct poll_table_struct *))
> +{
> +	__poll_t ret;
> +
> +	down_read(&gdev->sem);
> +	ret = func(file, wait);
> +	up_read(&gdev->sem);
> +
> +	return ret;
> +}

...

> +	down_write(&gdev->sem);

+ Blank line?

>  	/* FIXME: should the legacy sysfs handling be moved to gpio_device? */
>  	gpiochip_sysfs_unregister(gdev);
>  	gpiochip_free_hogs(gc);

...

>  	gcdev_unregister(gdev);

+ Blank line ?

> +	up_write(&gdev->sem);
>  	put_device(&gdev->dev);

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2022-11-29 17:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-29 12:35 [PATCH v3 0/2] gpiolib: don't allow user-space to crash the kernel with hot-unplugs Bartosz Golaszewski
2022-11-29 12:35 ` [PATCH v3 1/2] gpiolib: cdev: fix NULL-pointer dereferences Bartosz Golaszewski
2022-11-29 12:35 ` [PATCH v3 2/2] gpiolib: protect the GPIO device against being dropped while in use by user-space Bartosz Golaszewski
2022-11-29 16:53   ` Andy Shevchenko [this message]
2022-11-29 23:57     ` Kent Gibson
2022-11-29 16:54 ` [PATCH v3 0/2] gpiolib: don't allow user-space to crash the kernel with hot-unplugs 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=Y4Y5BjTwVCF5bAn5@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.