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 6D851C433B4 for ; Tue, 4 May 2021 04:03:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 456BF611AC for ; Tue, 4 May 2021 04:03:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229737AbhEDEEL (ORCPT ); Tue, 4 May 2021 00:04:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59946 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229499AbhEDEEG (ORCPT ); Tue, 4 May 2021 00:04:06 -0400 Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4DB3EC061574 for ; Mon, 3 May 2021 21:03:12 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id h6so5302132ila.7 for ; Mon, 03 May 2021 21:03:12 -0700 (PDT) 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=56mc9V9A73cEiKQwEt/CmT2tfj/Xb7ZTWRyNvK3LPcU=; b=sjWwmwPLHvAZ5OYHc8laaQYJ21h6DUy3a/1ZbzgvzYBL1ettIr/V1Cda+PHn6Ur1bg 2TNC/juaaivWrbPCDKEXruL5l+jEg2iWLD2viU7ONt/7oMJQxYhKwYMC8toQQ8BymCah pDHDsCeU1JtG7utkSDDiS3o3kQmYwjw7y7jdBAVwmZgNqHYlXRcsQdh/zTWFLMRkZhqe khaOLGwoJ9kaQ0L5KF7nt2PfuwSqsy5zvq6NUna1Y+LUuLXlCpTPh66tMZU/dtKPCe6t XXDjme+ultGz/SXeYKpqZ1Omm+KnStWrmCtnr4HshaFWTL3YHKT4LhLCohAbniuX5wPv WNtQ== 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=56mc9V9A73cEiKQwEt/CmT2tfj/Xb7ZTWRyNvK3LPcU=; b=Je9YIArbmMLmi41YY7b7MFcTd37WLozJd1p6IWi55IyKkYBxewQu+1LRI1bGWxj4vU XQN8cODUJtADGz3Rla129p7SfVhpophxux0v4ZLSYm/FFV1iqL6t65E5ZW0ILlDJhUZ9 Vj6Kbd7IxksaBAKSNZe63ewRFksIA68eD5ON/SO/IgYl28Qh5wzko4K3+IZoctfC0j3T ZaiPRGO5BKygOozAWLY8LvyCEtl4KKbAXlu6gV8/pRaktUy3vNE6LUhSIdLzI/7m8ebE pxdn1Zp9f6r/IwZbWld2M6Do+9p082GWzu/jvMxKlU4JtS/yM6YARmPEZwIBsNDU3EmV Je8Q== X-Gm-Message-State: AOAM530bd98AFl4Xf9JtFrYcXGA8qIvl3DcXCnpb3HcKsX40DxB5Okid CbsmgMGBFDY50X7M7dI9ughy+NuAKA0SEKH/hg8pfA== X-Google-Smtp-Source: ABdhPJxYw4qW/PxhIAcTsJBYVxgjOPDbZGLD0/ZW+c9jDDL5xLTlCYuGYFR46HXp51APom4CyuALzoxPZmKV/tvT+ME= X-Received: by 2002:a05:6e02:13d3:: with SMTP id v19mr18182359ilj.56.1620100991437; Mon, 03 May 2021 21:03:11 -0700 (PDT) MIME-Version: 1.0 References: <20210503203814.25487-1-ebiederm@xmission.com> <20210503203814.25487-10-ebiederm@xmission.com> In-Reply-To: From: Peter Collingbourne Date: Mon, 3 May 2021 21:03:00 -0700 Message-ID: Subject: Re: [PATCH 10/12] signal: Redefine signinfo so 64bit fields are possible To: "Eric W. Biederman" Cc: Marco Elver , Arnd Bergmann , Florian Weimer , "David S. Miller" , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Dmitry Vyukov , Alexander Potapenko , sparclinux , linux-arch , Linux Kernel Mailing List , Linux API , kasan-dev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 3, 2021 at 8:42 PM Eric W. Biederman wrote: > > Marco Elver writes: > > > On Mon, 3 May 2021 at 23:04, Eric W. Biederman wrote: > >> "Eric W. Beiderman" writes: > >> > From: "Eric W. Biederman" > >> > > >> > The si_perf code really wants to add a u64 field. This change enables > >> > that by reorganizing the definition of siginfo_t, so that a 64bit > >> > field can be added without increasing the alignment of other fields. > > > > If you can, it'd be good to have an explanation for this, because it's > > not at all obvious -- some future archeologist will wonder how we ever > > came up with this definition of siginfo... > > > > (I see the trick here is that before the union would have changed > > alignment, introducing padding after the 3 ints -- but now because the > > 3 ints are inside the union the union's padding no longer adds padding > > for these ints. Perhaps you can explain it better than I can. Also > > see below.) > > Yes. The big idea is adding a 64bit field into the second union > in the _sigfault case will increase the alignment of that second > union to 64bit. > > In the 64bit case the alignment is already 64bit so it is not an > issue. > > In the 32bit case there are 3 ints followed by a pointer. When the > 64bit member is added the alignment of _segfault becomes 64bit. That > 64bit alignment after 3 ints changes the location of the 32bit pointer. > > By moving the 3 preceding ints into _segfault that does not happen. > > > > There remains one very subtle issue that I think isn't a problem > but I would appreciate someone else double checking me. > > > The old definition of siginfo_t on 32bit almost certainly had 32bit > alignment. With the addition of a 64bit member siginfo_t gains 64bit > alignment. This difference only matters if the 64bit field is accessed. > Accessing a 64bit field with 32bit alignment will cause unaligned access > exceptions on some (most?) architectures. > > For the 64bit field to be accessed the code needs to be recompiled with > the new headers. Which implies that when everything is recompiled > siginfo_t will become 64bit aligned. > > > So the change should be safe unless someone is casting something with > 32bit alignment into siginfo_t. How about if someone has a field of type siginfo_t as an element of a struct? For example: struct foo { int x; siginfo_t y; }; With this change wouldn't the y field move from offset 4 to offset 8? Peter