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=-5.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 AFACAC2BA19 for ; Thu, 9 Apr 2020 20:47:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 67B6620730 for ; Thu, 9 Apr 2020 20:47:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="ojmHHSXt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 67B6620730 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1630E8E0015; Thu, 9 Apr 2020 16:47:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 114DD8E0003; Thu, 9 Apr 2020 16:47:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 050F78E0015; Thu, 9 Apr 2020 16:47:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0040.hostedemail.com [216.40.44.40]) by kanga.kvack.org (Postfix) with ESMTP id ED8668E0003 for ; Thu, 9 Apr 2020 16:47:06 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id BB316824C723 for ; Thu, 9 Apr 2020 20:47:06 +0000 (UTC) X-FDA: 76689501252.21.ink43_20ecaa464503c X-HE-Tag: ink43_20ecaa464503c X-Filterd-Recvd-Size: 6023 Received: from hqnvemgate24.nvidia.com (hqnvemgate24.nvidia.com [216.228.121.143]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Thu, 9 Apr 2020 20:47:06 +0000 (UTC) Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Thu, 09 Apr 2020 13:45:20 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate102.nvidia.com (PGP Universal service); Thu, 09 Apr 2020 13:47:04 -0700 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Thu, 09 Apr 2020 13:47:04 -0700 Received: from DRHQMAIL107.nvidia.com (10.27.9.16) by HQMAIL109.nvidia.com (172.20.187.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Apr 2020 20:47:04 +0000 Received: from [10.2.58.92] (10.124.1.5) by DRHQMAIL107.nvidia.com (10.27.9.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Apr 2020 20:47:03 +0000 Subject: Re: [PATCH 1/5] mm: Constify a lot of struct page arguments To: Jason Gunthorpe , "Kirill A. Shutemov" CC: Matthew Wilcox , , , References: <20200408150148.25290-1-willy@infradead.org> <20200408150148.25290-2-willy@infradead.org> <20200409140914.u3mff4xrk5u4tvht@box> <20200409141550.GU21484@bombadil.infradead.org> <20200409142851.obndv6u7wpo2zovj@box> <20200409143238.GV21484@bombadil.infradead.org> <20200409144744.25bloz245hmtr5rm@box> <20200409171210.GJ11886@ziepe.ca> X-Nvconfidentiality: public From: John Hubbard Message-ID: Date: Thu, 9 Apr 2020 13:47:03 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200409171210.GJ11886@ziepe.ca> X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL111.nvidia.com (172.20.187.18) To DRHQMAIL107.nvidia.com (10.27.9.16) Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1586465120; bh=UmgPdkigpo8Eh53OleRKrZJLdF4lmAYsAUWV3SAimSU=; h=X-PGP-Universal:Subject:To:CC:References:X-Nvconfidentiality:From: Message-ID:Date:User-Agent:MIME-Version:In-Reply-To: X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=ojmHHSXtrNM8OCUxbkSh1uyuoK70WvGYcy0A8oDLTLj66q0Ed4TPyMQ930dsLCUAC MWq65aDnOAFGjjXxHpRAUyMLOlD89AesVEE664ofG84EyVafZsWOU/9eKVCU5ZI/oA Mqa8VNvB8o0sxXzyS1bchOv4ozg3w1snb3NCFMD/7ygloJQP2cTD9Yeu5vdoAYm+u3 /ClW4GmzeU+eG1x6AMiqEXuNLOo8BvFLI5MllJDtrX6XQpSS51SDxatptSO6kRN/zZ wdbP9Pcvd8/lvZIIV15Y90K9erfOUnDBt8nYQunLZtQ2Z+t1JDv6ZlRq4uYc/NpGrs v1TxKofQX4VTw== 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 4/9/20 10:12 AM, Jason Gunthorpe wrote: > On Thu, Apr 09, 2020 at 05:47:44PM +0300, Kirill A. Shutemov wrote: >> On Thu, Apr 09, 2020 at 07:32:38AM -0700, Matthew Wilcox wrote: >>> On Thu, Apr 09, 2020 at 05:28:51PM +0300, Kirill A. Shutemov wrote: >>>>> We have a few places that do things like >>>>> >>>>> mm/filemap.c: if (unlikely(compound_head(page)->mapping != mapping)) { >>>> >>>> Good point. >>>> >>>> Acked-by: Kirill A. Shutemov >>> >>> Darn, I hoped you'd have a better idea. I feel quite ashamed of this patch. >> >> I had two ideas. Both awful. >> >> - Rename compound_head() to __compound_head() or something and make it >> return void *. Then wrap it into a macro that would cast return type to >> type of the argument. It would allow to regain *some* type safety. >> >> - Provide two implementations and use C11 _Generic() :P >> (bump GCC version requirements first) > > I saw people using static_assert stuff in the kernel, maybe C11 is > feasible now? It is 9 years old.. ohhh, if this patch is a reliable indicator of what const correctness looks like in the kernel, then we're going to end up with a lot movement in that direction, too. With that in mind, let's provide some counter-force, by: 1) Poking around at the C11 idea, just in case It Is Time. Because clearly the C language dialect that we're using now is not *quite* up to doing const correctness, so moving the language ahead is likely to give us the cleanest solution. Better than writing our own language in macros, which yes, I realize is a way to compensate. But, uggghhh. :) 2) Perhaps providing two routines with different names might be the answer in this case? This avoids macros, still provides a const cast (which is breaks the chain of const correctness, but on the other hand, we still get most of the const goodness--the rest comes when the language supports it): diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h index 222f6f7b2bb3..71e2d07ddcf4 100644 --- a/include/linux/page-flags.h +++ b/include/linux/page-flags.h @@ -186,6 +186,11 @@ static inline struct page *compound_head(struct page *page) return page; } +static inline const struct page *compound_head_const(struct page *page) +{ + return (const struct page*)compound_head(page); +} + static __always_inline int PageTail(struct page *page) { return READ_ONCE(page->compound_head) & 1; diff --git a/mm/debug.c b/mm/debug.c index 2189357f0987..9a1f37a80ed7 100644 --- a/mm/debug.c +++ b/mm/debug.c @@ -44,7 +44,7 @@ const struct trace_print_flags vmaflag_names[] = { void __dump_page(struct page *page, const char *reason) { - struct page *head = compound_head(page); + const struct page *head = compound_head_const(page); struct address_space *mapping; bool page_poisoned = PagePoisoned(page); bool compound = PageCompound(page); ...etc thanks, -- John Hubbard NVIDIA