Quoting Christian König (2019-08-21 13:31:42)
> Add a new dma_resv_prune_fences() function to improve memory management.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c | 37 ++
> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 3 +-
>
be the
> only thing reserving buffers (in the ttm/dma_resv sense) in that
> code. So looks safe.
>
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> everywhere and needs to be fix
The dma-fence selftest uses an on-stack timer that requires explicit
annotation for debugobjects.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/dma-buf/st-dma-fence.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma
Use the %zu format specifier for a size_t returned by sizeo.
Reported-by: kbuild-...@01.org
Signed-off-by: Chris Wilson
---
drivers/dma-buf/st-dma-fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-fence.c
index
Include the DMABUF_SELFTESTS as part of the standard build for IGT, so
that they can be run by igt/dmabuf
Testcase: igt/dmabuf
Signed-off-by: Chris Wilson
Cc: Tomi Sarvela
---
drivers/gpu/drm/i915/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915
Quoting Chris Wilson (2019-08-19 10:59:26)
> In light of recent review slip ups, the absence of a suite of tests for
> dma-buf became apparent. Given the current plethora of testing
> frameworks, opt for one already in use by Intel's CI and so allow easy
> hook up into igt.
>
>
Quoting Masanari Iida (2019-08-19 14:05:52)
> This patch fix a spelling typo in test-drm_mm.c
>
> Signed-off-by: Masanari Iida
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freede
that we get a signal when the cb_list is complete,
useful in a few cases that need to serialise against the cb_list.
Suggested-by: Christian König
Signed-off-by: Chris Wilson
Cc: Christian König
---
drivers/dma-buf/dma-fence.c | 41 +++---
drivers/dma-buf/st-dma
Exercise the dma-fence API exported to drivers.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/dma-buf/Makefile | 5 +-
drivers/dma-buf/selftests.h| 1 +
drivers/dma-buf/st-dma-fence.c | 571 +
3 files changed, 576 insertions(+), 1
of
selftests and their subtest. The names of the selftests are put into the
modinfo as parameters so that igt can identify each, and run them
independently, principally for ease of error reporting.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Tomi Sarvela
---
drivers/dma-buf/Kconfig | 5
as no references are held can be replaced by the rcu_head.
By reusing the union for the timestamp, we squeeze the base dma_fence
struct to 64 bytes on x86-64.
v2: Sort the union chronologically
Suggested-by: Christian König
Signed-off-by: Chris Wilson
Cc: Christian König
---
drivers/dma-buf/dma-fence.c
Quoting Koenig, Christian (2019-08-17 16:20:12)
> Am 17.08.19 um 16:47 schrieb Chris Wilson:
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index 89d96e3e6df6..2c21115b1a37 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/
error so expected to be very unlikely.
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Daniel Vetter
---
drivers/dma-buf/dma-fence.c | 44 ++---
1 file changed, 12 insertions(+), 32 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma
Rearrange the couple of 32-bit atomics hidden amongst the field of
pointers that unnecessarily caused the compiler to insert some padding,
shrinks the size of the base struct dma_fence from 80 to 72 bytes on
x86-64.
Signed-off-by: Chris Wilson
Cc: Christian König
Reviewed-by: Christian König
of
selftests and their subtest. The names of the selftests are put into the
modinfo as parameters so that igt can identify each, and run them
independently, principally for ease of error reporting.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/dma-buf/Kconfig | 5 ++
drivers/dma-buf
Before we notify the fence signal callback, we remove the cb from the
list. However, since we are processing the entire list from underneath
the spinlock, we do not need to individual delete each element, but can
simply reset the link and the entire list.
Signed-off-by: Chris Wilson
Cc: Daniel
to notify the callbacks on signaling. As such, we will
always need to take the spinlock and dma_fence_signal() effectively
becomes a clone of dma_fence_signal_locked().
v2: Update the test_and_set_bit() before entering the spinlock.
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Daniel Vetter
Exercise the dma-fence API exported to drivers.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/dma-buf/Makefile | 5 +-
drivers/dma-buf/selftests.h| 1 +
drivers/dma-buf/st-dma-fence.c | 571 +
3 files changed, 576 insertions(+), 1
as no references are held can be replaced by the rcu_head.
By reusing the union for the timestamp, we squeeze the base dma_fence
struct to 64 bytes on x86-64.
Suggested-by: Christian König
Signed-off-by: Chris Wilson
Cc: Christian König
---
drivers/dma-buf/dma-fence.c | 16
Quoting Koenig, Christian (2019-08-17 12:42:48)
> Am 17.08.19 um 13:39 schrieb Chris Wilson:
> > Rearrange the couple of 32-bit atomics hidden amongst the field of
> > pointers that unnecessarily caused the compiler to insert some padding,
> > shrinks the size of the base str
Rearrange the couple of 32-bit atomics hidden amongst the field of
pointers that unnecessarily caused the compiler to insert some padding,
shrinks the size of the base struct dma_fence from 80 to 72 bytes on
x86-64.
Signed-off-by: Chris Wilson
Cc: Christian König
---
include/linux/dma-fence.h
Quoting Daniel Vetter (2019-08-16 20:07:24)
> On Fri, Aug 16, 2019 at 9:02 PM Koenig, Christian
> wrote:
> >
> > Am 16.08.19 um 17:21 schrieb Chris Wilson:
> > > Currently dma_fence_signal() tries to avoid the spinlock and only takes
> > > it if absolutel
to notify the callbacks on signaling. As such, we will
always need to take the spinlock and dma_fence_signal() effectively
becomes a clone of dma_fence_signal_locked().
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Daniel Vetter
---
drivers/dma-buf/dma-fence.c | 19 +--
1
Before we notify the fence signal callback, we remove the cb from the
list. However, since we are processing the entire list from underneath
the spinlock, we do not need to individual delete each element, but can
simply reset the link and the entire list.
Signed-off-by: Chris Wilson
Cc: Daniel
Quoting Maxime Ripard (2019-08-16 12:32:01)
> Hi Daniel, Dave,
>
> Here's this week drm-misc-next PR.
>
> Maxime
>
> drm-misc-next-2019-08-16:
> drm-misc-next for 5.4:
>
> UAPI Changes:
>
> Cross-subsystem Changes:
>
> Core Changes:
> - dma-buf: add reservation_object_fences helper, relax
Quoting Chris Wilson (2019-08-15 20:03:13)
> Quoting Daniel Vetter (2019-08-15 19:48:42)
> > On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson
> > wrote:
> > > Quoting Daniel Vetter (2019-08-14 18:20:53)
> > > > On Sun, Aug 11, 2019 at 10:15:23AM +010
Quoting Daniel Vetter (2019-08-15 19:48:42)
> On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson wrote:
> > Quoting Daniel Vetter (2019-08-14 18:20:53)
> > > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote:
> > > > Now that dma_fence_signal alwa
Quoting Daniel Vetter (2019-08-14 18:20:53)
> On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote:
> > Now that dma_fence_signal always takes the spinlock to flush the
> > cb_list, simply take the spinlock and call dma_fence_signal_locked() to
> > avoid code repetitio
Quoting Koenig, Christian (2019-08-14 18:58:32)
> Am 14.08.19 um 19:48 schrieb Chris Wilson:
> > Quoting Chris Wilson (2019-08-14 18:38:20)
> >> Quoting Chris Wilson (2019-08-14 18:22:53)
> >>> Quoting Chris Wilson (2019-08-14 18:06:18)
> >>>&
Quoting Chris Wilson (2019-08-14 19:24:01)
> This reverts
> 67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
> dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
> 0e1d8083bddb ("dma-buf: further relax reservation_object_add_sh
hat no
fence was changed in the dma_resv after a read (or full) memory barrier.
Signed-off-by: Chris Wilson
Cc: Chris Wilson
Cc: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 31 -
drivers/dma-buf/dma-resv.c| 109 -
.../gpu/drm
Quoting Chris Wilson (2019-08-14 19:22:54)
You saw nothing; wrong experimental branch.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
---
drivers/gpu/drm/i915/Makefile | 7 +
drivers/gpu/drm/i915/ttm/Makefile | 5 +
drivers/gpu/drm/i915/ttm/i915_ttm_drv.c | 4 +
drivers/gpu/drm/i915/ttm/i915_ttm_drv.h | 12 ++
drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c | 174 ++
Quoting Chris Wilson (2019-08-14 18:38:20)
> Quoting Chris Wilson (2019-08-14 18:22:53)
> > Quoting Chris Wilson (2019-08-14 18:06:18)
> > > Quoting Chris Wilson (2019-08-14 17:42:48)
> > > > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > >
Quoting Chris Wilson (2019-08-14 18:22:53)
> Quoting Chris Wilson (2019-08-14 18:06:18)
> > Quoting Chris Wilson (2019-08-14 17:42:48)
> > > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > > > + } while (rcu_access_pointer(obj->fence_excl) !
Quoting Chris Wilson (2019-08-14 18:06:18)
> Quoting Chris Wilson (2019-08-14 17:42:48)
> > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > > + } while (rcu_access_pointer(obj->fence_excl) != *excl);
> > >
> > > What if someone i
Quoting Daniel Vetter (2019-08-14 18:06:26)
> On Wed, Aug 14, 2019 at 05:42:48PM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2019-08-14 16:39:08)
[snip]
> > > > > > if (old)
> > > > > > - old->shared_count
Quoting Chris Wilson (2019-08-14 17:42:48)
> Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > + } while (rcu_access_pointer(obj->fence_excl) != *excl);
> >
> > What if someone is real fast (like really real fast) and recycles the
> > exclusive f
Quoting Daniel Vetter (2019-08-14 16:39:08)
> Sorry I burried myself in some other stuff ...
>
> On Sat, Aug 10, 2019 at 12:51:00PM +0200, Christian König wrote:
> > Am 07.08.19 um 16:17 schrieb Chris Wilson:
> > > Quoting Christian König (2019-08-07 14:53:12)
> &
Quoting Koenig, Christian (2019-08-13 07:59:28)
> Am 12.08.19 um 16:53 schrieb Chris Wilson:
> > Quoting Koenig, Christian (2019-08-12 15:50:59)
> >> Am 12.08.19 um 16:43 schrieb Chris Wilson:
> >>> Quoting Koenig, Christian (2019-08-12 15:34:32)
> >>>&
lla: https://bugs.freedesktop.org/show_bug.cgi?id=111381
Fixes: d3862e44daa7 ("dma-buf/sw-sync: Fix locking around sync_timeline lists")
References: 0e2f733addbf ("dma-buf: make dma_fence structure a bit smaller v2")
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Pa
Quoting Koenig, Christian (2019-08-12 15:50:59)
> Am 12.08.19 um 16:43 schrieb Chris Wilson:
> > Quoting Koenig, Christian (2019-08-12 15:34:32)
> >> Am 10.08.19 um 17:34 schrieb Chris Wilson:
> >>> Move the duplicated code within dma-fence.c into the header for wid
Quoting Koenig, Christian (2019-08-12 15:34:32)
> Am 10.08.19 um 17:34 schrieb Chris Wilson:
> > Move the duplicated code within dma-fence.c into the header for wider
> > reuse. In the process apply a small micro-optimisation to only prune the
> > fence->cb_list once
Same as for the individual fences, we want to report the actual status
of the fence when queried.
Reported-by: Petri Latvala
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Petri Latvala
Reviewed-by: Matthew Auld
---
drivers/dma-buf/sync_file.c | 2 +-
1 file changed
the signal cb.
v5: Use cmpxchg to only set the error once before using a nifty idea by
Christian to avoid changing the status after emitting the signal.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
Reviewed-by: Christian König
---
drivers/dma-buf/dma-fence
the signal cb.
v5: Use cmpxchg to only set the error once before using a nifty idea by
Christian to avoid changing the status after emitting the signal.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
Reviewed-by: Christian König
---
drivers/dma-buf/dma-fence
the signal cb.
v5: Use cmpxchg to only set the error once before using a nifty idea by
Christian to avoid changing the status after emitting the signal.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
---
drivers/dma-buf/dma-fence-array.c | 32
the signal cb.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
---
drivers/dma-buf/dma-fence-array.c | 37 ++-
include/linux/dma-fence-array.h | 2 ++
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma
When one of the array of fences is signaled, propagate its errors to the
parent fence-array (keeping the first error to be raised).
v2: Opencode cmpxchg_local to avoid compiler freakout.
v3: Be careful not to flag an error if we race against signal-on-any
Signed-off-by: Chris Wilson
Cc: Sumit
Quoting Koenig, Christian (2019-08-11 09:58:31)
> Am 10.08.19 um 17:34 schrieb Chris Wilson:
> > + /*
> > + * Propagate the first error reported by any of our fences, but only
> > + * before we ourselves are signaled.
> > + */
> > +
lation), and overwhelmingly agreeing with
the motivation,
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Now that dma_fence_signal always takes the spinlock to flush the
cb_list, simply take the spinlock and call dma_fence_signal_locked() to
avoid code repetition.
Suggested-by: Christian König
Signed-off-by: Chris Wilson
Cc: Christian König
---
drivers/dma-buf/dma-fence.c | 32
Move the duplicated code within dma-fence.c into the header for wider
reuse. In the process apply a small micro-optimisation to only prune the
fence->cb_list once rather than use list_del on every entry.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/dma-buf/Makef
always notify the callbacks.
The cost is that dma_fence_signal() must always acquire the spinlock to
ensure that the cb_list is flushed.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/dma-fence.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c
Same as for the individual fences, we want to report the actual status
of the fence when queried.
Reported-by: Petri Latvala
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Petri Latvala
---
drivers/dma-buf/sync_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
When one of the array of fences is signaled, propagate its errors to the
parent fence-array (keeping the first error to be raised).
v2: Opencode cmpxchg_local to avoid compiler freakout.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
---
drivers/dma-buf/dma-fence-array.c
Quoting Matthew Auld (2019-08-09 23:26:42)
> From: Abdiel Janulgue
>
> Returns the available memory region areas supported by the HW.
And how does one use this information?
How does this relate to the information presented by Vulkan or OpenCL
Testcase: igt/...?
New uAPI should always come
Quoting Matthew Auld (2019-08-09 23:26:41)
> From: Abdiel Janulgue
>
> This call will specify which memory region an object should be placed.
>
> Note that changing the object's backing storage should be immediately
> done after an object is created or if it's not yet in use, otherwise
> this
Quoting Matthew Auld (2019-08-09 23:26:40)
> We are going want to able to move objects between different regions
> like system memory and local memory. In the future everything should
> be just another region.
>
> Signed-off-by: Matthew Auld
> Signed-off-by: Abdiel Janulgue
> Signed-off-by: CQ
Quoting Matthew Auld (2019-08-09 23:26:39)
> From: Abdiel Janulgue
>
> If there is no aperture we can't use map_gtt to map dumb buffers, so we
> need a cpu-map based path to do it. We prefer map_gtt on platforms that
> do have aperture.
>
> Signed-off-by: Abdiel Janulgue
> Cc: Daniele Ceraolo
Quoting Matthew Auld (2019-08-09 23:26:38)
> -void __i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
> +static vm_fault_t i915_gem_fault_cpu(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *area = vmf->vma;
> + struct i915_mmap_offset *priv = area->vm_private_data;
>
Quoting Matthew Auld (2019-08-09 23:26:36)
> From: Abdiel Janulgue
>
> Add a new CPU mmap implementation that allows multiple fault handlers
> that depends on the object's backing pages.
>
> Note that we multiplex mmap_gtt and mmap_offset through the same ioctl,
> and use the zero extending
Quoting Matthew Auld (2019-08-09 23:26:35)
> From: Abdiel Janulgue
>
> This enables us to store extra data within vma->vm_private_data and assign
> the pagefault ops for each mmap instance.
>
> We replace the core drm_gem_mmap implementation to overcome the limitation
> in having only a single
Quoting Matthew Auld (2019-08-09 23:26:34)
> From: CQ Tang
>
> Signed-off-by: CQ Tang
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gem.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index
Quoting Matthew Auld (2019-08-09 23:26:33)
> From: Michal Wajdeczko
>
> HWS placement restrictions can't just rely on HAS_LLC flag.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> 1 file changed, 1 insertion(+), 1
Quoting Matthew Auld (2019-08-09 23:26:32)
> From: Daniele Ceraolo Spurio
>
> If the aperture is not available in HW we can't use a ggtt slot and wc
> copy, so fall back to regular kmap.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: Abdiel Janulgue
> ---
>
Quoting Matthew Auld (2019-08-09 23:26:29)
> From: Daniele Ceraolo Spurio
>
> Skip both setup and cleanup of the aperture mapping if the HW doesn't
> have an aperture bar.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 36
Quoting Matthew Auld (2019-08-09 23:26:25)
> From: Abdiel Janulgue
>
> Nothing to enumerate yet...
>
> Signed-off-by: Abdiel Janulgue
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> drivers/gpu/drm/i915/i915_gem_gtt.c
Quoting Matthew Auld (2019-08-09 23:26:22)
> @@ -1017,10 +1020,14 @@ static void reloc_cache_reset(struct reloc_cache
> *cache)
> } else {
> struct i915_ggtt *ggtt = cache_to_ggtt(cache);
>
> - intel_gt_flush_ggtt_writes(ggtt->vm.gt);
> + if
Quoting Matthew Auld (2019-08-09 23:26:18)
> +struct i915_vma *intel_emit_vma_copy_blt(struct intel_engine_pool_node **p,
> +struct intel_context *ce,
> +struct i915_vma *src,
> +
ed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Matthew Auld (2019-08-09 23:26:13)
> @@ -1369,6 +1371,8 @@ struct drm_i915_private {
> */
> resource_size_t stolen_usable_size; /* Total size minus reserved
> ranges */
>
> + struct intel_memory_region *regions[INTEL_MEMORY_UKNOWN];
If there was ever an
Quoting Matthew Auld (2019-08-09 23:26:12)
> From: Abdiel Janulgue
>
> Exposes available regions for the platform. Shared memory will
> always be available.
>
> Signed-off-by: Abdiel Janulgue
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
>
Quoting Matthew Auld (2019-08-09 23:26:11)
> Volatile objects are marked as DONTNEED while pinned, therefore once
> unpinned the backing store can be discarded.
Do we also have the concept of non-volatile backing store, e.g. shmemfs
(non-volatile) vs stolen (volatile)?
-Chris
hat's quite a nice generalisation.
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Matthew Auld (2019-08-09 23:26:10)
> Some objects may need to be allocated as a continuous block, thinking
> ahead the various kernel io_mapping interfaces seem to expect it.
But we could always use scattergather over top...
> @@ -98,10 +101,12 @@ i915_gem_object_get_pages_buddy(struct
Quoting Matthew Auld (2019-08-09 23:26:09)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 6ff01a404346..8735dea74809 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1105,6 +1105,23 @@
Quoting Matthew Auld (2019-08-09 23:26:08)
> diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
> b/drivers/gpu/drm/i915/intel_memory_region.c
> new file mode 100644
> index ..ef12e462acb8
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_memory_region.c
> @@ -0,0 +1,175 @@
>
Quoting Lionel Landwerlin (2019-08-09 13:38:57)
> On 09/08/2019 14:58, Chris Wilson wrote:
> > Not atomic (the u64 write should really be to avoid total corruption)
> > and nothing prevents userspace from racing. How safe is that in the
> > overall design?
>
>
&
Quoting Chris Wilson (2019-08-09 12:58:51)
> Quoting Lionel Landwerlin (2019-08-09 12:30:30)
> > + if (flags & I915_DRM_SYNCOBJ_BINARY_ITEM_VALUE_READ) {
> > + copy_to_user([i],
> > [i]->binary_payload, sizeof(values[i]));
> >
Quoting Lionel Landwerlin (2019-08-09 12:30:30)
> +int drm_syncobj_binary_ioctl(struct drm_device *dev, void *data,
> +struct drm_file *file_private)
> +{
> + struct drm_syncobj_binary_array *args = data;
> + struct drm_syncobj **syncobjs;
> + u32
Quoting Lionel Landwerlin (2019-08-09 12:30:30)
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 8a5b2f8f8eb9..1ce83853f997 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -785,6 +785,22 @@ struct drm_syncobj_timeline_array {
> __u32 pad;
>
Quoting Hugh Dickins (2019-08-08 16:54:16)
> On Thu, 8 Aug 2019, Al Viro wrote:
> > On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> > > On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > > > Though personally I'm averse to managing "f"objects through
> > > >
Quoting Dan Carpenter (2019-08-08 11:32:36)
> We can't free "workload" until after the printk or it's a use after
> free.
>
> Fixes: 2089a76ade90 ("drm/i915/gvt: Checking workload's gma earlier")
> Signed-off-by: Dan Carpenter
That's the simpler patch
Quoting Christian König (2019-08-07 14:53:11)
> Other cores don't busy wait any more and we removed the last user of checking
> the seqno for changes. Drop updating the number for shared fences altogether.
>
> Signed-off-by: Christian König
Reviewed-by: Chris Wilson
> ---
>
Quoting Christian König (2019-08-07 14:53:10)
> Instead of open coding the sequence loop use the new helper.
>
> Signed-off-by: Christian König
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.
an König
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
2 *shared_count)
> {
> - unsigned int seq;
> -
> do {
> - seq = read_seqcount_begin(>seq);
> *excl = rcu_dereference(obj->fence_excl);
> *list = rcu_dereference(obj->fence);
> *shared_count = *list ?
No one should be adding to the cb_list
that they don't themselves hold a reference for, this only now makes for
a much more spectacular use-after-free. :)
> Signed-off-by: Christian König
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
Quoting Chris Wilson (2019-08-07 13:32:15)
> Quoting Dan Carpenter (2019-08-07 13:28:32)
> > There were several places which check for NULL when they should have
> > been checking for IS_ERR().
> >
> > Fixes: d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier
n Carpenter
Oops,
Reviewed-by: Chris Wilson
Thanks,
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Christian König (2019-08-07 13:08:38)
> Am 06.08.19 um 21:57 schrieb Chris Wilson:
> > If we add to shared-list during the read, ... Hmm, actually we should
> > return num_list, i.e.
> >
> > do {
> > *list = rcu_dereference(obj->fence);
> >
Quoting Christian König (2019-08-06 16:01:34)
> The only remaining use for this is to protect against setting a new exclusive
> fence while we grab both exclusive and shared. That can also be archived by
> looking if the exclusive fence has changed or not after completing the
> operation.
>
>
RCU_INIT_POINTER(fobj->shared[i], fence);
> /* pointer update must be visible before we extend the shared_count */
> smp_store_mb(fobj->shared_count, count);
Yup, that's all the mb rules we need to apply for the rcu readers to see
a consistent view.
Reviewed-
do hold rcu_read_lock.
I didn't check all the conversions, just stared at the heart of the
problem.
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Christian König (2019-08-06 16:01:32)
> We can add the exclusive fence to the list after making sure we got
> a consistent state.
>
> Signed-off-by: Christian König
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing li
Quoting Christian König (2019-08-06 16:01:30)
> Instead of open coding the sequence loop use the new helper.
I've missed something. What reservation_object_fences()?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
f-by: Christian König
Reviewed-by: Chris Wilson
I like keeping the reminder about the lack of pruning on idle objects :)
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
y own bug... But if we accept it is worth preventing here then the
only odd one out is on a reservation_object_copy_fences() error path,
where the extra delay shouldn't be an issue.
So to double-RCU defer on reservation_object_fini() or not?
For the rest of the mechanical changes,
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
der will see a refcount==0 fence and restart, whereas by
dropping the ref later, that reader has a better chance of getting to
the end before noticing the change.
> Signed-off-by: Christian König
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing
401 - 500 of 3670 matches
Mail list logo
