Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1166139imm; Wed, 22 Aug 2018 21:01:59 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYYYfm307nvxFd8WlrWRmVaaPywcflnhIPaVnl6zUVKr+8rSjbliI+4cNakQ3D5Pv9uafrv X-Received: by 2002:a63:5b5c:: with SMTP id l28-v6mr8068194pgm.50.1534996919311; Wed, 22 Aug 2018 21:01:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534996919; cv=none; d=google.com; s=arc-20160816; b=NmzaN0sUH9YmYFOGhqD0ZGHobNpgh/RjBbryLT1qJqru4LjAIfxqOXie7+d561IgV+ cqR9F4DgYzB/wyVdDNht/AGTKbobLWAV/qhLXpA8NOZu1NA1CeBCHRI2LcQfRJktT026 slk6po94Tzafebakg7G3fQPIbxQvTpNrYsmbmU4u29S8u9ESBhihiI2HI3mwR/xOJpl3 kwptQ3Q+Bx/yd59ijU6GQ6AsFaRiFt2uL9STVOjKgyWVfnvmwpEnv3OdrN4GP3s4/Nx/ MMpgO5aczH7a0tLsvMFvGymhQTYP0oTM+aMl50SlZ2EOGQXljWpu4bpqcbuH/5R1RVmD BbYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=GWbtkZMgO44q21FL+QlPkVXET6vkQdrpdf+86VyR8fM=; b=tgLVOVzS3r5cE5swYSRbZGOx+mwnmwUBcY9th+BSZNuhQY6zDMCiTDq/fcPIgbmd+f /g578HwYvCHnQ3UlY5Mf91CFGIrOGB9DA3D1+LkRl2bvoGLE88YXNESO8lLPXqoa8OQ3 sBj/BrL/+3OClLS6XclJTkQM6hBpVA25WQc8Qpb3ubkZpCakeAVgGcTddWIl/QPTi+I2 AhlNEDcB5lE2WYXZL+iHsOELGG7/e3KAPI2tJy5l8knTyYwbfjW0g5N3G0zu4iE2BHix tc57oD6BcdDpWREswPkZ4rDLARsG8LrVRHDalRwEbQLViAXqNDni8ftSxjF2h8WMqgWK Vo7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=IQjnTO6A; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d22-v6si3369769pgd.104.2018.08.22.21.01.43; Wed, 22 Aug 2018 21:01:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=IQjnTO6A; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728340AbeHWH1h (ORCPT + 99 others); Thu, 23 Aug 2018 03:27:37 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:33937 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726150AbeHWH1g (ORCPT ); Thu, 23 Aug 2018 03:27:36 -0400 Received: by mail-io0-f195.google.com with SMTP id c22-v6so3253151iob.1 for ; Wed, 22 Aug 2018 20:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GWbtkZMgO44q21FL+QlPkVXET6vkQdrpdf+86VyR8fM=; b=IQjnTO6Ac751aj7VFtgC2QHYDDoCuN/+TUOD9UVjvpreSaSXZV4o3MnWn6LDMa5pnj xkWShlcjCxwNzusQyXIBN2oH3m0WCH/QlbypvHmKMCgc3ZaF09iqOSHSLZTgkIvmqcQd Pzm4alOTLdiEqAk9qLlov5p1ZH51vE9hYrNaU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GWbtkZMgO44q21FL+QlPkVXET6vkQdrpdf+86VyR8fM=; b=kJxRBaiNBd3n/GUCH+CzRHTSARJXHJ19zeeAUmCu2aH1/SMhsVOM5+VsiMHqZ7ap9o jg5GaH34CINe87JpWQkFSi4nud2e7g1gmYDopG2fWjpr08fnFk5XVV0BRknHKYpTqGyr gX4yanhykFdXark01jIwOsjBDeDOKKj2tJonVDTlEiMCFP73ie5ksz6PizICssjoKMU+ nK4Dxnpt+JTTTtQ1hYFq4GXxm0xcWUUhOxsHfMDjGBgtR11UeIQdGGZmDLDUBLs34vSE cHFhZoi4g6vr1B1VMIjPaNIf666ZucTQb5bcbTE6wOkz9IB1wANmMIcGtQnP2S9hENh7 z1xQ== X-Gm-Message-State: AOUpUlEc7xZhu/zA0g03h+1FxcW6nvmeU1tCob/ACVT0aRfN/1IyQnAL b/atJLyxUAdn+NlGXB59f96Wt1f4eE8Gpi7KVH0= X-Received: by 2002:a6b:f609:: with SMTP id n9-v6mr32454704ioh.259.1534996797255; Wed, 22 Aug 2018 20:59:57 -0700 (PDT) MIME-Version: 1.0 References: <20180822153012.173508681@infradead.org> <20180822154046.823850812@infradead.org> <20180822155527.GF24124@hirez.programming.kicks-ass.net> <20180823134525.5f12b0d3@roar.ozlabs.ibm.com> In-Reply-To: <20180823134525.5f12b0d3@roar.ozlabs.ibm.com> From: Linus Torvalds Date: Wed, 22 Aug 2018 20:59:46 -0700 Message-ID: Subject: Re: [PATCH 3/4] mm/tlb, x86/mm: Support invalidating TLB caches for RCU_TABLE_FREE To: Nick Piggin Cc: Peter Zijlstra , Andrew Lutomirski , "the arch/x86 maintainers" , Borislav Petkov , Will Deacon , Rik van Riel , Jann Horn , Adin Scannell , Dave Hansen , Linux Kernel Mailing List , linux-mm , David Miller , Martin Schwidefsky , Michael Ellerman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 22, 2018 at 8:45 PM Nicholas Piggin wrote: > > powerpc/radix has no such issue, it already does this tracking. Yeah, I now realize that this was why you wanted to add that hacky thing to the generic code, so that you can add the tlb_flush_pgtable() call. I thought it was because powerpc had some special flush instruction for it, and the regular tlb flush didn't do it. But no. It was because the regular code had lost the tlb flush _entirely_, because powerpc didn't want it. > We were discussing this a couple of months ago, I wasn't aware of ARM's > issue but I suggested x86 could go the same way as powerpc. The problem is that x86 _used_ to do this all correctly long long ago. And then we switched over to the "generic" table flushing (which harkens back to the powerpc code). Which actually turned out to be not generic at all, and did not flush the internal pages like x86 used to (back when x86 just used tlb_remove_page for everything). So as a result, x86 had unintentionally lost the TLB flush we used to have, because tlb_remove_table() had lost the tlb flushing because of a powerpc quirk. You then added it back as a hacky per-architecture hook (apparently having realized that you never did it at all), which didn't fix the unintentional lack of flushing on x86. So now we're going to do it right. No more "oh, powerpc didn't need to flush because the hash tables weren't in the tlb at all" thing in the generic code that then others need to work around. Linus