linux-kernel - Re: [PATCH 05/31] x86/mm: Reduce tlb flushes from ptep_set_access

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, 26 Oct 2012 14:14:23 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Michel Lespinasse <walken@...gle.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Mel Gorman <mgorman@...e.de>,
	Johannes Weiner <hannes@...xchg.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 05/31] x86/mm: Reduce tlb flushes from ptep_set_access_flags()

On 10/26/2012 02:02 PM, Linus Torvalds wrote:
> On Fri, Oct 26, 2012 at 10:54 AM, Rik van Riel <riel@...hat.com> wrote:
>>
>> Would tlb_fix_spurious_fault take care of that on those
>> architectures?
>
> .. assuming that they implement it as a real TLB flush, yes.
>
> But maybe the architecture never noticed that it happened to depend on
> the fact that we do a cross-CPU invalidate? So a missing
> tlb_fix_spurious_fault() implementation could cause a short loop of
> repeated page faults, until the IPI happens. And it would be so
> incredibly rare that nobody would ever have noticed.
>
> And if that could have happened, then with the cross-cpu invalidate
> removed, the "incredibly rare short-lived constant page fault retry"
> could turn into "incredibly rare lockup due to infinite page fault
> retry due to TLB entry that never turns dirty despite it being marked
> dirty by SW in the in-memory page tables".

I suspect the next context switch would flush out the TLB,
making it a slowdown, not a lockup.

Still a good reason to make such a change in its own commit,
so it can be bisected and tracked down.

The commit message could tell architecture maintainers what
to do if this particular commit got them into trouble:
implement a proper local TLB flush in tlb_fix_spurious_fault.

I'll send this in as a separate patch.

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