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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 95328C433E0 for ; Thu, 21 Jan 2021 19:24:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 109C823136 for ; Thu, 21 Jan 2021 19:24:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 109C823136 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 736CD6B0006; Thu, 21 Jan 2021 14:24:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E55B6B0007; Thu, 21 Jan 2021 14:24:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 622176B0008; Thu, 21 Jan 2021 14:24:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 4BAFC6B0006 for ; Thu, 21 Jan 2021 14:24:49 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 107C98249980 for ; Thu, 21 Jan 2021 19:24:49 +0000 (UTC) X-FDA: 77730759498.30.pan83_5d0449b27565 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id DBF52180B3AB8 for ; Thu, 21 Jan 2021 19:24:48 +0000 (UTC) X-HE-Tag: pan83_5d0449b27565 X-Filterd-Recvd-Size: 5545 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Thu, 21 Jan 2021 19:24:48 +0000 (UTC) Received: by mail-pg1-f171.google.com with SMTP id n10so1983290pgl.10 for ; Thu, 21 Jan 2021 11:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/gqSp7OcRr/ed55qU/19Bnmbh+jsqIQNuD5w35l1bQs=; b=V0LztueDbN4iG0gjmN25TNfzITrA3aCeZH/L7I6Ksa+5VCc63DQfSQZ7OBLMBjRHg2 7eYdFa5BCmIwSTuLdq5y29eDGRwl3SpKtc58yMRonCi/CYQTOSyn3/ld3rO/ABzn3Hyu u577D/KK23BerSVmTUda1Hhzq1mkd2vnS/1W3t8TlfcM5xx+JSuYo5Sr7IAAj+bCxT+B voc7iIzKjE+UM2ntT40FwdJ1WxdpXX1F9bzClRmVTkwRNB+S7CIC9slJxJbYyIBykUCj LNO1hBC7rfgLEwTWC868gS/Kj64358n9mTFfLHlA0cTVYpfpTDZSyfKCDHPxXGipSSeh c01g== 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=/gqSp7OcRr/ed55qU/19Bnmbh+jsqIQNuD5w35l1bQs=; b=A71rVVteBQkauKW6xbpAfAYmGGFCfuMNFsp/nkTHDBdTURkpd4PgWP2wKUBuODIvO/ 5ThTvNyJ8uqNkasEq52LQSRptNJxutYVl+6J9JiAl/n+j7zxgahEgeMnJahpz9NpMOqn EBITihh+p1r+McbpDr/dVAix/7DaaBMamJfQusXc0PKiKqjsyTtRnaFrhMrJW5LnMOw9 O4oT5F1fK6nYII9E3FypSgYS3O+SCCjzhb7Kjfcl1WvDe3eB6byBb9Y0inbPQnHUFFdJ vEgi0dosDVvVwRMeeIv4wtSko4fxIp0vm3IZndfoTvHZiwHb82Q2sj+TNXmvloLkIyWs 00iA== X-Gm-Message-State: AOAM530vpLs5NStIumw6Pzqh+WUCP3GzTKxnqxhFeIia4TUcIOoVoe5z KpnMLkLyd7jQ7K7hQBvtxgRpyg1QNlaWyJJvmf7UKA== X-Google-Smtp-Source: ABdhPJyRkjYcnaiD6RGS63GWq9+T6pTjXHEcp654EFy2JWq7JLVbynLjUukaZB9crrdy/DhTTewtfYeve07hc7LLaeU= X-Received: by 2002:a62:7896:0:b029:1b6:7319:52a7 with SMTP id t144-20020a6278960000b02901b6731952a7mr1026808pfc.30.1611257087169; Thu, 21 Jan 2021 11:24:47 -0800 (PST) MIME-Version: 1.0 References: <20210120173612.20913-1-will@kernel.org> <20210120173612.20913-9-will@kernel.org> <20210121131101.GD22123@willie-the-truck> In-Reply-To: <20210121131101.GD22123@willie-the-truck> From: Nick Desaulniers Date: Thu, 21 Jan 2021 11:24:36 -0800 Message-ID: Subject: Re: [PATCH v4 8/8] mm: Mark anonymous struct field of 'struct vm_fault' as 'const' To: Will Deacon Cc: Linus Torvalds , Luc Van Oostenryck , LKML , Linux Memory Management List , Linux ARM , Catalin Marinas , Jan Kara , Minchan Kim , Andrew Morton , "Kirill A . Shutemov" , Vinayak Menon , Hugh Dickins , kernel-team 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 Thu, Jan 21, 2021 at 5:11 AM Will Deacon wrote: > > 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. What's to stop a new non-const field from getting added outside the const qualified anonymous struct? What's to stop someone from removing const from the anonymous struct? What's to stop a number of callers from manipulating the structure temporarily before restoring it when returning by casting away the const? Code review. Using a non-toolchain-portable solution certainly could be considered more fragile. It's always possible that the resolution is the C standards body goes the C++ route, at which point GCC would be forced to address this and potentially change behavior. Kind of like how people avoid going to court since things are never guaranteed to work out in their favor. > > 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 -- Thanks, ~Nick Desaulniers