lkml.org 
[lkml]   [2006]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Using remap_pfn_range causes system hang on app close in 2.6.15 & up
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-04-27 05:38    [W:0.039 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site