Re: [RESEND PATCH] x86/mm: only allow memmap=XX!YY over existing RAM

[H. Peter Anvin]

On 06/28/16 09:33, Dan Williams wrote:
> On Tue, Jun 28, 2016 at 1:31 AM, Yigal Korman <yigal@xxxxxxxxxxxxx> wrote:
>> Before this patch, passing a range that is beyond the physical memory
>> range will succeed, the user will see a /dev/pmem0 and will be able to
>> access it. Reads will always return 0 and writes will be silently
>> ignored.
>>
>> I've gotten more than one bug report about mkfs.{xfs,ext4} or nvml
>> failing that were eventually tracked down to be wrong values passed to
>> memmap.
>>
>> This patch prevents the above issue by instead of adding a new memory
>> range, only update a RAM memory range with the PRAM type. This way,
>> passing the wrong memmap will either not give you a pmem at all or give
>> you a smaller one that actually has RAM behind it.
>>
>> And if someone still needs to fake a pmem that doesn't have RAM behind
>> it, they can simply do memmap=XX@YY,XX!YY.
>>
>> Signed-off-by: Yigal Korman <yigal@xxxxxxxxxxxxx>
>> Acked-by: Dan Williams <dan.j.williams@xxxxxxxxx>
>> Acked-by: Johannes Thumshirn <jthumshirn@xxxxxxx>
>> Tested-by: Boaz Harrosh <boaz@xxxxxxxxxxxxx>
>> ---
> 
> I have some other libnvdimm fixes heading upstream shortly if x86
> folks just want to ack this one...
> 

I'm concerned about this.  This would mean that memory not marked as RAM
because it is persistent and you don't want the OS to accidentally
clobber persistent RAM can't be added.  So it seems like The Wrong
Thing.  If all you want is simulated pram then it shouldn't care about
addresses in the first place and instead we should just specify it by
quantity.

	-hpa