Return-path: Received: from mx2.suse.de ([195.135.220.15]:51369 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751940AbdHCLe2 (ORCPT ); Thu, 3 Aug 2017 07:34:28 -0400 Date: Thu, 3 Aug 2017 13:34:25 +0200 (CEST) From: Jiri Kosina To: "Coelho, Luciano" cc: "linux-kernel@vger.kernel.org" , linuxwifi , "Zhang, Rui" , "edubezval@gmail.com" , "linux-pm@vger.kernel.org" , "Weinehall, David" , "Berg, Johannes" , "kvalo@codeaurora.org" , "Sharon, Sara" , "linux-wireless@vger.kernel.org" , "Grumbach, Emmanuel" Subject: Re: [linuxwifi] x86/thermal: AB-BA dependency between mvm->mutex and tz->lock In-Reply-To: <1501759724.15969.49.camel@intel.com> Message-ID: (sfid-20170803_133441_875744_6CD89E95) References: <1501753405.15969.43.camel@intel.com> <87vam5nf4w.fsf@kamboji.qca.qualcomm.com> <1501759724.15969.49.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-wireless-owner@vger.kernel.org List-ID: On Thu, 3 Aug 2017, Coelho, Luciano wrote: > Okay, so as I understand it the problem has been there for a long time, > but the splat is only coming up now because of Thomas' patch that adds > the lockdep map[1], right? Yeah, sorry, forgot to mention that pre-49dfe2a67797 kernels wouldn't produce this, as there would not be aware of the fact that cpus_read_lock() is actually semantically a lock. > I see the workqueue allocation you mentioned. I'll try to move this > allocation out of the mutex and see how it goes. I have been briefly looking into this as well -- it'll basically have to be moved out of the trans_pcie->mutex context, but (a) I'm not sure whether that's actually safe (b) iwl_pcie_rx_reuse_rbd() (which is where corresponding work is being queued) is not a proper context either (it's atomic context) Thanks, -- Jiri Kosina SUSE Labs