On Tue, Apr 19, 2011 at 03:51:19PM +0200, Andrea Arcangeli wrote: > Hi, > > this should fix bug > https://bugzilla.kernel.org/show_bug.cgi?id=33682 . > > ==== > Subject: thp: fix /dev/zero MAP_PRIVATE and vm_flags cleanups > > From: Andrea Arcangeli <aarcange@xxxxxxxxxx> > > The huge_memory.c THP page fault was allowed to run if vm_ops was null (which > would succeed for /dev/zero MAP_PRIVATE, as the f_op->mmap wouldn't setup a > special vma->vm_ops and it would fallback to regular anonymous memory) but > other THP logics weren't fully activated for vmas with vm_file not NULL > (/dev/zero has a not NULL vma->vm_file). > > So this removes the vm_file checks so that /dev/zero also can safely > use THP (the other albeit safer approach to fix this bug would have > been to prevent the THP initial page fault to run if vm_file was set). > > After removing the vm_file checks, this also makes huge_memory.c > stricter in khugepaged for the DEBUG_VM=y case. It doesn't replace the > vm_file check with a is_pfn_mapping check (but it keeps checking for > VM_PFNMAP under VM_BUG_ON) because for a is_cow_mapping() mapping > VM_PFNMAP should only be allowed to exist before the first page fault, > and in turn when vma->anon_vma is null (so preventing khugepaged > registration). So I tend to think the previous comment saying if > vm_file was set, VM_PFNMAP might have been set and we could still be > registered in khugepaged (despite anon_vma was not NULL to be > registered in khugepaged) was too paranoid. The is_linear_pfn_mapping > check is also I think superfluous (as described by comment) but under > DEBUG_VM it is safe to stay. > > Signed-off-by: Andrea Arcangeli <aarcange@xxxxxxxxxx> Acked-by: Mel Gorman <mel@xxxxxxxxx> -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>