On Thu, Nov 17, 2011 at 6:03 PM, David Miller <[email protected]> wrote:
> I suspect this is an issue about who is responsible for setting the
> various VM_* flags in the VMA.
>
> It at least used to be the case that the caller was responsible, but
> it seems that this has changed in some regard. And if you look at
> remap_pfn_range(), which is what x86 uses, it sets things like VM_IO
> explicitly.
>
> In fact, sparc is one of the few platforms not using remap_pfn_range()
> as it's io_remap_pfn_range() implementation.
Somewhat makes sense but OTOH I don't see the difference between
arch/sparc/mm/generic_64.c:
int io_remap_pfn_range(struct vm_area_struct *vma, unsigned long from,
unsigned long pfn, unsigned long size, pgprot_t prot)
{
...
vma->vm_flags |= VM_IO | VM_RESERVED | VM_PFNMAP;
and mm/memory.c:
int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t prot)
{
...
if (addr == vma->vm_start && end == vma->vm_end) {
vma->vm_pgoff = pfn;
vma->vm_flags |= VM_PFN_AT_MMAP;
} else if (is_cow_mapping(vma->vm_flags))
return -EINVAL;
vma->vm_flags |= VM_IO | VM_RESERVED | VM_PFNMAP;
The only thing sparc seems to be missing is the VM_PFN_AT_MMAP
but that only gets tested in the x86 PAT code and in the transparent
hugepage code (which I suspect doesn't get used on sparc either).
Anyway definitely makes sense as something to check.
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
