Re: problems with 2.6.12 and ioremap/iounmap

[Andi Kleen <ak@muc.de>]

Terence Ripperda <tripperda@nvidia.com> writes:


> this appears to be the 'vmalloc guard page causing change_page_attr
> problems' bug. at one point, iounmap subtracted the guard page before
> calling change_page_attr, but I see this was reverted as part of a
> recent cleanup.

Hmm, yes looks like it was reintroduced. 

> from looking at the implementation in 2.6.12-pre4, I'm not clear how

I suppose you mean rc4, not pre4?

> the guard page is accounted for in iounmap. in vmalloc.c, the guard
> page is subtracted from the vm_struct in remove_vm_area (which calls
> unmap_vm_area). but iounmap in ioremap.c calls unmap_vm_area directly
> rather than calling remove_vm_area, so the guard page is never 
> subtracted and the wrong size is passed to change_page_attr.

Ok obviously needs to be fixed. 

>
> is the intent that iounmap should call remove_vm_area rather than
> unmap_vm_area (with additional changes to not unlink the vma itself)?
> or that the guard page should be removed by unmap_ rather than
> remove_?

There doesn't seem to be a clear rule, that is where the confusion
comes from I guess. I would consider it cleaner to handle it in
the higher level vmalloc code.

>
> when debugging this issue, I also ran into problems with iounmap using
> virt_to_page on a pci IO region. this problem went away when I tried
> calling change_page_attr_addr with the virtual address instead. but

A patch for that already went into mainline.

> perhaps iounmap should be calling ioremap_change_attr rather than

What is ioremap_change_attr? 

> change_page_attr directly. I'll run some additional tests and send out
> a patch.

-Andi
-
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/