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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 E9FACC43464 for ; Fri, 18 Sep 2020 21:00:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 68A4A21481 for ; Fri, 18 Sep 2020 21:00:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iy16vZfU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 68A4A21481 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=alum.mit.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A05366B0080; Fri, 18 Sep 2020 17:00:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DB296B0095; Fri, 18 Sep 2020 17:00:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F3878E0001; Fri, 18 Sep 2020 17:00:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0215.hostedemail.com [216.40.44.215]) by kanga.kvack.org (Postfix) with ESMTP id 7A1D96B0080 for ; Fri, 18 Sep 2020 17:00:54 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 459FC247A for ; Fri, 18 Sep 2020 21:00:54 +0000 (UTC) X-FDA: 77277401628.29.jar38_2116ee22712e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 1D274180868D5 for ; Fri, 18 Sep 2020 21:00:54 +0000 (UTC) X-HE-Tag: jar38_2116ee22712e X-Filterd-Recvd-Size: 6254 Received: from mail-qv1-f65.google.com (mail-qv1-f65.google.com [209.85.219.65]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Fri, 18 Sep 2020 21:00:53 +0000 (UTC) Received: by mail-qv1-f65.google.com with SMTP id j10so3662722qvk.11 for ; Fri, 18 Sep 2020 14:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ZJ8zmvc17bX9xj6+//ug0LM49mqv1RsrDk1L3tNk8ec=; b=iy16vZfUztyOxKq/IfHgI7kJQtwerpgo53nlcxG4i0DEjyExYJZzcnvYLRZ7dv41C/ uaQhCPGAqENb++afLCD1je++48JWOwmrzYv5ZAFoyTwgXdm9/MfkK+nNwmlrqsPEUIFS zpCLZ5gN6euxSAl7cguwqsDnmWIOHXSTa7tWW9LroF3wpSYyN9+nqnEuCdJHyxsWH8b4 B3L5cm6Ix6jRaOz5BL3uee+vaatoD1sR8m0nUX1jABVjFRbamQg1/5dhtEb+DPXQbdfa CXkwTnbSwjfJoV7dqbHFgbgUyf/wpRRr1YFNZiUoCyNmUm7jcQCOJ/xUpUVxo8z42uUm p+Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:date:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=ZJ8zmvc17bX9xj6+//ug0LM49mqv1RsrDk1L3tNk8ec=; b=HwKJiOMYGVkQ2f+FnbflJ+U5RajQ//+i5ip05HKUGBaXNFBHLnB+Pv9nVPSHAN1L57 LpQYfSgCdGd9/YcMBWSlmY7jf5PMJW6ylF870LpjYCrkk4ZBeAstnz/FeeTfC6XFML2w mTmVwDVWEXHiyjcr9+jiXchOlkixLCBAcxilwjRbrYFdNNq91SE3XY4oIQU1zG1Sfg54 xAad8mDdGwxtgf3C7UU880foC0Nn4m4Szc9+VhTldt4Jg4Own9/hF8S0/iAfrK7owvX+ xInewtyHNFQ4prOuXPlRRmTg9OlUgscryjMreM3b3YjRA/zMb1hga4dg5Xl0fWo0I9+t zfwQ== X-Gm-Message-State: AOAM531p4HJg6LOOqicHs7y1kLKPWC5l0VWIZ+rShimeN1OTCPxB6sq8 d6bETeJODLUyMR0cetvdujQ= X-Google-Smtp-Source: ABdhPJzjxkT9OR9uM81+L5YyaGQDJOqg7HbRZA/dBjiHRdtdxqwZ4ZxPjLW83OKSBGbwtd/RgqjGbA== X-Received: by 2002:a0c:8246:: with SMTP id h64mr19332976qva.54.1600462852729; Fri, 18 Sep 2020 14:00:52 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id y69sm2877429qkb.52.2020.09.18.14.00.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2020 14:00:52 -0700 (PDT) From: Arvind Sankar X-Google-Original-From: Arvind Sankar Date: Fri, 18 Sep 2020 17:00:50 -0400 To: Linus Torvalds Cc: Arvind Sankar , Matthew Wilcox , "Gustavo A. R. Silva" , Dennis Zhou , Tejun Heo , Christoph Lameter , Linux-MM , Linux Kernel Mailing List , Kees Cook Subject: Re: [GIT PULL] percpu fix for v5.9-rc6 Message-ID: <20200918210050.GA2953017@rani.riverdale.lan> References: <20200917204514.GA2880159@google.com> <20200918162305.GB25599@embeddedor> <20200918193426.GA15213@embeddedor> <20200918200252.GH32101@casper.infradead.org> <20200918202909.GA2946008@rani.riverdale.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 Fri, Sep 18, 2020 at 01:40:44PM -0700, Linus Torvalds wrote: > On Fri, Sep 18, 2020 at 1:29 PM Arvind Sankar wrote: > > > > In general (i.e. outside the implementation of the macro itself), what > > is the preferred way of getting the size of just the header? > > 1) offsetof(typeof(s),flex) > > 2) struct_size(s, flex, 0) > > I think those two should end up being equivalent. Yeah, but it would be good to standardize on one of them. > > > 3) sizeof(s) > > This works right now, but exactly *because* it works, we're not seeing > the questionable cases. > > Of course, _also_ exactly because it just silently works, I also don't > know if there may be thousands of perfectly fine uses where people > really do want the header, and a "sizeof()" is simpler than > alternatives 1-2. > > It's possible that there really are a lot of "I want to know just the > header size" cases. It sounds odd, but I could _imagine_ situations > like that, even though no actual case comes to mind. I'm asking because I just added an instance of (3) and want to know if I should change it :) The case was when you have a function that got passed a pointer and a size, and wants to verify that the size covers the structure before accessing its fields. If the function only needs the "fixed" fields, it feels a little unnatural to use (1) or (2) when the flex member is otherwise not going be accessed at all. > > > 4) new macro that's easier to read than 1 or 2, but makes it clear > > what you're doing? > > I don't think this would have any real advantage, would it? The advantage is documenting that you do mean the header size, i.e. something like struct_header_size(s). > > Now what might be good is if we can make "struct_size()" also actually > verify that the member that is passed in is that last non-sized > member. I'm not sure how to do that. > > I know how to check that it's *not* that last unsized member (just do > "sizeof(s->flex)", and it should error), but I don't see how to assert > the reverse of that). > > Because that kind of "yes, we actually pass in the right member" check > would be good to have too. > > Linus You could just assert that offsetof(typeof(s),flex) == sizeof(s), no? It would also make sure that someone doesn't try to use struct_size() with a 1-sized array member.