Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3788789pxf; Mon, 29 Mar 2021 11:24:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwA4BtrwYcvqse0d3VEq54NkEj6XxzYpDOQJ57i7U0kBgdDs+xJONemT8MtrJEUloqvo/F9 X-Received: by 2002:a17:906:c0c8:: with SMTP id bn8mr29462366ejb.445.1617042275639; Mon, 29 Mar 2021 11:24:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617042275; cv=none; d=google.com; s=arc-20160816; b=b7+8yQduTTpqw9bWShOI9V1itfEqC3w5cioFImvHoRK/bLy3xr1qQoHQQOy7CnWe9U yKXEm+nf0uEwObN/C9nv6NomLm9PBDWs/qBNUp9bfd5lz/oigPdk5q+YF2PQXDjr0t0e XSQTl9udy/+UeGkG2EUbetSLJTWLMkzhoex8Ux16RADs6aLQqepShUrdGtDq6b9DVIlj zf8oUQTW78KR+WFO2STe8lCRvQStpU6dSf4ApUIyKdWY8tooHyKBq98FPSPJmsKj/A0V DZV2fgJR2Xs4KEpViTki7KQQ8zMb+39kCiTilyccKCSk0T82CM3of46KbCGM4k43GNPh 06Lg== 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=P+4V7kdgmOSoM2q5m0q378E9m02rDEI4zRk0CO5JIEk=; b=vPrHwJh+KsQqGV1zpFlZcgdbTep3ZIDNS3LAv9EOf2zMtR/AQ7SYAAbVjah17V6IkS Hxb4uItj2FTE6R5xT9fu1k58fEQkr1LdbCpH83g7qVEf/m5inc3PqsqbpWkPa7YcVv4o Vdb3IanY4Zu1a6gphSgTx6Hb/5Mv+oFIIhSKaq4myCs3ZrG21ZdZcPb0FIEW+n3lmeU3 w0g3uGO3EzHVLcNFPoOsn6NRngXb5xy8Yi+j1dQRzyj9nUfOqq9NKvloZtC1JgXM26dK XTeP/Fl1LnNmbmyOig7zMC59FF4kn7icYhGznlLOQH87HH1wPwuemeuUHbXrl+S0pCc6 Vt/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ihmdOem+; 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 q8si12474032ejb.609.2021.03.29.11.24.12; Mon, 29 Mar 2021 11:24:35 -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=ihmdOem+; 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 S231438AbhC2SXS (ORCPT + 99 others); Mon, 29 Mar 2021 14:23:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231312AbhC2SWs (ORCPT ); Mon, 29 Mar 2021 14:22:48 -0400 Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3BFBC061764 for ; Mon, 29 Mar 2021 11:22:47 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id 91-20020a9d08640000b0290237d9c40382so13146121oty.12 for ; Mon, 29 Mar 2021 11:22:47 -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=P+4V7kdgmOSoM2q5m0q378E9m02rDEI4zRk0CO5JIEk=; b=ihmdOem+jlQqEIYcjQMemO9yzZ76f8aNqKaq2e8wFi4szCWed/e1VkYakstJEI3Drg NaAdM5GWc0knwIVc+ct6Hw2HnP7hY90CMpni9QukM9RxNUdKXO+8UtDrP5hSr3OnGdo3 SKg0voWbPM4pd5WN6CYz0lwI3i8uBCJ9cypbH1Cf9U6oVSlVmAF/cJilJc+gS1S8l056 +rctM+5G8Sc+Et8OC9/ZiaHJ6YISl9zzcyHMyx8QAhSYg+ZfYEKNIsYVF8TO4CFqDl6K bMRlibkCRKn3uTiSk9PfKBr3QBZq+/VnNjn39AfuF1jjVsf+WQ6k/kEX2sx+aMYVbwJH 2+fA== 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=P+4V7kdgmOSoM2q5m0q378E9m02rDEI4zRk0CO5JIEk=; b=eKxmMqHDtB5r1GGZ2JaUXl1xTQbaFSaaOXJ2dhmNMsRVGUZBBffG0vPKxbgbnnD0EP jhXlJMcnnn1GwB0BfR13JigwgI+fyglf+r2EkaQloOclwZF+7DKhxKGbZ/pAbePAn+Jg FGCf4ROQ3CIKSLZ4cSYM9X0x91eGcZsohNFnxP6kd+bC20eyoNnaFC8tJNsQbugQ1ve2 +YQFkHKIA7YeNcHsdaLVWqLNLM/vidkzS7I8jLT1r9kgX6gAoYbu+5TOzx1BU5uBc+zy JiKcpjc6oUBgghoJhyhekUtl5ElNZBcQVoN3/yYx9BRZi6gio7pFX0qTIMNkooM3Xq/E IjMQ== X-Gm-Message-State: AOAM531sHfTVKmaAr/FamHxQisl7fmZl5UyDtoiBei1vnjffJj0HlAfi fA2kCzh5OL3t8ssvXeaV5yPtJnjY5vCEng9TOQTtPg== X-Received: by 2002:a05:6830:148c:: with SMTP id s12mr24623928otq.251.1617042166749; Mon, 29 Mar 2021 11:22:46 -0700 (PDT) MIME-Version: 1.0 References: <20210324112503.623833-1-elver@google.com> <20210324112503.623833-7-elver@google.com> <20210329142705.GA24849@redhat.com> In-Reply-To: <20210329142705.GA24849@redhat.com> From: Marco Elver Date: Mon, 29 Mar 2021 20:22:34 +0200 Message-ID: Subject: Re: [PATCH v3 06/11] perf: Add support for SIGTRAP on perf events To: Oleg Nesterov 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 , Dmitry Vyukov , 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" , Jiri Olsa Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 29 Mar 2021 at 16:27, Oleg Nesterov wrote: > On 03/29, Peter Zijlstra wrote: > > > > On Thu, Mar 25, 2021 at 09:14:39AM +0100, Marco Elver wrote: > > > @@ -6395,6 +6395,13 @@ static void perf_sigtrap(struct perf_event *event) > > > { > > > struct kernel_siginfo info; > > > > > > + /* > > > + * This irq_work can race with an exiting task; bail out if sighand has > > > + * already been released in release_task(). > > > + */ > > > + if (!current->sighand) > > > + return; > > This is racy. If "current" has already passed exit_notify(), current->parent > can do release_task() and destroy current->sighand right after the check. > > > Urgh.. I'm not entirely sure that check is correct, but I always forget > > the rules with signal. It could be we ought to be testing PF_EXISTING > > instead. > > Agreed, PF_EXISTING check makes more sense in any case, the exiting task > can't receive the signal anyway. So, per off-list discussion, it appears that I should ask to clarify: PF_EXISTING or PF_EXITING? It appears that PF_EXISTING is what's being suggested, whereas it has not been mentioned anywhere, nor are its semantics clear. If it is not simply the negation of PF_EXITING, what are its semantics? And why do we need it in the case here (instead of something else that already exists)? Thanks, -- Marco