Messages in this thread | | | Subject | Re: problems with 2.6.12 and ioremap/iounmap | From | Andi Kleen <> | Date | Thu, 19 May 2005 01:29:01 +0200 |
| |
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/
| |