Re: [PATCH] pstore/ram: Clarify resource reservation labels

[Dan Williams]

On Thu, Oct 18, 2018 at 3:19 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>
> On Thu, Oct 18, 2018 at 2:35 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
> > On Thu, Oct 18, 2018 at 1:31 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
[..]
> > I cringe at users picking addresses because someone is going to enable
> > ramoops on top of their persistent memory namespace and wonder why
> > their filesystem got clobbered. Should attempts to specify an explicit
> > ramoops range that intersects EfiPersistentMemory fail by default? The
> > memmap=ss!nn parameter has burned us many times with users picking the
> > wrong address, so I'd be inclined to hide this ramoops sharp edge from
> > them.
>
> Yeah, this is what I'm trying to solve. I'd like ramoops to find the
> address itself, but it has to do it really early, so if I can't have
> nvdimm handle it directly, will having regions already allocated with
> request_mem_region() "get along" with the rest of nvdimm?

If the filesystem existed on the namespace before the user specified
the ramoops command line then ramoops will clobber the filesystem and
the user will only find out when mount later fails. All the kernel
will say is:

    dev_warn(dev, "could not reserve region %pR\n", res);

...from the pmem driver, and then the only way to figure who the
conflict is with is to look at /proc/iomem, but the damage is already
likely done by that point.