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=-7.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 4B1C7C433E0 for ; Thu, 21 Jan 2021 13:11:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 43D2C239FF for ; Thu, 21 Jan 2021 13:11:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 43D2C239FF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 593B46B0005; Thu, 21 Jan 2021 08:11:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 544C36B0007; Thu, 21 Jan 2021 08:11:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 481EB6B0008; Thu, 21 Jan 2021 08:11:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0007.hostedemail.com [216.40.44.7]) by kanga.kvack.org (Postfix) with ESMTP id 320266B0005 for ; Thu, 21 Jan 2021 08:11:09 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id F07BB181AF5C7 for ; Thu, 21 Jan 2021 13:11:08 +0000 (UTC) X-FDA: 77729817816.19.glove64_2104b5e27563 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id C0E341AD1B3 for ; Thu, 21 Jan 2021 13:11:08 +0000 (UTC) X-HE-Tag: glove64_2104b5e27563 X-Filterd-Recvd-Size: 3452 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Thu, 21 Jan 2021 13:11:08 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id B3DCA239FD; Thu, 21 Jan 2021 13:11:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611234667; bh=2y3nGlOhKVuLqnNjQEH4fvR9yoxLXv3W74n69qv+ztU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DMGerGrEyeuqZjQcioHC6qJlSjxztZkPOzz9rPBbGMGM4CrCsv2OoPx+nqbx/5U6V qqnUASiYhMVlSFup3Xtd+GhMe9vouxtjgM5xEUoC6vloFLyuBsYJMqoV6HDsfK2Jwt s+Fn9tbQHe7o+zXPgNW3OjfJ3quFDKohpqwKv0OVYn2/OrqHoFw8VXYruoZLw0NJQs NnxmPBHMheaB9NLaz2p2IamJL7YC3LegARCqCn5DcSxRv6Ta0fLczedsj26scJmFLN hmuJp9osXG++3J9N+kDY72bLNkZ3z2e6KAhFY9IiGFany5cGQ8RQH4E7acxjU2EdIO Im3FHP1GKDehg== Date: Thu, 21 Jan 2021 13:11:01 +0000 From: Will Deacon To: Linus Torvalds , luc.vanoostenryck@gmail.com Cc: Nick Desaulniers , LKML , Linux Memory Management List , Linux ARM , Catalin Marinas , Jan Kara , Minchan Kim , Andrew Morton , "Kirill A . Shutemov" , Vinayak Menon , Hugh Dickins , kernel-team Subject: Re: [PATCH v4 8/8] mm: Mark anonymous struct field of 'struct vm_fault' as 'const' Message-ID: <20210121131101.GD22123@willie-the-truck> References: <20210120173612.20913-1-will@kernel.org> <20210120173612.20913-9-will@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 Wed, Jan 20, 2021 at 11:02:06AM -0800, Linus Torvalds wrote: > On Wed, Jan 20, 2021 at 10:27 AM Nick Desaulniers > wrote: > > > > Is there a difference between: [ const unnamed struct and individual const members ] > > Semantically? No. > > Syntactically the "group the const members together" is a lot cleaner, > imho. Not just from a "just a single const" standpoint, but from a > "code as documentation" standpoint. > > But I guess to avoid the clang issue, we could do the "mark individual > fields" thing. I'd prefer to wait until the bug against LLVM has been resolved before we try to work around anything. Although I couldn't find any other examples like this in the kernel, requiring all of the member fields to be marked as 'const' still feels pretty fragile to me; it's only a matter of time before new non-const fields get added, at which point the temptation for developers to remove 'const' from other fields when it gets in the way is pretty high. None of this is bullet-proof, of course, but if clang ends up emitting a warning (even if it's gated behind an option) then I think we're in a good place. > (It turns out that sparse gets this wrong too, so it's not just clang). Adding Luc, as hopefully that's fixable. Will