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=-10.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 A389DC433ED for ; Thu, 13 May 2021 05:15:27 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 130546142C for ; Thu, 13 May 2021 05:15:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 130546142C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=aD8EVc10Z5mH7blz8EkvYRuE7j6eobOp8I1Zkvsc+Ww=; b=JJhtvKKYNV3yA6bTFRL9uZGSm mAYkV4hwz4WluF0cFSv6rZgeByFTfNQDZFyez+JB0Jz9Zzk+hkkEP+5o3ZqQ4FbrT5HEmIklFZYgq jOusr2iMf/8O5xROxgRFHK8HdjImk/2swUIpCoNyxfMJCUaJvCSbw7cqg1atb7K1NSPmIOHAQMGQl SkjBnMqWqgU+t1yHWUkdbrh1TzyvfDrCWpDpUCQhciHOrAPwBAhVpntdTI+p/BItt5rrFkn2L9QGP zEGbkRvBPjNSmxeusMGl407G1M/lqnAMjCm65+8Sp32Q0tKQd2pfQeWN/6xqlMNHlHCUU0QLuOcG/ wWKsjpoAg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lh3fB-004mnx-HG; Thu, 13 May 2021 05:13:33 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lh3f6-004mnf-Jr for linux-arm-kernel@desiato.infradead.org; Thu, 13 May 2021 05:13:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To: Subject:Sender:Reply-To:Content-ID:Content-Description; bh=h2jnB4gpr/zUWi2QDjsI7KA1naPY9xeU2S7g6e+DRAg=; b=ITXNZ6DPvVeBiLs9D4HYyew5gw +EWqzIHwy2K3QaXKc3CaYIvxmkbmwjHdNfvL2tM5gXg9Uv2YWxvafpBapwlaSPztAmgF7EG5vzxOm G14KnSvA5y47xSFYlj/v98d6PnHWWwARFDOZHcdAMdnefy71TmQ6C1j3nOWo4BH61vD8gTQ6vmf8A LFYgiZku4xETf9tCYgMJ+Y5IKWPjXqLLDDE2IgpA0aRbwtXRA9Db748m817xyyNxRK1t+uZHwiaT3 UvlDGqss0alYzS10hc8c/4Il9DkiiwE/L2WeJv6+V4JfNhR5wY4yi5SWmi3MLkR9GiHRkRBBqs9Up A+Fz47EQ==; Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lh3f3-00B1K6-Og for linux-arm-kernel@lists.infradead.org; Thu, 13 May 2021 05:13:27 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CD77F101E; Wed, 12 May 2021 22:13:20 -0700 (PDT) Received: from [10.163.78.16] (unknown [10.163.78.16]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ECE7E3F73B; Wed, 12 May 2021 22:13:18 -0700 (PDT) Subject: Re: [PATCH] arm64/mm: Remove [PUD|PMD]_TABLE_BIT from [pud|pmd]_bad() To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org References: <1620644871-26280-1-git-send-email-anshuman.khandual@arm.com> <20210510144337.GA92897@C02TD0UTHF1T.local> <4a36d7b7-6b27-31cc-d701-ebe3c6e4946e@arm.com> <20210511140708.GC8933@C02TD0UTHF1T.local> From: Anshuman Khandual Message-ID: <8023de56-e6d5-8df0-9920-35fe7dbde640@arm.com> Date: Thu, 13 May 2021 10:44:04 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210511140708.GC8933@C02TD0UTHF1T.local> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210512_221325_886462_6B2E29C6 X-CRM114-Status: GOOD ( 20.66 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 5/11/21 7:37 PM, Mark Rutland wrote: > On Tue, May 11, 2021 at 09:21:46AM +0530, Anshuman Khandual wrote: >> >> On 5/10/21 8:13 PM, Mark Rutland wrote: >>> On Mon, May 10, 2021 at 04:37:51PM +0530, Anshuman Khandual wrote: >>>> Semantics wise, [pud|pmd]_bad() have always implied that a given [PUD|PMD] >>>> entry does not have a pointer to the next level page table. This had been >>>> made clear in the commit a1c76574f345 ("arm64: mm: use *_sect to check for >>>> section maps"). Hence explicitly check for a table entry rather than just >>>> testing a single bit. This basically redefines [pud|pmd]_bad() in terms of >>>> [pud|pmd]_table() making the semantics clear. >>>> >>>> Cc: Catalin Marinas >>>> Cc: Will Deacon >>>> Cc: Mark Rutland >>>> Cc: linux-arm-kernel@lists.infradead.org >>>> Cc: linux-kernel@vger.kernel.org >>>> Signed-off-by: Anshuman Khandual >>> >>> I have no strong feelings either way, so: >>> >>> Acked-by: Mark Rutland >>> >>> ... that said, I think that the "bad" naming is unclear and misleading, >>> and it'd be really nice if we could clean that up treewide with >>> something clearer than "bad". >> >> Agreed, the name is misleading. >> >>> It does seem that would roughly fit p??_leaf() if we had >> >> But what if the platform does not support huge page aka leaf mapping >> at the given level ? Also a non table i.e bad entry might not always >> mean a leaf/section/huge page mapping, it could simply imply that the >> entry is not just pointing to next level and might be just in an bad >> intermediate or invalid state. > > Ah, so that's also covering swap entries, too? It's not entirely clear > to me what "bad intermediate or invalid state" means, because I assume > it's not arbitrary junk or this wouldn't be sound genrally. Intermediate states like swap, migration or probably even splitting THP. Though I am not really sure whether pxx_bad() only gets used for valid table or leaf entries i.e things which are mapped. Hence checking just for non table entry is better and even safer, than looking out for what other states the entry could be in. > > I had assumed it was only covering *valid* non-table entries. > >>> p??_clear_leaf() and p??_none_or_clear_leaf() helpers. >> >> Could you please elaborate how these new helpers might help define >> pxx_bad() ? > > This was based on my (evidently wrong) prior understanding above. > > Thanks, > Mark. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel