On Thu, Nov 21, 2019 at 11:18 AM Gerd Hoffmann wrote:
>
> On Thu, Nov 21, 2019 at 09:49:53AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 21, 2019 at 09:02:59AM +0100, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > > update-object-after-move works fine.
> > > > >
> > > > > try zap mappings with
On Thu, Nov 21, 2019 at 09:49:53AM +0100, Daniel Vetter wrote:
> On Thu, Nov 21, 2019 at 09:02:59AM +0100, Gerd Hoffmann wrote:
> > Hi,
> >
> > > > update-object-after-move works fine.
> > > >
> > > > try zap mappings with madvise(dontneed) has no bad effects (after vram
> > > > move, trying
On Thu, Nov 21, 2019 at 09:02:59AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > update-object-after-move works fine.
> > >
> > > try zap mappings with madvise(dontneed) has no bad effects (after vram
> > > move, trying to force re-creating the ptes).
> >
> > Well if it's broken the zapping
On Thu, Nov 21, 2019 at 09:10:21AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > Aside: the amdgpu isn't great because it's racy, userspace could have
> > guessed the fd and already started an mmap before we managed to update
> > stuff.
>
> Can't see that race. When I read the code correctly the fd
Hi,
> Aside: the amdgpu isn't great because it's racy, userspace could have
> guessed the fd and already started an mmap before we managed to update
> stuff.
Can't see that race. When I read the code correctly the fd is created
and installed (using dma_buf_fd) only after dmabuf setup is
Hi,
> > update-object-after-move works fine.
> >
> > try zap mappings with madvise(dontneed) has no bad effects (after vram
> > move, trying to force re-creating the ptes).
>
> Well if it's broken the zapping wouldn't work :-)
>
> > didn't try the memory pressure thing yet.
>
> I'm
On Wed, Nov 20, 2019 at 2:08 PM Gerd Hoffmann wrote:
> > Ah, we're not going to replace the mapping on the dma-buf file. Only
> > the file of the vma structure. Doing the former would indeed be pretty
> > bad from a security pov.
>
> Now where do I get a filp from? Can I just call drm_open?
Hm,
Hi,
> Ah, we're not going to replace the mapping on the dma-buf file. Only
> the file of the vma structure. Doing the former would indeed be pretty
> bad from a security pov.
Now where do I get a filp from? Can I just call drm_open?
cheers,
Gerd
On Wed, Nov 20, 2019 at 1:18 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > > > I think for ttm just consistently using the one per-device mapping for
> > > > everything, with all the fake offsets, is probably the quickest route.
> > >
> > > Hmm, not clear how to fit dmabufs into this. dmabufs already
Hi,
> > > I think for ttm just consistently using the one per-device mapping for
> > > everything, with all the fake offsets, is probably the quickest route.
> >
> > Hmm, not clear how to fit dmabufs into this. dmabufs already have their
> > own file, inode and address space. I'm not sure you
On Wed, Nov 20, 2019 at 12:40 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > > Anything building on shmem helpers should be able to use
> > > obj->filp->f_mapping, right? So allocating an inode unconditionally
> > > doesn't look like a good plan.
> >
> > Not sure the shmem helpers forward the mmap to
Hi,
> > Anything building on shmem helpers should be able to use
> > obj->filp->f_mapping, right? So allocating an inode unconditionally
> > doesn't look like a good plan.
>
> Not sure the shmem helpers forward the mmap to the underlying shmem file,
> so not sure this is the greatest way
On Wed, Nov 20, 2019 at 09:05:32AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > I can see now why you want a private address space for each object.
> > > Does that imply we need an anon_inode for each gem object? Or is
> > > there some more lightweight way to do this?
> >
> > I have no idea
Hi,
> > I can see now why you want a private address space for each object.
> > Does that imply we need an anon_inode for each gem object? Or is
> > there some more lightweight way to do this?
>
> I have no idea whether we can get a address_space struct without an inode
> (and no disasters).
On Mon, Nov 18, 2019 at 11:40:26AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > > > Is any move buffer good enough to trigger this, i.e. will SYSTEM ->
> > > > > VRAM
> > > > > work too? That'll be easier because all I need to do is map the
> > > > > buffer
> > > > > to a crtc to force pinning
Hi,
> > > > Is any move buffer good enough to trigger this, i.e. will SYSTEM -> VRAM
> > > > work too? That'll be easier because all I need to do is map the buffer
> > > > to a crtc to force pinning to vram, then check if the mappings are
> > > > intact still ...
> > >
> > > I think that
On Fri, Nov 15, 2019 at 11:56 AM Gerd Hoffmann wrote:
>
> On Fri, Nov 15, 2019 at 11:18:28AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 15, 2019 at 10:37 AM Gerd Hoffmann wrote:
> > >
> > > > You need memory pressure, to force ttm to unmap the bo, not userspace.
> > > > So
> > > > roughly
> >
On Fri, Nov 15, 2019 at 11:18:28AM +0100, Daniel Vetter wrote:
> On Fri, Nov 15, 2019 at 10:37 AM Gerd Hoffmann wrote:
> >
> > > You need memory pressure, to force ttm to unmap the bo, not userspace. So
> > > roughly
> > > 1. create bo
> > > 2. mmap it through drm fd, write some stuff
> > > 3.
On Fri, Nov 15, 2019 at 10:37 AM Gerd Hoffmann wrote:
>
> > You need memory pressure, to force ttm to unmap the bo, not userspace. So
> > roughly
> > 1. create bo
> > 2. mmap it through drm fd, write some stuff
> > 3. export to dma-buf, mmap it, verify stuff is there
> > 4. create a pile more bo,
> You need memory pressure, to force ttm to unmap the bo, not userspace. So
> roughly
> 1. create bo
> 2. mmap it through drm fd, write some stuff
> 3. export to dma-buf, mmap it, verify stuff is there
> 4. create a pile more bo, mmap them write to them
> 5. once you've thrashed all of vram
On Wed, Nov 13, 2019 at 07:53:56AM -0600, Rob Herring wrote:
> On Wed, Nov 13, 2019 at 2:18 AM Daniel Vetter wrote:
> >
> > On Wed, Nov 13, 2019 at 8:39 AM Gerd Hoffmann wrote:
> > >
> > > Hi,
> > >
> > > > > > >> VRAM helpers use drm_gem_ttm_mmap(), which wraps
> > > > > > >>
On Wed, Nov 13, 2019 at 02:51:45PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > ... but after looking again I think we are all green here. Given that
> > > only self-import works we'll only see vram gem objects in the mmap code
> > > path, which should have everything set up correctly. Same goes
On Wed, Nov 13, 2019 at 2:18 AM Daniel Vetter wrote:
>
> On Wed, Nov 13, 2019 at 8:39 AM Gerd Hoffmann wrote:
> >
> > Hi,
> >
> > > > > >> VRAM helpers use drm_gem_ttm_mmap(), which wraps ttm_bo_mmap_obj().
> > > > > >> These changes should be transparent.
> > > > > >
> > > > > > There's still
Hi,
> > ... but after looking again I think we are all green here. Given that
> > only self-import works we'll only see vram gem objects in the mmap code
> > path, which should have everything set up correctly. Same goes for qxl.
> >
> > All other ttm drivers still use the old mmap code path,
On Wed, Nov 13, 2019 at 8:39 AM Gerd Hoffmann wrote:
>
> Hi,
>
> > > > >> VRAM helpers use drm_gem_ttm_mmap(), which wraps ttm_bo_mmap_obj().
> > > > >> These changes should be transparent.
> > > > >
> > > > > There's still the issue that for dma-buf mmap vs drm mmap you use
> > > > > different
Hi,
> > > I guess ... but kinda awkward to leave this issue in here, it's really
> > > surprising if you call the pte shootdown function, and it doesn't work as
> > > advertised.
> >
> > I was mainly wondering how this worked for us and how to hit it not
> > working to test fixing it.
> >
> >
Hi,
> > > >> VRAM helpers use drm_gem_ttm_mmap(), which wraps ttm_bo_mmap_obj().
> > > >> These changes should be transparent.
> > > >
> > > > There's still the issue that for dma-buf mmap vs drm mmap you use
> > > > different f_mapping, which means ttm's pte shootdown won't work
> > > >
On Tue, Nov 12, 2019 at 10:31 PM Rob Herring wrote:
>
> On Tue, Nov 12, 2019 at 1:06 PM Daniel Vetter wrote:
> >
> > On Tue, Nov 12, 2019 at 09:37:45AM -0600, Rob Herring wrote:
> > > On Tue, Nov 12, 2019 at 3:35 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, Nov 12, 2019 at 09:52:54AM +0100,
On Tue, Nov 12, 2019 at 1:06 PM Daniel Vetter wrote:
>
> On Tue, Nov 12, 2019 at 09:37:45AM -0600, Rob Herring wrote:
> > On Tue, Nov 12, 2019 at 3:35 AM Daniel Vetter wrote:
> > >
> > > On Tue, Nov 12, 2019 at 09:52:54AM +0100, Gerd Hoffmann wrote:
> > > > On Fri, Nov 08, 2019 at 05:55:28PM
On Tue, Nov 12, 2019 at 09:37:45AM -0600, Rob Herring wrote:
> On Tue, Nov 12, 2019 at 3:35 AM Daniel Vetter wrote:
> >
> > On Tue, Nov 12, 2019 at 09:52:54AM +0100, Gerd Hoffmann wrote:
> > > On Fri, Nov 08, 2019 at 05:55:28PM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 08, 2019 at
On Tue, Nov 12, 2019 at 3:35 AM Daniel Vetter wrote:
>
> On Tue, Nov 12, 2019 at 09:52:54AM +0100, Gerd Hoffmann wrote:
> > On Fri, Nov 08, 2019 at 05:55:28PM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 08, 2019 at 05:27:59PM +0100, Daniel Vetter wrote:
> > > > On Fri, Oct 25, 2019 at
On Tue, Nov 12, 2019 at 11:38:19AM +0100, Gerd Hoffmann wrote:
> On Tue, Nov 12, 2019 at 10:49:21AM +0100, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 12.11.19 um 10:32 schrieb Daniel Vetter:
> > > On Tue, Nov 12, 2019 at 10:26:44AM +0100, Thomas Zimmermann wrote:
> > >> Hi
> > >>
> > >> Am
On Tue, Nov 12, 2019 at 10:49:21AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 12.11.19 um 10:32 schrieb Daniel Vetter:
> > On Tue, Nov 12, 2019 at 10:26:44AM +0100, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 08.11.19 um 17:27 schrieb Daniel Vetter:
> >>> On Fri, Oct 25, 2019 at 09:30:42AM
Hi
Am 12.11.19 um 10:32 schrieb Daniel Vetter:
> On Tue, Nov 12, 2019 at 10:26:44AM +0100, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 08.11.19 um 17:27 schrieb Daniel Vetter:
>>> On Fri, Oct 25, 2019 at 09:30:42AM +0200, Daniel Vetter wrote:
On Thu, Oct 24, 2019 at 02:18:59PM -0500, Rob Herring
On Tue, Nov 12, 2019 at 09:52:54AM +0100, Gerd Hoffmann wrote:
> On Fri, Nov 08, 2019 at 05:55:28PM +0100, Daniel Vetter wrote:
> > On Fri, Nov 08, 2019 at 05:27:59PM +0100, Daniel Vetter wrote:
> > > On Fri, Oct 25, 2019 at 09:30:42AM +0200, Daniel Vetter wrote:
> > > > On Thu, Oct 24, 2019 at
On Tue, Nov 12, 2019 at 10:26:44AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 08.11.19 um 17:27 schrieb Daniel Vetter:
> > On Fri, Oct 25, 2019 at 09:30:42AM +0200, Daniel Vetter wrote:
> >> On Thu, Oct 24, 2019 at 02:18:59PM -0500, Rob Herring wrote:
> >>> Commit c40069cb7bd6 ("drm: add mmap()
Hi
Am 08.11.19 um 17:27 schrieb Daniel Vetter:
> On Fri, Oct 25, 2019 at 09:30:42AM +0200, Daniel Vetter wrote:
>> On Thu, Oct 24, 2019 at 02:18:59PM -0500, Rob Herring wrote:
>>> Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
>>> introduced a GEM object mmap() hook which is
On Fri, Nov 08, 2019 at 05:55:28PM +0100, Daniel Vetter wrote:
> On Fri, Nov 08, 2019 at 05:27:59PM +0100, Daniel Vetter wrote:
> > On Fri, Oct 25, 2019 at 09:30:42AM +0200, Daniel Vetter wrote:
> > > On Thu, Oct 24, 2019 at 02:18:59PM -0500, Rob Herring wrote:
> > > > Commit c40069cb7bd6 ("drm:
On Fri, Nov 08, 2019 at 05:27:59PM +0100, Daniel Vetter wrote:
> On Fri, Oct 25, 2019 at 09:30:42AM +0200, Daniel Vetter wrote:
> > On Thu, Oct 24, 2019 at 02:18:59PM -0500, Rob Herring wrote:
> > > Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
> > > introduced a GEM object
On Fri, Oct 25, 2019 at 09:30:42AM +0200, Daniel Vetter wrote:
> On Thu, Oct 24, 2019 at 02:18:59PM -0500, Rob Herring wrote:
> > Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
> > introduced a GEM object mmap() hook which is expected to subtract the
> > fake offset from vm_pgoff.
On Thu, Oct 24, 2019 at 02:18:59PM -0500, Rob Herring wrote:
> Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
> introduced a GEM object mmap() hook which is expected to subtract the
> fake offset from vm_pgoff. However, for mmap() on dmabufs, there is not
> a fake offset.
>
> To
On Thu, Oct 24, 2019 at 02:18:59PM -0500, Rob Herring wrote:
> Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
> introduced a GEM object mmap() hook which is expected to subtract the
> fake offset from vm_pgoff. However, for mmap() on dmabufs, there is not
> a fake offset.
>
> To
Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
introduced a GEM object mmap() hook which is expected to subtract the
fake offset from vm_pgoff. However, for mmap() on dmabufs, there is not
a fake offset.
To fix this, let's always call mmap() object callback with an offset of 0,
43 matches
Mail list logo
