Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp6312896rwi; Sun, 23 Oct 2022 22:44:04 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5l5vO890Iid3nRpuwY6MXi03KT/n3/CQJKNF35LrihsOx93WV82UafX2aBDX1MDTW17/Kf X-Received: by 2002:a05:6402:35d1:b0:45d:3661:567e with SMTP id z17-20020a05640235d100b0045d3661567emr29808390edc.343.1666590244628; Sun, 23 Oct 2022 22:44:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666590244; cv=none; d=google.com; s=arc-20160816; b=plJWQRwrTW4xFu2qxldyhXruLHdUVvOn7/kKbKHIZoh4IV/KtrmkmG+Lxt/chQdIJP DIrp7YAhJTwzvEOgezdunlUXgk+Dn7nnDNGvhAqdDjJiPsfNO1qTAlzQlV565k8k2Ok2 KYQwJ+NRqwg3C26QeLHO2zx/6DzfRFCHBDeueD2OU/QH3kZYlWzfT+f6NsUCtUo4tBaO Y0yZ1xHZqav98eeoQGX3XdoVHcCEVC5pY8mcn+C5QCfqzj2g1fExQBUVSBKCVGbyROws +bdDNQDO3ARx75oKc5GcQR9HQP7msH81sJdlFyCFF81++K8184+VU+6/aZ29/EXkjexM R7Qg== 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=FPSIWsFJNQhmUPJF7n8WqvsLFtclPPR/mNLlWiKjkNw=; b=TxT6Cm28f1rzjUkw7XIwHev8o3a7Z07zzxVvGZ9dcjl2/GaFk2aKAVFa69i+tV3N1j zr8YGG2otzhL752S5a67SAnLvYU+beiLa5F17VtZnzDE/2n47E4Kz9YHv+fviAWcVcbP kgytXs42XD1OXj0wxUiR8JZE9xEiNDfDvKvyps3rVGagVDnOMOdZNt1CwVOuKTy5h51n SriCK4x35QopU6lxTixsqEsgs+IsRVOyWQsjP3DJyDofKq3eScF1h4xqFCOKRyIXkXOC 6SCmmDLPAfOOqG03qvFPP1RekMZMgtiARGJaEQE8c1rnJB0yjO8qMNoNWysiPelHTWIB HLyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=p0RUQqe4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m22-20020a056402051600b00458c130870esi20323170edv.385.2022.10.23.22.43.39; Sun, 23 Oct 2022 22:44:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=p0RUQqe4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S229988AbiJXFds (ORCPT + 99 others); Mon, 24 Oct 2022 01:33:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57796 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229927AbiJXFdp (ORCPT ); Mon, 24 Oct 2022 01:33:45 -0400 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33B6B7B7AD for ; Sun, 23 Oct 2022 22:33:44 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id 186-20020a1c02c3000000b003c6c154d528so9216305wmc.4 for ; Sun, 23 Oct 2022 22:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FPSIWsFJNQhmUPJF7n8WqvsLFtclPPR/mNLlWiKjkNw=; b=p0RUQqe4QJW3SY3M7bsWCZ2VYexAIelrq8fVMVGUOoyFJXI3ly10A6/O7biughp/fe vacChmI8FWzktztBzdgR/WH9HKKiSjhOrPtt822hKWTJGspuXgxcX0iUKO0gwQkz7kOW 4QFrnHDHYZOyjHetGX1ApNuuM/O8XTbiljjoCOfXWk+EdYtKQBr1BuJG+8S004e39n+a ocvqnEQepvTRrMpQHnga24NqsEEx/HRVl29/5lAJJMmo+d47OrHrmTTIT8gTOLzbLpAh LIfhn6aYl2MZFPHjJoX/M7yoXjxB4qYCNcXJepJILP0mbx0c5SSIPj0T73coY3JeZjuz tu4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FPSIWsFJNQhmUPJF7n8WqvsLFtclPPR/mNLlWiKjkNw=; b=FPIW0K2aFvyBB+hJNnsU+8bNpppX+YQIhtmdVtAAn6y77WgZcdRBKjp5/1w7ug3wXV 7dQa5SOdD6C8efes6sPmlPsj5hBo39F/C4PzPlTpv/n+cCsbFlDf+1EZsWfM932RLA5N NExR9zhr0IU4ujEz7SZNvsGFIx6w/pt3in4pahDGQr92oEwhJsr33kOyCDiHO9Q/4cbl 6o63ou6fH9pWksps/Y1R7ZNGXbO19lpXFOfBqjym+tlCEN/5ySnjBP/giyipAUg/ELwM LITrYMJBJ6/8tnHjNfb35n5ZhyQkoaXBN4DYA7Q9SJhLQGCC6jxtRHtNZSswG2ck5pJK gV7g== X-Gm-Message-State: ACrzQf0ELIZ60lKpw6Ep0qikUZx9BfjTGb51rai2VmpkoFc1X8eX40iK VwkymX1QfpQ8X+Ubr1QEqZcFMqxD1cYuRannzgdRQw== X-Received: by 2002:a05:600c:3789:b0:3c6:beed:fecf with SMTP id o9-20020a05600c378900b003c6beedfecfmr20071015wmr.174.1666589622593; Sun, 23 Oct 2022 22:33:42 -0700 (PDT) MIME-Version: 1.0 References: <20221024011024.462518-1-irogers@google.com> In-Reply-To: From: Ian Rogers Date: Sun, 23 Oct 2022 22:33:30 -0700 Message-ID: Subject: Re: [PATCH v1] perf record: Fix event fd races To: Leo Yan Cc: Greg Thelen , Anand K Mistry , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, Stephane Eranian Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Oct 23, 2022 at 7:56 PM Leo Yan wrote: > > Hi Ian, > > On Sun, Oct 23, 2022 at 06:10:24PM -0700, Ian Rogers wrote: > > The write call may set errno which is problematic if occurring in a > > function also setting errno. Save and restore errno around the write > > call. > > > > done_fd may be used after close, clear it as part of the close and > > check its validity in the signal handler. > > > > Suggested-by: Greg Thelen > > Signed-off-by: Ian Rogers > > --- > > tools/perf/builtin-record.c | 41 ++++++++++++++++++++++--------------- > > 1 file changed, 25 insertions(+), 16 deletions(-) > > > > diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c > > index 52d254b1530c..e128b855ddde 100644 > > --- a/tools/perf/builtin-record.c > > +++ b/tools/perf/builtin-record.c > > @@ -649,7 +649,7 @@ static int record__pushfn(struct mmap *map, void *to, void *bf, size_t size) > > static volatile int signr = -1; > > static volatile int child_finished; > > #ifdef HAVE_EVENTFD_SUPPORT > > -static int done_fd = -1; > > +static volatile int done_fd = -1; > > Here is a bit suspecious for adding volatile qualifier. See the > document: process/volatile-considered-harmful.rst. > > I know the document is mainly for kernel programming, but seems to me > it's also valid for C programming in userspace. > > I not sure what's the purpose for adding volatile for done_fd, if we > really have concern for reading any stale value for done_fd, should we > use WRITE_ONCE/READ_ONCE? We could just switch to C11 and stdatomic. The volatile is consistent with the code above and more consistent with the expectation of writing to a variable that is read in a signal handler. Thanks, Ian > The rest changes look good to me. > > Thanks, > Leo > > > #endif > > > > static void sig_handler(int sig) > > @@ -661,19 +661,24 @@ static void sig_handler(int sig) > > > > done = 1; > > #ifdef HAVE_EVENTFD_SUPPORT > > -{ > > - u64 tmp = 1; > > - /* > > - * It is possible for this signal handler to run after done is checked > > - * in the main loop, but before the perf counter fds are polled. If this > > - * happens, the poll() will continue to wait even though done is set, > > - * and will only break out if either another signal is received, or the > > - * counters are ready for read. To ensure the poll() doesn't sleep when > > - * done is set, use an eventfd (done_fd) to wake up the poll(). > > - */ > > - if (write(done_fd, &tmp, sizeof(tmp)) < 0) > > - pr_err("failed to signal wakeup fd, error: %m\n"); > > -} > > + if (done_fd >= 0) { > > + u64 tmp = 1; > > + int orig_errno = errno; > > + > > + /* > > + * It is possible for this signal handler to run after done is > > + * checked in the main loop, but before the perf counter fds are > > + * polled. If this happens, the poll() will continue to wait > > + * even though done is set, and will only break out if either > > + * another signal is received, or the counters are ready for > > + * read. To ensure the poll() doesn't sleep when done is set, > > + * use an eventfd (done_fd) to wake up the poll(). > > + */ > > + if (write(done_fd, &tmp, sizeof(tmp)) < 0) > > + pr_err("failed to signal wakeup fd, error: %m\n"); > > + > > + errno = orig_errno; > > + } > > #endif // HAVE_EVENTFD_SUPPORT > > } > > > > @@ -2834,8 +2839,12 @@ static int __cmd_record(struct record *rec, int argc, const char **argv) > > > > out_delete_session: > > #ifdef HAVE_EVENTFD_SUPPORT > > - if (done_fd >= 0) > > - close(done_fd); > > + if (done_fd >= 0) { > > + fd = done_fd; > > + done_fd = -1; > > + > > + close(fd); > > + } > > #endif > > zstd_fini(&session->zstd_data); > > perf_session__delete(session); > > -- > > 2.38.0.135.g90850a2211-goog > >