From: "Huang, Ying" <ying.huang@intel.com>
To: Nadav Amit <namit@vmware.com>
Cc: Linux-MM <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mel Gorman <mgorman@techsingularity.net>,
Andrea Arcangeli <aarcange@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
Will Deacon <will@kernel.org>, Yu Zhao <yuzhao@google.com>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: [RFC 20/20] mm/rmap: avoid potential races
Date: Tue, 24 Aug 2021 08:36:18 +0800 [thread overview]
Message-ID: <87v93vy8zh.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <3F1EF02A-6FD4-42BE-BD07-1C5AC97A515B@vmware.com> (Nadav Amit's message of "Mon, 23 Aug 2021 15:50:22 +0000")
Nadav Amit <namit@vmware.com> writes:
>> On Aug 23, 2021, at 1:05 AM, Huang, Ying <ying.huang@intel.com> wrote:
>>
>> Hi, Nadav,
>>
>> Nadav Amit <nadav.amit@gmail.com> writes:
>>
>>> From: Nadav Amit <namit@vmware.com>
>>>
>>> flush_tlb_batched_pending() appears to have a theoretical race:
>>> tlb_flush_batched is being cleared after the TLB flush, and if in
>>> between another core calls set_tlb_ubc_flush_pending() and sets the
>>> pending TLB flush indication, this indication might be lost. Holding the
>>> page-table lock when SPLIT_LOCK is set cannot eliminate this race.
>>
>> Recently, when I read the corresponding code, I find the exact same race
>> too. Do you still think the race is possible at least in theory? If
>> so, why hasn't your fix been merged?
>
> I think the race is possible. It didn’t get merged, IIRC, due to some
> addressable criticism and lack of enthusiasm from other people, and
> my laziness/busy-ness.
Got it! Thanks your information!
>>> The current batched TLB invalidation scheme therefore does not seem
>>> viable or easily repairable.
>>
>> I have some idea to fix this without too much code. If necessary, I
>> will send it out.
>
> Arguably, it would be preferable to have a small back-portable fix for
> this issue specifically. Just try to ensure that you do not introduce
> performance overheads. Any solution should be clear about its impact
> on additional TLB flushes on the worst-case scenario and the number
> of additional atomic operations that would be required.
Sure. Will do that.
Best Regards,
Huang, Ying
next prev parent reply other threads:[~2021-08-24 0:36 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-31 0:11 [RFC 00/20] TLB batching consolidation and enhancements Nadav Amit
2021-01-31 0:11 ` Nadav Amit
2021-01-31 0:11 ` [RFC 01/20] mm/tlb: fix fullmm semantics Nadav Amit
2021-01-31 1:02 ` Andy Lutomirski
2021-01-31 1:02 ` Andy Lutomirski
2021-01-31 1:19 ` Nadav Amit
2021-01-31 2:57 ` Andy Lutomirski
2021-01-31 2:57 ` Andy Lutomirski
2021-02-01 7:30 ` Nadav Amit
2021-02-01 11:36 ` Peter Zijlstra
2021-02-02 9:32 ` Nadav Amit
2021-02-02 11:00 ` Peter Zijlstra
2021-02-02 21:35 ` Nadav Amit
2021-02-03 9:44 ` Will Deacon
2021-02-04 3:20 ` Nadav Amit
2021-01-31 0:11 ` [RFC 02/20] mm/mprotect: use mmu_gather Nadav Amit
2021-01-31 0:11 ` [RFC 03/20] mm/mprotect: do not flush on permission promotion Nadav Amit
2021-01-31 1:07 ` Andy Lutomirski
2021-01-31 1:07 ` Andy Lutomirski
2021-01-31 1:17 ` Nadav Amit
2021-01-31 2:59 ` Andy Lutomirski
2021-01-31 2:59 ` Andy Lutomirski
[not found] ` <7a6de15a-a570-31f2-14d6-a8010296e694@citrix.com>
2021-02-01 5:58 ` Nadav Amit
2021-02-01 15:38 ` Andrew Cooper
2021-01-31 0:11 ` [RFC 04/20] mm/mapping_dirty_helpers: use mmu_gather Nadav Amit
2021-01-31 0:11 ` [RFC 05/20] mm/tlb: move BATCHED_UNMAP_TLB_FLUSH to tlb.h Nadav Amit
2021-01-31 0:11 ` [RFC 06/20] fs/task_mmu: use mmu_gather interface of clear-soft-dirty Nadav Amit
2021-01-31 0:11 ` [RFC 07/20] mm: move x86 tlb_gen to generic code Nadav Amit
2021-01-31 18:26 ` Andy Lutomirski
2021-01-31 18:26 ` Andy Lutomirski
2021-01-31 0:11 ` [RFC 08/20] mm: store completed TLB generation Nadav Amit
2021-01-31 20:32 ` Andy Lutomirski
2021-01-31 20:32 ` Andy Lutomirski
2021-02-01 7:28 ` Nadav Amit
2021-02-01 16:53 ` Andy Lutomirski
2021-02-01 16:53 ` Andy Lutomirski
2021-02-01 11:52 ` Peter Zijlstra
2021-01-31 0:11 ` [RFC 09/20] mm: create pte/pmd_tlb_flush_pending() Nadav Amit
2021-01-31 0:11 ` [RFC 10/20] mm: add pte_to_page() Nadav Amit
2021-01-31 0:11 ` [RFC 11/20] mm/tlb: remove arch-specific tlb_start/end_vma() Nadav Amit
2021-01-31 0:11 ` Nadav Amit
2021-02-01 12:09 ` Peter Zijlstra
2021-02-01 12:09 ` Peter Zijlstra
2021-02-02 6:41 ` Nicholas Piggin
2021-02-02 6:41 ` Nicholas Piggin
2021-02-02 7:20 ` Nadav Amit
2021-02-02 7:20 ` Nadav Amit
2021-02-02 9:31 ` Peter Zijlstra
2021-02-02 9:31 ` Peter Zijlstra
2021-02-02 9:54 ` Nadav Amit
2021-02-02 9:54 ` Nadav Amit
2021-02-02 11:04 ` Peter Zijlstra
2021-02-02 11:04 ` Peter Zijlstra
2021-01-31 0:11 ` [RFC 12/20] mm/tlb: save the VMA that is flushed during tlb_start_vma() Nadav Amit
2021-02-01 12:28 ` Peter Zijlstra
2021-01-31 0:11 ` [RFC 13/20] mm/tlb: introduce tlb_start_ptes() and tlb_end_ptes() Nadav Amit
2021-01-31 9:57 ` Damian Tometzki
2021-01-31 10:07 ` Damian Tometzki
2021-02-01 7:29 ` Nadav Amit
2021-02-01 13:19 ` Peter Zijlstra
2021-02-01 23:00 ` Nadav Amit
2021-01-31 0:11 ` [RFC 14/20] mm: move inc/dec_tlb_flush_pending() to mmu_gather.c Nadav Amit
2021-01-31 0:11 ` [RFC 15/20] mm: detect deferred TLB flushes in vma granularity Nadav Amit
2021-02-01 22:04 ` Nadav Amit
2021-02-02 0:14 ` Andy Lutomirski
2021-02-02 20:51 ` Nadav Amit
2021-02-04 4:35 ` Andy Lutomirski
2021-01-31 0:11 ` [RFC 16/20] mm/tlb: per-page table generation tracking Nadav Amit
2021-01-31 0:11 ` [RFC 17/20] mm/tlb: updated completed deferred TLB flush conditionally Nadav Amit
2021-01-31 0:11 ` [RFC 18/20] mm: make mm_cpumask() volatile Nadav Amit
2021-01-31 0:11 ` [RFC 19/20] lib/cpumask: introduce cpumask_atomic_or() Nadav Amit
2021-01-31 0:11 ` [RFC 20/20] mm/rmap: avoid potential races Nadav Amit
2021-08-23 8:05 ` Huang, Ying
2021-08-23 8:05 ` Huang, Ying
2021-08-23 15:50 ` Nadav Amit
2021-08-24 0:36 ` Huang, Ying [this message]
2021-08-24 0:36 ` Huang, Ying
2021-01-31 0:39 ` [RFC 00/20] TLB batching consolidation and enhancements Andy Lutomirski
2021-01-31 0:39 ` Andy Lutomirski
2021-01-31 0:39 ` Andy Lutomirski
2021-01-31 1:08 ` Nadav Amit
2021-01-31 1:08 ` Nadav Amit
2021-01-31 3:30 ` Nicholas Piggin
2021-01-31 3:30 ` Nicholas Piggin
2021-01-31 7:57 ` Nadav Amit
2021-01-31 7:57 ` Nadav Amit
2021-01-31 8:14 ` Nadav Amit
2021-01-31 8:14 ` Nadav Amit
2021-02-01 12:44 ` Peter Zijlstra
2021-02-01 12:44 ` Peter Zijlstra
2021-02-02 7:14 ` Nicholas Piggin
2021-02-02 7:14 ` Nicholas Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v93vy8zh.fsf@yhuang6-desk2.ccr.corp.intel.com \
--to=ying.huang@intel.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mgorman@techsingularity.net \
--cc=namit@vmware.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=yuzhao@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.