linux-kernel - Re: [PATCH RFC] vm_unmap_aliases: allow callers to inhibit TLB flush

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:	Tue, 30 Dec 2008 14:42:36 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Memory Management List <linux-mm@...ck.org>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: [PATCH RFC] vm_unmap_aliases: allow callers to inhibit TLB flush

On Tuesday 16 December 2008 12:28:19 Jeremy Fitzhardinge wrote:
> Nick Piggin wrote:
> > On Friday 12 December 2008 12:59, Jeremy Fitzhardinge wrote:

> >> No.  Well, yes, it would, but Xen itself will do whatever tlb flushes
> >> are necessary to keep it safe (it must, since it doesn't trust guest
> >> kernels).  It's fairly clever about working out which cpus need flushing
> >> and if other flushes have already done the job.
> >
> > OK. Yeah, then the problem is simply that the guest may reuse that
> > virtual memory for another vmap.
>
> Hm.  What you would you think of a "deferred tlb flush" flag (or
> something) to cause the next vmap to do the tlb flushes, in the case the
> vunmap happens in a context where the flushes can't be done?

Sorry to get back to you late... I would just prefer to have a flushing mode
that clears page tables but leaves the vm entries there that will get picked
up and flushed naturally as needed.

I have patches to move the tlb flushing to an asynchronous process context...
but all tweaks to that (including flushing at vmap) are just variations on the
existing flushing scheme and don't solve your problem, so I don't think we
really need to change that for the moment (my patches are mainly for latency
improvement and to allow vunmap to be usable from interrupt context).



--
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/