From: Thomas Hellstrom <thellstrom@vmware.com>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: linux-graphics-maintainer@vmware.com,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm/vma-manager: Don't unmap COW'd pages when zapping bo ptes
Date: Wed, 20 Nov 2013 11:38:02 +0100 [thread overview]
Message-ID: <528C910A.8050107@vmware.com> (raw)
In-Reply-To: <CANq1E4R-F27s7fddDJe6c87RBXqafN78RZbYXk4=HYvJXaxayw@mail.gmail.com>
On 11/20/2013 11:14 AM, David Herrmann wrote:
> Hi
>
> On Wed, Nov 20, 2013 at 10:55 AM, Thomas Hellstrom
> <thellstrom@vmware.com> wrote:
>> Not sure if there are any user-space users of private bo mappings, but
>> if there are, or will be, zapping the COW'd pages when, for example,
>> moving a bo would confuse the user immensely since the net effect for the
>> user would be that pages written to would lose their contents.
> You're only talking about moving bos, but what happens when you evict
> a bo? You *must* clear COW mappings, too. Otherwise, they might still
> get read-access to the evicted bo.
Hmm. When I talk about COW'd pages, I mean individual anonymous pages.
If there is a COW mapping left in a VMA, it points to an anonymous page
and will never access the evicted bo.
All (read-only-enabled) ptes pointing to the evicted bo would still be
zapped, so I'm afraid I don't understand your comment?
>
> Note that we currently cause SIGBUS on access to mmap'd bos if they
> are evicted and cannot be restored (think: user-space mapped the
> VESA-FB but a real driver took over). So maybe we want two independent
> helpers here?
It shouldn't be needed.
Thanks,
Thomas
>
> Thanks
> David
>
>> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
>> ---
>> include/drm/drm_vma_manager.h | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
>> index c18a593..347077d 100644
>> --- a/include/drm/drm_vma_manager.h
>> +++ b/include/drm/drm_vma_manager.h
>> @@ -231,9 +231,9 @@ static inline void drm_vma_node_unmap(struct drm_vma_offset_node *node,
>> struct address_space *file_mapping)
>> {
>> if (file_mapping && drm_vma_node_has_offset(node))
>> - unmap_mapping_range(file_mapping,
>> - drm_vma_node_offset_addr(node),
>> - drm_vma_node_size(node) << PAGE_SHIFT, 1);
>> + unmap_shared_mapping_range
>> + (file_mapping, drm_vma_node_offset_addr(node),
>> + drm_vma_node_size(node) << PAGE_SHIFT);
>> }
>>
>> /**
>> --
>> 1.7.10.4
next prev parent reply other threads:[~2013-11-20 10:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-20 9:55 [PATCH] drm/vma-manager: Don't unmap COW'd pages when zapping bo ptes Thomas Hellstrom
2013-11-20 10:14 ` David Herrmann
2013-11-20 10:38 ` Thomas Hellstrom [this message]
2013-11-20 14:24 ` Daniel Vetter
2013-11-20 22:35 ` Thomas Hellstrom
2013-11-21 8:18 ` Daniel Vetter
2013-11-21 8:29 ` Thomas Hellstrom
2013-11-21 9:15 ` Daniel Vetter
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=528C910A.8050107@vmware.com \
--to=thellstrom@vmware.com \
--cc=dh.herrmann@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-graphics-maintainer@vmware.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.