linux-kernel - Re: [v5 0/3] "Hotremove" persistent memory

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: <9bf70d80718d014601361f07813b68e20b089201.camel@intel.com>
Date:   Thu, 2 May 2019 22:29:34 +0000
From:   "Verma, Vishal L" <vishal.l.verma@...el.com>
To:     "pasha.tatashin@...een.com" <pasha.tatashin@...een.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jmorris@...ei.org" <jmorris@...ei.org>,
        "sashal@...nel.org" <sashal@...nel.org>, "bp@...e.de" <bp@...e.de>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "david@...hat.com" <david@...hat.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "tiwai@...e.de" <tiwai@...e.de>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        "jglisse@...hat.com" <jglisse@...hat.com>,
        "zwisler@...nel.org" <zwisler@...nel.org>,
        "mhocko@...e.com" <mhocko@...e.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "Busch, Keith" <keith.busch@...el.com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "Huang, Ying" <ying.huang@...el.com>,
        "Wu, Fengguang" <fengguang.wu@...el.com>,
        "baiyaowei@...s.chinamobile.com" <baiyaowei@...s.chinamobile.com>
Subject: Re: [v5 0/3] "Hotremove" persistent memory

On Thu, 2019-05-02 at 17:44 -0400, Pavel Tatashin wrote:

> > In running with these patches, and testing the offlining part, I ran
> > into the following lockdep below.
> > 
> > This is with just these three patches on top of -rc7.
> 
> Hi Verma,
> 
> Thank you for testing. I wonder if there is a command sequence that I
> could run to reproduce it?
> Also, could you please send your config and qemu arguments.
> 
Yes, here is the qemu config:

qemu-system-x86_64
	-machine accel=kvm
	-machine pc-i440fx-2.6,accel=kvm,usb=off,vmport=off,dump-guest-core=off,nvdimm
	-cpu Haswell-noTSX
	-m 12G,slots=3,maxmem=44G
	-realtime mlock=off
	-smp 8,sockets=2,cores=4,threads=1
	-numa node,nodeid=0,cpus=0-3,mem=6G
	-numa node,nodeid=1,cpus=4-7,mem=6G
	-numa node,nodeid=2
	-numa node,nodeid=3
	-drive file=/virt/fedora-test.qcow2,format=qcow2,if=none,id=drive-virtio-disk1
	-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk1,id=virtio-disk1,bootindex=1
	-object memory-backend-file,id=mem1,share,mem-path=/virt/nvdimm1,size=16G,align=128M
	-device nvdimm,memdev=mem1,id=nv1,label-size=2M,node=2
	-object memory-backend-file,id=mem2,share,mem-path=/virt/nvdimm2,size=16G,align=128M
	-device nvdimm,memdev=mem2,id=nv2,label-size=2M,node=3
	-serial stdio
	-display none

For the command list - I'm using WIP patches to ndctl/daxctl to add the
command I mentioned earlier. Using this command, I can reproduce the
lockdep issue. I thought I should be able to reproduce the issue by
onlining/offlining through sysfs directly too - something like:

   node="$(cat /sys/bus/dax/devices/dax0.0/target_node)"
   for mem in /sys/devices/system/node/node"$node"/memory*; do
     echo "offline" > $mem/state
   done

But with that I can't reproduce the problem.

I'll try to dig a bit deeper into what might be happening, the daxctl
modifications simply amount to doing the same thing as above in C, so
I'm not immediately sure what might be happening.

If you're interested, I can post the ndctl patches - maybe as an RFC -
to test with.

Thanks,
-Vishal