linux-kernel

Open Source and information security mailing list archives

Message-ID: <20160913145137.GA6706@linux.intel.com>
Date:   Tue, 13 Sep 2016 08:51:37 -0600
From:   Ross Zwisler <ross.zwisler@...ux.intel.com>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     ryan chen <ryan.chan105@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>
Subject: Re: Panic when insmod nfit_test.ko

On Tue, Sep 13, 2016 at 06:38:02AM -0700, Dan Williams wrote:
> 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]:

[1] https://github.com/pmem/ndctl/blob/master/README.md

> 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.
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@...ts.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm

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