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.2 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,URIBL_BLOCKED,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 4CF78C433ED for ; Sat, 1 May 2021 16:24:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 29E42613CA for ; Sat, 1 May 2021 16:24:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231500AbhEAQZ2 (ORCPT ); Sat, 1 May 2021 12:25:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45406 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230195AbhEAQZ1 (ORCPT ); Sat, 1 May 2021 12:25:27 -0400 Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B6DDC06138C for ; Sat, 1 May 2021 09:24:36 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id 103-20020a9d0d700000b02902a5baf33f37so833614oti.9 for ; Sat, 01 May 2021 09:24:36 -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=CyRw8Tn64/8GQf/qvRpik9Jpd4CoRgx2tUKy0Z4v2kk=; b=eF/f5QKwpZj4P0iRgwV9mG08ATE6TtljmgOwFiZt6YvZXdccsD5UWUHr3XvSwu//qG NPJJumNb1Zr68wu1wpu1k66hY/gXorsicuXcYJFtGZGJhTD3zkyGC1NlFeVevEyC1VJY CRmSkGTGR/sM1sCwBRfLDIx4qq1Z1WbZpsa+rKG3t/LR2XoiQJovPWIT4VkR5fc/nAs8 4wn6Tzmc2CG2whHqu1l7tRE+chGrFt3lXNXaaWepgbANGpj6o05TW6iLrAseEa03Iw23 5lXhasqa0NDzEaj1UbE6BGTHoKHGohYMhVnJdcWhiNjg0tp9CJUZrIoy5Teb9U/6Cem1 5g/A== 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=CyRw8Tn64/8GQf/qvRpik9Jpd4CoRgx2tUKy0Z4v2kk=; b=i9OEV0T5i9paQ471eM5LO6QcgBZjlxAZ714b2bgLet+gBNgdBuw1udH5iM0xaNKZ17 ibaX610l+rwyFSYi6bAN+o9PRh2NTuAqBKBcNgPytVX1zpXrU06cI+Tqo6UYSBxfqOcK /tgv1kmLU8LG3JNuytDdWJxyJpRWdXSTo2iSHpTNmhFVx6C+Gvt2ou2iCg8eXfZ0qfY5 qQnBs/ND7jaG6V66Vbbl5HHE/gF3twOB1ZLoHmKPYqyFcVBiOrNoZSb+jR0HaILXGVeh I7ax0RyUNsY2b27XqN2wVlGMOBnbVDQQ/mLCCvuNExSfaUfdgsphrLvQc+jxqBgDmTLQ dmrA== X-Gm-Message-State: AOAM533oaBMHz4rRTryYbxdOa2RgynB9WxU6Ykf+DPNZIIdTGJuJI9tu Ztd9OJmlCGh2iDE+9xT1TuBrKJ82X+wQF/p701QpSQ== X-Google-Smtp-Source: ABdhPJxP2xABVwsxq8iuIy2TqPxCCxagtYWhXnnuGIb0YzWKLQ9rVYtpLctNHuotNan+7uHcpM+rhlw76MQT8E/rFJ8= X-Received: by 2002:a9d:60c8:: with SMTP id b8mr8272179otk.17.1619886275343; Sat, 01 May 2021 09:24:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marco Elver Date: Sat, 1 May 2021 18:24:24 +0200 Message-ID: Subject: Re: [RFC][PATCH 0/3] signal: Move si_trapno into the _si_fault union 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 Sat, 1 May 2021 at 17:17, Eric W. Biederman wrote: > > Marco Elver writes: > > > On Sat, 1 May 2021 at 01:48, Eric W. Biederman wrote: > >> > >> Well with 7 patches instead of 3 that was a little more than I thought > >> I was going to send. > >> > >> However that does demonstrate what I am thinking, and I think most of > >> the changes are reasonable at this point. > >> > >> I am very curious how synchronous this all is, because if this code > >> is truly synchronous updating signalfd to handle this class of signal > >> doesn't really make sense. > >> > >> If the code is not synchronous using force_sig is questionable. > >> > >> Eric W. Biederman (7): > >> siginfo: Move si_trapno inside the union inside _si_fault > >> signal: Implement SIL_FAULT_TRAPNO > >> signal: Use dedicated helpers to send signals with si_trapno set > >> signal: Remove __ARCH_SI_TRAPNO > >> signal: Rename SIL_PERF_EVENT SIL_FAULT_PERF_EVENT for consistency > >> signal: Factor force_sig_perf out of perf_sigtrap > >> signal: Deliver all of the perf_data in si_perf > > > > Thank you for doing this so quickly -- it looks much cleaner. I'll > > have a more detailed look next week and also run some tests myself. > > > > At a first glance, you've broken our tests in > > tools/testing/selftests/perf_events/ -- needs a > > s/si_perf/si_perf.data/, s/si_errno/si_perf.type/ > > Yeah. I figured I did, but I couldn't figure out where the tests were > and I didn't have a lot of time. I just wanted to get this out so we > can do as much as reasonable before the ABI starts being actively used > by userspace and we can't change it. No worries, and agreed. I've run tools/testing/selftests/perf_events tests on x86-64 (native + 32-bit compat), and compile-tested x86-32, arm64, arm (with my static asserts), m68k, and sparc64. Some trivial breakages, note comments in other patches. With the trivial fixes this looks good to me. I'll happily retest v2 when you send it. Thanks, -- Marco