linux-kernel - Re: [PATCH] mm: disable preemption in apply_to_pte

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 13 Feb 2009 09:41:55 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Nick Piggin <nickpiggin@...oo.com.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] mm: disable preemption in apply_to_pte_range

Peter Zijlstra wrote:
> If the lazy mmu code relies on per-cpu data, then it should be the lazy
> mmu's responsibility to ensure stuff is properly serialized. Eg. it
> should do get_cpu_var() and put_cpu_var().
>
> Those constructs can usually be converted to preemptable variants quite
> easily, as it clearly shows what data needs to be protected.
>   

At the moment the lazy update stuff is inherently cpu-affine.  The basic 
model is that you can amortize the cost of individual update operations 
(via hypercall, for example) by batching them up.  That batch is almost 
certainly a piece of percpu state (in Xen's case its maintained on the 
kernel side as per-cpu data, but in VMI it happens somewhere under their 
ABI), and so we can't allow switching to another cpu while lazy update 
mode is active.

Preemption is also problematic because if we're doing lazy updates and 
we switch to another task, it will likely get very confused if its 
pagetable updates get deferred until some arbitrary point in the future...

So at the moment, we just disable preemption, and take advantage of the 
existing work to make sure pagetable updates are not non-preemptible for 
too long.  This has been fine so far, because almost all the work on 
using lazy mmu updates has focused on usermode mappings.

But I can see how this is problematic from your perspective.  One thing 
we could consider is making the lazy mmu mode a per-task property, so if 
we get preempted we can flush any pending changes and safely switch to 
another task, and then reenable it when we get scheduled in again.  
(This may be already possible with the existing paravirt-ops hooks in 
switch_to.)

In this specific case, if the lazy mmu updates / non-preemptable section 
is really causing heartburn, we can just back it out for now.

    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/