Re: [Xen-devel] Double mapping of iomem assertion

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 18.10.07 17:22 >>>
>On 18/10/07 15:40, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:
>
>> Vmalloc area pagetables are demand mapped into per-process pgdirs. So it's
>> invalid for vunmap_pte_range() to be relying solely on update_va_mapping().
>> Either it should use some other method, or at least have some other method
>> as a fallback.
>> 
>> This is easily fixed. I guess I'll audit other uses of update_va_mapping()
>> at the same time.
>
>Fixed by linux-2.6.18-xen.hg changeset 265. I'll also backport for 3.1
>series.
>
>This was introduced by xen changeset 14731, back in April. So Jan is to
>blame (and me, I suppose!). ;-) I expect it's in a few vendor kernels at
>this point...

Indeed, I didn't consider this situation. However, excluding the check
against current->mm here was on purpose (and hence I'm not certain
your adding of it was correct) - when used on user mappings,
ptep_get_and_clear() is expected to return the most up-to-date A/D
flags, which cannot be achieved through a hypercall. On the contrary,
the use(s) with init_mm never have such expectations as far as I
recall, they at best check the returned value for validity/presence/null.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel