cking/lockdep: Provide lockdep_assert{,_once}() helpers
Extract lockdep_assert{,_once}() helpers to more easily write composite
assertions like, for example:
lockdep_assert(lockdep_is_held(&drm_device.master_mutex) ||
lockdep_is_held(&drm_file.master_lookup_lock));
Signed-o
On Thu, Jul 29, 2021 at 10:32:13PM +0800, Desmond Cheong Zhi Xi wrote:
> Sounds good, will do. Thanks for the patch, Peter.
>
> Just going to make a small edit:
> s/LOCK_STAT_NOT_HELD/LOCK_STATE_NOT_HELD/
Bah, I knew I should've compile tested it :-), Thanks!
On Mon, Aug 02, 2021 at 10:26:16AM +0200, Daniel Vetter wrote:
> On Sat, Jul 31, 2021 at 04:24:56PM +0800, Desmond Cheong Zhi Xi wrote:
> > Hi,
> >
> > Following a discussion on the patch ("drm: use the lookup lock in
> > drm_is_current_master") [1], Peter
On Mon, Jan 18, 2021 at 07:03:34PM +0100, Christian König wrote:
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 6e74e6745eca..f51458615158 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -387,6 +387,13 @@ int drm_syncobj
On Tue, Jan 19, 2021 at 10:46:53AM +0100, Christian König wrote:
> But I'm going to double check if drm_syncobj_fence_add_wait() isn't used
> elsewhere as well.
drm_syncobj_array_wait_timeout()
Which is why I asked.. :-)
___
dri-devel mailing list
dri-d
_once(l)do { (void)(l); } while (0)
> > +#define lockdep_assert_none_held_once() do { } while (0)
> >
> > #define lockdep_recursing(tsk) (0)
>
> ofc needs ack from Peter, but drm parts look all good to me.
Acked-by: Peter Zijlstra (Intel)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Feb 16, 2021 at 10:29:00AM +0100, Daniel Vetter wrote:
> On Tue, Feb 16, 2021 at 09:21:46AM +0100, Christian König wrote:
> > The last user went away in the 5.11 cycle.
> >
> > Signed-off-by: Christian König
>
> Nice.
>
> Reviewed-by: Daniel Vetter
>
> I think would be good to still s
On Tue, Feb 16, 2021 at 01:38:49PM +0100, Christian König wrote:
>
>
> Am 16.02.21 um 11:13 schrieb Peter Zijlstra:
> > On Tue, Feb 16, 2021 at 10:29:00AM +0100, Daniel Vetter wrote:
> > > On Tue, Feb 16, 2021 at 09:21:46AM +0100, Christian König wrote:
> > >
h over
> to rwsem.
>
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Will Deacon
> Cc: linux-ker...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
No SoB!
Assuning you actually wrote and and simply forgot to add it, the patch
does look ok
gt; Cc: "Matthew Wilcox (Oracle)"
> Signed-off-by: Daniel Vetter
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Will Deacon
> Cc: linux-ker...@vger.kernel.org
> ---
> lib/locking-selftest.c | 47 ++
> 1 file changed, 47 in
On Tue, Sep 07, 2021 at 03:20:44PM +0200, Maarten Lankhorst wrote:
> i915 will soon gain an eviction path that trylock a whole lot of locks
> for eviction, getting dmesg failures like below:
>
> BUG: MAX_LOCK_DEPTH too low!
> turning off the locking correctness validator.
> depth: 48 max: 48!
> 4
On Thu, Sep 09, 2021 at 07:38:06AM +0200, Maarten Lankhorst wrote:
> > You'll need a similar hunk in ww_rt_mutex.c
>
> What tree has that file?
Linus' tree should have it. Per commit:
f8635d509d80 ("locking/ww_mutex: Implement rtmutex based ww_mutex API
functions")
On Thu, Sep 09, 2021 at 11:32:18AM +0200, Maarten Lankhorst wrote:
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index d456579d0952..791c28005eef 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -736,6 +736,44 @@ __ww_mutex_lock(struct mutex *lock, unsign
On Fri, Sep 10, 2021 at 05:02:54PM +0200, Peter Zijlstra wrote:
> That doesn't look right, how's this for you?
Full patch for the robots here:
https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/commit/?h=locking/core&id=826e7b8826f0af185bb93249600533c33fd69a95
priority, but
it requires a rework of the entire driver, which can only be done one
step at a time.
As an intermediate solution, add an acquire context to
ww_mutex_trylock, which allows us to do proper nesting annotations on
the trylocks, making the above lockdep splat disappear.
This is also usef
On Thu, Sep 16, 2021 at 03:00:39PM +0200, Maarten Lankhorst wrote:
> > For merge logistics, can we pls have a stable branch? I expect that the
> > i915 patches will be ready for 5.16.
> >
> > Or send it in for -rc2 so that the interface change doesn't cause needless
> > conflicts, whatever you thi
On Thu, Sep 16, 2021 at 03:28:11PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 16, 2021 at 03:00:39PM +0200, Maarten Lankhorst wrote:
>
> > > For merge logistics, can we pls have a stable branch? I expect that the
> > > i915 patches will be ready for 5.16.
> > >
On Wed, Oct 20, 2021 at 08:40:05AM -0700, Lucas De Marchi wrote:
> On Fri, Mar 26, 2021 at 06:55:03AM +0100, Christoph Hellwig wrote:
> > Add a helper that calls remap_pfn_range for an struct io_mapping, relying
> > on the pgprot pre-validation done when creating the mapping instead of
> > doing it
On Thu, Sep 30, 2021 at 06:15:47PM +0100, Tvrtko Ursulin wrote:
> void set_user_nice(struct task_struct *p, long nice)
> {
> bool queued, running;
> - int old_prio;
> + int old_prio, ret;
> struct rq_flags rf;
> struct rq *rq;
>
> @@ -6913,6 +6945,9 @@ void set_user_ni
On Thu, Sep 30, 2021 at 06:15:46PM +0100, Tvrtko Ursulin wrote:
> (Note I did not copy
> everyone on all patches but just the cover letter for context and the rest
> should be available from the mailing list.)
In general, if you can't be arsed to send it to me, I can't be arsed to
dig it out.
On Fri, Oct 01, 2021 at 11:32:16AM +0100, Tvrtko Ursulin wrote:
>
> On 01/10/2021 10:04, Tvrtko Ursulin wrote:
> >
> > Hi Peter,
> >
> > On 30/09/2021 19:33, Peter Zijlstra wrote:
> > > On Thu, Sep 30, 2021 at 06:15:47PM +0100, Tvrtko Ursulin wro
On Mon, Oct 04, 2021 at 09:12:37AM +0100, Tvrtko Ursulin wrote:
> On 01/10/2021 16:48, Peter Zijlstra wrote:
> > Hmm? That's for normalize_rt_tasks() only, right? Just don't have it
> > call the notifier in that special case (that's a magic sysrq thing
> >
ave been acquired, false if other magic is involved and the lock
> is not needed. Use the `false' argument only from within
> switch_to_kernel_context() and remove __timeline_mark_lock().
>
> Cc: Peter Zijlstra
> Signed-off-by: Sebastian Andrzej Siewior
Eeew,
On Tue, Nov 09, 2021 at 12:06:48PM -0800, Sultan Alsawaf wrote:
> Hi,
>
> I encountered a printk deadlock on 5.13 which appears to still affect the
> latest
> kernel. The deadlock occurs due to printk being used while having the current
> CPU's runqueue locked, and the underlying framebuffer cons
On Wed, Nov 10, 2021 at 11:50:38AM +0100, Petr Mladek wrote:
> On Tue 2021-11-09 12:06:48, Sultan Alsawaf wrote:
> > Hi,
> >
> > I encountered a printk deadlock on 5.13 which appears to still affect the
> > latest
> > kernel. The deadlock occurs due to printk being used while having the
> > curr
| 7 ---
> arch/x86/mm/ioremap.c | 2 +-
> arch/x86/xen/setup.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 4 ++--
> include/asm-generic/fixmap.h | 2 +-
> 6 files changed, 6 insertions(+), 13 deletions(-)
Acked-by: Peter Zijlstra (Intel)
ush this upstream through the drm subsystem?
Nah, take it.
Acked-by: Peter Zijlstra (Intel)
On Wed, Jun 22, 2016 at 08:46:12AM +0100, Chris Wilson wrote:
> We are only documenting that the read is outside of the lock, and do not
> require strict ordering on the operation. In this case the more relaxed
> lockless_dereference() will suffice.
No, no, no... This is 'broken'. lockless_derefer
On Thu, Aug 11, 2016 at 11:26:47AM -0700, Paul E. McKenney wrote:
> If my upcoming testing of the two changes together pans out, I will
> give you a Tested-by -- I am guessing that you don't want to wait
> until the next merge window for these changes.
I was planning to stuff them in tip/locking/u
On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote:
> Fix this by creating a prinkt_safe_up() which calls wake_up_process
> outside of the spinlock. This isn't correct in full generality, but
> good enough for console_lock:
>
> - console_lock doesn't use interruptible or killable or tim
On Thu, May 09, 2019 at 03:06:09PM +0200, Daniel Vetter wrote:
> On Thu, May 9, 2019 at 2:31 PM Peter Zijlstra wrote:
> > On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote:
> > > Fix this by creating a prinkt_safe_up() which calls wake_up_process
> > > ou
On Mon, May 13, 2019 at 10:42:42PM -0700, Brendan Higgins wrote:
> This fixes the following warning seen on GCC 7.3:
> kunit/test-test.o: warning: objtool: kunit_test_unsuccessful_try() falls
> through to next function kunit_test_catch()
>
What is that file and function; no kernel tree near me
On Tue, May 14, 2019 at 01:12:23AM -0700, Brendan Higgins wrote:
> On Tue, May 14, 2019 at 08:56:43AM +0200, Peter Zijlstra wrote:
> > On Mon, May 13, 2019 at 10:42:42PM -0700, Brendan Higgins wrote:
> > > This fixes the following warning seen on GCC 7.3:
> > >
On Thu, Apr 18, 2019 at 05:42:55PM +0200, Thomas Gleixner wrote:
> On Thu, 18 Apr 2019, Josh Poimboeuf wrote:
> > Another idea I had (but never got a chance to work on) was to extend the
> > x86 unwind interface to all arches. So instead of the callbacks, each
> > arch would implement something l
On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote:
> +typedef bool (*stack_trace_consume_fn)(void *cookie, unsigned long addr,
> + bool reliable);
> +void arch_stack_walk(stack_trace_consume_fn consume_entry, void *cookie,
> + st
On Fri, Apr 19, 2019 at 10:32:30AM +0200, Thomas Gleixner wrote:
> On Fri, 19 Apr 2019, Peter Zijlstra wrote:
> > On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote:
> >
> > > +typedef bool (*stack_trace_consume_fn)(void *co
On Mon, Apr 22, 2019 at 10:27:45AM -0300, Mauro Carvalho Chehab wrote:
> .../{atomic_bitops.txt => atomic_bitops.rst} | 2 +
What's happend to atomic_t.txt, also NAK, I still occationally touch
these files.
___
dri-devel mailing list
dri-devel@lists.f
On Tue, Apr 23, 2019 at 10:30:53AM -0600, Jonathan Corbet wrote:
> On Tue, 23 Apr 2019 15:01:32 +0200
> Peter Zijlstra wrote:
>
> > But yes, I have 0 motivation to learn or abide by rst. It simply doesn't
> > give me anything in return. There is no upside, only wor
On Tue, Apr 23, 2019 at 08:55:19AM -0400, Mike Snitzer wrote:
> On Tue, Apr 23 2019 at 4:31am -0400,
> Peter Zijlstra wrote:
>
> > On Mon, Apr 22, 2019 at 10:27:45AM -0300, Mauro Carvalho Chehab wrote:
> >
> > > .../{atomic_bitops.txt => atomic_bitops.rst}
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedeskt
On Tue, Apr 23, 2019 at 11:38:16PM +0200, Borislav Petkov wrote:
> If that is all the changes it would need, then I guess that's ok. Btw,
> those rst-conversion patches don't really show what got changed. Dunno
> if git can even show that properly. I diffed the two files by hand to
> see what got c
On Tue, Apr 23, 2019 at 11:53:49AM -0600, Jonathan Corbet wrote:
> > Look at crap like this:
> >
> > "The memory allocations via :c:func:`kmalloc`, :c:func:`vmalloc`,
> > :c:func:`kmem_cache_alloc` and"
> >
> > That should've been written like:
> >
> > "The memory allocations via kmalloc(), vmal
On Thu, Apr 18, 2019 at 10:41:37AM +0200, Thomas Gleixner wrote:
> There is only one caller of check_prev_add() which hands in a zeroed struct
> stack trace and a function pointer to save_stack(). Inside check_prev_add()
> the stack_trace struct is checked for being empty, which is always
> true. B
On Thu, Apr 18, 2019 at 10:41:38AM +0200, Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace by using the storage
> array based interfaces and storing the information is a small lockdep
> specific data structure.
>
Acked-by: Peter Zij
On Thu, Apr 25, 2019 at 11:45:11AM +0200, Thomas Gleixner wrote:
> There is only one caller which hands in save_trace as function pointer.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra (Intel)
___
dri-devel mailing list
On Fri, Jun 14, 2019 at 02:41:20PM +0200, Christian König wrote:
> The ww_mutex implementation allows for detection deadlocks when multiple
> threads try to acquire the same set of locks in different order.
>
> The problem is that handling those deadlocks was the burden of the user of
> the ww_mut
On Fri, Jun 14, 2019 at 02:41:22PM +0200, Christian König wrote:
> Use the provided macros instead of implementing deadlock handling on our own.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/drm_gem.c | 49 ++-
> 1 file changed, 12 insertions(+),
On Fri, Jun 14, 2019 at 02:41:22PM +0200, Christian König wrote:
> Use the provided macros instead of implementing deadlock handling on our own.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/drm_gem.c | 49 ++-
> 1 file changed, 12 insertions(+),
On Fri, Jun 14, 2019 at 03:06:10PM +0200, Christian König wrote:
> Am 14.06.19 um 14:59 schrieb Peter Zijlstra:
> > +#define ww_mutex_lock_for_each(loop, pos, contended, ret, intr, ctx) \
> > + for (contended = ERR_PTR(-ENOENT); ({ \
> > +
On Wed, Jun 19, 2019 at 07:22:18AM -0300, Mauro Carvalho Chehab wrote:
> Hi Daniel,
>
> Em Wed, 19 Jun 2019 11:05:57 +0200
> Daniel Vetter escreveu:
>
> > On Tue, Jun 18, 2019 at 10:55 PM Mauro Carvalho Chehab
> > wrote:
> > > diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm
On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro Carvalho Chehab wrote:
> .../{ => driver-api}/atomic_bitops.rst| 2 -
That's a .txt file, big fat NAK for making it an rst.
> .../{ => driver-api}/futex-requeue-pi.rst | 2 -
> .../{ => driver-api}/gcc-plugins.rst | 2 -
>
On Wed, Jun 19, 2019 at 01:43:56PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro Carvalho Chehab wrote:
>
> > .../{ => driver-api}/atomic_bitops.rst| 2 -
>
> That's a .txt file, big fat NAK for making it an rst.
Also, how many
On Wed, Jun 19, 2019 at 01:45:51PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 19, 2019 at 01:43:56PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro Carvalho Chehab wrote:
> >
> > > .../{ => driver-api}/atomic_bitops.rst| 2 -
Hi all,
I tried using wake_up_var() today and accidentally noticed that it
didn't imply an smp_mb() and specifically requires it through
wake_up_bit() / waitqueue_active().
Now, wake_up_bit() doesn't imply the barrier because it is assumed to be
used with the atomic bitops API which either implie
(sorry for cross-posting to moderated lists btw, I've since
acquired a patch to get_maintainers.pl that wil exclude them
in the future)
On Tue, Jun 25, 2019 at 08:51:01AM +0100, David Howells wrote:
> Peter Zijlstra wrote:
>
> > I tried using wake_up_var() today and accident
On Tue, Jun 25, 2019 at 11:19:35AM +0200, Andreas Gruenbacher wrote:
> > diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
> > index cf4c767005b1..29ea5da7 100644
> > --- a/fs/gfs2/glops.c
> > +++ b/fs/gfs2/glops.c
> > @@ -227,6 +227,7 @@ static void gfs2_clear_glop_pending(struct gfs2_inode
> >
On Tue, Jun 25, 2019 at 02:12:22PM +0200, Andreas Gruenbacher wrote:
> > Only if we do as David suggested and make clean_and_wake_up_bit()
> > provide the RELEASE barrier.
>
> (It's clear_and_wake_up_bit, not clean_and_wake_up_bit.)
Yes, typing hard.
> > That is, currently clear_and_wake_up_bit
On Tue, Jun 25, 2019 at 03:55:06PM +0200, Christian König wrote:
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index 4d32e2c67862..9e53e42b053a 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -55,6 +55,88 @@ EXPORT_SYMBOL(res
On Thu, Aug 01, 2019 at 07:16:19PM -0700, john.hubb...@gmail.com wrote:
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions"). That commit
> has an extensive description of the problem and the planned steps to
> solve
On Thu, Apr 07, 2022 at 10:59:46AM +0200, Christian König wrote:
> Daniel pointed out that this series removes the last user of
> seqcount_ww_mutex_t, so let's drop this.
>
> Signed-off-by: Christian König
Acked-by: Peter Zijlstra (Intel)
On Tue, Oct 08, 2019 at 06:33:51PM +0200, Daniel Vetter wrote:
> On Thu, Sep 19, 2019 at 12:09:40PM -0400, Qian Cai wrote:
> > Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> > in __lock_release"), @nested is no longer used in lock_release(), so
> > remove it from all lock
On Thu, Sep 19, 2019 at 12:09:40PM -0400, Qian Cai wrote:
> Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> in __lock_release"), @nested is no longer used in lock_release(), so
> remove it from all lock_release() calls and friends.
Right; I never did this cleanup for not
On Thu, Nov 21, 2019 at 02:54:03PM +1100, Stephen Rothwell wrote:
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> index f940526c5889..63e734a125fb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> +++ b/drivers/gpu/drm/amd/amdgpu/am
rks better when I actually squash in the fixup I had lying
> > around :-/
> >
> > v4: Pick the suggestion from Andrew Morton to give non_block_start/end
> > some good kerneldoc comments. I added that other blocking calls like
> > wait_event pose similar issues, since t
On Fri, Aug 23, 2019 at 09:12:34AM -0300, Jason Gunthorpe wrote:
> I still haven't heard a satisfactory answer why a whole new scheme is
> needed and a simple:
>
>if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP))
> preempt_disable()
>
> isn't sufficient to catch the problematic cases during
On Fri, Aug 23, 2019 at 03:42:47PM +0200, Daniel Vetter wrote:
> I'm assuming the lockdep one will land, so not going to resend that.
I was assuming you'd wake the might_lock_nested() along with the i915
user through the i915/drm tree. If want me to take some or all of that,
lemme know.
__
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 2d6d790d9bed..6c7c70bf50dd 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -491,7 +491,13 @@ struct vm_area_struct {
>
On Wed, Jan 18, 2023 at 04:35:22PM +0100, Andrzej Hajda wrote:
> Andrzej Hajda (7):
> arch: rename all internal names __xchg to __arch_xchg
> linux/include: add non-atomic version of xchg
> arch/*/uprobes: simplify arch_uretprobe_hijack_return_addr
> llist: simplify __llist_del_all
> io_
On Thu, Feb 23, 2023 at 10:24:19PM +0100, Andrzej Hajda wrote:
> On 22.02.2023 18:04, Peter Zijlstra wrote:
> > On Wed, Jan 18, 2023 at 04:35:22PM +0100, Andrzej Hajda wrote:
> >
> > > Andrzej Hajda (7):
> > >arch: rename all internal names __xchg to __arch
On Fri, Jan 13, 2023 at 12:30:16PM -0700, Jim Cromie wrote:
> __jump_label_patch currently will "crash the box" if it finds a
> jump_entry not as expected. ISTM this overly harsh; it doesn't
> distinguish between "alternate/opposite" state, and truly
> "insane/corrupted".
>
> The "opposite" (but
On Wed, Nov 16, 2022 at 10:16:34AM -0800, Linus Torvalds wrote:
> Following the history of it is a big of a mess, because there's a
> number of renamings and re-organizations, but it seems to go back to
> 2007 and commit b6a2fea39318 ("mm: variable length argument support").
I went back and read p
On Mon, Jul 24, 2023 at 05:43:10PM +0800, Qi Zheng wrote:
> +void shrinker_unregister(struct shrinker *shrinker)
> +{
> + struct dentry *debugfs_entry;
> + int debugfs_id;
> +
> + if (!shrinker || !(shrinker->flags & SHRINKER_REGISTERED))
> + return;
> +
> + down_write(
++
> kernel/events/core.c | 33 ++--
> security/selinux/hooks.c | 7 ++
> 6 files changed, 44 insertions(+), 65 deletions(-)
Acked-by: Peter Zijlstra (Intel)
On Tue, Jul 11, 2023 at 11:39:17AM -1000, Tejun Heo wrote:
> I wonder whether the right thing to do here is somehow scaling the threshold
> according to the relative processing power. It's difficult to come up with a
> threshold which works well across the latest & fastest and really tiny CPUs.
>
On Wed, Jul 12, 2023 at 11:04:16AM +0200, Geert Uytterhoeven wrote:
> Hoi Peter,
>
> On Wed, Jul 12, 2023 at 10:05 AM Peter Zijlstra wrote:
> > On Tue, Jul 11, 2023 at 11:39:17AM -1000, Tejun Heo wrote:
> > > I wonder whether the right thing to do here is somehow scal
On Wed, Jul 19, 2023 at 03:51:14PM +0800, Kefeng Wang wrote:
> Use the helpers to simplify code, also kill unneeded goto cpy_name.
Grrr.. why am I only getting 4/4 ?
I'm going to write a bot that auto NAKs all partial series :/
On Tue, Nov 08, 2016 at 11:44:03AM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > FIXME: Add owner of second tree to To:
> >Add author(s)/SOB of conflicting commits.
> >
> > Today's linux-next merge of the tip tree got a
On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote:
> > You're talking about:
> >
> > lkml.kernel.org/r/20161007154351.GL3117 at twins.programming.kicks-ass.net
> >
> > ? I got no feedback from you DRM guys on that so I kinda forgot about
> > that in the hope we'd not have to do this
On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote:
> > Now, I know you're working on getting rid of this entirely for i915, but
> > what about that MSM driver? Will we continue to need it there, is
> > anybody actually maintaining that thing?
>
> Rob Clark is, and since he's a one-man
ams reference
> hundreds of GPU buffer objects with a lot of overlap in the buffer lists
> between command streams. This test reliably caused a deadlock, and while I
> haven't completely confirmed that it is exactly the scenario outlined
> above, this patch does fix
On Wed, Nov 23, 2016 at 12:25:22PM +0100, Nicolai Hähnle wrote:
> @@ -473,7 +476,14 @@ void __sched ww_mutex_unlock(struct ww_mutex *lock)
>*/
> mutex_clear_owner(&lock->base);
> #endif
> - __mutex_fastpath_unlock(&lock->base.count, __mutex_unlock_slowpath);
> + /*
> +
On Wed, Nov 23, 2016 at 03:25:25PM +0100, Daniel Vetter wrote:
> Without thinking it through in detail this is a PI issue, except that we
> replace boosting with wakeup&back-off. Could we perhaps steal something
> from rt mutexes to make it fair&efficient?
rt_mutexes order the waiters by 'priorit
On Thu, Nov 24, 2016 at 12:26:57PM +0100, Nicolai Hähnle wrote:
> I do believe we can win a bit by keeping the wait list sorted, if we also
> make sure that waiters don't add themselves in the first place if they see
> that a deadlock situation cannot be avoided.
>
> I will probably want to exte
On Thu, Nov 24, 2016 at 12:52:25PM +0100, Daniel Vetter wrote:
> On Thu, Nov 24, 2016 at 12:40 PM, Peter Zijlstra
> wrote:
> >
> >> I do believe we can win a bit by keeping the wait list sorted, if we also
> >> make sure that waiters don't add themselves in th
On Mon, Nov 28, 2016 at 01:42:26PM +0100, Maarten Lankhorst wrote:
> > + ww_mutex_lock(&resv->lock.base, NULL);
> Yuck, can we rename base to __NEVER_TOUCH_DIRECTLY_OUTSIDE_LOCKING_CORE?
> It's harder to get them confused like that, even with a null context it's
> illegal to call mutex_lock/unl
OK, so I got this far, although I stuffed two patches in the middle
(which I should probably pull to the beginning and did this one patch
differently.
I've not really tested the result yet, will attempt to do so tomorrow.
Please have a look at the current state of things here:
git://git.kern
On Thu, Jan 14, 2016 at 02:30:50PM -0800, Stefan Agner wrote:
> Hi Mark,
>
> I currently work on the DCU DRM driver (drivers/gpu/drm/fsl-dcu/) on a
> Linux 4.4 kernel. With CONFIG_LOCKDEP enabled I get the following
> warning on startup:
>
> [1.327284] [ cut here ]
> [
On Mon, Mar 30, 2020 at 03:00:35PM +0200, Daniel Vetter wrote:
> Hi all, for all = rcu, cpuhotplug and perf maintainers
>
> We've hit an interesting new lockdep splat in our drm/i915 CI:
>
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17096/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-r
On Wed, Apr 08, 2020 at 01:59:15PM +0200, Christoph Hellwig wrote:
> This is always GFP_KERNEL - for long term mappings with other properties
> vmap should be used.
PAGE_KERNEL != GFP_KERNEL :-)
> - return vm_map_ram(mock->pages, mock->npages, 0, PAGE_KERNEL);
> + return vm_map_ram(mock-
ore systematic. This also removes any chance to create vmalloc
> mappings outside the designated areas or using executable permissions
> from modules. Besides that it removes more than 300 lines of code.
>
Looks great, thanks for doing this!
A
On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote:
> Hi,
>
> On 4/8/20 4:59 AM, Christoph Hellwig wrote:
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index 36949a9425b8..614cc786b519 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -702,7 +702,7 @@ config ZSMALLOC
> >
> > conf
On Thu, Apr 09, 2020 at 09:08:26AM -0700, Minchan Kim wrote:
> On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote:
> > This allows to unexport map_vm_area and unmap_kernel_range, which are
> > rather deep internal and should not be available to modules.
>
> Even though I don't know
On Thu, Sep 24, 2020 at 08:32:41AM -0400, Steven Rostedt wrote:
> Anyway, instead of blocking. What about having a counter of number of
> migrate disabled tasks per cpu, and when taking a migrate_disable(), and
> there's
> already another task with migrate_disabled() set, and the current task has
On Thu, Sep 24, 2020 at 09:51:38AM -0400, Steven Rostedt wrote:
> > It turns out, that getting selected for pull-balance is exactly that
> > condition, and clearly a migrate_disable() task cannot be pulled, but we
> > can use that signal to try and pull away the running task that's in the
> > way.
On Mon, Sep 28, 2020 at 06:04:23PM +0800, Chengming Zhou wrote:
> Well, you are lucky. So it's a problem in our printk implementation.
Not lucky; I just kicked it in the groin really hard:
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git
debug/experimental
> The deadlock path i
On Tue, Sep 29, 2020 at 04:27:51PM +0200, Petr Mladek wrote:
> Upstreaming the console handling will be the next big step. I am sure
> that there will be long discussion about it. But there might be
> few things that would help removing printk_deferred().
>
> 1. Messages will be printed on consol
On Tue, Oct 06, 2020 at 11:08:59AM +0200, Daniel Vetter wrote:
> vblank work needs to preempt commit work.
>
> Right now we don't have any driver requiring this, but if we e.g. roll out
> the gamma table update for i915, then this _has_ to happen in the vblank
> period.
>
> Whereas the commit wor
On Fri, May 15, 2015 at 02:07:29AM +0100, Robert Bragg wrote:
> On Fri, May 8, 2015 at 5:24 PM, Peter Zijlstra
> wrote:
> > On Thu, May 07, 2015 at 03:15:43PM +0100, Robert Bragg wrote:
> >
> >> I've changed the uapi for configuring the i915_oa speci
On Thu, May 21, 2015 at 12:17:48AM +0100, Robert Bragg wrote:
> >
> > So for me the 'natural' way to represent this in perf would be through
> > event groups. Create a perf event for every single event -- yes this is
> > 53 events.
>
> So when I was first looking at this work I had considered the
On Tue, Jul 05, 2016 at 01:53:03PM +1000, Stephen Rothwell wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d3502c0603e5..1f91f187b2a8 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3290,7 +3290,7 @@ i915_g
1 - 100 of 259 matches
Mail list logo
