[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <x49pnrm2w1w.fsf@segfault.boston.devel.redhat.com>
Date: Wed, 20 Feb 2019 12:45:31 -0500
From: Jeff Moyer <jmoyer@...hat.com>
To: Dan Williams <dan.j.williams@...el.com>
Cc: linux-nvdimm <linux-nvdimm@...ts.01.org>,
"Darrick J. Wong" <darrick.wong@...cle.com>,
stable <stable@...r.kernel.org>, Jan Kara <jack@...e.cz>,
"Oliver O'Halloran" <oohall@...il.com>,
Johannes Thumshirn <jthumshirn@...e.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Vishal L Verma <vishal.l.verma@...el.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 0/7] libnvdimm/pfn: Fix section-alignment padding
Dan Williams <dan.j.williams@...el.com> writes:
> On Tue, Feb 12, 2019 at 1:37 PM Dan Williams <dan.j.williams@...el.com> wrote:
>>
>> Lately Linux has encountered platforms that collide Persistent Memory
>> regions between each other, specifically cases where ->start_pad needed
>> to be non-zero. This lead to commit ae86cbfef381 "libnvdimm, pfn: Pad
>> pfn namespaces relative to other regions". That commit allowed
>> namespaces to be mapped with devm_memremap_pages(). However dax
>> operations on those configurations currently fail if attempted within the
>> ->start_pad range because pmem_device->data_offset was still relative to
>> raw resource base not relative to the section aligned resource range
>> mapped by devm_memremap_pages().
>>
>> Luckily __bdev_dax_supported() caught these failures and simply disabled
>> dax. However, to fix this situation a non-backwards compatible change
>> needs to be made to the interpretation of the nd_pfn info-block.
>> ->start_pad needs to be accounted in ->map.map_offset (formerly
>> ->data_offset), and ->map.map_base (formerly ->phys_addr) needs to be
>> adjusted to the section aligned resource base used to establish
>> ->map.map formerly (formerly ->virt_addr).
>>
>> See patch 7 "libnvdimm/pfn: Fix 'start_pad' implementation" for more
>> details, and the ndctl patch series "Improve support + testing for
>> labels + info-blocks" for the corresponding regression test.
>
> Hello valued reviewers, can I plead for a sanity check of at least
> "libnvdimm/pfn: Introduce super-block minimum version requirements"
> and "libnvdimm/pfn: Fix 'start_pad' implementation"? In particular
> Jeff / Johannes this has end user / distro impact in that users may
> lose access to namespaces that are upgraded to v1.3 info-blocks and
> then boot an old kernel. I did not see a way around that sharp edge.
Yes, I'll take a look.
Cheers,
Jeff
Powered by blists - more mailing lists