v2: Add a couple more variations for degenerate ww_mutex, decrease
timeouts
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/locking/Makefile| 1 +
kernel/locking/test-ww_mutex.c | 140
Nicolai Hähnle was looking into a deadlock within ww_mutexes (that has
been fixed by Peter's mutex rewrite) and to support his changes, I
thought it was be useful to have a small validation suite for ww_mutex.
-Chris
Although ww_mutexes degenerate into mutexes, it would be useful to
torture the deadlock handling between multiple ww_mutexes in addition to
torturing the regular mutexes.
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel
710 ("mutex: Move ww_mutex definitions to ww_mutex.h")
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Cc: Peter Zijlstra
Cc: Ingo Molnar
---
include/linux/ww_mutex.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/ww_mutex.h b/include/linux/ww_
v2: Use both inorder and reorder locking strategies
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/locking/test-ww_mutex.c | 254 +
1 file changed, 254 insertions(+)
diff --git
Add the minimal test running (modprobe test-ww_mutex) to the kselftests
CI framework.
Signed-off-by: Chris Wilson
Cc: Shuah Khan
Cc: Peter Zijlstra
Cc: Ingo Molnar
---
tools/testing/selftests/locking/ww_mutex.sh | 10 ++
1 file changed, 10 insertions(+)
create mode 100755 tools
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Maarten Lankhorst <d...@mblankhorst.nl>
Cc: Nicolai Hähnle <nhaeh...@gmail.com>
---
kerne
Check that ww_mutexes can detect cyclic deadlocks (generalised ABBA
cycles) and resolve them by lock reordering.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Maarten Lankhorst <d.
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/locking/test-ww_mutex.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test
Check that ww_mutexes can detect cyclic deadlocks (generalised ABBA
cycles) and resolve them by lock reordering.
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/locking/test-ww_mutex.c | 115
ntinue;
> + }
> +
> + list_add_tail(>list, >list);
> + return 0;
> + }
> + }
> +
> + list_add_tail(>list, >wait_list);
> + return 0;
> +}
--
Chris Wilson, Intel Open Source Technology Centre
list_add_tail(>list, >list);
> + return 0;
> + }
> + }
> +
> + list_add_tail(>list, >wait_list);
> + return 0;
> +}
--
Chris Wilson, Intel Open Source Technology Centre
king
everything, slowlock the contended lock, then lock everything else.
I have now a second worker that follows the reordering method as well.
(As well as a test that slowlock after the ABBA deadlock detection
resolves the locking order.)
If you have a sketch of something else to try, I'll add it.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
king
everything, slowlock the contended lock, then lock everything else.
I have now a second worker that follows the reordering method as well.
(As well as a test that slowlock after the ABBA deadlock detection
resolves the locking order.)
If you have a sketch of something else to try, I'll add it.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Wed, Nov 30, 2016 at 12:52:28PM +0100, Nicolai Hähnle wrote:
> On 30.11.2016 10:40, Chris Wilson wrote:
> >On Mon, Nov 28, 2016 at 01:20:01PM +0100, Nicolai Hähnle wrote:
> >>I've included timings taken from a contention-heavy stress test to some of
> >>the patche
On Wed, Nov 30, 2016 at 12:52:28PM +0100, Nicolai Hähnle wrote:
> On 30.11.2016 10:40, Chris Wilson wrote:
> >On Mon, Nov 28, 2016 at 01:20:01PM +0100, Nicolai Hähnle wrote:
> >>I've included timings taken from a contention-heavy stress test to some of
> >>the patche
> improve the wall time quite a bit.
In looking at your contention scenarios, what was the average/max list
size? Just wondering if it makes sense to use an rbtree + first_waiter
instead of a sorted list from the start.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
> improve the wall time quite a bit.
In looking at your contention scenarios, what was the average/max list
size? Just wondering if it makes sense to use an rbtree + first_waiter
instead of a sorted list from the start.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Maarten Lankhorst <d...@mblankhorst.nl>
Cc: Nicolai Hähnle <nhaeh...@gmail.com>
---
kernel/locking/test-ww_mutex.c | 39 +++
1 fil
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/locking/test-ww_mutex.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c
index
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Maarten Lankhorst <d...@mblankhorst.nl>
Cc: Nicolai Hähnle <nhaeh...@gmail.com>
---
kernel/locking/test-ww_mutex.c | 75 ++
1 fil
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/locking/test-ww_mutex.c | 75 ++
1 file changed, 75 insertions(+)
diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c
index
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Maarten Lankhorst <d...@mblankhorst.nl>
Cc: Nicolai Hähnle <nhaeh...@gmail.com>
---
kernel/locking/test-ww_mutex.c | 134 +
1 file
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Maarten Lankhorst <d...@mblankhorst.nl>
Cc: Nicolai Hähnle <nhaeh...@gmail.com>
---
kernel/locking/Makefile| 1 +
kernel/locki
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/locking/test-ww_mutex.c | 134 +
1 file changed, 134 insertions(+)
diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c
index
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/locking/Makefile| 1 +
kernel/locking/test-ww_mutex.c | 137 +
lib/Kconfig.debug | 10 +++
3 files changed, 148 insertions
of EXPORT_SYMBOL_GPL for use by modules.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: "Du, Changbin" <changbin...@intel.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Christian Borntraeger <borntrae...@de.ibm.com
of EXPORT_SYMBOL_GPL for use by modules.
Signed-off-by: Chris Wilson
Cc: "Du, Changbin"
Cc: Andrew Morton
Cc: Thomas Gleixner
Cc: Christian Borntraeger
Cc: intel-...@lists.freedesktop.org
---
lib/debugobjects.c | 8
1 file changed, 8 insertions(+)
diff --git a/lib/debugobjec
ks it,
> depending in how fast I switch. (Yes, strange).
The fix should have landed in v4.9-rc5
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
ks it,
> depending in how fast I switch. (Yes, strange).
The fix should have landed in v4.9-rc5
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
m_device *dev,
> }
> EXPORT_SYMBOL(drm_atomic_clean_old_fb);
>
> +static struct dma_fence *get_crtc_fence(struct drm_crtc *crtc)
> +{
return drm_crtc_fence_create(crtc);
(or possibly, drm_crtc_fence_get(), drm_crtc_timeline_advance() or
somesuch if we need finer control over fence_seqno)
Or if you want to embed it,
struct our_fence *fence;
fence = kzalloc(sizeof(*fence), GFP_KERNEL);
if (!fence)
return NULL;
drm_crtc_fence_init(crtc, >base);
return >base;
Looks tidier than dumping all the fence construction here
> + dma_fence_init(fence, _crtc_fence_ops, >fence_lock,
> +crtc->fence_context, ++crtc->fence_seqno);
--
Chris Wilson, Intel Open Source Technology Centre
}
> - }
> -
> - e->base.fence = fence;
> -
> return e;
> }
>
> @@ -1793,6 +1809,165 @@ void drm_atomic_clean_old_fb(struct drm_device *dev,
> }
> EXPORT_SYMBOL(drm_atomic_clean_old_fb);
>
> +static struct dma_fence *get_crtc_fence(struct drm_crtc *crtc)
> +{
return drm_crtc_fence_create(crtc);
(or possibly, drm_crtc_fence_get(), drm_crtc_timeline_advance() or
somesuch if we need finer control over fence_seqno)
Or if you want to embed it,
struct our_fence *fence;
fence = kzalloc(sizeof(*fence), GFP_KERNEL);
if (!fence)
return NULL;
drm_crtc_fence_init(crtc, >base);
return >base;
Looks tidier than dumping all the fence construction here
> + dma_fence_init(fence, _crtc_fence_ops, >fence_lock,
> +crtc->fence_context, ++crtc->fence_seqno);
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Nov 15, 2016 at 05:42:35PM +0900, Gustavo Padovan wrote:
> 2016-11-15 Chris Wilson <ch...@chris-wilson.co.uk>:
>
> > On Tue, Nov 15, 2016 at 10:57:35AM +0900, Gustavo Padovan wrote:
> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> >
On Tue, Nov 15, 2016 at 05:42:35PM +0900, Gustavo Padovan wrote:
> 2016-11-15 Chris Wilson :
>
> > On Tue, Nov 15, 2016 at 10:57:35AM +0900, Gustavo Padovan wrote:
> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > index 11780a9..0870de1
On Tue, Nov 15, 2016 at 08:25:55AM +, Chris Wilson wrote:
> On Tue, Nov 15, 2016 at 10:57:35AM +0900, Gustavo Padovan wrote:
> > /**
> > + * dma_crtc_fence_ops - fence ops for the drm_crtc timeline
> > + *
> > + * It contains the dma_fence_ops that should
On Tue, Nov 15, 2016 at 08:25:55AM +, Chris Wilson wrote:
> On Tue, Nov 15, 2016 at 10:57:35AM +0900, Gustavo Padovan wrote:
> > /**
> > + * dma_crtc_fence_ops - fence ops for the drm_crtc timeline
> > + *
> > + * It contains the dma_fence_ops that should
nitializing fences.
> + */
> +extern const struct dma_fence_ops drm_crtc_fence_ops;
> +
> +static inline struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
> +{
> + BUG_ON(fence->ops != _crtc_fence_ops);
> + return container_of(fence->lock, struct drm_crtc, fence_lock);
> +}
If you are planning to export this for use by drivers, you are missing
the EXPORT_SYMBOL(drm_crtc_fence_ops).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
nitializing fences.
> + */
> +extern const struct dma_fence_ops drm_crtc_fence_ops;
> +
> +static inline struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
> +{
> + BUG_ON(fence->ops != _crtc_fence_ops);
> + return container_of(fence->lock, struct drm_crtc, fence_lock);
> +}
If you are planning to export this for use by drivers, you are missing
the EXPORT_SYMBOL(drm_crtc_fence_ops).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
ing a page, unsigned int is
> wide enough.
>
> Also converts callers which were using unsigned long locally
> with the lower_32_bits annotation to make it explicitly
> clear what is happening.
>
> v2: Use offset_in_page. (Chris Wilson)
>
> Signed-off-by: Tvrtko Ursul
t is
> wide enough.
>
> Also converts callers which were using unsigned long locally
> with the lower_32_bits annotation to make it explicitly
> clear what is happening.
>
> v2: Use offset_in_page. (Chris Wilson)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Masahiro Yamada
> Introduce and export the __sg_alloc_table_from_pages function
> which will allow it that control.
>
> v2: Reorder parameters. (Chris Wilson)
> v3: Fix incomplete reordering in v2.
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> Cc: Masahiro Yamada <yamada.m
lloc_table_from_pages function
> which will allow it that control.
>
> v2: Reorder parameters. (Chris Wilson)
> v3: Fix incomplete reordering in v2.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Masahiro Yamada
> Cc: linux-kernel@vger.kernel.org
> Cc: Chris Wilson
Works for
helper to i915_sg_segment_size and fix swiotlb override.
> * Commit message update.
>
> v3:
> * Actually include the swiotlb override fix.
>
> v4:
> * Regroup parameters a bit. (Chris Wilson)
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> Cc: Ch
fix swiotlb override.
> * Commit message update.
>
> v3:
> * Actually include the swiotlb override fix.
>
> v4:
> * Regroup parameters a bit. (Chris Wilson)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> Reviewed-by: Chris Wilson (v2)
(bump)
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
t sg_table *sgt, struct page **pages,
> + unsigned int n_pages, unsigned int offset,
> + unsigned long size, gfp_t gfp_mask,
> + unsigned int max_segment);
Just the question of parameter order, I like gfp_t last :)
And I think offset / size / max_segment tie together.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
n_pages, unsigned int offset,
> + unsigned long size, gfp_t gfp_mask,
> + unsigned int max_segment);
Just the question of parameter order, I like gfp_t last :)
And I think offset / size / max_segment tie together.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
helper to i915_sg_segment_size and fix swiotlb override.
> * Commit message update.
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 9 +
&g
fix swiotlb override.
> * Commit message update.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.h | 9 +
> drivers/gpu/drm/i915/i915_gem.c | 15 +--
> drivers/gpu/drm/i915/i915_gem_userptr.c |
ffset;
?
> - sg_set_page(s, pages[cur_page], min(size, chunk_size), offset);
> + sg_set_page(s, pages[cur_page],
> + min_t(unsigned long, size, chunk_size), offset);
> size -= chunk_size;
> offset = 0;
>
sg_set_page(s, pages[cur_page],
> + min_t(unsigned long, size, chunk_size), offset);
> size -= chunk_size;
> offset = 0;
> cur_page = j;
Could BUG_ON(size); afterwards and BUG_ON(!size) inside? Although that
requires the caller didn't make a mistake in n_pages vs offset+size.
Minor comments,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
uot;drm/i915: Queue the idling context switch after all
> other timelines")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
uot;drm/i915: Queue the idling context switch after all
> other timelines")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
lib in commit
cd11016e5f521 ("mm, kasan: stackdepot implementation. Enable stackdepot
for SLAB") so that it could be shared with mm/. In turn, we want to
share it now with drivers.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Andrew Morton <a...@linux-foundat
lib in commit
cd11016e5f521 ("mm, kasan: stackdepot implementation. Enable stackdepot
for SLAB") so that it could be shared with mm/. In turn, we want to
share it now with drivers.
Signed-off-by: Chris Wilson
Cc: Andrew Morton
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: Dmitry
On Tue, Nov 08, 2016 at 01:43:40PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 11:45:51AM +0000, Chris Wilson wrote:
> > On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote:
> > > &
On Tue, Nov 08, 2016 at 01:43:40PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 11:45:51AM +0000, Chris Wilson wrote:
> > On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote:
> > > &
On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 10:35:08AM +0000, Chris Wilson wrote:
> > On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:
> > > From: Gustavo Padovan <gustavo.pado...@collabora.c
On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 10:35:08AM +0000, Chris Wilson wrote:
> > On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > Hi,
> > >
e flip). Since the user doesn't know about these operations,
they are not included in the explicit fence they provide, at which point
we can't trust their fence to the exclusion of the implicit fences...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
t these operations,
they are not included in the explicit fence they provide, at which point
we can't trust their fence to the exclusion of the implicit fences...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
e highest version). Since my guess was wrong, any clues you can find
to point me in the direction will be very useful.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
e highest version). Since my guess was wrong, any clues you can find
to point me in the direction will be very useful.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
/drm-intel/commit/?h=drm-intel-next-queued=d2a84a76a3b970fa32e6eda3d85e7782f831379e
>
> Do you want me to test this patch only on top of master? (If it applies!!!)
It won't apply directly, but you could try testing that commit and its
parent to see if my hunch was correct.
Thanks,
-Chris
/drm-intel/commit/?h=drm-intel-next-queued=d2a84a76a3b970fa32e6eda3d85e7782f831379e
>
> Do you want me to test this patch only on top of master? (If it applies!!!)
It won't apply directly, but you could try testing that commit and its
parent to see if my hunch was correct.
Thanks,
-Chris
m-intel/ #drm-intel-nightly contains one
interesting patch wrt to the partial vma->pages
https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next-queued=d2a84a76a3b970fa32e6eda3d85e7782f831379e
Do you mind testing -nightly to see if I'm barking up the wrong tree?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
m-intel/ #drm-intel-nightly contains one
interesting patch wrt to the partial vma->pages
https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next-queued=d2a84a76a3b970fa32e6eda3d85e7782f831379e
Do you mind testing -nightly to see if I'm barking up the wrong tree?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, Nov 03, 2016 at 12:11:55PM -0400, Lyude Paul wrote:
> On Thu, 2016-11-03 at 12:11 -0400, Lyude Paul wrote:
> > On Thu, 2016-11-03 at 16:02 +0000, Chris Wilson wrote:
> > >
> > > On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote:
> > > >
On Thu, Nov 03, 2016 at 12:11:55PM -0400, Lyude Paul wrote:
> On Thu, 2016-11-03 at 12:11 -0400, Lyude Paul wrote:
> > On Thu, 2016-11-03 at 16:02 +0000, Chris Wilson wrote:
> > >
> > > On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote:
> > > >
per_hotplug_event(dev);
which also depends upon us actually reseting the connector->status to
unknown in drm_mode_config_reset(), Daniel!
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
ually reseting the connector->status to
unknown in drm_mode_config_reset(), Daniel!
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
008e3324] kernel_init+0x4/0x100
> [2.543681] [00405f04] ret_from_fork+0x1c/0x2c
>
> Bisect points to commit 0c79e3331f08 ("mm/vmalloc: replace opencoded 4-level
> page walkers"). Reverting this patch fixes the problem.
Hmm, apply_to_pte_range() has a BUG_ON(
ts to commit 0c79e3331f08 ("mm/vmalloc: replace opencoded 4-level
> page walkers"). Reverting this patch fixes the problem.
Hmm, apply_to_pte_range() has a BUG_ON(pmd_huge(*pmd)) but the old
vmap_pte_range() does not and neither has the code to handle that case.
Presuming that the BUG_ON() there is actually meaningful.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Oct 28, 2016 at 04:33:10PM +0300, Jani Nikula wrote:
> On Fri, 28 Oct 2016, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> > Some subsystem polices have a strict requirement that every patch must
> > have at least one reviewer before being approved for upstream.
On Fri, Oct 28, 2016 at 04:33:10PM +0300, Jani Nikula wrote:
> On Fri, 28 Oct 2016, Chris Wilson wrote:
> > Some subsystem polices have a strict requirement that every patch must
> > have at least one reviewer before being approved for upstream. Since
> > encouraging review
(or with --review).
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Andy Whitcroft <a...@canonical.com>
Cc: Joe Perches <j...@perches.com>
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
---
scripts/checkpatch.pl | 17 -
1 file changed, 16 insertions(+), 1
(or with --review).
Signed-off-by: Chris Wilson
Cc: Andy Whitcroft
Cc: Joe Perches
Cc: Joonas Lahtinen
---
scripts/checkpatch.pl | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index a8368d1c4348..9eaa5a4fbbc0 100755
return the
garbage. Not only should we fix the error handling here, but you also
need to fix the error handling in drivers/video/backlight/backlight.c as
despite many callees returning an error, it assumes that
bd->ops->get_brightness() never returns an error...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
return the
garbage. Not only should we fix the error handling here, but you also
need to fix the error handling in drivers/video/backlight/backlight.c as
despite many callees returning an error, it assumes that
bd->ops->get_brightness() never returns an error...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Oct 21, 2016 at 08:19:03PM +0200, Daniel Vetter wrote:
> On Fri, Oct 21, 2016 at 01:57:28PM +0100, Chris Wilson wrote:
> > I think of a use for sending an empty clip: where you don't want to
> > push any new pixel data, but you do want to be sure that the pipeline
>
On Fri, Oct 21, 2016 at 08:19:03PM +0200, Daniel Vetter wrote:
> On Fri, Oct 21, 2016 at 01:57:28PM +0100, Chris Wilson wrote:
> > I think of a use for sending an empty clip: where you don't want to
> > push any new pixel data, but you do want to be sure that the pipeline
>
return -ENOMEM;
Full circle! The whole reason this exists was to avoid that vmalloc. I
don't really want it back...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
return -ENOMEM;
Full circle! The whole reason this exists was to avoid that vmalloc. I
don't really want it back...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
mebuffer.c
@@ -504,10 +504,13 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
}
if (num_clips && clips_ptr) {
+ int i;
+
if (num_clips < 0 || num_clips > DRM_MODE_FB_DIRTY_MAX_CLIPS) {
ret = -EINVAL;
goto out_err1;
}
+
clips = kcalloc(num_clips, sizeof(*clips), GFP_KERNEL);
if (!clips) {
ret = -ENOMEM;
@@ -520,6 +523,14 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
ret = -EFAULT;
goto out_err2;
}
+
+ for (i = 0; i < num_clips; i++) {
+ if (clips[i].x2 < clips[i].x1 ||
+ clips[i].y2 < clips[i].y1) {
+ ret = -EINVAL;
+ goto out_err2;
+ }
+ }
}
if (fb->funcs->dirty)
--
Chris Wilson, Intel Open Source Technology Centre
ther.
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 49fd7db758e0..ada6a5517945 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -504,10 +504,13 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
}
if (num_
it's only magic from interrupt context..
>
> Chris, does this patch make virtually mapped stack work for you again?
So far, so good. No warns from anyone else.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
it's only magic from interrupt context..
>
> Chris, does this patch make virtually mapped stack work for you again?
So far, so good. No warns from anyone else.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Wed, Oct 19, 2016 at 08:26:35AM +0100, Chris Wilson wrote:
> On Wed, Oct 19, 2016 at 08:27:23AM +0200, Valentin Rothberg wrote:
> > Dear Chris,
> >
> > your commit 9f267eb8d2ea ("drm/i915: Stop the machine whilst capturing
> > the GPU crash dump") has pop
On Wed, Oct 19, 2016 at 08:26:35AM +0100, Chris Wilson wrote:
> On Wed, Oct 19, 2016 at 08:27:23AM +0200, Valentin Rothberg wrote:
> > Dear Chris,
> >
> > your commit 9f267eb8d2ea ("drm/i915: Stop the machine whilst capturing
> > the GPU crash dump") has pop
char rtc_intr;
> + unsigned long flags;
>
> - spin_lock_irq(_lock);
> + spin_lock_irqsave(_lock, flags);
My reading of the acpi fixed event handlers suggests that this can only
be called from interrupt context.
Anyway using irqsave is correct (just may be optimised away to a plain
spin_lock() if the condition that this is only called in irq context is
satisfied).
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
he acpi fixed event handlers suggests that this can only
be called from interrupt context.
Anyway using irqsave is correct (just may be optimised away to a plain
spin_lock() if the condition that this is only called in irq context is
satisfied).
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
h is not defined anywhere in
> Kconfig.
>
> STOP_MACHINE has been removed a while ago (see
> https://lkml.org/lkml/2015/11/19/133). I assume that HOTPLUG_CPU
> could be used?
No. We don't need the select anymore as the core machinery now just
works without having to force compilatio
h is not defined anywhere in
> Kconfig.
>
> STOP_MACHINE has been removed a while ago (see
> https://lkml.org/lkml/2015/11/19/133). I assume that HOTPLUG_CPU
> could be used?
No. We don't need the select anymore as the core machinery now just
works without having to force compilatio
ggered by earlier patch to remove the serialisation and add
cond_resched_lock(_area_lock)]
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
ggered by earlier patch to remove the serialisation and add
cond_resched_lock(_area_lock)]
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
>
> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
Yup, missed that it jumps to fail b
>
> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Signed-off-by: Arnd Bergmann
Yup, missed that it jumps to fail before allocating state.
Function still looks a bit odd, but nvm
Reviewed-by: Chris Wilson
: Daniel Vetter <daniel.vet...@ffwll.ch>
> > Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> > Cc: Rob Clark <robdcl...@gmail.com>
> > Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org>
> > ---
> > drivers/gpu/drm/i915/i915_gem_shrinker.c | 2
; > 2 files changed, 6 insertions(+), 43 deletions(-)
>
> OK, so it appears that i915 changed their locking around and got rid of
> this thing entirely. Much appreciated Chris!!
It's not dead yet! Sorry.
It's close though, in the next cycle we may be at a point where we don't
rely on
On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote:
> This is how everyone seems to already use them, but let's make that
> explicit.
mm/page_alloc.c: alloc_large_system_hash() is perhaps the exception to
the rule.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote:
> This is how everyone seems to already use them, but let's make that
> explicit.
mm/page_alloc.c: alloc_large_system_hash() is perhaps the exception to
the rule.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
601 - 700 of 1356 matches
Mail list logo
