Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1207615imm; Wed, 22 Aug 2018 22:05:18 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzNArDJRP5JSb3nr/zmPM9tLl7Gy1tamS6YqEkKGEJsKvOSLznun9aNk0kBdNCvClUPRPgk X-Received: by 2002:a62:5a01:: with SMTP id o1-v6mr61596859pfb.0.1535000718202; Wed, 22 Aug 2018 22:05:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535000718; cv=none; d=google.com; s=arc-20160816; b=LDtEtLjeaR2pb+FKt9pMjFsgGS7qkKg8Iw9KJYxMp3xS4+aKGa1neM0W59hV4IZHGT Wi/nnl1lrFJ4+HUCp9IzPGEERRU6uBBh4NbA747Oa7IPOlspvHXtGilTeqd7tJ08fLbs hjgvvntkkN8zwI4CAFdf0os+hweNKSWEkZoF3SHU2xqIk8e3B+46bJkZjSOkw8q7gp6s Xxcn30KT56LmFUjWKXV3JcWEruXbUU/gi4WajxKqfzAfCeKJV41+mvqErHD4DbMi/oUO S1zHwYXmQw4pwhwp3BkMU0MbQpahgLx5OxPCYnux5cFLjvHJD6oWB7uk2qG1TnBIbl8w V2lA== 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=ixznoVkOoGa1qpjRCZtl5ykCSLlEeAb99KUN0Ox0pMI=; b=Y227N4xnLCr89MqUzjwO2R+VjgouV6GnhB+e4x1Ed0hOHAqLuTeQsZ8sbycqcNzVVa O3fcg8kOl+MtGdoUPOtUFQginqTiOsQlBwatI3gataZtd7lJjAr3Soxx55u17muzNoRN 9H7tSlqB460d4s8pC1szUg8PUEpGIMHtRSAGH9xuy3LmFYNKBwqJks5BOye/Efa2kLRi /oF+ZeuBqXw8O0elCRdgKe5/RNWRHFB8NJJeoAoxE7Gr3DzEmM8U6fDMa1MC7gcp5xSs lcYlOtEEQ/6Rb9BAQyHtyWs/VNfA6b79pT7EOa3zdjxySsTseNAtHbzYpHH2GJ4DiJr3 1cWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=ITgB6g8O; 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 s125-v6si4039655pfb.335.2018.08.22.22.05.00; Wed, 22 Aug 2018 22:05:18 -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=ITgB6g8O; 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 S1728410AbeHWIbm (ORCPT + 99 others); Thu, 23 Aug 2018 04:31:42 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:36435 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726267AbeHWIbm (ORCPT ); Thu, 23 Aug 2018 04:31:42 -0400 Received: by mail-it0-f67.google.com with SMTP id p81-v6so6046722itp.1 for ; Wed, 22 Aug 2018 22:03:52 -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=ixznoVkOoGa1qpjRCZtl5ykCSLlEeAb99KUN0Ox0pMI=; b=ITgB6g8OmZfkWhW9J8NjFPHtkcxdsWfFf8h1gBMhsepfsEp2KID9zsx3uNajwwRaNL puntJ8+RiXT7zo1rTM3+U3HMWyBNfSB5ag/mBr247vZoAyXB504tCbT30x2JNyymuwjr ICnwhhuIsgdg26CTu9K0CdeHBqkvEM/Of7RS8= 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=ixznoVkOoGa1qpjRCZtl5ykCSLlEeAb99KUN0Ox0pMI=; b=BTfxWQv70V1cLNwJfDTQUoJ9GiUar7HHNOF90DtexSKbQkarCc9zoaljByzTRFlxK1 3Gfd+KyLdeSsXLZx+1ba4qgVq5VPbgAx56Sp+VYjfPznZk8c8uIKsj9AhiiemDdN1Z29 2ADVj4xV8NPmMHCdZzQvqIFderN1V40ezVBIouduDtiMs/yqtSsk3CHJf41wMVV0ldrl 3V19+gU1LvdtRalpin8+cHLH8wy5lH9D4R5pxIZZdgl70CP+wlU+LiOoExlrA5x1aZ5g wCyn2oPM6ADWgd/KPF8YCrVs6j2YAiKPubXFzfF2Un3Uc6FYDGTdEt0nzcCYJcDbp13E GVTw== X-Gm-Message-State: APzg51AGbJ1Q2wKONSMeXE0Ln1Jp9uu0YzVLMO52VKyLpTWJvxTBsNu7 araIqaSMVTYo3uUlTMbJVYvXOEnsiE6gXulYqWM= X-Received: by 2002:a24:61d2:: with SMTP id s201-v6mr6042311itc.22.1535000631916; Wed, 22 Aug 2018 22:03:51 -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> <20180823143349.65cb0da0@roar.ozlabs.ibm.com> In-Reply-To: <20180823143349.65cb0da0@roar.ozlabs.ibm.com> From: Linus Torvalds Date: Wed, 22 Aug 2018 22:03:40 -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 9:33 PM Nicholas Piggin wrote: > > I think it was quite well understood and fixed here, a145abf12c9 but > again that was before I really started looking at it. You don't understand the problem. All the x86 people thought WE ALREADY DID THAT. Because we had done this all correctly over a decade ago! Nobody realized that it had been screwed up by the powerpc code, and the commit you point to was believed to be a new *powerpc* only issue, because the semantics on powerpc has changed because of the radix tree. The semantics on x86 have never changed, they've always been the same. So why would the x86 people react to powerpc doing something that x86 had already always done. See? Nobody cared one whit about commit a145abf12c9, because it just handles a new powerpc-specific case. > I don't really understand what the issue you have with powerpc here. > powerpc hash has the page table flushing accessors which are just > no-ops, it's the generic code that fails to call them properly. Surely > there was no powerpc patch that removed those calls from generic code? Yes there was. Look where the generic code *came* from. It's powerpc code. See commit 267239116987 ("mm, powerpc: move the RCU page-table freeing into generic code"). The powerpc code was made into the generic code, because the powerpc code had to handle all those special RCU freeing things etc that others didn't. It's just that when x86 was then switched over to use the "generic" code, people didn't realize that the generic code didn't do the TLB invalidations for page tables, because they hadn't been needed on powerpc. So the powerpc code that was made generic, never really was. The new "generic" code had a powerpc-specific quirk. That then very subtly broke x86, without the x86 people ever realizing. Because the old simple non-RCU x86 code had never had that issue, it just treated the leaf pages and the directory pages exactly the same. See? And THAT is why I talk about the powerpc code. Because what is "generic" code in 4.18 (and several releases before) oisn't actually generic. And that's basically exactly the bug that the patches from PeterZ is fixing. Making the "tlb_remove_table()" code always flush the tlb, the way it should have when it was made generic. Linus