Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp143122pxf; Thu, 25 Mar 2021 00:04:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy2hihNLIFwZR5ph/AAM/YZuLul8X6pmYQHxjR43eDxuzeGJqN9orVRA0XL0qCHDDPARp5F X-Received: by 2002:a05:6402:440d:: with SMTP id y13mr7529472eda.316.1616655856916; Thu, 25 Mar 2021 00:04:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616655856; cv=none; d=google.com; s=arc-20160816; b=aka370eXJjTpCrdElwuqok9t0Cji9ZT005JLs0fLjejQbh64eZZ2WbvgRjcyxNMYJq AVjiitNHUYTmowSdTY9FXHqN+U0jlUfnrfUcvhd1cY1SSGkjUU1Rd2tzzWwVU+tbMqAk M+wpvXCvXs5tZVL2EApavmvEi8CeeWfXcvViMCRNZ6eMqUhHYwfHSyPXXAnPVQ6+qejU 87m4C8sVlSTvuPR0nZN4GomrnDzn1cV2FYBGocnJU4ya3r9QqQR3oCTKf8LjSO3PLr0F 8kk1Q38BonJLhISQ4cFn8Xfh1e+SyjoH4K3CY2AzDkXG9T6Ba7pYfOPF7pfttstn3Cfg Qtiw== 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=Er9VTBwwaI4g9NSWPaQXCrSglwdU7EBlM0d7c0+OO70=; b=KbzmGTcFpMUYNowdtQqoy/mY7rtpn9ff3XKs8BbN/l5sIJpNXik6CgwR7XI33pQc7A t1SF2zrSbGYX+OZCCe3KisfwAdvml4beOEolzd2mEWNnMpP62PxM5Vj/qYJcCZzPGLB3 xwGWT8Po5PcO5w1mMp/rtK+ExPYlYRN6EnnorSh04l+9QOLO6MzdSoazLhH5ZLuzztp1 44gItEGxfBtWQF6OmdcqwgcvunIMbmdkby1A9gktSTle4kZJvGHQzKbNCtNl8baAGfQa zOZXf+Umuc3oMwECh8mtCCBpavR3xbKwsvzu7utq240ZjWdvhCzh+bmTfeeAjB9RPvC/ ph4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="hbSQau/S"; 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 a5si3496030ejj.325.2021.03.25.00.03.54; Thu, 25 Mar 2021 00:04:16 -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="hbSQau/S"; 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 S229619AbhCYHCd (ORCPT + 99 others); Thu, 25 Mar 2021 03:02:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229651AbhCYHB7 (ORCPT ); Thu, 25 Mar 2021 03:01:59 -0400 Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 01379C061760 for ; Thu, 25 Mar 2021 00:01:58 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id w21-20020a9d63950000b02901ce7b8c45b4so1020392otk.5 for ; Thu, 25 Mar 2021 00:01:58 -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=Er9VTBwwaI4g9NSWPaQXCrSglwdU7EBlM0d7c0+OO70=; b=hbSQau/S0befhroiNXRd5O8t1oN/3OjEIMZCtSzpFl/RHERsBfwJwZVn6Nm5FDuLsn X3sE96eypk30BXKU2tgnMTmXLdrLEFveDKo4zr0M36qJwyT8nWlLcajgqON0Zz4xNSQ/ qR7Ue/CQkq4CWUE6EA9jQngra/S/MAhRUej/W/rdhbXE+iGxs7vYzwRaKTIeH8lM7+t1 KvLnUbsb4cs3XNHr3mNjZaNPjUnVAAqg/zKjDtUE3LJcrtlIva+eWdqE5sxgHi3R6Hk/ M3ySio+sobh7dR7VNABom34tFO67Dp2oeR7GPXWNr1TW0hlyDutwoxRZ8vUjvvmRIcDk FQuw== 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=Er9VTBwwaI4g9NSWPaQXCrSglwdU7EBlM0d7c0+OO70=; b=SQVOEUxqa0WPghGFxp2cNQT61FBiR+ZiEUrzrzKw/8xf/BnrMBMekDSiaOANHknnD8 /BsSa8OR0AGJv5kJlq7jAE6oCxBRpHZSwledwg0MhVKfS+svFVzilsYMCn1O+9lwhrdf lFdMEQmc7LdDNtrhR336AM8ABxXZdjt3c0Bxaba30tiQ+4XagtUyzSAkbP/J5X+qu9kz 9n6/Uoal6s+BRLxIZheB5noz4cpeuea5VW+VMnCOkq2iPZ+vt0tUTsyR5OVTv79mJO1P miQ+WGjH4CIfbUwCnN2BkEbZHHSRqOTkvTSxCRVA1BbP0MPjJbNAt0afY+b0z70D1+x3 coXA== X-Gm-Message-State: AOAM531nFAnyx5HMw+oNwVDfA6qLJEcw9FwpQsHeyRYJt8W1nT2nOlIs K8mp1mzsoSbxv0G5o+p3/fqEbNYoILybBU1/hTzAiQ== X-Received: by 2002:a05:6830:1c6e:: with SMTP id s14mr6341695otg.17.1616655718013; Thu, 25 Mar 2021 00:01:58 -0700 (PDT) MIME-Version: 1.0 References: <20210324112503.623833-1-elver@google.com> <20210324112503.623833-8-elver@google.com> In-Reply-To: From: Marco Elver Date: Thu, 25 Mar 2021 08:00:00 +0100 Message-ID: Subject: Re: [PATCH v3 07/11] perf: Add breakpoint information to siginfo on SIGTRAP To: Dmitry Vyukov Cc: Peter Zijlstra , Alexander Shishkin , Arnaldo Carvalho de Melo , Ingo Molnar , Jiri Olsa , Mark Rutland , Namhyung Kim , Thomas Gleixner , Alexander Potapenko , Al Viro , Arnd Bergmann , Christian Brauner , Jann Horn , Jens Axboe , Matt Morehouse , Peter Collingbourne , Ian Rogers , kasan-dev , linux-arch , linux-fsdevel , LKML , "the arch/x86 maintainers" , "open list:KERNEL SELFTEST FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 24 Mar 2021 at 15:15, Dmitry Vyukov wrote: > On Wed, Mar 24, 2021 at 3:12 PM Dmitry Vyukov wrote: > > > On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra wrote: > > > > > > > > One last try, I'll leave it alone now, I promise :-) > > > > > > This looks like it does what you suggested, thanks! :-) > > > > > > I'll still need to think about it, because of the potential problem > > > with modify-signal-races and what the user's synchronization story > > > would look like then. > > > > I agree that this looks inherently racy. The attr can't be allocated > > on stack, user synchronization may be tricky and expensive. The API > > may provoke bugs and some users may not even realize the race problem. > > > > One potential alternative is use of an opaque u64 context (if we could > > shove it into the attr). A user can pass a pointer to the attr in > > there (makes it equivalent to this proposal), or bit-pack size/type > > (as we want), pass some sequence number or whatever. > > Just to clarify what I was thinking about, but did not really state: > perf_event_attr_t includes u64 ctx, and we return it back to the user > in siginfo_t. Kernel does not treat it in any way. This is a pretty > common API pattern in general. Ok, let's go for a new field in perf_event_attr which is copied to si_perf. This gives user space full flexibility to decide what to stick in it, and the kernel does not prescribe some weird encoding or synchronization that user space would have to live with. I'll probably call it perf_event_attr::sig_data, because all si_* things are macros. Thanks, -- Marco