linux-kernel - Re: Panic when insmod nfit

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: <CAPcyv4gv1nYGSsS0uDsp0R2_oGZ_qtkRg+ihO_x-UwByDTqE+A@mail.gmail.com>
Date:   Tue, 13 Sep 2016 06:38:02 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     ryan chen <ryan.chan105@...il.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 Mon, Sep 12, 2016 at 11:01 PM, ryan chen <ryan.chan105@...il.com> wrote:
> 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

For the unit tests to operate you need the unit test version of
nfit.ko loaded.  All of these dependencies are figured out
automatically if you have performed the following build / installation
steps as recommended by the ndctl readme [1]:

make M=tools/testing/nvdimm/
sudo make M=tools/testing/nvdimm/ modules_install
sudo make modules_install

...after that is complete you only need to perform:

modprobe nfit_test

...and modprobe will figure out all the right dependencies and load
all the other modules.

In fact to run the unit tests you don't even need to load nfit_test
ahead of time.  The unit test itself takes care of that.