linux-kernel - Could we do immediate pte zaps in vunmap?

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-next>] [day] [month] [year] [list]

Message-ID: <4CEF6B8B.8080206@goop.org>
Date:	Fri, 26 Nov 2010 00:10:51 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Nick Piggin <npiggin@...nel.dk>
CC:	"Xen-devel@...ts.xensource.com" <Xen-devel@...ts.xensource.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Could we do immediate pte zaps in vunmap?

What if vm_unmap_ram() and co. immediately zeroed out the ptes, but
lazily deferred the tlb flushes?  It seems to me there's no benefit in
batching up the pte clearing since that can't be amortized like the tlb
flush.

I think that would solve the problem we have with the interactions
between lazy unmap and Xen.  The issue is having stray pte entries
around (because Xen keeps track of those as part of its page-type
mechanism), but stale tlb entries are no problem.

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/