linux-kernel - Re: [PATCH v6 6/7] mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem

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 for Android: free password hash cracker in your pocket

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

Message-ID: <E340B75B-2830-4E6D-BF0A-2C58A7002CF1@vmware.com>
Date:   Sun, 13 Aug 2017 06:14:21 +0000
From:   Nadav Amit <namit@...are.com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     "open list:MEMORY MANAGEMENT" <linux-mm@...ck.org>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Minchan Kim <minchan@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Russell King <linux@...linux.org.uk>,
        Tony Luck <tony.luck@...el.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        "David S. Miller" <davem@...emloft.net>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Jeff Dike <jdike@...toit.com>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: Re: [PATCH v6 6/7] mm: fix MADV_[FREE|DONTNEED] TLB flush miss
 problem

Peter Zijlstra <peterz@...radead.org> wrote:

> On Tue, Aug 01, 2017 at 05:08:17PM -0700, Nadav Amit wrote:
>> void tlb_finish_mmu(struct mmu_gather *tlb,
>> 		unsigned long start, unsigned long end)
>> {
>> -	arch_tlb_finish_mmu(tlb, start, end);
>> +	/*
>> +	 * If there are parallel threads are doing PTE changes on same range
>> +	 * under non-exclusive lock(e.g., mmap_sem read-side) but defer TLB
>> +	 * flush by batching, a thread has stable TLB entry can fail to flush
>> +	 * the TLB by observing pte_none|!pte_dirty, for example so flush TLB
>> +	 * forcefully if we detect parallel PTE batching threads.
>> +	 */
>> +	bool force = mm_tlb_flush_nested(tlb->mm);
>> +
>> +	arch_tlb_finish_mmu(tlb, start, end, force);
>> }
> 
> I don't understand the comment nor the ordering. What guarantees we see
> the increment if we need to?

The comment regards the problem that is described in the change-log, and a
long thread that is referenced in it. So the question is whether “I don’t
understand” means “I don’t understand” or “it is not clear enough”. I’ll
be glad to address either one - just say which.

As for the ordering - I tried to clarify it in the thread of the commit. Let
me know if it is clear now.

Regards,
Nadav