Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp1229590pxv; Fri, 16 Jul 2021 04:50:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwbFX3MENVBX+aJzW0jY3J8H1q/MfyOdOF+dyD4xlQQw6BHitsUDf9eSLY+TNB/7/bTmTQw X-Received: by 2002:a05:6e02:c73:: with SMTP id f19mr5999063ilj.291.1626436259638; Fri, 16 Jul 2021 04:50:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626436259; cv=none; d=google.com; s=arc-20160816; b=fh75p1xkPC4RASXz255oXCVebIXteEnHEhxuZ09LJ8nFXjsxdfw2vKQMeP+N7Gsmk+ I5Qx8r/Yg3hFxQVlhqOQSwWi84I0ZmNGHyjp1trl8HbKNc7Npse2afvXsY7hj65LbgHQ RidrgIEHYSn4YJiKiNulxcX2LpH3EWc7jIJHGKBvasPQxXsEHhxKzPuXa7OxuWlCcaaX tL8yaGpb68d/3AhSHh/Rappk90ipjAYEU3Qt9P08pBIJrwUzsFaWlUggs80CRzDavhPU 7cNEzYcZdO/rZ74MC+UrUN+yrqMQLC410Jv+9G+aEXdiaBvyurGOPGvnJkJM9Fz/aTn2 UC9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=nzabWvrTaM3dlhAMkGE1TPAE+zrQX3XHiWsmylmIlBU=; b=MTUCtY/eRh9u1MJA6lk29WoNxf7TZkEKrtx96j7M1iLEV0v2vPt19UljycHqu32zjx ZFcxK9EJ07dqj7ng32cZAzA42lWxg8QsUbMdeLtycG5IRVuNqgWtbsHTY6LOXiR6QX+r Lts1sKTJMP1pMCKIrNQ8lrV6ewvtHjm6fzRMSEkusorOHxuKgAEyKkSa4VBgsaxAdwBW jMckfDoWyDc19qRceN8m+aV3tDtLonvJeTJDPA+AdyPwhMwthNjsGBCAlbFYlS3u3HFO ef9lVFNy7zMKyeP0TQ/hpGl1SB4+Uns+ahQI1iZ8vVl9agaZraVfnnvOlaBcm4czhjmV syfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=vZIQ2SoX; 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 s5si9996831ilq.98.2021.07.16.04.50.47; Fri, 16 Jul 2021 04:50:59 -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=vZIQ2SoX; 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 S232146AbhGPLxH (ORCPT + 99 others); Fri, 16 Jul 2021 07:53:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34906 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232235AbhGPLxG (ORCPT ); Fri, 16 Jul 2021 07:53:06 -0400 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED39BC061764 for ; Fri, 16 Jul 2021 04:50:11 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id o30-20020a05600c511eb029022e0571d1a0so5658788wms.5 for ; Fri, 16 Jul 2021 04:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=nzabWvrTaM3dlhAMkGE1TPAE+zrQX3XHiWsmylmIlBU=; b=vZIQ2SoXPxosz3Bc9mWtUSTcZht3OswE1gyNYTdMwjAIrpVhZRfuRU+Dat7i7t2Q18 1PLnalJ3nd+LH1FIQZWVrAGH6bN43KDGKvuBvVQ0uknQ7NHcyNtlb3T0h2MCvMgfOwqn fXtOZGYnsXGzAC7V0zMi8MkHS1manK4/OJ1Axk1Ip3tOvv2AVridtc5f+umTDfqvVees IMQkIGSval7DAA/tXpX5NWiucWrcKyZUI+aVR/oBbHbZgiggfg4417x8OWtfgpeiZ77F tKu9txadr8mqRh2PQmCVkE6XX+s3I9loUxCI7XTTFw/Yn0d2vsBrWnt0TQjN8L8shwBy oJTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=nzabWvrTaM3dlhAMkGE1TPAE+zrQX3XHiWsmylmIlBU=; b=ZKIbWxIjwwXl2hJ5ltkwxAWyDs0hJHGYX2MTJ/e94u9fugA6cN8HR269mxWmfwZXPi wDF27ZOyHiPNp+CQ3GoOTOlGoBXAyi9YwbQy6P9l5dpbKsOV+GJkgQXcqhrhf4ECLecP WHfUd8/GUuSBJH+/p2tEhkFtRtfRD7cpV/NbM19vLHVfyZY3QCPtZj4MKpwLUjx6PT7x JRAWFBhH1WnWDOLLicNJC0d9jw22bz1XzNcQg1+UhfHQ8j+1+kjzhdbUyrFUwLR60GQC 9mSLZ86dNgUPA21v3/Z0xeRHOA1RSyWBIWlROXmZ33ouTQqjaNZGQzD40a6sRimjppIw YegQ== X-Gm-Message-State: AOAM5313tl9vUQUORAQelkT/TiGdSY8FlvQPI+VoMC4Cdz0X736cgthD bigun6El3urbjAqblIsCQ4iSBw== X-Received: by 2002:a1c:39d5:: with SMTP id g204mr16168668wma.66.1626436210180; Fri, 16 Jul 2021 04:50:10 -0700 (PDT) Received: from elver.google.com ([2a00:79e0:15:13:fb3b:45b4:a42a:5668]) by smtp.gmail.com with ESMTPSA id k24sm10147181wrh.30.2021.07.16.04.50.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Jul 2021 04:50:09 -0700 (PDT) Date: Fri, 16 Jul 2021 13:50:04 +0200 From: Marco Elver 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 Subject: Re: [PATCH 0/6] Final si_trapno bits Message-ID: References: <87a6mnzbx2.fsf_-_@disp2133> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a6mnzbx2.fsf_-_@disp2133> User-Agent: Mutt/2.0.5 (2021-01-21) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 15, 2021 at 01:09PM -0500, Eric W. Biederman wrote: > As a part of a fix for the ABI of the newly added SIGTRAP TRAP_PERF a > si_trapno was reduced to an ordinary extention of the _sigfault case > of struct siginfo. > > When Linus saw the complete set of changes come in as a fix he requested > that the set of changes be trimmed down to just what was necessary to > fix the SIGTRAP TRAP_PERF ABI. > > I had intended to get the rest of the changes into the merge window for > v5.14 but I dropped the ball. > > I have made the changes to stop using __ARCH_SI_TRAPNO be per > architecture so they are easier to review. In doing so I found one > place on alpha where I used send_sig_fault instead of > send_sig_fault_trapno(... si_trapno = 0). That would not have changed > the userspace behavior but it did make the kernel code less clear. > > My rule in these patches is everywhere that siginfo layout calls > for SIL_FAULT_TRAPNO the code uses either force_sig_fault_trapno > or send_sig_fault_trapno. > > And of course I have rebased and compile tested Marco's compile time > assert patches. > > Eric > > > Eric W. Biederman (3): > signal/sparc: si_trapno is only used with SIGILL ILL_ILLTRP > signal/alpha: si_trapno is only used with SIGFPE and SIGTRAP TRAP_UNK > signal: Remove the generic __ARCH_SI_TRAPNO support > > Marco Elver (3): > sparc64: Add compile-time asserts for siginfo_t offsets > arm: Add compile-time asserts for siginfo_t offsets > arm64: Add compile-time asserts for siginfo_t offsets Nice, thanks for the respin. If I diffed it right, I see this is almost (modulo what you mentioned above) equivalent to: https://lore.kernel.org/linux-api/m1tuni8ano.fsf_-_@fess.ebiederm.org/ + what's already in mainline. It's only missing: signal: Verify the alignment and size of siginfo_t signal: Rename SIL_PERF_EVENT SIL_FAULT_PERF_EVENT for consistency Would this be appropriate for this series, or rather separately, or dropped completely? Thanks, -- Marco