From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751782AbdJEQ2q (ORCPT ); Thu, 5 Oct 2017 12:28:46 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33340 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751178AbdJEQ2o (ORCPT ); Thu, 5 Oct 2017 12:28:44 -0400 X-Google-Smtp-Source: AOwi7QA0B/b4sOTRInkfoGXwQZtHvC1ZlkBLFCjLepSpyPZBWW74BMYIG4MmspZknNT/fN73LNLbSA== 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 Message-ID: <20171005162840.nr5wkvt6rcmbixmu@phenom.ffwll.local> Mail-Followup-To: Thomas Gleixner , Tejun Heo , Lai Jiangshan , Intel Graphics Development , LKML , Chris Wilson , Tvrtko Ursulin , Joonas Lahtinen , Peter Zijlstra , Sasha Levin , Daniel Vetter References: <20171005132206.21365-1-daniel.vetter@ffwll.ch> <20171005155848.tqiveborg5aqc4ep@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 4.12.0-1-amd64 User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch