linux-kernel - Re: another pmem variant V2

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: <20150331160853.GA1152@lst.de>
Date:	Tue, 31 Mar 2015 18:08:53 +0200
From:	Christoph Hellwig <hch@....de>
To:	Boaz Harrosh <boaz@...xistor.com>
Cc:	Christoph Hellwig <hch@....de>, linux-nvdimm@...1.01.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	x86@...nel.org, ross.zwisler@...ux.intel.com, axboe@...nel.dk
Subject: Re: another pmem variant V2

On Tue, Mar 31, 2015 at 01:25:46PM +0300, Boaz Harrosh wrote:
> The problem I see is that if I state a memmap=nn!aa that crosses a NUMA
> boundary then the machine will not boot.
> So BTW for sure I need that "don't merge E820_PMEM ranges" patch because
> otherwise I will not be able to boot if I have pmem on both NUMA nodes
> and they happen to be contiguous.

Ok.

> Regarding the SQUASHMEs to PMEM. Originally I had them as 3-4 patches.
> But I thought since you are squashing them into a single submitted patch
> I can just send just the one patch. Tell me what you prefer and I'll
> resend (The one vs the three)

The slpit is mostly to get a good description for each change.

> And one last issue. I have some configuration "hardness" with the
> memmap=nn!aa Kernel command line API, it was better for me with the
> pmem map= module param. Will you be OK if I split pmem_probe() into
> calling pmem_alloc(addr, length), so I can keep an out-of-tree patch
> that adds the map= parameter to pmem?

Can't your out of tree patch do that as well?  In fact you might want to
rewrite it to a module that allows your to create/destroy the platform_devices
you use.  And for your PCIe case I'd really prefer a proper in-tree PCI
driver for it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/