lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 5 Oct 2017 18:28:40 +0200
From:   Daniel Vetter <>
To:     Thomas Gleixner <>, Tejun Heo <>,
        Lai Jiangshan <>
Cc:     Daniel Vetter <>,
        Daniel Vetter <>,
        Intel Graphics Development <>,
        LKML <>,
        Chris Wilson <>,
        Tvrtko Ursulin <>,
        Joonas Lahtinen <>,
        Peter Zijlstra <>,
        Sasha Levin <>,
        Daniel Vetter <>
Subject: Re: [PATCH] drm/i915: Preallocate mmu notifier to unbreak cpu
 hotplug deadlock

On Thu, Oct 05, 2017 at 06:19:30PM +0200, Thomas Gleixner wrote:
> On Thu, 5 Oct 2017, Daniel Vetter wrote:
> > On Thu, Oct 05, 2017 at 05:23:20PM +0200, Thomas Gleixner wrote:
> > > Aside of that, is it really required to use stomp_machine() for this
> > > synchronization? We certainly have less intrusive mechansisms than that.
> > 
> > Yeah, the stop_machine needs to go, I'm working on something that uses
> > rcu_read_lock+synchronize_rcu for this case. Probably shouldn't have
> > merged even.
> > 
> > Now this one isn't the one I wanted to fix with this patch since there's
> > clearly something dubious going on on the i915 side too.
> I already wondered :)
> > The proper trace, with the same part on the cpu hotplug side, highlights
> > that you can't allocate a workqueue while hodling mmap_sem. That one
> > matches patch description&diff a bit better :-)
> > Sorry for misleading you, should have checked to attach the right one. No
> > stop_machine()/i915_gem_set_wedged() in the below one.
> Well the problem is more or less the same and what I said about solving it
> in a different place is still valid. I think about it some more, but don't
> expect wonders :)

Yeah just want to make you aware there's now new implications in the
locking maze and that we overall decide to break the loop in the right
place. Also adding Tejun, since this is about workqueues, I forgot him.

tldr for Tejun: The new cross-release stuff in lockdep seems to indicate
that we cannot allocate a new workqueue while holding mmap_sem. Full
details in the thread.
Daniel Vetter
Software Engineer, Intel Corporation

Powered by blists - more mailing lists