linux-kernel - Re: [linuxwifi] x86/thermal: AB-BA dependency between mvm->mutex and tz->lock

lists.openwall.net		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]

Message-ID: <alpine.LSU.2.20.1708031330570.30597@cbobk.fhfr.pm>
Date:   Thu, 3 Aug 2017 13:34:25 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     "Coelho, Luciano" <luciano.coelho@...el.com>
cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linuxwifi <linuxwifi@...el.com>,
        "Zhang, Rui" <rui.zhang@...el.com>,
        "edubezval@...il.com" <edubezval@...il.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "Weinehall, David" <david.weinehall@...el.com>,
        "Berg, Johannes" <johannes.berg@...el.com>,
        "kvalo@...eaurora.org" <kvalo@...eaurora.org>,
        "Sharon, Sara" <sara.sharon@...el.com>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "Grumbach, Emmanuel" <emmanuel.grumbach@...el.com>
Subject: Re: [linuxwifi] x86/thermal: AB-BA dependency between mvm->mutex
 and tz->lock

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