lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 09 Jul 2010 08:51:39 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Andrea Arcangeli <aarcange@...hat.com>
CC:	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: mmu notifier calls in apply_to_page_range()

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists