[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2f996fb5ee503512fbabd7496cc7498ecb2cdb2.camel@surriel.com>
Date: Thu, 05 Dec 2024 09:21:13 -0500
From: Rik van Riel <riel@...riel.com>
To: kernel test robot <oliver.sang@...el.com>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com, linux-kernel@...r.kernel.org,
x86@...nel.org, Ingo Molnar <mingo@...nel.org>, Dave Hansen
<dave.hansen@...el.com>, Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>, Mel Gorman <mgorman@...e.de>
Subject: Re: [tip:x86/mm] [x86/mm/tlb] 209954cbc7:
WARNING:at_arch/x86/mm/tlb.c:#flush_tlb_func
On Thu, 2024-12-05 at 16:43 +0800, kernel test robot wrote:
>
> [ 210.338271][ T4668] ------------[ cut here ]------------
> [ 210.343902][ T4668] WARNING: CPU: 38 PID: 4668 at
> arch/x86/mm/tlb.c:815 flush_tlb_func (arch/x86/mm/tlb.c:815)
Huh, this is the warning below:
WARN_ON_ONCE(local_tlb_gen > mm_tlb_gen);
This cannot happen on remote CPUs, because they
will check whether f->mm != loaded_mm, but with
my patches it can happen on the _local_ CPU, if:
The current CPU:
- Is in the mm_cpumask for another mm
- Tries to flush the TLB for that other mm
- Calls flush_tlb_func locally with f->mm being
that other mm.
It should be a fairly easy fix, pulling the
/* Can only happen on remote CPUs */ thing
out from the !local condition, since it can
now happen locally :)
I'll send a fix in a little bit.
--
All Rights Reversed.
Powered by blists - more mailing lists