From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751025AbdEaEFH (ORCPT ); Wed, 31 May 2017 00:05:07 -0400 Received: from mga06.intel.com ([134.134.136.31]:11883 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750862AbdEaEFG (ORCPT ); Wed, 31 May 2017 00:05:06 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,421,1491289200"; d="scan'208";a="93737758" Subject: Re: [x86/mm] e2a7dcce31: kernel_BUG_at_arch/x86/mm/tlb.c To: Andy Lutomirski References: <20170527133113.GA33229@inn.lkp.intel.com> Cc: kernel test robot , X86 ML , Rik van Riel , Dave Hansen , Nadav Amit , Michal Hocko , Andrew Morton , LKML , LKP From: Arjan van de Ven Message-ID: <06ab9499-0c74-f2f0-251c-57244360219f@linux.intel.com> Date: Tue, 30 May 2017 21:05:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/27/2017 9:56 AM, Andy Lutomirski wrote: > On Sat, May 27, 2017 at 9:00 AM, Andy Lutomirski wrote: >> On Sat, May 27, 2017 at 6:31 AM, kernel test robot >> wrote: >>> >>> FYI, we noticed the following commit: >>> >>> commit: e2a7dcce31f10bd7471b4245a6d1f2de344e7adf ("x86/mm: Rework lazy TLB to track the actual loaded mm") >>> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git x86/tlbflush_cleanup >> >> Ugh, there's an unpleasant interaction between this patch and >> intel_idle. I suspect that the intel_idle code in question is either >> wrong or pointless, but I want to investigate further. Ingo, can you >> hold off on applying this patch? > > I think this is what's going on: intel_idle has an optimization and > sometimes calls leave_mm(). This is a rather expensive way of working > around x86 Linux's fairly weak lazy mm handling. It also abuses the > whole switch_mm state machine. In particular, there's no guarantee > that the mm is actually lazy at the time. The old code didn't care, > but the new code can oops. > > The short-term fix is to just reorder the code in leave_mm() to avoid the OOPS. fwiw the reason the code is in intel_idle is to avoid tlb flush IPIs to idle cpus, once the cpu goes into a deep enough idle state. In the current linux code, that is done by no longer having the old TLB live on the CPU, by switching to the neutral kernel-only set of tlbs. If your proposed changes do that (avoid the IPI/wakeup), great! (if not, there should be a way to do that)