Re: Using remap_pfn_range causes system hang on app close in 2.6.15 & up

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

 



Sam Abu-Nassar wrote:


Nick Piggin wrote:
Well, I think I said it shouldn't oops like this... I don't think it
is particularly robust WRT error cases or concurrent page faults
(between mmap and ioctl).

As we established earlier with a debug patch, the reason for the oops
is that VM_PFNMAP has been cleared from your vma->vm_flags for some
reason. This is causing the unmap code to mistakenly try to remove
reverse maps and refcounts from the struct pages.

I don't know why VM_PFNMAP should be getting cleared. But if it
remains set then the oops should go away.



As one of my tests, I manually added the VM_PFNMAP flag before calling remap_pfn_range(). This did not resolve the issue. Also, I checked the kernel source (vanilla Fedora Core 5) and VM_PFNMAP is always added inside remap_pfn_range() anyway, along with VM_IO & VM_RESERVED.


Yes, VM_PFNMAP is being removed after the remap_pfn_range.

Note that the kernel oops I posted only happened rarely. Most of the time, the system completely froze immediately when the file descriptor was closed and I didn't get any oops message.


Quite likely to do all sorts of weird stuff because it will attempt to free
these pages to the page allocator which may get allocated for kernel internal
use for example.

--

Send instant messages to your online friends http://au.messenger.yahoo.com -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux