lkml.org 
[lkml]   [2016]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()
On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
> On Tue, 2016-08-23 at 15:32 -0700, Dan Williams wrote:
>> On Tue, Aug 23, 2016 at 11:43 AM, Toshi Kani <toshi.kani@hpe.com>
>> wrote:
> :
>> I'm not sure about this fix. The point of honoring
>> vmem_altmap_offset() is because a portion of the resource that is
>> passed to devm_memremap_pages() also contains the metadata info block
>> for the device. The offset says "use everything past this point for
>> pages". This may work for avoiding a crash, but it may corrupt info
>> block metadata in the process. Can you provide more information
>> about the failing scenario to be sure that we are not triggering a
>> fault on an address that is not meant to have a page mapping? I.e.
>> what is the host physical address of the page that caused this fault,
>> and is it valid?
>
> The fault address in question was the 2nd page of an NVDIMM range. I
> assumed this fault address was valid and needed to be handled. Here is
> some info about the base and patched cases. Let me know if you need
> more info.
>
> Base
> ====
>
> The following NVDIMM range was set to /dev/dax.
>
> /proc/iomem
> 480000000-87fffffff : Persistent Memory
>
> devm_memremap_pages() initialized struct page from 0x490200-0x87ffff.

This seems like the start of the trouble. What happened to the first
1GB of the address range? I'm assuming the 'align' attribute is set
to 2MB because we start at a pfn offset of 0x200, but this should be
starting at 0x480200.

\
 
 \ /
  Last update: 2016-09-17 09:57    [W:0.078 / U:0.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site