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: <CAC1QiQEQS0sXYPfRw-=GSOsChopQ60mF4YXnmQVv7BxbL5soHQ@mail.gmail.com>
Date:   Tue, 13 Sep 2016 14:01:13 +0800
From:   ryan chen <ryan.chan105@...il.com>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Panic when insmod nfit_test.ko

On Tue, Sep 13, 2016 at 10:50 AM, Dan Williams <dan.j.williams@...el.com> wrote:
> On Mon, Sep 12, 2016 at 7:30 PM, ryan chen <ryan.chan105@...il.com> wrote:
>> Hi all,
>> Recently I'm trying to check the testing suite of nfit_test for nvdimm
>> on 4.8-rc5, and system got panic once insmod nfit_test.ko ,
>> I've checked the RIP, I guess it panics due to NULL
>> nvdimm_map pointer, i.e., accessing nvdimm_map->mem,
>> so I have a question that, should we check the return value of
>> alloc_nvdimm_map if it failed:
>>
>> --- a/drivers/nvdimm/core.c
>> +++ b/drivers/nvdimm/core.c
>> @@ -171,6 +171,9 @@ void *devm_nvdimm_memremap(struct device *dev,
>> resource_size_t offset,
>>                 kref_get(&nvdimm_map->kref);
>>         nvdimm_bus_unlock(dev);
>>
>> +       if (!nvdimm_map)
>> +               return NULL;
>> +
>>         if (devm_add_action_or_reset(dev, nvdimm_map_put, nvdimm_map))
>>                 return NULL;
>> But why we got NULL nvdimm_map is still unknown,
>> please let me know if you need any information. Thanks.
>
> Thanks for the report.  We do need to check if alloc_nvdimm_map fails.
> My guess as to why it is failing the call to request_mem_region().
> Can you try the attached patch, and send the kernel log as well as the
> contents of /proc/iomem?
OK, I've tried this patch, and there is no panic anymore, however the
request region offset
seems a little weird, it is not in the iomem space, not sure if I'm
doing the right testing.
please refer to attachment the kernel boot log , iomem address space
and the insmod nfit_test.ko message.
I'm testing like this:
modprobe dax
modprobe dax_pmem
modprobe libnvdimm
modprobe nd_blk
modprobe nd_btt
modprobe nd_e820
modprobe nd_pmem
modprobe nfit
insmod nfit_test_iomap.ko
insmod nfit_test.ko

View attachment "bootup.log" of type "text/x-log" (65063 bytes)

View attachment "iomem.log" of type "text/x-log" (2630 bytes)

View attachment "nfit_test.log" of type "text/x-log" (2081 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ