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:31:48 +0200 [thread overview]
Message-ID: <Y4dNNAHOFU5izEbm@smile.fi.intel.com> (raw)
In-Reply-To: <CAMRc=Meo7_YuNEHPn0zH7FoRaNOXhd5B0Z664jeZcrhzngW=KA@mail.gmail.com>
On Wed, Nov 30, 2022 at 01:05:30PM +0100, Bartosz Golaszewski wrote:
> On Wed, Nov 30, 2022 at 1:02 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Wed, Nov 30, 2022 at 10:05:56AM +0100, Bartosz Golaszewski wrote:
> > > + down_read(&gdev->sem);
> >
> > Thinking more about this, wouldn't be better to actually
> >
> > ret = down_read_trylock(&gdev->sem);
> > if (ret)
> > return ret;
> >
> > ?
>
> You mean as in: try to take the lock, but if we're already removing
> the device (as the down_write() can only happen in gpiochip_remove()),
> then die right away? Smart! Yeah, I'll do it this way.
But please check return values properly (it seems not obvious what it does
return).
--
With Best Regards,
Andy Shevchenko
prev parent reply other threads:[~2022-11-30 12:31 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
2022-11-30 12:05 ` Bartosz Golaszewski
2022-11-30 12:31 ` Andy Shevchenko [this message]
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=Y4dNNAHOFU5izEbm@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.