linux-kernel - Re: [PATCH RT] nvdimm: make lane acquirement RT aware

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] [day] [month] [year] [list]

Message-ID: <20190328173858.hpbtoep42ucomav2@linutronix.de>
Date:   Thu, 28 Mar 2019 18:38:59 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     "Liu, Yongxin" <Yongxin.Liu@...driver.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-rt-users@...r.kernel.org" <linux-rt-users@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "pagupta@...hat.com" <pagupta@...hat.com>,
        "Gortmaker, Paul" <Paul.Gortmaker@...driver.com>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>
Subject: Re: [PATCH RT] nvdimm: make lane acquirement RT aware

On 2019-03-18 11:48:28 [+0000], Liu, Yongxin wrote:
> 
> > 
> > Bummer. That would dead lock indeed.
> > Is it easily possible to recognize the recursive case?
> 
> Not easily. I don't have test case for recursive call. 
> For now, just code analysis.

So I've been playing with qemu's nvdimm device. So I *think* the
recursive case is here not possible because qemu only supports pmem
while it would require the blk mode to trigger it. It is just a wild
guess…

On top of qemu's nvdimm device I can create a block device via
	ndctl create-namespace  namespace0.0 --mode=sector

and then I trigger the code path in question.

I would *really* prefer to understand the recursive case and avoid it.
That way the recursive case is explicitly known and uses another path.
The lock can then be always acquired which gives you always lockdep
coverage (which is now missing unless you have more LANEs than CPUs).

The local_lock thingy is completely unneeded: a simple get_cpu_light()
would do the job.

> Yongxin

Sebastian