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]