Message ID | 20221024011024.462518-1-irogers@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp202457wru; Sun, 23 Oct 2022 18:37:00 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4ZIFvzFMGRSCBy0VcaoNXkyAnsV84fl1cS5M3ABriJUnzRs1Se5YJILoBiGgCtsw1M3CQ3 X-Received: by 2002:a17:903:248:b0:172:7520:db04 with SMTP id j8-20020a170903024800b001727520db04mr31456622plh.99.1666575420688; Sun, 23 Oct 2022 18:37:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666575420; cv=none; d=google.com; s=arc-20160816; b=UB2VH4oyl2jOBOznNwJ/CrFNrgjM0VPJARN2I3xuqVxVp94e/RS2ZgAaN4W9divslL 28Nq3NOMGjGUDyqKn5d413ONRSfk/a90DWVvkL3heuWTH5QuwRrTPtq31y11NYaIhOSz 0wtgstIc8JqDYLhJYZcjJaGYVowLzi+ohfMdAHKBJKokOUpMkScfWtL6Eyvpt1VRli2C GKq78FpUg/UYhYevDW3NvaDUMmBtJQjh+Myxz/oLmraibh4QBQe/ptDDPKfMJ3TT0Mxb 9JdNgFtDGAeglwQIDAXsiCrSAZtB/KuVVznIWOaY2QX3XQpefl19jXb0y6dKT/fjZxeI V8gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:mime-version:message-id:date :dkim-signature; bh=bPFUPgqfkuveFVX9ctMwkjUhtRM4a3rz3/7u8h2+JCY=; b=L80nV6MQj0MCM4aaYDRl8j/eB0IDHbkAT5C0rQnohMGt/MBmLM2CU4bTLWFdpf4eRZ UwqocKWnqjwI7TLe29ECOmdUIQRXYVF92DeZ5p39g4cWjmRUq2SeeNVYfUdTUpiik1Qd 5uG+YYXCo5Xv0sHbV62qZR02i2fNugYbI4/nFQeYjPs+J2n9Px6XUyK07dgY8FHSLEK8 +jKFUW+Sjv84+baE5MeUF/Sfgk5xhLLGUq+21qZckLFyZyJre2XjVmXAMw3P8u3Ocf2V pNZrZqhSssQIU7PLvxvHBqvnop7T16uaWF6js34ScTojd3gvEzN6UfEmWwiqBu03dY/T vKDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=tS9ysiGK; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a70-20020a639049000000b004611cfaca6asi32803650pge.381.2022.10.23.18.36.48; Sun, 23 Oct 2022 18:37:00 -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=tS9ysiGK; 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 S229667AbiJXBKy (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Sun, 23 Oct 2022 21:10:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229732AbiJXBKu (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 23 Oct 2022 21:10:50 -0400 Received: from mail-pf1-x44a.google.com (mail-pf1-x44a.google.com [IPv6:2607:f8b0:4864:20::44a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BF1E5FC2C for <linux-kernel@vger.kernel.org>; Sun, 23 Oct 2022 18:10:49 -0700 (PDT) Received: by mail-pf1-x44a.google.com with SMTP id s2-20020aa78282000000b00561ba8f77b4so3881764pfm.1 for <linux-kernel@vger.kernel.org>; Sun, 23 Oct 2022 18:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:mime-version:message-id:date:from:to:cc:subject :date:message-id:reply-to; bh=bPFUPgqfkuveFVX9ctMwkjUhtRM4a3rz3/7u8h2+JCY=; b=tS9ysiGKKfafl7Yy2AmyJBOWCbaWVea5uX+3ZhaWOph14OQ4/vNuCdX8cDRQ2xJdDX 4JUyqkUXGJOPDSCPP2OncfSFAcW5zfU1m8bj8zM1SJvDl/BUFh3czJtJivaZmlJb/gro 6GcyTBWU5FQfH9lWsieRrt1rKdTzJpIjaJwOGxqPgYddAQi1CYcP5AMsHmcxk/fMq6FK UB3vVYxn3ERUz/PWtOODhhjMFlXLAjW/FRsfmZ2mZn+BxTYk6cByHEXFe+zbBUNVkphi aMsQHBuQbYEbxKWCSDW5uyTWCB4RnTXDg6YLF+9IQCB/RNFxaujVeGMcRyJGh8JMc7vL pnRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:mime-version:message-id:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=bPFUPgqfkuveFVX9ctMwkjUhtRM4a3rz3/7u8h2+JCY=; b=etdPaIKGm29jvZ+5iQT6jsY4MPePVK3AnauwmxPZs2joHS2sT0GAoH0UQ4Pas9xTk5 MMSBC+kfmYHf1X9PcbvkgVUwT/tx/KQAwhAphBSY601sQwsdUQolmf4sgLtHxfQQMz9u I621aIcXC5DAT+Pr6zrzcnpnN+USFBZmm/AeIoOtUif+esWnBkeR/WTeNdqObjZBpand HhlaZ7tP+3fade3R/jg0wzacQXXZcuG2uXi94DuMztRIwu80//RGYvSxHD5BVAjGySIZ yBZMuQpxp2VYOCBl3mH3LPTqG7jDIov4KoX2stuv6oYdaQKahEAtm/jV1OMlgBtL+ovo ATJg== X-Gm-Message-State: ACrzQf38xa9r99mlHDRU2ErVhJqaP0AderEqlSYPX/+R5nNixUDMClJP akkA1FGxO6/kCxAJNPb7GNkC9wjVnf44 X-Received: from irogers.svl.corp.google.com ([2620:15c:2d4:203:26d5:b9c8:e16c:3a45]) (user=irogers job=sendgmr) by 2002:a05:6a00:10c8:b0:563:1bd1:2ce4 with SMTP id d8-20020a056a0010c800b005631bd12ce4mr31080819pfu.6.1666573849036; Sun, 23 Oct 2022 18:10:49 -0700 (PDT) Date: Sun, 23 Oct 2022 18:10:24 -0700 Message-Id: <20221024011024.462518-1-irogers@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.38.0.135.g90850a2211-goog Subject: [PATCH v1] perf record: Fix event fd races From: Ian Rogers <irogers@google.com> To: Greg Thelen <gthelen@google.com>, Anand K Mistry <amistry@google.com>, Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, Arnaldo Carvalho de Melo <acme@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Stephane Eranian <eranian@google.com>, Ian Rogers <irogers@google.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747530988245455412?= X-GMAIL-MSGID: =?utf-8?q?1747530988245455412?= |
Series |
[v1] perf record: Fix event fd races
|
|
Commit Message
Ian Rogers
Oct. 24, 2022, 1:10 a.m. UTC
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 <gthelen@google.com>
Signed-off-by: Ian Rogers <irogers@google.com>
---
tools/perf/builtin-record.c | 41 ++++++++++++++++++++++---------------
1 file changed, 25 insertions(+), 16 deletions(-)
Comments
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 <gthelen@google.com> > Signed-off-by: Ian Rogers <irogers@google.com> > --- > 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? 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 >
On Sun, Oct 23, 2022 at 7:56 PM Leo Yan <leo.yan@linaro.org> 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 <gthelen@google.com> > > Signed-off-by: Ian Rogers <irogers@google.com> > > --- > > 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 > >
On Sun, Oct 23, 2022 at 10:33:30PM -0700, Ian Rogers wrote: [...] > > > +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 for the info for C11 and stdatomic.h. The documentation [1] says the safe way is for accessing shared data in signal handler is: static volatile sig_atomic_t done_fd = -1; It's fine if you want to use another patch to address this issue, this patch for fixing errno is fine for me: Reviewed-by: Leo Yan <leo.yan@linaro.org> [1] https://wiki.sei.cmu.edu/confluence/display/c/SIG31-C.+Do+not+access+shared+objects+in+signal+handlers
Em Mon, Oct 24, 2022 at 05:16:56PM +0800, Leo Yan escreveu: > On Sun, Oct 23, 2022 at 10:33:30PM -0700, Ian Rogers wrote: > > [...] > > > > > +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 for the info for C11 and stdatomic.h. The documentation [1] says > the safe way is for accessing shared data in signal handler is: > > static volatile sig_atomic_t done_fd = -1; > > It's fine if you want to use another patch to address this issue, this > patch for fixing errno is fine for me: > > Reviewed-by: Leo Yan <leo.yan@linaro.org> Thanks, applied. - Arnaldo > [1] https://wiki.sei.cmu.edu/confluence/display/c/SIG31-C.+Do+not+access+shared+objects+in+signal+handlers
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; #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);