linux-kernel - Re: [pmem_attach_disk] WARNING: CPU: 46 PID: 518 at kernel/memremap.c:363 devm_memremap

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: <20171112001531.m23yeuuiqmawlbhj@thunk.org>
Date:   Sat, 11 Nov 2017 19:15:31 -0500
From:   Theodore Ts'o <tytso@....edu>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     Fengguang Wu <fengguang.wu@...el.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Vishal Verma <vishal.l.verma@...el.com>
Subject: Re: [pmem_attach_disk] WARNING: CPU: 46 PID: 518 at
 kernel/memremap.c:363 devm_memremap_pages+0x350/0x4b0

On Mon, Oct 30, 2017 at 05:24:42PM -0700, Dan Williams wrote:
> 
> Something is going wrong with memmap= because you are not getting 1G
> aligned address ranges. I think you would have better luck switching
> to the official nvdimm emulation in qemu-kvm rather than relying on
> memmap= which is just a fragile / unreliable interface. In fact we
> should look to deprecate it and point everyone to use the standard
> methods. We just have a problem of legacy pre-ACPI6 platforms that
> have no other way than a kernel command line to identify persistent
> memory ranges.

Why is memmap fragile/unreliable?  I'm not using qemu-kvm for most of
my testing and right now memmap is the only way I can test ext4 DAX
codepaths.   :-/

						- Ted