[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190514114919.GO2589@hirez.programming.kicks-ass.net>
Date: Tue, 14 May 2019 13:49:19 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Nadav Amit <namit@...are.com>
Cc: Jan Stancek <jstancek@...hat.com>,
Yang Shi <yang.shi@...ux.alibaba.com>,
Will Deacon <will.deacon@....com>,
"minchan@...nel.org" <minchan@...nel.org>,
"mgorman@...e.de" <mgorman@...e.de>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [v2 PATCH] mm: mmu_gather: remove __tlb_reset_range() for force
flush
On Tue, May 14, 2019 at 07:21:33AM +0000, Nadav Amit wrote:
> > On May 14, 2019, at 12:15 AM, Jan Stancek <jstancek@...hat.com> wrote:
> > Replacing fullmm with need_flush_all, brings the problem back / reproducer hangs.
>
> Maybe setting need_flush_all does not have the right effect, but setting
> fullmm and then calling __tlb_reset_range() when the PTEs were already
> zapped seems strange.
>
> fullmm is described as:
>
> /*
> * we are in the middle of an operation to clear
> * a full mm and can make some optimizations
> */
>
> And this not the case.
Correct; starting with fullmm would be wrong. For instance
tlb_start_vma() would do the wrong thing because it assumes the whole mm
is going away. But we're at tlb_finish_mmu() time and there the
difference doesn't matter anymore.
But yes, that's a wee abuse.
Powered by blists - more mailing lists