dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: David Herrmann <dh.herrmann@gmail.com>
To: "Stéphane Marchesin" <stephane.marchesin@gmail.com>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>, Haixia Shi <hshi@chromium.org>
Subject: Re: [PATCH 2/2] drm: make unplugged flag specific to udl driver
Date: Wed, 10 Feb 2016 22:54:06 +0100	[thread overview]
Message-ID: <CANq1E4TqNq9bZJMmMRRJEcAXRxDFyyecgzdjq94eNMNMo8x4Nw@mail.gmail.com> (raw)
In-Reply-To: <CACP_E++cSddHcrGNs+P89avYovnq7wmt2hcqvWdr5Z-24hqjCg@mail.gmail.com>

Hi

On Wed, Feb 10, 2016 at 10:46 PM, Stéphane Marchesin
<stephane.marchesin@gmail.com> wrote:
> On Wed, Feb 10, 2016 at 1:38 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> Hi
>>
>> On Wed, Feb 10, 2016 at 9:39 PM, Haixia Shi <hshi@chromium.org> wrote:
>>>
>>>> +       if (udl_device_is_unplugged(dev) &&
>>>> +               nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_SETCRTC) &&
>>>> +               nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_RMFB) &&
>>>> +               nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_DESTROY_DUMB))
>>>> +               return -ENODEV;
>>>>
>>>>Why?
>>>>
>>>>Just do:
>>>>
>>>>        if (udl_device_is_unplugged(dev))
>>>>                return -ENODEV;
>>>>
>>>>Why this complex logic here?
>>>
>>> Because there are legitimate ioctl calls after UDL is unplugged. See
>>> crbug.com/583508 and crbug.com/583758 for some background.
>>>
>>> The userspace (Chrome in this case) has allocated FBs and Dumb buffers on
>>> the drm device and needs to be given a chance to properly deallocate them
>>> (via RMFB and DESTROY_DUMB). In addition, it needs to call SETCRTC with
>>> fb_id = 0 to properly release the last refcount on the primary fb.
>>>
>>> I initially proposed adding an "UNPLUG_DISALLOW" flag to ioctls so that we
>>> can whitelist them on a case-by-case basis but that proposal got shot down
>>> as being unnecessary, but you can see my original patch at
>>> https://chromium-review.googlesource.com/#/c/326160/
>>
>> If a device is unplugged, you should consider all your resources to be
>> destroyed. There is no reason to release them manually. User-space
>> *must* be able to deal with asynchronous unplugs.
>
> So the problem if you do that is that things like a buffer's memory
> pages can disappear from under you. How would you deal with that case?
> User space certainly can't have a segfault handler catch that just in
> case :)

If you rip out hardware resources, then you better be able to deal
with it. Sure, UDL is an exception as it doesn't have memory resources
on the chip. But it sounds fishy to me, if you base your API on it. On
a lot of other devices, the memory will simply not be there. So you
cannot keep it around.

There are many ways to invalidate memory mappings. You either unmap
the entire range (and user-space must deal with SIGBUS, which is
completely feasible and a lot of code already does it), or you replace
all with a zero page, or you duplicate all pages, ... IMO, user-space
has to start dealing with hardware unplug properly and stop pretending
it cannot happen.

If you mmap() your filesystem, and you rip out your block device, then
you also will get SIGBUS if you access pages that are not in
pagecache. Why are graphics buffers different?

Thanks
David
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2016-02-10 21:54 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-05 21:57 [PATCH 1/2] drm/msm: remove the drm_device_is_unplugged check Haixia Shi
2016-02-05 21:57 ` [PATCH 2/2] drm: make unplugged flag specific to udl driver Haixia Shi
2016-02-09 12:44   ` David Herrmann
2016-02-09 20:45     ` Haixia Shi
2016-02-09 20:52       ` David Herrmann
2016-02-10 23:16   ` [PATCH v2 2/2] drm: remove drm_device_is_unplugged checks in common drm code Haixia Shi
2016-02-09 10:25 ` [PATCH 1/2] drm/msm: remove the drm_device_is_unplugged check David Herrmann
2016-02-09 13:03   ` Daniel Vetter
2016-02-09 21:05 ` [PATCH 2/2] drm: make unplugged flag specific to udl driver Haixia Shi
2016-02-10  6:27   ` Daniel Vetter
2016-02-10 12:24   ` David Herrmann
2016-02-10 20:39     ` Haixia Shi
2016-02-10 21:38       ` David Herrmann
2016-02-10 21:46         ` Stéphane Marchesin
2016-02-10 21:54           ` David Herrmann [this message]
2016-02-10 22:02             ` Stéphane Marchesin
2016-02-10 22:09               ` David Herrmann
2016-02-11  8:17               ` Daniel Vetter
2016-02-10 20:51     ` Haixia Shi
2016-02-10 21:00       ` Haixia Shi
2016-02-10 21:33         ` David Herrmann
2016-02-10 21:35       ` David Herrmann
2016-02-10 21:38         ` Haixia Shi
2016-02-10 21:40           ` David Herrmann
2016-02-10 23:18 ` [PATCH v2 2/2] drm: remove drm_device_is_unplugged checks in common drm code Haixia Shi
2016-02-11  8:19   ` Daniel Vetter
2016-02-11 10:30   ` David Herrmann
2016-02-11 19:19     ` Haixia Shi
2016-02-11 21:57     ` [PATCH v3 2/2] drm: remove drm_device_is_unplugged and related code Haixia Shi
2016-02-12  6:22       ` Daniel Vetter
2016-02-12 19:50       ` Haixia Shi
2016-02-17  0:27         ` Haixia Shi
2016-02-26 14:29         ` David Herrmann

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=CANq1E4TqNq9bZJMmMRRJEcAXRxDFyyecgzdjq94eNMNMo8x4Nw@mail.gmail.com \
    --to=dh.herrmann@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hshi@chromium.org \
    --cc=stephane.marchesin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).