Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp3117222pxy; Mon, 3 May 2021 15:49:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxhDDEVtHfamRoWp6OxxaRUjuYs6p00gZnEHOjbSryERAcPsGh1iZi2JKQK+q3QbLrLhm1P X-Received: by 2002:a17:90a:ea11:: with SMTP id w17mr1151652pjy.6.1620082168150; Mon, 03 May 2021 15:49:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620082168; cv=none; d=google.com; s=arc-20160816; b=m5dBIQMRNrutTvt/jTirC1ho8CNqiOus6TxBoikBrQCVD/XzJbLUHtbvBh48JQj2WL Rc1ZNTAJGxnUVrOeF+dkUVdQBjd9Ru6ZwZ6/BvXmG+SM516Iu0zhUZ8LhMmAD0RhPBSU Uym3YXdYD0ZIgdNsCGjqUs3qAa8ay7LuTLybJFkd6t4YCrxmhgw8jfZCrxTrouYnxb0g 1MnAhWO04elzcr8YA9xxwT1kszX4H5C7d9eVJd34avud9Kfoq0PGmiefZYsNVlq0vwFY lX3TCBiumJ8FtDXhuNCGjK0zX2pJaxLjcXaa9RwOgJWDnEreI7XKGuXjjnwIy01H6jNE 8/Vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=J3yLB+vbpq5Xc9JhKmZutr67bAiFvkUnDMtUXpplUGA=; b=ZZRINCqIwobS7artfncU/15MbmncVPXAQ197K/faqHt8Tu1XpwzM1cc27qybS8htYO UsJAwtsVzx0oG6xvKLd2/yfCCO/yLN55gYsJ/TVEbJvyJEhQAqj2dlxfoMoxkmJj//hW hk9SXB8vxPqloPjU2JZtWYFD4rdxq/enB3Bnn/64lTbgdzlsSMe1tiRlGt5GOiEiiMWO uXkq8M9vn5TsIYOoWHRRFOl6y9Q/CDIWsYnYNIXFJqGG8c2KspIQuuAJQ1nPnvIT4JhT 2RzF/VIssmqjvAZvb26uY+0hr9N+RUV6BPoPJ+RuHSrWNIjm1vb/G8+uvSAfBp8XcYUx Oyig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=OveNxb30; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v10si1164620plp.428.2021.05.03.15.49.15; Mon, 03 May 2021 15:49:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=OveNxb30; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229815AbhECWso (ORCPT + 99 others); Mon, 3 May 2021 18:48:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229836AbhECWsm (ORCPT ); Mon, 3 May 2021 18:48:42 -0400 Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C51CC061763 for ; Mon, 3 May 2021 15:47:48 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id e25so6979191oii.2 for ; Mon, 03 May 2021 15:47:48 -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=J3yLB+vbpq5Xc9JhKmZutr67bAiFvkUnDMtUXpplUGA=; b=OveNxb30rHLgSAzaM0tOpGtIlHylKdXRMEUg4g++/qGr+akviNgcsl9ZS1R/rXYoyp zwOveCIwXETnqsCO8OIfxkkHRQhhF4Fj9aHystlJxD1VsKnGjbWz24yFpXAsxp2rO5JY eNg84L2UL6R+SBmBR+MX8Ht2EYS/d7upYu5y0cpodgFCtMtSp5ubo0IzWvQ8TMcKmNCq CLalcxcOtduKKCdDuFAK3CiwV2RQJ1sWoUVjhloU3Nm5K2DEkk8M2XO+YN0biUXPDPGG LtYXy29QGclKlNPbz9XTmvq7I4Gu55+eLr9r4M1aofY1IwvxUDvtCxU+lYJ1eAVPa5rC aWpQ== 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=J3yLB+vbpq5Xc9JhKmZutr67bAiFvkUnDMtUXpplUGA=; b=Ti4Jqh3hBoeJYvo76W6FT5J+h5qNLv/+z90sGTZyoZH56Rb17T6J5DV5HadoFc3/Cg AS5An5gVyKMoWR1aL8ikU4DcagOtcpYiViCGgL7k0bRR44k23qXmAV+W0OVm8FKIDGWA kl0FwNlZOi7awrfleQ4EErTn2t/2LQ1+bDaYl/aAXkU67pBzJltfpPz5mOdq4FBhpKPl rQ+f17Oqsv0F2v3Ti22RQY+bQkBW+r+BrONzl6gXiwTDoeUheN3WTalD6ZR/8tZ3o5ve zfNG7mtQu9mAPXsvUbrjpPKcM7NEoSDBnDF6yHAac2YyT/9Fcl7xaU2/hgEmTUZWirw3 Varg== X-Gm-Message-State: AOAM530n/pQQx0lDoaj07ZxktPP6tepLnw1uUbeZCvhNpX6QXXI7WwMD IhLz8xPUcmI2xBBnLgNRqDpiawcHxFRFWf7Crphtbw== X-Received: by 2002:aca:44d6:: with SMTP id r205mr15201349oia.172.1620082067206; Mon, 03 May 2021 15:47:47 -0700 (PDT) MIME-Version: 1.0 References: <20210503203814.25487-1-ebiederm@xmission.com> <20210503203814.25487-10-ebiederm@xmission.com> In-Reply-To: From: Marco Elver Date: Tue, 4 May 2021 00:47:35 +0200 Message-ID: Subject: Re: [PATCH 10/12] signal: Redefine signinfo so 64bit fields are possible To: "Eric W. Biederman" Cc: Arnd Bergmann , Florian Weimer , "David S. Miller" , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Peter Collingbourne , 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, 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.) > I decided to include this change because it is not that complicated, > and it allows si_perf_data to have the definition that was originally > desired. Neat, and long-term I think this seems to be worth having. Sooner or later something else might want __u64, too. But right now, due to the slight increase in complexity, we need to take extra care ensuring nothing broke -- at a high-level I see why this seems to be safe. > If this looks difficult to make in the userspace definitions, > or is otherwise a problem I don't mind dropping this change. I just > figured since it was not too difficult and we are changing things > anyway I should try for everything. Languages that support inheritance might end up with the simpler definition here (and depending on which fields they want to access, they'd have to cast the base siginfo into the one they want). What will become annoying is trying to describe siginfo_t. I will run some tests in the morning. Thanks, -- Marco [...] > > diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h > > index e663bf117b46..1fcede623a73 100644 > > --- a/include/uapi/asm-generic/siginfo.h > > +++ b/include/uapi/asm-generic/siginfo.h > > @@ -29,15 +29,33 @@ typedef union sigval { > > #define __ARCH_SI_ATTRIBUTES > > #endif > > > > +#ifndef __ARCH_HAS_SWAPPED_SIGINFO > > +#define ___SIGINFO_COMMON \ > > + int si_signo; \ > > + int si_errno; \ > > + int si_code > > +#else > > +#define ___SIGINFO_COMMON \ > > + int si_signo; \ > > + int si_code; \ > > + int si_errno > > +#endif /* __ARCH_HAS_SWAPPED_SIGINFO */ > > + > > +#define __SIGINFO_COMMON \ > > + ___SIGINFO_COMMON; \ > > + int _common_pad[__alignof__(void *) != __alignof(int)] Just to verify my understanding of _common_pad: this is again a legacy problem, right? I.e. if siginfo was designed from the start like this, we wouldn't need the _common_pad. While this looks quite daunting, this is effectively turning siginfo from a struct with a giant union, into lots of smaller structs, each of which share a common header a'la inheritance -- until now the distinction didn't matter, but it starts to matter as soon as alignment of one child-struct would affect the offsets of another child-struct (i.e. the old version). Right? I was wondering if it would make things look cleaner if the above was encapsulated in a struct, say __sicommon? Then the outermost union would use 'struct __sicommon _sicommon' and we need #defines for si_signo, si_code, and si_errno. Or would it break alignment somewhere? I leave it to your judgement -- just an idea. > > union __sifields { > > /* kill() */ > > struct { > > + __SIGINFO_COMMON; > > __kernel_pid_t _pid; /* sender's pid */ > > __kernel_uid32_t _uid; /* sender's uid */ > > } _kill; > > > > /* POSIX.1b timers */ > > struct { > > + __SIGINFO_COMMON; > > __kernel_timer_t _tid; /* timer id */ > > int _overrun; /* overrun count */ > > sigval_t _sigval; /* same as below */ > > @@ -46,6 +64,7 @@ union __sifields { > > > > /* POSIX.1b signals */ > > struct { > > + __SIGINFO_COMMON; > > __kernel_pid_t _pid; /* sender's pid */ > > __kernel_uid32_t _uid; /* sender's uid */ > > sigval_t _sigval; > > @@ -53,6 +72,7 @@ union __sifields { > > > > /* SIGCHLD */ > > struct { > > + __SIGINFO_COMMON; > > __kernel_pid_t _pid; /* which child */ > > __kernel_uid32_t _uid; /* sender's uid */ > > int _status; /* exit code */ > > @@ -62,6 +82,7 @@ union __sifields { > > > > /* SIGILL, SIGFPE, SIGSEGV, SIGBUS, SIGTRAP, SIGEMT */ > > struct { > > + __SIGINFO_COMMON; > > void __user *_addr; /* faulting insn/memory ref. */ > > #ifdef __ia64__ > > int _imm; /* immediate value for "break" */ > > @@ -97,35 +118,28 @@ union __sifields { > > > > /* SIGPOLL */ > > struct { > > + __SIGINFO_COMMON; > > __ARCH_SI_BAND_T _band; /* POLL_IN, POLL_OUT, POLL_MSG */ > > int _fd; > > } _sigpoll; > > > > /* SIGSYS */ > > struct { > > + __SIGINFO_COMMON; > > void __user *_call_addr; /* calling user insn */ > > int _syscall; /* triggering system call number */ > > unsigned int _arch; /* AUDIT_ARCH_* of syscall */ > > } _sigsys; > > }; > > > > -#ifndef __ARCH_HAS_SWAPPED_SIGINFO > > -#define __SIGINFO \ > > -struct { \ > > - int si_signo; \ > > - int si_errno; \ > > - int si_code; \ > > - union __sifields _sifields; \ > > -} > > -#else > > + > > #define __SIGINFO \ > > -struct { \ > > - int si_signo; \ > > - int si_code; \ > > - int si_errno; \ > > +union { \ > > + struct { \ > > + __SIGINFO_COMMON; \ > > + }; \ > > union __sifields _sifields; \ > > } > > -#endif /* __ARCH_HAS_SWAPPED_SIGINFO */ > > > > typedef struct siginfo { > > union {