From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: "Laurent Pinchart" <laurent.pinchart+renesas@ideasonboard.com>,
linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
"Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>,
"Sakari Ailus" <sakari.ailus@linux.intel.com>,
"Hans Verkuil" <hans.verkuil@cisco.com>
Subject: Re: [PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race
Date: Tue, 12 Dec 2017 16:49:10 +0200 [thread overview]
Message-ID: <6414276.bWOzFEfRW5@avalon> (raw)
In-Reply-To: <8942419d-fc0e-7a82-cc35-a7960cd22800@xs4all.nl>
Hi Hans,
On Friday, 17 November 2017 13:09:20 EET Hans Verkuil wrote:
> On 16/11/17 01:33, Laurent Pinchart wrote:
> > Device unplug being asynchronous, it naturally races with operations
> > performed by userspace through ioctls or other file operations on video
> > device nodes.
> >
> > This leads to potential access to freed memory or to other resources
> > during device access if unplug occurs during device access. To solve
> > this, we need to wait until all device access completes when unplugging
> > the device, and block all further access when the device is being
> > unplugged.
> >
> > Three new functions are introduced. The video_device_enter() and
> > video_device_exit() functions must be used to mark entry and exit from
> > all code sections where the device can be accessed. The
> > video_device_unplug() function is then used in the unplug handler to
> > mark the device as being unplugged and wait for all access to complete.
> >
> > As an example mark the ioctl handler as a device access section. Other
> > file operations need to be protected too, and blocking ioctls (such as
> > VIDIOC_DQBUF) need to be handled as well.
>
> As long as the queue field in struct video_device is filled in properly
> this shouldn't be a problem.
>
> This looks pretty good, simple and straightforward.
Thank you.
> Do we need something similar for media_device? Other devices?
I believe so, which is why I'm wondering whether this shouldn't somehow go to
the device core (and in the cdev core). Not all devices will need such an
infrastructure as some subsystems already protect against device access after
unbind (USB is one of them if I'm not mistaken), but it certainly shouldn't
hurt.
DRM is also considering a similar implementation, but based on srcu to lower
the performance penalty. I feel that's going a bit overboard but I have no
numbers yet to confirm or infirm the suspicion.
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> >
> > drivers/media/v4l2-core/v4l2-dev.c | 57 +++++++++++++++++++++++++++++++++
> > include/media/v4l2-dev.h | 47 +++++++++++++++++++++++++++++++
> > 2 files changed, 104 insertions(+)
[snip]
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2017-12-12 14:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-16 0:33 [PATCH/RFC 0/2] V4L2: Handle the race condition between device access and unbind Laurent Pinchart
2017-11-16 0:33 ` [PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race Laurent Pinchart
2017-11-16 12:32 ` Sakari Ailus
2017-11-16 14:47 ` Kieran Bingham
2017-12-12 14:44 ` Laurent Pinchart
2017-12-12 14:42 ` Laurent Pinchart
2017-12-14 12:42 ` Sakari Ailus
2017-11-17 11:09 ` Hans Verkuil
2017-12-12 14:49 ` Laurent Pinchart [this message]
2017-11-23 13:07 ` Mauro Carvalho Chehab
2017-11-23 14:21 ` Greg Kroah-Hartman
2017-12-12 12:39 ` Mauro Carvalho Chehab
2017-12-12 15:32 ` Laurent Pinchart
2017-12-12 15:24 ` Laurent Pinchart
2017-12-12 14:54 ` Laurent Pinchart
2017-11-16 0:33 ` [PATCH/RFC 2/2] v4l: rcar-vin: Wait for device access to complete before unplugging Laurent Pinchart
2017-11-16 12:36 ` Sakari Ailus
2017-11-16 15:49 ` Niklas Söderlund
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=6414276.bWOzFEfRW5@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=hans.verkuil@cisco.com \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=niklas.soderlund+renesas@ragnatech.se \
--cc=sakari.ailus@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox