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.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 EB750C43463 for ; Sat, 19 Sep 2020 03:04:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7351021897 for ; Sat, 19 Sep 2020 03:04:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="ELTsF7aY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7351021897 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BC2DA6B005D; Fri, 18 Sep 2020 23:04:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B72E06B0062; Fri, 18 Sep 2020 23:04:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A626F6B0068; Fri, 18 Sep 2020 23:04:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0161.hostedemail.com [216.40.44.161]) by kanga.kvack.org (Postfix) with ESMTP id 8EB8C6B005D for ; Fri, 18 Sep 2020 23:04:26 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 56ECF362B for ; Sat, 19 Sep 2020 03:04:26 +0000 (UTC) X-FDA: 77278317732.25.force44_350ce4c27130 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id 2F75D1804E3A0 for ; Sat, 19 Sep 2020 03:04:26 +0000 (UTC) X-HE-Tag: force44_350ce4c27130 X-Filterd-Recvd-Size: 6082 Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com [209.85.167.67]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Sat, 19 Sep 2020 03:04:25 +0000 (UTC) Received: by mail-lf1-f67.google.com with SMTP id y11so8173106lfl.5 for ; Fri, 18 Sep 2020 20:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X1Ix3nDJUNCSSkI/qDnAEimI2vgF9CCBIhywdlTaE0U=; b=ELTsF7aYKL++ZnB8PzR2rM3B1QcCJLHPvQYUx/dbB0a5QGG2kNoBlM8rGw9xtfLHxI D5tTl0yi38La6jzPpyM77PdBMImhhiBH0F+P41vUTVj+kLSItaS/1xq+kUcvn5X6V4WI 0vhbET7ZJMd4GFhXV+gyaSoYWQog+Xh8VfXIA= 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=X1Ix3nDJUNCSSkI/qDnAEimI2vgF9CCBIhywdlTaE0U=; b=gEvrZCBbbPf1/okR02WHeqyX6qujxZOeU4HXVIedI69sRa2EF12nQ3Ap6LUmEOnmkf YQ2zfh+7+EGQWvM2Kf/RUWd6IcGbq+C4fi9oXSxmIKDYYACTa5R5SBWQdtoOWzWGj5FE t7ZaSeOh79b8GpNuer2ZFghbhucrq4xeuEOGZWvybSynra5iOiFGcoT5uDnX7fpOkmLi gjcdPabQHPIeWpz4+EDlfJmwsqBBJTI+K/MBnW90g4wZ9+RrGHM84EWMYG8XIHR1A6ym Ib5cPtLBKdj00EZk2/PkxV45OeVC1biPYUsyJe4LyNmb4br58NUjtCfv+6HpTAoUsP/a Em9A== X-Gm-Message-State: AOAM533+FLJIg1fjzDFtZRvyK7oE/Bp8Y+ifavqT2aPQkxXEl8cB4J2Y LN26iaBSOHNZI65SqTxeTn0Fjox9k9YQoA== X-Google-Smtp-Source: ABdhPJyfzBYPcCn1mkPtRxcBCRtFv01JvT6iTcjZNPqhZAHql4LnU4+uGs49Qd7l+W//MXB5712jCg== X-Received: by 2002:a19:4a58:: with SMTP id x85mr11575589lfa.168.1600484664086; Fri, 18 Sep 2020 20:04:24 -0700 (PDT) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id 138sm988565lfl.241.2020.09.18.20.04.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2020 20:04:23 -0700 (PDT) Received: by mail-lf1-f46.google.com with SMTP id z17so8121937lfi.12 for ; Fri, 18 Sep 2020 20:04:22 -0700 (PDT) X-Received: by 2002:a19:8907:: with SMTP id l7mr11418508lfd.105.1600484662603; Fri, 18 Sep 2020 20:04:22 -0700 (PDT) MIME-Version: 1.0 References: <20200918193426.GA15213@embeddedor> <20200918200252.GH32101@casper.infradead.org> <20200918202909.GA2946008@rani.riverdale.lan> <20200918210050.GA2953017@rani.riverdale.lan> <20200918223957.GA2964553@rani.riverdale.lan> <20200919025336.GA3008405@rani.riverdale.lan> In-Reply-To: <20200919025336.GA3008405@rani.riverdale.lan> From: Linus Torvalds Date: Fri, 18 Sep 2020 20:04:06 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] percpu fix for v5.9-rc6 To: Arvind Sankar Cc: Matthew Wilcox , "Gustavo A. R. Silva" , Dennis Zhou , Tejun Heo , Christoph Lameter , Linux-MM , Linux Kernel Mailing List , Kees Cook Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000020, 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 7:53 PM Arvind Sankar wrote: > > Is it ever necessary to allocate _at least_ sizeof() even if > offsetof()+size is smaller? Not that I can tell. Obviously all allocators tend to have their own alignment concerns, so they'll all align things up internally anyway. But why would the alignment of the earlier members of the structure have anything to do with the size of it? That's nonsensical outside of the array situation, I feel. Of course, maybe somebody has such a case: an "array of structures, each with the same size of flexible array member". And then you _do_ want to align all those entries. But honestly, once you start doing things like that, why would you only have one single structure type, much less just one single size of that flexible array? If you lay out these variably-sized things in memory each after each other, maybe you lay out multiple different _kinds_ of variably sized structures? So there are lots of reasons to want alignment at the end, but why would the alignment be the same as the beginning of that particular type? That said, in the kernel, this probably practically never really matters. Because typically, our allocation alignment tends to be bigger than any individual structure type alignment anyway. So it's probably all moot. The difference between using "sizeof()" and "offsetof()" is in the noise and not important per se. No, the real reason I would advocate using 'offsetof()' is really just that I'd rather have 'sizeof()' cause a warning. > I think you can't do this in standard C. It's a GCC extension. > > A structure containing a flexible array member, or a union > containing such a structure (possibly recursively), may not be a > member of a structure or an element of an array. (However, these > uses are permitted by GCC as extensions.) Ahh. But I'm pretty sure the 'sizeof()' thing is actually the standard, not gcc. Arrays of those things is odd, and apparently the standard got that right. Good (but I think it also means that allowing sizeof() makes even less sense). Linus