From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6699FECE58C for ; Mon, 14 Oct 2019 20:38:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 198EA2083B for ; Mon, 14 Oct 2019 20:38:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="JHYeinNb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 198EA2083B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BD8568E0005; Mon, 14 Oct 2019 16:38:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B87ED8E0001; Mon, 14 Oct 2019 16:38:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A76068E0005; Mon, 14 Oct 2019 16:38:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0184.hostedemail.com [216.40.44.184]) by kanga.kvack.org (Postfix) with ESMTP id 87CE08E0001 for ; Mon, 14 Oct 2019 16:38:57 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 3476F82DF9E6 for ; Mon, 14 Oct 2019 20:38:57 +0000 (UTC) X-FDA: 76043554314.10.house12_4e149a03a8c46 X-HE-Tag: house12_4e149a03a8c46 X-Filterd-Recvd-Size: 8778 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Mon, 14 Oct 2019 20:38:56 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id d1so17880286ljl.13 for ; Mon, 14 Oct 2019 13:38:56 -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=LvNlasHHPKccXox7dKQ61wjVRqsBAIykBowufugafNw=; b=JHYeinNbUhDU9JOT1icXjbCc6D8tAAxdTuxxBxHbP7n5BxrRPMJN6jHCkGxuqtQsmo F38havP+GnWryvYUJVgEpDkK/4ERk+FjYdhOiRWDlYL15HUvXuaNMXnyFom5PU8TxlkT jhgnijOPh4hbegqJqlkHK+WVNTGc3Zb0SylD4= 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=LvNlasHHPKccXox7dKQ61wjVRqsBAIykBowufugafNw=; b=knz2Yyg4PR31kdvC5/dR5CnM8eLp7H5K4Cdzvn3kS7Ivwt26guLG/Xlu2jG+ox0dEo 7PCbnvsG+PSOVY2r0MqbV53oLA9yWKKFfSi9DvNd50yjHy3j/J3nl/JoCd00DgsWnidz 3DmCLpwYHUdHR0zJ/AzEvMRsGfvpoASOKqTVnBLB/dLop/Lt7l8mdMT99yXJwIdPlMrt vqcGUbr01Cu6a/i9ixtSoOpVS8mj1hTNnerzJxdN4zngMD83CPcxLAdXfzDty6ZQPUfb 2thArEAxippIFMGRGHJMNYqfQI8iEN9xXPTXXB+Req/nlTcPYwyovw7PhFPqH0mpfdRZ 7zJw== X-Gm-Message-State: APjAAAXqcv7NRU9+kh+JFEHqLUdSp4KaCL9RCy9R/aiS0LI3rcigK5iA 2H9xfOdFk7DhexsxlmEKhb7uWGW0vdk= X-Google-Smtp-Source: APXvYqy2HbXCLJFHgZ4R/Qv9iSy2msRjk9VO+oxpWnzEzd3ynX+5srPHQkhqc27BsAUHusXB3/f9TQ== X-Received: by 2002:a2e:9702:: with SMTP id r2mr17766541lji.194.1571085534102; Mon, 14 Oct 2019 13:38:54 -0700 (PDT) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com. [209.85.208.175]) by smtp.gmail.com with ESMTPSA id f22sm4469492lfa.41.2019.10.14.13.38.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Oct 2019 13:38:51 -0700 (PDT) Received: by mail-lj1-f175.google.com with SMTP id a22so17963460ljd.0 for ; Mon, 14 Oct 2019 13:38:51 -0700 (PDT) X-Received: by 2002:a2e:8315:: with SMTP id a21mr10388327ljh.133.1571085530949; Mon, 14 Oct 2019 13:38:50 -0700 (PDT) MIME-Version: 1.0 References: <20191011121951.nxna6hruuskvdxod@box> <20191011223818.7238-1-vgupta@synopsys.com> <8bfd023b-5c00-8355-fd0f-3b4377951e6c@gmail.com> In-Reply-To: <8bfd023b-5c00-8355-fd0f-3b4377951e6c@gmail.com> From: Linus Torvalds Date: Mon, 14 Oct 2019 13:38:34 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] asm-generic/tlb: stub out pmd_free_tlb() if __PAGETABLE_PMD_FOLDED To: Vineet Gupta Cc: linux-arch , Arnd Bergmann , Peter Zijlstra , "Aneesh Kumar K . V" , Linux Kernel Mailing List , Nick Piggin , Linux-MM , Andrew Morton , linux-snps-arc@lists.infradead.org, Will Deacon , "Kirill A . Shutemov" Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Oct 14, 2019 at 12:08 PM Vineet Gupta wrote: > > > And yes, pmd_clear_bad() should just go away. We have > > > > static inline int pmd_none_or_clear_bad(pmd_t *pmd) > > { > > if (pmd_none(*pmd)) > > return 1; > > if (unlikely(pmd_bad(*pmd))) { > > pmd_clear_bad(pmd); > > return 1; > > } > > return 0; > > } That was a particularly bad example. The pmd always exists, even in a 2-level setup. It's the pgd/p4d/pud that end up containing a lower level, but pmd_none() is never one of the fixed "doesn't exist" cases. > > Exactly what part isn't working for you? > > I haven't tested that patch but I suspect even if it was broken, it would not > necessarily show right away with a trivial test. > > Anyhow my worry/confusions starts at free_pgd_range() where > pgd_none_or_clear_bad(pgd) is no-op given pgd_none()/pgd_bad() are stubs for nopmd > case. Right. If you have a two-level setup, then p[g4u]d_none_or_clear_bad() should end up being no-ops. Buit then: > And the validation of pgd entry actually happens in pmd_none_or_clear_bad(pmd) > since there pmd actually ends up referencing pgd entry. Hence the ensuing > pmd_clear_bad() doesn't seem like if it could be stubbed out. Yes, you're correct, I was just "off by one" in my levels. Yeah, the folding is damn confusing. And it doesn't help that I think some of the code talks about the lower level being folded into the higher level for historical reasons, so we have those PMD_FOLDED macros etc, which are really about pud() just going away because pmd is folded inside the pud. So when the pud level is compiled away, we talk about the pmd level being folded into it, and then we get confusion (like mine above) where you end up being off by one level, because depending on how it's being talked about, you talk about one or the other. And it shows in the header files too. We have "pgtable-nopmd.h", which then defines the page table accessors not for the pmd level, but for the pud level. Which is why I then spout nonsense like the above about pmd_none() - because I was thinking of the nopmd case, but that makes the p*u*d_none() be always 0, not p*m*d_none(). So we have this whole "off-by-one" error in our naming and thus our thinking, and it's really easy to just get really confused about it. We should probably get rid of the whole "PMD_FOLDED" logic, and instead talk about "no PUD level". It actually shows in our types too. We do this: typedef struct { pud_t pud; } pmd_t; #define PTRS_PER_PMD 1 because some of the code thinks of the pmd as containing the pud. But it would probably be better to do it the other way around, and just consistently think of it as "pud level doesn't exist, the pud level just contains a pmd" instead. So we have these really odd "somethimes we think of pmd as part of a pud entry" vs "sometimes we think of pud as just containing a single pmd". And I think that latter model is the better mental model, but then we should have typedef struct { pmd_t pud; } pud_t; #define PTRS_PER_PUD 1 instead, and we'd get static inline pmd_t * pmd_offset(pud_t * pud, unsigned long address) { return &pud->pmd; } and that would make more sense, wouldn't it? But trying to fix our odd "we seem to think about it wrong" model would likely be too painful to be realistic., It would involve renaming nop4d.h -> nopgd.h nopud.h -> nop4d.h nopmd.h -> nopud.h and turning those types around (so we'd have those typedef struct { p4d_t p4d; } pgd_t; typedef struct { pud_t pud; | p4d_t; typedef struct { pmd_t pmd; } pud_t; for no-pgd/no-p4d/no-pud respectively. So then a 2-level machine would only define the pmd and pte levels, and be done with it, because the upper levels would be defined in terms of those. But that's not what we do, and we mix up levels in odd and confusing ways. And now I've said pgd/pud/p4d/pmd so many times that I've confused myself and think I'm wrong again, and I think that historically - originally - we always had a pgd, and then the pmd didn't exist because it was folded into it. That makes sense from a x86 naming standpoint. Then x86 _did_ get a pmd, and then we added more levels in between, and other architectures did things differently. So I think the confusion is historical, and is because we've switched between thinking that the the lower level that doesn't exist, but is embedded in the upper level, and slowly converted to "it's the upper level that doesn't exist, and just contains the lower level" The point stands: it's confusing, and we should probably pick one model, and the model we pick should likely be "this level doesn't exist, and just wraps the lower level", so it *should* be "no pgd"/"no p4d"/"no pud". Linus