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
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 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,
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 Wed, May 12, 2021 at 11:57:02AM +0200, Hans de Goede wrote:
> Hi All,
>
> I'm not sure if this is a i915 bug, or caused by changes elsewhere in the
> kernel,
> so I thought it would be best to just send out an email and then see from
> there.
>
> With 5.13-rc1 gdm fails to show and dmesg con
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
On Wed, Apr 07, 2021 at 09:18:51AM -0400, Rodrigo Vivi wrote:
> On Thu, Jun 04, 2020 at 12:11:07PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 02, 2020 at 08:27:10PM +0200, Peter Zijlstra wrote:
> > > On Tue, Jun 02, 2020 at 06:08:03PM +, Souza, Jose wrote:
> > >
Avoid using apply_to_page_range() from modules, use the safer
verify_page_range() instead.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/xen/privcmd.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -946,9 +946,9
Now that all module users of apply_to_page_range() have been removed,
unexport this function.
This is an unsafe function in that it gives direct access to the
page-tables.
Signed-off-by: Peter Zijlstra (Intel)
---
mm/memory.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a
There are no modular in-tree users, remove the EXPORT.
This is an unsafe function in that it gives direct access to the
page-tables.
Signed-off-by: Peter Zijlstra (Intel)
---
mm/memory.c |1 -
1 file changed, 1 deletion(-)
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2558,7 +2558,6 @@ int
Hi,
These patches remove the last few modular apply_to_page_range() users and
unexports these interface. Since these functions provide direct access to our
page-tables they're a prime target for nefarious activities.
These patches rely on the remap_pfn_range_notrack() patches from Christoph that
check_{present,absent}() only need R/O access, use verify_page_range()
instead to remove modular use of apply_to_page_range().
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 16
1 file changed, 8 insertions(+), 8 deletions
Instead of relying on apply_to_page_range() being available to
modules, move its use into core kernel code and export it's
application.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/xen/gntdev-common.h |2 ++
drivers/xen/gntdev.c| 30 +-
driver
Introduce and EXPORT a read-only counterpart to apply_to_page_range().
It only exposes the PTE value, not a pointer to the pagetables itself
and is thus quite a bit safer to export. A number of
apply_to_page_range() users can be converted to this primitive.
Signed-off-by: Peter Zijlstra (Intel
Instead of relying on apply_to_page_range() being available to
modules, move its use into core kernel code and export it's
application.
NOTE: ideally we do: use_ptemod = !auto_translate_physmap &&
gnttab_map_avail_bits and remove this hack.
Signed-off-by: Peter Zijlstra (Intel)
On Mon, Apr 12, 2021 at 10:27:21AM +0200, Christoph Hellwig wrote:
> On Mon, Apr 12, 2021 at 10:00:15AM +0200, Peter Zijlstra wrote:
> > --- a/drivers/xen/grant-table.c
> > +++ b/drivers/xen/grant-table.c
> > @@ -1591,6 +1591,43 @@ int gnttab_init(void)
> > }
> &g
On Mon, Apr 12, 2021 at 10:28:05AM +0200, Christoph Hellwig wrote:
> On Mon, Apr 12, 2021 at 10:00:16AM +0200, Peter Zijlstra wrote:
> > +extern int verify_page_range(struct mm_struct *mm,
>
> No need for the extern here.
It's consistent with the rest of the functions there
On Mon, Apr 12, 2021 at 10:26:40AM +0200, Christoph Hellwig wrote:
> On Mon, Apr 12, 2021 at 10:00:14AM +0200, Peter Zijlstra wrote:
> > Instead of relying on apply_to_page_range() being available to
> > modules, move its use into core kernel code and export it's
> > appl
On Mon, Apr 12, 2021 at 09:00:16AM -, Patchwork wrote:
> == Series Details ==
>
> Series: mm: Unexport apply_to_page_range()
> URL : https://patchwork.freedesktop.org/series/88943/
> State : failure
>
> == Summary ==
>
> CALLscripts/checksyscalls.sh
> CALLscripts/atomic/check-ato
On Mon, Apr 12, 2021 at 01:05:09PM -0700, Kees Cook wrote:
> On Mon, Apr 12, 2021 at 10:00:16AM +0200, Peter Zijlstra wrote:
> > +struct vpr_data {
> > + int (*fn)(pte_t pte, unsigned long addr, void *data);
> > + void *data;
> > +};
>
> Eeerg. This is likely
On Mon, Apr 12, 2021 at 01:08:38PM -0700, Kees Cook wrote:
> On Mon, Apr 12, 2021 at 10:00:18AM +0200, Peter Zijlstra wrote:
> > @@ -1249,14 +1249,14 @@ static int check_absent_pte(pte_t *pte,
> >
> > static int check_present(unsigned long addr, unsigned long len)
On Mon, Apr 12, 2021 at 01:05:09PM -0700, Kees Cook wrote:
> On Mon, Apr 12, 2021 at 10:00:16AM +0200, Peter Zijlstra wrote:
> > +struct vpr_data {
> > + int (*fn)(pte_t pte, unsigned long addr, void *data);
> > + void *data;
> > +};
>
> Eeerg. This is likely
On Tue, Apr 13, 2021 at 08:01:08PM -0700, Kees Cook wrote:
> So the addr can just be encoded in "int", and no structure is needed at:
>
> typedef bool (*vpr_fn_t)(pte_t pte);
>
> static int vpr_fn(pte_t *pte, unsigned long addr, void *data)
> {
> vpr_fn_t callback = data;
>
> if (!ca
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 11:32:57AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-05-06 08:45:53)
> > +/**
> > + * printk_safe_up - release the semaphore in console_unlock
> > + * @sem: the semaphore to release
> > + *
> > + * Release the semaphore. Unlike mutexes, up() may be called fro
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 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 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)
___
Intel-gfx mailing list
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
On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> I do not see any scheduler guys Cced and it would be really great to get
> their opinion here.
>
> On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off
On Mon, Dec 10, 2018 at 05:20:10PM +0100, Michal Hocko wrote:
> > OK, no real objections to the thing. Just so long we're all on the same
> > page as to what it does and doesn't do ;-)
>
> I am not really sure whether there are other potential users besides
> this one and whether the check as suc
On Mon, Dec 10, 2018 at 04:01:59PM +0100, Michal Hocko wrote:
> On Mon 10-12-18 15:47:11, Peter Zijlstra wrote:
> > On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> > > I do not see any scheduler guys Cced and it would be really great to get
> > > their op
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 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)
| 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)
On Tue, Feb 08, 2022 at 10:41:56AM -0800, Namhyung Kim wrote:
> Eventually I'm mostly interested in the contended locks only and I
> want to reduce the overhead in the fast path. By moving that, it'd be
> easy to track contended locks with timing by using two tracepoints.
So why not put in two n
On Wed, Feb 09, 2022 at 03:17:38PM -0500, Waiman Long wrote:
>
> On 2/9/22 14:45, Namhyung Kim wrote:
> > On Wed, Feb 9, 2022 at 11:28 AM Mathieu Desnoyers
> > wrote:
> > > - On Feb 9, 2022, at 2:22 PM, Namhyung Kim namhy...@kernel.org wrote:
> > > > I'm also concerning dynamic allocated lock
On Wed, Feb 09, 2022 at 04:32:58PM -0800, Namhyung Kim wrote:
> On Wed, Feb 9, 2022 at 1:09 AM Peter Zijlstra wrote:
> >
> > On Tue, Feb 08, 2022 at 10:41:56AM -0800, Namhyung Kim wrote:
> >
> > > Eventually I'm mostly interested in the contended locks only and
On Thu, Feb 10, 2022 at 09:55:27PM -0800, Namhyung Kim wrote:
> So you are ok with adding two new tracepoints, even if they are
> similar to what we already have in lockdep/lock_stat, right?
Yeah, I don't think adding tracepoints to the slowpaths of the various
locks should be a problem.
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 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 Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote:
>
> Open access to perf_events monitoring for CAP_SYS_PERFMON privileged
> processes. For backward compatibility reasons access to perf_events
> subsystem remains open for CAP_SYS_ADMIN privileged processes but
> CAP_SYS_ADMIN usage
On Thu, Jan 09, 2020 at 02:36:50PM +0300, Alexey Budankov wrote:
> On 08.01.2020 19:07, Peter Zijlstra wrote:
> > On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote:
> >> diff --git a/kernel/events/core.c b/kernel/events/core.c
> >> index 059ee7116008..d9d
On Tue, Mar 10, 2020 at 02:41:54PM -0700, Francisco Jerez wrote:
> +static void cpu_response_frequency_qos_apply(struct pm_qos_request *req,
> + enum pm_qos_req_action action,
> + s32 value)
> +{
> + int ret = pm_
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 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
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 Tue, Aug 20, 2019 at 10:19:50AM +0200, Daniel Vetter wrote:
> Necessary to annotate functions where we might acquire a
> mutex_lock_nested() or similar. Needed by i915.
>
> Signed-off-by: Daniel Vetter
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Will De
On Tue, Aug 20, 2019 at 10:19:51AM +0200, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index a0b1fa8a3224..b3fd6aac93bc 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915
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.
__
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 Mon, Apr 27, 2020 at 08:22:47PM -0700, Francisco Jerez wrote:
> This addresses the technical concerns people brought up about my
> previous v2 revision of this series. Other than a few bug fixes, the
> only major change relative to v2 is that the controller is now exposed
> as a new CPUFREQ gen
Hi All,
My desktop (Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz) is spewing tons
and tons of:
[ 778.461227] [drm:gen8_de_irq_handler [i915]] *ERROR* Fault errors on pipe B:
0x0080
[ 778.477763] [drm:gen8_de_irq_handler [i915]] *ERROR* Fault errors on pipe B:
0x0080
[ 778.577718] [drm:g
On Tue, Jun 02, 2020 at 06:08:03PM +, Souza, Jose wrote:
> Hi Peter
> Please file a bug by follow this instructions:
> https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
*sigh*, top posting and webforms :-(
Steps to reproduce: Boot into X
How often: Always
uname -r: 5.6
On Mon, Jul 13, 2020 at 03:51:52PM -0300, Arnaldo Carvalho de Melo wrote:
> > > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > > index 856d98c36f56..a2397f724c10 100644
> > > --- a/kernel/events/core.c
> > > +++ b/kernel/events/core.c
> > > @@ -11595,7 +11595,7 @@ SYSCALL_DEFINE5(per
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 Thu, Feb 27, 2020 at 07:03:42PM -0600, Josh Poimboeuf wrote:
> > And why not mark gen8_canonical_addr() __always_inline?
>
> Right, marking those two functions as __always_inline is the other
> option. The problem is, if you keep doing it, eventually you end up
> with __always_inline-itis spre
On Wed, Nov 29, 2017 at 04:41:45PM +0100, Daniel Vetter wrote:
> cross-release ftl
>
> From Chris:
>
> "Fwiw, this isn't cross-release but us reloading the module many times,
> creating a whole host of new lockclasses. Even more fun is when the
> module gets a slightly different address and the n
On Thu, Dec 07, 2017 at 11:08:49AM +0100, Daniel Vetter wrote:
> Since -rc1 we're hitting a bunch of lockdep splats using the new
> cross-release stuff around the 2 kthread completions. In all cases
> they are because totally independent uses of kthread are mixed up by
> lockdep into the same locki
On Thu, Dec 07, 2017 at 03:58:28PM +0100, Daniel Vetter wrote:
> [ 85.069417] gem_exec_captur/2810 is trying to acquire lock:
> [ 85.069419] ((completion)&self->parked){+.+.}, at: []
> kthread_park+0x3d/0x50
> [ 85.069426]
>but task is already holding lock:
> [ 85.069428
On Thu, Dec 07, 2017 at 09:56:57PM +0100, Daniel Vetter wrote:
> On Thu, Dec 07, 2017 at 08:57:09PM +0100, Peter Zijlstra wrote:
> > Is what it says I suppose. Now I don't know enough about that i915 code
> > to say if that breadcrumbs_signal thread can ever trigger a fau
ue to the many entry points this is slightly
> tedious.
>
> Cc: Tvrtko Ursulin
> Cc: Marta Lofstedt
> Cc: Byungchul Park
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Tejun Heo
> Cc: Kees Cook
> Cc: Thomas Gleixner
> Cc: Shaohua Li
> Cc: Andrew Morton
&
On Fri, Dec 08, 2017 at 05:36:28PM +0100, Daniel Vetter wrote:
> Aside: Could/should we take some fake lockdep locks around these
> callbacks, since not all drivers call them from a hardirq context? Just to
> validate that everyone follows the contract.
What I typically do is use local_irq_save/r
On Wed, Dec 13, 2017 at 06:36:33PM +0100, Sebastian Andrzej Siewior wrote:
> +peterz
> context: http://www.spinics.net/lists/intel-gfx/msg149011.html
>
> On 2017-12-13 17:37:21 [+0200], Joonas Lahtinen wrote:
> > On Wed, 2017-12-13 at 16:06 +0100, Sebastian Andrzej Siewior wrote:
> > > On 2017-12-
On Thu, Apr 12, 2018 at 11:34:54AM -0700, Francisco Jerez wrote:
> The reason for the energy efficiency problem of iowait boosting is
> precisely the greater oscillation between turbo and idle. Say that
> iowait boost increases the frequency by a factor alpha relative to the
> optimal frequency f0
On Thu, Apr 12, 2018 at 12:55:39PM -0700, Francisco Jerez wrote:
> Actually assuming that a single geometric feature of the power curve is
> known -- it being convex in the frequency range allowed by the policy
> (which is almost always the case, not only for Intel CPUs), the optimal
> frequency fo
On Fri, Apr 13, 2018 at 06:57:39PM -0700, Francisco Jerez wrote:
> Peter Zijlstra writes:
>
> > On Thu, Apr 12, 2018 at 12:55:39PM -0700, Francisco Jerez wrote:
> >> Actually assuming that a single geometric feature of the power curve is
> >> known -- it being
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 Wed, Apr 12, 2017 at 12:04:00PM +, Lofstedt, Marta wrote:
> Hi,
>
> We have this "old" Lenovo Cantiga laptop(Intel Core 2 Duo L9400), hocked up
> to our i915 pre-merge CI system, that has started to give unstable results
> after commit:
>
> commit 7b09cc5a9debc86c903c2eff8f8a1fdef773c649
On Wed, Apr 12, 2017 at 04:30:32PM +0300, Jani Nikula wrote:
> On Wed, 12 Apr 2017, Peter Zijlstra wrote:
> > On Wed, Apr 12, 2017 at 12:04:00PM +, Lofstedt, Marta wrote:
> >> The issue is describe more in detail here:
> >> https://bugs.freedesktop.org/show_bug.cg
On Wed, Apr 12, 2017 at 04:40:11PM +0300, Martin Peres wrote:
> > > So, why is this only affecting the Core 2 Duo?
> >
> > Core2 doesn't have a usable TSC and would revert to the slow path. I'll
> > have another look at that patch.
> >
>
> So, by default, it is using the hpet clock source. FYI,
On Wed, Apr 12, 2017 at 05:49:53PM +0300, Martin Peres wrote:
>
>
> On 12/04/17 17:32, Peter Zijlstra wrote:
> > On Wed, Apr 12, 2017 at 04:40:11PM +0300, Martin Peres wrote:
> >
> > > > > So, why is this only affecting the Core 2 Duo?
> > > >
&
On Wed, Apr 12, 2017 at 05:49:53PM +0300, Martin Peres wrote:
> Good to know. Is there a way to disable this behaviour, as a workaround for
> our CI system until a proper fix lands? We already pushed locally the revert
> for this patch, but that may affect other platforms which do not exhibit the
On Thu, Apr 13, 2017 at 03:30:25PM +0300, Martin Peres wrote:
> On 13/04/17 14:48, Peter Zijlstra wrote:
> > On Wed, Apr 12, 2017 at 05:49:53PM +0300, Martin Peres wrote:
> >
> > > Good to know. Is there a way to disable this behaviour, as a workaround
> > >
On Tue, Apr 18, 2017 at 02:10:07PM +, Lofstedt, Marta wrote:
> Sorry Peter, I still see regression on the Core2 machine, with your patch.
>
Blergh, ok. I'll see if I can dig out an actual Core2 machine somewhere.
I should have enough parts about.
__
On Tue, Apr 18, 2017 at 05:53:56PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 18, 2017 at 02:10:07PM +, Lofstedt, Marta wrote:
> > Sorry Peter, I still see regression on the Core2 machine, with your patch.
> >
>
> Blergh, ok. I'll see if I can dig out an actual Co
On Thu, Apr 20, 2017 at 07:19:50PM +0200, Peter Zijlstra wrote:
> Just for my sanity, could you confirm "tsc=unstable" (which requires the
> patch) actually works for you?
Also, could you get me the dmesg of a 'broken' boot?
On Mon, Jul 09, 2018 at 10:36:49AM +0200, Daniel Vetter wrote:
> Avoids complaints from gcc about ambiguous else clauses.
Is that a new thing? I'm fairly sure I've never seen it do that,
> Signed-off-by: Daniel Vetter
> Cc: Andrew Morton
> Cc: Peter Zijlstra
> ---
&g
On Mon, Jul 09, 2018 at 05:00:07PM +0200, Daniel Vetter wrote:
> On Mon, Jul 9, 2018 at 12:36 PM, Peter Zijlstra wrote:
> > On Mon, Jul 09, 2018 at 10:36:49AM +0200, Daniel Vetter wrote:
> >> #define for_each_node_with_cpus(node)\
> >>
On Mon, Jul 09, 2018 at 05:52:04PM +0200, Daniel Vetter wrote:
> for_each_something(foo)
> if (foo->bla)
> call_bla(foo);
> else
> call_default(foo);
>
> Totally contrived, but this complains. Liberally sprinkling {} also shuts
> up the compiler, but it's a
1 - 100 of 174 matches
Mail list logo
