Latest working kernel version: 2.6.28-xx
Earliest failing kernel version: 2.6.29-rc series
Distribution:
Hardware Environment:
Software Environment:
X86-Pat enabled

Problem Description:

There are a number of incorrect assumptions in the PAT code entered for 2.6.29:

1) The code incorrectly assumest that no PTEs set up by vm_insert_pfn() are pointing to RAM memory.
Such PTEs will hit
vm_insert_pfn()
track_pfn_vma_new()
reserve_pfn_range()
WARN_ON_ONCE() -> arch/x86/mm/pat.c aroucn line 637

2) If is_linear_pfn_mapping() returns true, the code incorrectly reserves the whole VMA each time vm_insert_pfn is called.
vm_insert_pfn()
track_pfn_vma_new()
is_linear_pfn_mapping() -> reserve_pfn_range(paddr, vma_size, prot, 0);

3) The implementation of is_linear_pfn_mapping in include/linux/mm.h is just incorrect and depends on the device offset user-space enters in mmap()

static inline int is_linear_pfn_mapping(struct vm_area_struct *vma)
{
	return ((vma->vm_flags & VM_PFNMAP) && vma->vm_pgoff);
}

A perhaps correct implementation would be 

static inline int is_linear_pfn_mapping(struct vm_area_struct *vma)
{
	return ((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags));
}

but then again, it would make no sense to test this from vm_insert_pfn.

4) When this is fixed, track_pfn_vma_new() should also be called from
vm_insert_mixed() when that function inserts a PTE pointing to IO / space.