Re: mmu notifier calls in apply_to_page_range()

From: Jeremy Fitzhardinge
Date: Fri Jul 09 2010 - 11:51:49 EST


On 07/09/2010 08:12 AM, Andrea Arcangeli wrote:
> On Fri, Jul 09, 2010 at 08:06:20AM -0700, Jeremy Fitzhardinge wrote:
>
>> I just noticed that the original mmu notifier change (cddb8a5c14a) adds
>> calls to mmu_notifier_invalidate_range_start/end to
>> apply_to_page_range(). This doesn't seem correct to me, since
>> apply_to_page_range can perform arbitrary operations to the range of
>> pages, not just invalidation of the pages. It seems to me that the
>> appropriate mmu notifiers should be called either around the call to
>> apply_to_page_range(), or from within the callback function.
>>
>> Andrea, what's the rationale for mmu_notifier_invalidate_range_start/end
>> here?
>>
> As long as the secondary mappings are teardown in range_start and
> allowed to be established again only after range_end, all
> modifications will be picked up by the secondary mmu. Imagine
> secondary mmu like a tlb, that you only invalidate, then it'll be
> refilled later (after range_end).
>

Yes, but apply_to_page_range isn't necessarily making changes which
requires that teardown/refill. The most common user is vmalloc, which
is just using a side-effect of apply_to_page_range to make sure that all
the intermediate levels of the pagetable are allocated over the
vmalloced range. I think all the other users of it are within Xen code.
In particular, we're using it in the gntdev driver, which also uses mmu
notifiers to keep grant mappings in sync with process mappings, so the
recursive mmu notifier call is causing problems.

It seems to me that apply_to_page_range should be agnostic to its use,
and its up to its callers to do any appropriate mmu notifier work.
Would you be happy with a patch to remove those calls?

Thanks,
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/