linux-kernel - flush_tlb_page() avoidance in balancenuma pull

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

Message-Id: <20121217.183746.284542903305308509.davem@davemloft.net>
Date:	Mon, 17 Dec 2012 18:37:46 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	riel@...hat.com
CC:	mgorman@...e.de, linux-kernel@...r.kernel.org
Subject: flush_tlb_page() avoidance in balancenuma pull

I think we need to be careful, going forward, with these
flush_tlb_page() removals in the initial commits.

On those cpus, each set_pte_at() call (and therefore indirectly
via pte_clear()) queue up a per-cpu flush entry.

Then, the various flush_tlb_*() calls don't flush a single entry
but rather run the queue of pending TLB flushes.

Therefore every single set_pte_at() call must have a subsequent
flush_tlb_*() otherwise we'll return to userspace with stale
entries in the per-cpu TLB flush queues.

It seems to be the case that we turn out to be OK here, because
__set_pte_at() on sparc64 as currently implemented does not queue up a
TLB flush in the per-cpu queue if the PTE did not have the valid bit.

And the default pte_accessible() returns true unconditionally.

In fact is shows that we can probably can implement pte_accessible()
to mirror the test done in __set_pte_at() and thus we'd get the
optimization too on sparc64.

But we really need to be careful about this, these kinds of bugs are
hard to track down.

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