Re: [PATCH v2 00/20] get_user_pages() for dax mappings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 2, 2015 at 2:02 PM, Logan Gunthorpe <logang@xxxxxxxxxxxx> wrote:
> On 30/11/15 03:15 PM, Dan Williams wrote:
>>
>> I appreciate the test report.  I appreciate it so much I wonder if
>> you'd be willing to re-test the current state of:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm
>> libnvdimm-pending
>
>
>
> Hi Dan,
>
> I've had some mixed success with the above branch. Many of my tests are
> working but I have the following two issues which I didn't see previously:
>
> * When trying to do RDMA transfers to a mmaped DAX file I get a kernel panic
> while de-registering the memory region. (The panic message is at the end of
> this email.) addr2line puts it around dax.c:723 for the first line in the
> call trace, the address where the failure occurs doesn't seem to map to a
> line of code.
>
> * Less important: my tests no longer work inside qemu because I'm using a
> region in the PCI bar space which is not on a section boundary. The latest
> code enforces that restriction which makes it harder to use with PCI memory.
> (I'm talking memremap.c:311). Presently, if I comment out the check, my VM
> tests work fine. This hasn't been a problem on real hardware as we are using
> a 64bit address space and thus the BAR addresses are better aligned.
>

I could loosen the restriction a bit to allow one unaligned mapping
per section.  However, if another mapping request came along that
tried to map a free part of the section it would fail because the code
depends on a  "1 dev_pagemap per section" relationship.  Seems an ok
compromise to me...

> I don't have much time at the moment to dig into the kernel panic myself so
> hopefully what I've provided will help you find the issue. If you need any
> more information let me know.

Could you share the test setup for this one so I can try to reproduce?
 As far as I can see this looks like an ext4 internals issue.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]