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 5A8E1C43465 for ; Sat, 19 Sep 2020 01:28:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D596121741 for ; Sat, 19 Sep 2020 01:28:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="L8nqdAiG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D596121741 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 172236B0037; Fri, 18 Sep 2020 21:28:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FCEA6B0055; Fri, 18 Sep 2020 21:28:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F061A8E0001; Fri, 18 Sep 2020 21:28:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0198.hostedemail.com [216.40.44.198]) by kanga.kvack.org (Postfix) with ESMTP id D7A136B0037 for ; Fri, 18 Sep 2020 21:28:51 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 955271EFF for ; Sat, 19 Sep 2020 01:28:51 +0000 (UTC) X-FDA: 77278076862.09.boat19_4111f942712f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id 7882D180AD807 for ; Sat, 19 Sep 2020 01:28:51 +0000 (UTC) X-HE-Tag: boat19_4111f942712f X-Filterd-Recvd-Size: 5930 Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Sat, 19 Sep 2020 01:28:50 +0000 (UTC) Received: by mail-lf1-f65.google.com with SMTP id m5so8025503lfp.7 for ; Fri, 18 Sep 2020 18:28:50 -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=03DDUpv2KYWvBoJTaf6UGmiZwq2gyd+Rx2kPEv84BC8=; b=L8nqdAiGERMhCaqM49alokZdWE19BEVx224/Tifw/M/twFSu3nqs7U4UvuJJpfUnnR 7BbRW4cvK78o5X7c2vrFwb8nMoZFrGXJfX2wGo/a/gbB4vU9s/YGGR+c1gRDdijwWnSa s4qp9bxyMNGGSIFTX9WPv4pEZFmvPOvav/e5Q= 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=03DDUpv2KYWvBoJTaf6UGmiZwq2gyd+Rx2kPEv84BC8=; b=unepfHQLtKHDCIEGqmOQ652j0Je/iLbVPosjRRi7SmbsRSroT1ThgWb11NtNMunvF3 dv/kDIRGXjb8FgvT+gazO7iyGBmd2obl9mBwpPEHo59OFwg/RCIS3lbUz5VLEiWCA1fo AyYWO2nw/uHtOMyhRk3C65IFpK3ojlo6Vk/2u3/zL0pRtzYZ6u9syybk96leRZjUlE3n Fi0kqiIJPYOkaJIUZvzwV/bPxY1PpxWyS9TrN6TC077QSG8QgCFEMZZEN95Fxm7w4LZb bqhxM1TWsHZx2LbJ4uIK8PgqW59Xk+SuRpgoB1NWzZwSw2Qm8SuMCJ/2FgvU4xpgxhpy e1ig== X-Gm-Message-State: AOAM531xiDIuK7shsEoFo3CwNdh++6G3/1FFPtCEuJVx0pKE4iJT6wu9 NGlh12YeqRweLiOf3wEonJhZP7WddhqBsg== X-Google-Smtp-Source: ABdhPJwqSi48yM6tqnVJsNaDahkG9yc3rLNrEQ9TY6Y+gd2V0OlEKpzY1gpBi7or43QR9txwP5zbBg== X-Received: by 2002:a19:4a88:: with SMTP id x130mr11431116lfa.31.1600478928772; Fri, 18 Sep 2020 18:28:48 -0700 (PDT) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com. [209.85.208.174]) by smtp.gmail.com with ESMTPSA id q22sm917647lfr.258.2020.09.18.18.28.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2020 18:28:47 -0700 (PDT) Received: by mail-lj1-f174.google.com with SMTP id b19so6500952lji.11 for ; Fri, 18 Sep 2020 18:28:47 -0700 (PDT) X-Received: by 2002:a05:651c:104c:: with SMTP id x12mr13659558ljm.285.1600478927200; Fri, 18 Sep 2020 18:28:47 -0700 (PDT) MIME-Version: 1.0 References: <20200918162305.GB25599@embeddedor> <20200918193426.GA15213@embeddedor> <20200918200252.GH32101@casper.infradead.org> <20200918202909.GA2946008@rani.riverdale.lan> <20200918210050.GA2953017@rani.riverdale.lan> <20200918223957.GA2964553@rani.riverdale.lan> In-Reply-To: <20200918223957.GA2964553@rani.riverdale.lan> From: Linus Torvalds Date: Fri, 18 Sep 2020 18:28:30 -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.000006, 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 3:40 PM Arvind Sankar wrote: > > Ouch, offsetof() and sizeof() will give different results in the > presence of alignment padding. Indeed. But from an allocation standpoint, the offsetof()+size is I think the correct size. The padding at the end makes very little sense for something like "struct_size()". Padding at the end is required for sizeof() for a very simple reason: arrays. The "sizeof()" needs to be aligned to the alignment of the entry, because if it isn't, then the standard C array traversal doesn't work. But you cannot sanely have arrays of these structures of variable size entries either - even if standard C cheerfully allows you to declare them (again: it will not behave like a variable sized array, it will behave like a zero-sized one). That was in fact one of the test-cases that I submitted to the sparse list - the insanity of allowing arrays of structures that have a flexible array at the end is just the C standard being confused. The C standard may allow it, but I don't think we should allow it in the kernel. Oh, I can see why somebody would want to have an array of those things - exactly because they want to have some "initializer _without_ the flexible array part", and they actually don't want that variably-sized array at all for that case. But I'm pretty sure we really really don't want that kind of oddities in the kernel. If we really want a separate "struct head_struct", then I think we should do so explicitly, and have something like struct real_struct { // Unnamed head struct here struct head_struct { ,,,, }; unsigned int variable_array[]; }; and if you want the part without the flexible array at the end, then you use that "struct head_struct". Instead of depending on the imho broken model of the C standard that says "in lots of cases, we'll just silently make that flexible array be a zero-sized one". Linus