Re: [PATCH v3 3/8] x86, lib: Add WBNOINVD helper functions

2025-07-11 Thread Peter Zijlstra
On Thu, Jul 10, 2025 at 05:47:05PM +0200, Peter Zijlstra wrote: > So kvm-amd is the SEV stuff, AGPGART is the ancient crap nobody cares > about, CCP is more SEV stuff, DRM actually does CLFLUSH loops, but has a > WBINVD fallback. i915 is rude and actually does WBINVD. Could they > p

Re: [PATCH v3 3/8] x86, lib: Add WBNOINVD helper functions

2025-07-10 Thread Peter Zijlstra
On Thu, Jul 10, 2025 at 08:55:02AM -0700, Sean Christopherson wrote: > > So kvm-amd is the SEV stuff, AGPGART is the ancient crap nobody cares > > about, CCP is more SEV stuff, DRM actually does CLFLUSH loops, but has a > > WBINVD fallback. i915 is rude and actually does WBINVD. Could they > > pre

Re: [PATCH v3 3/8] x86, lib: Add WBNOINVD helper functions

2025-07-10 Thread Peter Zijlstra
On Thu, Jul 10, 2025 at 04:37:29PM +0200, Peter Zijlstra wrote: > On Thu, Jul 10, 2025 at 01:29:02PM +0200, Borislav Petkov wrote: > > On Thu, May 22, 2025 at 04:37:27PM -0700, Sean Christopherson wrote: > > > diff --git a/arch/x86/lib/cache-smp.c b/arch/x86/lib/cache

Re: [PATCH v3 3/8] x86, lib: Add WBNOINVD helper functions

2025-07-10 Thread Peter Zijlstra
On Thu, Jul 10, 2025 at 01:29:02PM +0200, Borislav Petkov wrote: > On Thu, May 22, 2025 at 04:37:27PM -0700, Sean Christopherson wrote: > > diff --git a/arch/x86/lib/cache-smp.c b/arch/x86/lib/cache-smp.c > > index 079c3f3cd32c..1789db5d8825 100644 > > --- a/arch/x86/lib/cache-smp.c > > +++ b/arch/

Re: [PATCH v5 1/5] bug/kunit: Core support for suppressing warning backtraces

2025-06-03 Thread Peter Zijlstra
On Mon, Jun 02, 2025 at 01:13:29PM +0200, Maxime Ripard wrote: > > I can't operate kunit > > Why not? Too complicated. People have even wrecked tools/testing/selftests/ to the point that it is now nearly impossible to run the simple selftests :-( And while I don't mind tests -- they're quite us

Re: [PATCH v5 1/5] bug/kunit: Core support for suppressing warning backtraces

2025-06-02 Thread Peter Zijlstra
On Sat, May 31, 2025 at 06:51:50AM -0700, Kees Cook wrote: > It's not for you, then. :) I can't operate ftrace, but I use kunit > almost daily. Ignoring WARNs makes this much nicer, and especially for > CIs. I'm thinking you are more than capable of ignoring WARNs too. This leaves the CI thing.

Re: [PATCH v5 1/5] bug/kunit: Core support for suppressing warning backtraces

2025-05-31 Thread Peter Zijlstra
On Fri, May 30, 2025 at 10:48:47AM -0700, Kees Cook wrote: > This needs docs too. I think this is collapsing 1 and 2 argument WARNs > into the ud1, and anything larger is explicitly calling __warn_printk + > __WARN_FLAGS? If only 1 and 2 args can be collapsed, why reserve 0xfe00 > through 0xfeff?

Re: [PATCH v5 1/5] bug/kunit: Core support for suppressing warning backtraces

2025-05-31 Thread Peter Zijlstra
On Fri, May 30, 2025 at 10:48:47AM -0700, Kees Cook wrote: > On Fri, May 30, 2025 at 04:01:40PM +0200, Peter Zijlstra wrote: > > I'm not really concerned with performance here, but more with the size > > of the code emitted by WARN_ONCE(). There are a *ton* of WARN sites

Re: [PATCH v5 1/5] bug/kunit: Core support for suppressing warning backtraces

2025-05-31 Thread Peter Zijlstra
On Fri, May 30, 2025 at 04:01:40PM +0200, Peter Zijlstra wrote: > I'm not really concerned with performance here, but more with the size > of the code emitted by WARN_ONCE(). There are a *ton* of WARN sites, > while only one report_bug() and printk(). We need a new and str

Re: [PATCH v5 1/5] bug/kunit: Core support for suppressing warning backtraces

2025-05-30 Thread Peter Zijlstra
+Mark because he loves a hack :-) On Thu, May 29, 2025 at 12:36:55PM +0200, Alessandro Carminati wrote: > > Like I said before; you need to do this on the report_bug() size of > > things. > > > I fully understand your concerns, and I truly appreciate both yours > and Josh’s feedback on this mat

Re: [PATCH v5 1/5] bug/kunit: Core support for suppressing warning backtraces

2025-05-30 Thread Peter Zijlstra
On Mon, May 26, 2025 at 01:27:51PM +, Alessandro Carminati wrote: > A helper function, `__kunit_is_suppressed_warning()`, is used to determine > whether suppression applies. It is marked as `noinstr`, since some `WARN*()` > sites reside in non-instrumentable sections. As it uses `strcmp`, a > `

Re: [PATCH v5 1/5] bug/kunit: Core support for suppressing warning backtraces

2025-05-30 Thread Peter Zijlstra
On Thu, May 29, 2025 at 10:46:15AM -0700, Kees Cook wrote: > Doing it on the other end doesn't look great (see the other reply). I was > suggesting it's not on fast path because the added code is a dependant > conditional following an "unlikley" conditional. But if you wanted to > push it totally

Re: [PATCH v5 1/5] bug/kunit: Core support for suppressing warning backtraces

2025-05-29 Thread Peter Zijlstra
On Wed, May 28, 2025 at 03:47:42PM -0700, Kees Cook wrote: > On Mon, May 26, 2025 at 01:27:51PM +, Alessandro Carminati wrote: > > Some unit tests intentionally trigger warning backtraces by passing bad > > parameters to kernel API functions. Such unit tests typically check the > > return value

Re: [PATCH v5 1/5] bug/kunit: Core support for suppressing warning backtraces

2025-05-29 Thread Peter Zijlstra
On Mon, May 26, 2025 at 01:27:51PM +, Alessandro Carminati wrote: > #define __WARN() __WARN_FLAGS(BUGFLAG_TAINT(TAINT_WARN)) > #define __WARN_printf(taint, arg...) do {\ > - instrumentation_begin();\ > -

Re: clang and drm issue: objtool warnings from clang build

2025-04-29 Thread Peter Zijlstra
On Mon, Apr 28, 2025 at 12:34:27PM -0700, Linus Torvalds wrote: > And yes, this really is a very potential and real security issue. In > the kernel I don't think we have this ever happening, partly because a > lot of configurations use gcc which afaik doesn't have this particular > horrendous mode

Re: [PATCH v4 06/14] x86: Add support for suppressing warning backtraces

2025-04-02 Thread Peter Zijlstra
On Tue, Apr 01, 2025 at 10:53:46AM -0700, Guenter Roeck wrote: > > > #define _BUG_FLAGS(ins, flags, extra) > > > \ > > > do { > > > \ > > > asm_inline volatile("1:\t" ins "\n"

Re: [PATCH v4 06/14] x86: Add support for suppressing warning backtraces

2025-04-02 Thread Peter Zijlstra
On Tue, Apr 01, 2025 at 10:53:46AM -0700, Guenter Roeck wrote: > > > @@ -92,7 +102,8 @@ do { > > > \ > > > do {\ > > > __auto_type __flags = BUGFLAG_WARNING|(flags);

Re: [PATCH v4 06/14] x86: Add support for suppressing warning backtraces

2025-04-01 Thread Peter Zijlstra
On Thu, Mar 13, 2025 at 11:43:21AM +, Alessandro Carminati wrote: > From: Guenter Roeck > > Add name of functions triggering warning backtraces to the __bug_table > object section to enable support for suppressing WARNING backtraces. > > To limit image size impact, the pointer to the functio

Re: [PATCH 3/5] perf: Add pmu get/put

2024-10-31 Thread Peter Zijlstra
On Thu, Oct 31, 2024 at 12:07:42AM -0500, Lucas De Marchi wrote: > On Wed, Oct 23, 2024 at 12:07:58AM -0500, Lucas De Marchi wrote: > > On Tue, Oct 22, 2024 at 11:52:10PM +0200, Peter Zijlstra wrote: > > > On Fri, Oct 18, 2024 at 02:46:31PM -0500, Lucas De Marchi wrote: > >

Re: [PATCH 3/5] perf: Add pmu get/put

2024-10-22 Thread Peter Zijlstra
On Fri, Oct 18, 2024 at 02:46:31PM -0500, Lucas De Marchi wrote: > I will give this a try with i915 and/or xe. Less horrible version here: git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/pmu-unregister I've just pushed it out to the robots, but it builds, passes perf test

Re: [PATCH 3/5] perf: Add pmu get/put

2024-10-16 Thread Peter Zijlstra
On Mon, Oct 14, 2024 at 09:25:19PM +0200, Peter Zijlstra wrote: > Let me ponder that a little bit. So I did the thing on top of the get/put thing that would allow you to get rid of the ->closed thing, and before I was finished I already hated all of it :-( The thing is, if you're g

Re: [PATCH 1/5] perf: Add dummy pmu module

2024-10-16 Thread Peter Zijlstra
On Tue, Oct 08, 2024 at 01:34:57PM -0500, Lucas De Marchi wrote: > +static int parse_device(const char __user *ubuf, size_t size, u32 *instance) > +{ > + char buf[16]; > + ssize_t len; > + > + if (size > sizeof(buf) - 1) > + return -E2BIG; > + > + len = strncpy_from_user

Re: [PATCH 3/5] perf: Add pmu get/put

2024-10-14 Thread Peter Zijlstra
On Mon, Oct 14, 2024 at 01:20:34PM -0500, Lucas De Marchi wrote: > On Mon, Oct 14, 2024 at 07:32:46PM +0200, Peter Zijlstra wrote: > > I'm confused.. probably because I still don't have any clue about > > drivers and the above isn't really telling me much either. &g

Re: [PATCH 3/5] perf: Add pmu get/put

2024-10-14 Thread Peter Zijlstra
On Tue, Oct 08, 2024 at 01:34:59PM -0500, Lucas De Marchi wrote: > If a pmu is unregistered while there's an active event, perf will still > access the pmu via event->pmu, even after the event is destroyed. This > makes it difficult for drivers like i915 that can be unbound from the > HW. > >

Re: [PATCH v2] locking/ww_mutex: Adjust to lockdep nest_lock requirements

2024-10-09 Thread Peter Zijlstra
On Wed, Oct 09, 2024 at 11:20:31AM +0200, Thomas Hellström wrote: > When using mutex_acquire_nest() with a nest_lock, lockdep refcounts the > number of acquired lockdep_maps of mutexes of the same class, and also > keeps a pointer to the first acquired lockdep_map of a class. That pointer > is then

Re: [PATCH RESEND] locking/ww_mutex: Adjust to lockdep nest_lock requirements

2024-10-04 Thread Peter Zijlstra
On Wed, Oct 02, 2024 at 02:56:11PM +0200, Thomas Hellström wrote: > When using mutex_acquire_nest() with a nest_lock, lockdep refcounts the > number of acquired lockdep_maps of mutexes of the same class, and also > keeps a pointer to the first acquired lockdep_map of a class. That pointer > is then

Re: [PATCH 6/7] drm/i915/pmu: Lazy unregister

2024-07-24 Thread Peter Zijlstra
On Tue, Jul 23, 2024 at 10:30:08AM -0500, Lucas De Marchi wrote: > On Tue, Jul 23, 2024 at 09:03:25AM GMT, Tvrtko Ursulin wrote: > > > > On 22/07/2024 22:06, Lucas De Marchi wrote: > > > Instead of calling perf_pmu_unregister() when unbinding, defer that to > > > the destruction of i915 object. Si

Re: [PATCH 5/5] fs: Convert struct file::f_count to refcount_long_t

2024-05-03 Thread Peter Zijlstra
On Fri, May 03, 2024 at 11:37:25AM +0200, Christian Brauner wrote: > On Thu, May 02, 2024 at 05:41:23PM -0700, Kees Cook wrote: > > On Fri, May 03, 2024 at 01:14:45AM +0100, Al Viro wrote: > > > On Thu, May 02, 2024 at 05:10:18PM -0700, Kees Cook wrote: > > > > > > > But anyway, there needs to be

Re: [PATCH v3 0/4] mm: convert to vma_is_initial_heap/stack()

2023-07-31 Thread Peter Zijlstra
++ > kernel/events/core.c | 33 ++-- > security/selinux/hooks.c | 7 ++ > 6 files changed, 44 insertions(+), 65 deletions(-) Acked-by: Peter Zijlstra (Intel)

Re: [PATCH v2 03/47] mm: shrinker: add infrastructure for dynamically allocating shrinker

2023-07-24 Thread Peter Zijlstra
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(

Re: [PATCH v2 4/4] perf/core: use vma_is_initial_stack() and vma_is_initial_heap()

2023-07-19 Thread Peter Zijlstra
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 :/

Re: Consider switching to WQ_UNBOUND messages (was: Re: [PATCH v2 6/7] workqueue: Report work funcs that trigger automatic CPU_INTENSIVE mechanism)

2023-07-12 Thread Peter Zijlstra
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

Re: Consider switching to WQ_UNBOUND messages (was: Re: [PATCH v2 6/7] workqueue: Report work funcs that trigger automatic CPU_INTENSIVE mechanism)

2023-07-12 Thread Peter Zijlstra
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. >

Re: [Intel-gfx] [PATCH v5 0/7] Introduce __xchg, non-atomic xchg

2023-02-27 Thread Peter Zijlstra
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

Re: [PATCH v5 0/7] Introduce __xchg, non-atomic xchg

2023-02-22 Thread Peter Zijlstra
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_

Re: [PATCH v2 1/6] mm: introduce vma->vm_flags modifier functions

2023-01-25 Thread Peter Zijlstra
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 { >

Re: [PATCH v2 20/20] jump_label: RFC - tolerate toggled state

2023-01-17 Thread Peter Zijlstra
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

Re: [PATCH mm-unstable v1 20/20] mm: rename FOLL_FORCE to FOLL_PTRACE

2022-11-18 Thread Peter Zijlstra
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

Re: [PATCH 15/15] seqlock: drop seqcount_ww_mutex_t

2022-04-07 Thread Peter Zijlstra
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)

Re: [PATCH] locking/rwsem: drop redundant semicolon of down_write_nest_lock

2022-01-14 Thread Peter Zijlstra
ush this upstream through the drm subsystem? Nah, take it. Acked-by: Peter Zijlstra (Intel)

Re: [PATCH 0/2] Nuke PAGE_KERNEL_IO

2021-11-12 Thread Peter Zijlstra
| 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)

Re: printk deadlock due to double lock attempt on current CPU's runqueue

2021-11-10 Thread Peter Zijlstra
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

Re: printk deadlock due to double lock attempt on current CPU's runqueue

2021-11-09 Thread Peter Zijlstra
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

Re: [Intel-gfx] [PATCH 2/4] mm: add a io_mapping_map_user helper

2021-10-20 Thread Peter Zijlstra
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

Re: [PATCH 8/8] drm/i915: Don't disable interrupts and pretend a lock as been acquired in __timeline_mark_lock().

2021-10-05 Thread Peter Zijlstra
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,

Re: [RFC 1/6] sched: Add nice value change notifier

2021-10-04 Thread Peter Zijlstra
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 > >

Re: [RFC 1/6] sched: Add nice value change notifier

2021-10-01 Thread Peter Zijlstra
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

Re: [RFC 0/6] CPU + GPU synchronised priority scheduling

2021-09-30 Thread Peter Zijlstra
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.

Re: [RFC 1/6] sched: Add nice value change notifier

2021-09-30 Thread Peter Zijlstra
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

Re: [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.

2021-09-17 Thread Peter Zijlstra
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. > > >

Re: [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.

2021-09-16 Thread Peter Zijlstra
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

Re: [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.

2021-09-13 Thread Peter Zijlstra
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

Re: [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.

2021-09-10 Thread Peter Zijlstra
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

Re: [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.

2021-09-10 Thread Peter Zijlstra
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

Re: [PATCH] kernel/locking: Add context to ww_mutex_trylock.

2021-09-09 Thread Peter Zijlstra
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")

Re: [PATCH] kernel/locking: Add context to ww_mutex_trylock.

2021-09-08 Thread Peter Zijlstra
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

Re: [PATCH v2 0/2] locking/lockdep, drm: apply new lockdep assert in drm_auth.c

2021-08-02 Thread Peter Zijlstra
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

Re: [PATCH 1/3] drm: use the lookup lock in drm_is_current_master

2021-07-29 Thread Peter Zijlstra
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!

Re: [PATCH 1/3] drm: use the lookup lock in drm_is_current_master

2021-07-27 Thread Peter Zijlstra
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

Re: [PATCH 1/2] locking/rwsem: Add down_write_interruptible

2021-03-09 Thread Peter Zijlstra
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

Re: [PATCH] mutex: nuke mutex_trylock_recursive

2021-02-16 Thread Peter Zijlstra
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: > > >

Re: [PATCH] mutex: nuke mutex_trylock_recursive

2021-02-16 Thread 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: > > 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

Re: [PATCH] drm/syncobj: make lockdep complain on WAIT_FOR_SUBMIT v3

2021-01-19 Thread Peter Zijlstra
_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

Re: [PATCH] drm/syncobj: make lockdep complain on WAIT_FOR_SUBMIT v2

2021-01-19 Thread Peter Zijlstra
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

Re: [PATCH] drm/syncobj: make lockdep complain on WAIT_FOR_SUBMIT v2

2021-01-19 Thread Peter Zijlstra
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

Re: [PATCH 3/3] locking/selftests: Add testcases for fs_reclaim

2020-11-20 Thread Peter Zijlstra
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

Re: [PATCH v2 0/3] drm: commit_work scheduling

2020-10-06 Thread Peter Zijlstra
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

Re: [External] Re: [PATCH 2/2] sched: mark PRINTK_DEFERRED_CONTEXT_MASK in __schedule()

2020-09-29 Thread Peter Zijlstra
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

Re: [External] Re: [PATCH 2/2] sched: mark PRINTK_DEFERRED_CONTEXT_MASK in __schedule()

2020-09-28 Thread Peter Zijlstra
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

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-24 Thread Peter Zijlstra
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.

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-24 Thread Peter Zijlstra
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

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

2020-04-09 Thread Peter Zijlstra
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

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

2020-04-08 Thread Peter Zijlstra
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

Re: decruft the vmalloc API

2020-04-08 Thread Peter Zijlstra
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

Re: [PATCH 17/28] mm: remove the prot argument from vm_map_ram

2020-04-08 Thread Peter Zijlstra
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-

Re: rcu_barrier() no longer allowed within mmap_sem?

2020-03-30 Thread Peter Zijlstra
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

Re: linux-next: build failure after merge of the tip tree

2019-11-21 Thread Peter Zijlstra
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

Re: [PATCH -next] treewide: remove unused argument in lock_release()

2019-10-08 Thread Peter Zijlstra
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

Re: [PATCH -next] treewide: remove unused argument in lock_release()

2019-09-30 Thread Peter Zijlstra
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

Re: [PATCH 3/4] kernel.h: Add non_block_start/end()

2019-08-23 Thread Peter Zijlstra
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. __

Re: [PATCH 3/4] kernel.h: Add non_block_start/end()

2019-08-23 Thread Peter Zijlstra
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

Re: [PATCH 3/4] kernel.h: Add non_block_start/end()

2019-08-23 Thread Peter Zijlstra
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

Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites

2019-08-02 Thread Peter Zijlstra
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

Re: [PATCH 1/2] dma-buf: add reservation_context for deadlock handling

2019-06-25 Thread Peter Zijlstra
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

Re: [RFC][PATCH] wake_up_var() memory ordering

2019-06-25 Thread Peter Zijlstra
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

Re: [RFC][PATCH] wake_up_var() memory ordering

2019-06-25 Thread Peter Zijlstra
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 > >

Re: [RFC][PATCH] wake_up_var() memory ordering

2019-06-25 Thread Peter Zijlstra
(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

[RFC][PATCH] wake_up_var() memory ordering

2019-06-24 Thread Peter Zijlstra
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

Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir

2019-06-19 Thread Peter Zijlstra
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 -

Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir

2019-06-19 Thread Peter Zijlstra
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

Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir

2019-06-19 Thread Peter Zijlstra
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 - >

Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir

2019-06-19 Thread Peter Zijlstra
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

Re: [PATCH 3/6] drm/gem: use new ww_mutex_(un)lock_for_each macros

2019-06-14 Thread Peter Zijlstra
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); ({ \ > > +

Re: [PATCH 3/6] drm/gem: use new ww_mutex_(un)lock_for_each macros

2019-06-14 Thread Peter Zijlstra
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(+),

Re: [PATCH 3/6] drm/gem: use new ww_mutex_(un)lock_for_each macros

2019-06-14 Thread Peter Zijlstra
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(+),

Re: [PATCH 1/6] locking: add ww_mutex_(un)lock_for_each helpers

2019-06-14 Thread Peter Zijlstra
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

Re: [PATCH v3 08/18] objtool: add kunit_try_catch_throw to the noreturn list

2019-05-14 Thread Peter Zijlstra
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: > > >

Re: [PATCH v3 08/18] objtool: add kunit_try_catch_throw to the noreturn list

2019-05-13 Thread Peter Zijlstra
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

Re: [PATCH] RFC: console: hack up console_lock more v3

2019-05-09 Thread Peter Zijlstra
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

Re: [PATCH] RFC: console: hack up console_lock more v3

2019-05-09 Thread Peter Zijlstra
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

  1   2   3   >