Message ID | 20240202234057.2085863-3-irogers@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-50720-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:9bc1:b0:106:209c:c626 with SMTP id op1csp759225dyc; Fri, 2 Feb 2024 15:42:08 -0800 (PST) X-Google-Smtp-Source: AGHT+IHaixNPbRPgM732MEq/6B9l8iR5HD/AnQvP0TtBZ685X/n/ebF9g/TnIF9w08BLXSEdRP5u X-Received: by 2002:a05:622a:593:b0:42b:f794:d46 with SMTP id c19-20020a05622a059300b0042bf7940d46mr6444540qtb.60.1706917327904; Fri, 02 Feb 2024 15:42:07 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706917327; cv=pass; d=google.com; s=arc-20160816; b=pZbDjV37+VIcZAgN7fIgja10VLlns1p3KhR7cEctdG0/VvGgl6WoFr4Q8ZBaCa7eGl nzFw/IXpgENfAqBV1QYQy6EgQgqA1u2wCVYWHxcJaFwt7NZLt1SsyJVqN3q6a9Km/y06 GLKPQsXOJIOXVFutbdwAaq4aAUDccsFiETOJD8OcbPDfoOeP7j8/3Mxgojq0o739dh8x NH3FuAxTqAdmw0uJ7/1WtsuI+1P185bYBUEKhxwTC2BXnJgpUmLIyHMAVE0v+FyurYVP knjJ1EbixMfusvQvg7kxeVYIHpq3HVC9oBT5BWTpdw6Vz84lc91aIZxpumWFOvF2tQuv 1G2A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:from:subject:references:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:in-reply-to:date :dkim-signature; bh=wOc7/ot5clrlqkd/XVVApb41eylij+dgoGLfSlWPOp0=; fh=Nlhf4X30j6heizD8GMG6198g4c7lxJN77yU2/5LPjsY=; b=ktUcMoyr8HVP5YLkDjQLZPwOWr797kiszJXfA3gi+dxx3AQq0IlVa6AjRrvQrQIvzD +1cW87DauHCtHL2GqCFlwZeVVt3FVdzTcB7DqSzGecdMF6X+wKTG43wLEeLWqNojFqR7 D0oYh0XuiEd4A1ALQB6hkhMnFCNgweLrlXzXBy6D2hR7vPqM6v0jYCtzq1OcixBAX9tG Agpfd4QoRQ+koh2Vq0iRTU+jFc4HDYnq+6jbFce0moJf2x/mycPds+rvCwQa7/ZMmqkD VhBSWP4rdTO43c+Y0gT+m1zJcwYG3w/Pilc1i21xMp4kAcxncjJq2hzl3GPGFDFthrcu Ohbw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=AyrvHKJj; arc=pass (i=1 spf=pass spfdomain=flex--irogers.bounces.google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-50720-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-50720-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com X-Forwarded-Encrypted: i=1; AJvYcCUWpIWrlP2StCEaSjc0pQRI8/BzOI3E5e8VOvqqhiAMMSmxse8BH4Pt1kLDM86ZB6QuMj2g7P3Aog+ANYcaI3kicJeVcg== Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id n9-20020a05622a040900b0042ab228f5dcsi3120156qtx.779.2024.02.02.15.42.07 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Feb 2024 15:42:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-50720-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=AyrvHKJj; arc=pass (i=1 spf=pass spfdomain=flex--irogers.bounces.google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-50720-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-50720-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id B04DD1C20CB4 for <ouuuleilei@gmail.com>; Fri, 2 Feb 2024 23:42:07 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 97DC812C7E5; Fri, 2 Feb 2024 23:41:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="AyrvHKJj" Received: from mail-yb1-f202.google.com (mail-yb1-f202.google.com [209.85.219.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3CA9212D779 for <linux-kernel@vger.kernel.org>; Fri, 2 Feb 2024 23:41:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706917277; cv=none; b=q8i2BwUoUuwPQdVM4q+GQygAFM+SPdcudjqE/70YYDPd/Dg5nRKaqLSwf91Xmfu/5G2rSkHYfupsIHc/0woUyx8qbUG6ViNVUaU3BW4/cGB6rz4cPgGaXsNdGxhWH+fsNzfKJw0b+UpxeEIIWsQiPFaz03bZdxlaMtBLclZPCLQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706917277; c=relaxed/simple; bh=R7HDLt+WXCKcw0UAraBcZnWD54QthkXyaQu13uOf35M=; h=Date:In-Reply-To:Message-Id:Mime-Version:References:Subject:From: To:Content-Type; b=JH+fbjxihsSQWLtf2SaB2TxVc/f1s4Ezf/vcNnocDD+ojPf/md3AXWjAl4ThngaKwdLOyuiNDy7GvS2+P/wGvsCr8bNF4pagm48Dm7vHaJ1SPe/afZrVkiRXwCeQWE7yPrAMZfz5+ee4Pn220g3/srRwHV9pgvWxsJL9yBbtRnA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--irogers.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=AyrvHKJj; arc=none smtp.client-ip=209.85.219.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--irogers.bounces.google.com Received: by mail-yb1-f202.google.com with SMTP id 3f1490d57ef6-dc6b9f4a513so4065541276.3 for <linux-kernel@vger.kernel.org>; Fri, 02 Feb 2024 15:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706917274; x=1707522074; darn=vger.kernel.org; h=to:from:subject:references:mime-version:message-id:in-reply-to:date :from:to:cc:subject:date:message-id:reply-to; bh=wOc7/ot5clrlqkd/XVVApb41eylij+dgoGLfSlWPOp0=; b=AyrvHKJjjXcpTnTw4Q1Oh72rOi5vJrbZ3NSKSgFRcmHrdQ9urAxqzaDeeAWfqmw1CL V2OIprdiY9MJ0htwTWHjbjukLdw7GmjOkyqarwZWfqn2/8Nov6Ocp/QbJOAyaHPZqEhv hziwunHjYpud1MfPnxCijqL4At/8TCLcXP3ITG/sHjJf5dLMZBDCWVnSsVuJpt8WizXl wZDeqrqXusMSV10naS2Ovb/WYhlAqQRr2Xtbkc0txIShOu29QlZQm42MK7Ezu4CBW1H2 OxpzDQzCpQwQLEealrpbXlNFI9Pleu4GOdpHUI3AnJSzmnPwCCL/ker674WkFBkQGxwz OW2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706917274; x=1707522074; h=to:from:subject:references:mime-version:message-id:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wOc7/ot5clrlqkd/XVVApb41eylij+dgoGLfSlWPOp0=; b=s0CHHmfWSUx/vLlekIpxwyw2nm3WhU1a0InuFyvicCZnvj0QCfxNoJ9Zmz/6HTFEbS q8cBTXxMK+uigQp6fohlY7xUVvDETdQ0OBGy9ZZIOmHdrY8fYnMh4jArljW0Xb36mVgA BbT/5ck7YKsHhEo8F6FzZrjk2XL/yvvnoQt2I7EbyNjX6m7O6BjNPCLGSNP2seTB7UpF s5PPNANemFd2qD3nHld0OM47BKaR9M/XOTJjlhlwWNjJBPlyq5Unx7m8wTBVxh9vm9sh XAyMAe9Ki4vnjqN0wkcWw83QmLQJ997BSIp8qXKtqxsNt4AHAaeSVddjWfAReX/wrwK/ hKYg== X-Gm-Message-State: AOJu0Yw1veCrCusjYhRQDA8GBA2mm66YBIHSRPXT+KcAEJz5IB9+CZSx uJnxMWkqqMV6hLMQOpGCvyhzsA/79kBOxlcpbsFZ8qS+K0vXsdRssycsuSnMyWaLux4UWGOKf/S R1hQlDA== X-Received: from irogers.svl.corp.google.com ([2620:15c:2a3:200:7732:d863:503:f53d]) (user=irogers job=sendgmr) by 2002:a05:6902:1b08:b0:dc2:398d:a671 with SMTP id eh8-20020a0569021b0800b00dc2398da671mr1024554ybb.10.1706917274174; Fri, 02 Feb 2024 15:41:14 -0800 (PST) Date: Fri, 2 Feb 2024 15:40:51 -0800 In-Reply-To: <20240202234057.2085863-1-irogers@google.com> Message-Id: <20240202234057.2085863-3-irogers@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> Mime-Version: 1.0 References: <20240202234057.2085863-1-irogers@google.com> X-Mailer: git-send-email 2.43.0.594.gd9cf4e227d-goog Subject: [PATCH v3 2/8] libperf cpumap: Ensure empty cpumap is NULL from alloc From: Ian Rogers <irogers@google.com> To: 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>, Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, Suzuki K Poulose <suzuki.poulose@arm.com>, Mike Leach <mike.leach@linaro.org>, James Clark <james.clark@arm.com>, Leo Yan <leo.yan@linaro.org>, John Garry <john.g.garry@oracle.com>, Will Deacon <will@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Darren Hart <dvhart@infradead.org>, Davidlohr Bueso <dave@stgolabs.net>, " =?utf-8?q?Andr=C3=A9_Almeida?= " <andrealmeid@igalia.com>, Kan Liang <kan.liang@linux.intel.com>, K Prateek Nayak <kprateek.nayak@amd.com>, Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, Kajol Jain <kjain@linux.ibm.com>, Athira Rajeev <atrajeev@linux.vnet.ibm.com>, Andrew Jones <ajones@ventanamicro.com>, Alexandre Ghiti <alexghiti@rivosinc.com>, Atish Patra <atishp@rivosinc.com>, "Steinar H. Gunderson" <sesse@google.com>, Yang Jihong <yangjihong1@huawei.com>, Yang Li <yang.lee@linux.alibaba.com>, Changbin Du <changbin.du@huawei.com>, Sandipan Das <sandipan.das@amd.com>, Ravi Bangoria <ravi.bangoria@amd.com>, Paran Lee <p4ranlee@gmail.com>, Nick Desaulniers <ndesaulniers@google.com>, Huacai Chen <chenhuacai@kernel.org>, Yanteng Si <siyanteng@loongson.cn>, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789832544332552779 X-GMAIL-MSGID: 1789832544332552779 |
Series |
Clean up libperf cpumap's empty function
|
|
Commit Message
Ian Rogers
Feb. 2, 2024, 11:40 p.m. UTC
Potential corner cases could cause a cpumap to be allocated with size
0, but an empty cpumap should be represented as NULL. Add a path in
perf_cpu_map__alloc to ensure this.
Suggested-by: James Clark <james.clark@arm.com>
Closes: https://lore.kernel.org/lkml/2cd09e7c-eb88-6726-6169-647dcd0a8101@arm.com/
Signed-off-by: Ian Rogers <irogers@google.com>
---
tools/lib/perf/cpumap.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
Comments
On Fri, Feb 2, 2024 at 3:41 PM Ian Rogers <irogers@google.com> wrote: > > Potential corner cases could cause a cpumap to be allocated with size > 0, but an empty cpumap should be represented as NULL. Add a path in > perf_cpu_map__alloc to ensure this. > > Suggested-by: James Clark <james.clark@arm.com> > Closes: https://lore.kernel.org/lkml/2cd09e7c-eb88-6726-6169-647dcd0a8101@arm.com/ > Signed-off-by: Ian Rogers <irogers@google.com> > --- > tools/lib/perf/cpumap.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c > index ba49552952c5..cae799ad44e1 100644 > --- a/tools/lib/perf/cpumap.c > +++ b/tools/lib/perf/cpumap.c > @@ -18,9 +18,13 @@ void perf_cpu_map__set_nr(struct perf_cpu_map *map, int nr_cpus) > > struct perf_cpu_map *perf_cpu_map__alloc(int nr_cpus) > { > - RC_STRUCT(perf_cpu_map) *cpus = malloc(sizeof(*cpus) + sizeof(struct perf_cpu) * nr_cpus); > + RC_STRUCT(perf_cpu_map) *cpus; > struct perf_cpu_map *result; > > + if (nr_cpus == 0) > + return NULL; But allocation failure also returns NULL. Then callers should check what's the expected result. Thanks, Namhyung > + > + cpus = malloc(sizeof(*cpus) + sizeof(struct perf_cpu) * nr_cpus); > if (ADD_RC_CHK(result, cpus)) { > cpus->nr = nr_cpus; > refcount_set(&cpus->refcnt, 1); > -- > 2.43.0.594.gd9cf4e227d-goog >
On Fri, Feb 16, 2024 at 4:25 PM Namhyung Kim <namhyung@kernel.org> wrote: > > On Fri, Feb 2, 2024 at 3:41 PM Ian Rogers <irogers@google.com> wrote: > > > > Potential corner cases could cause a cpumap to be allocated with size > > 0, but an empty cpumap should be represented as NULL. Add a path in > > perf_cpu_map__alloc to ensure this. > > > > Suggested-by: James Clark <james.clark@arm.com> > > Closes: https://lore.kernel.org/lkml/2cd09e7c-eb88-6726-6169-647dcd0a8101@arm.com/ > > Signed-off-by: Ian Rogers <irogers@google.com> > > --- > > tools/lib/perf/cpumap.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c > > index ba49552952c5..cae799ad44e1 100644 > > --- a/tools/lib/perf/cpumap.c > > +++ b/tools/lib/perf/cpumap.c > > @@ -18,9 +18,13 @@ void perf_cpu_map__set_nr(struct perf_cpu_map *map, int nr_cpus) > > > > struct perf_cpu_map *perf_cpu_map__alloc(int nr_cpus) > > { > > - RC_STRUCT(perf_cpu_map) *cpus = malloc(sizeof(*cpus) + sizeof(struct perf_cpu) * nr_cpus); > > + RC_STRUCT(perf_cpu_map) *cpus; > > struct perf_cpu_map *result; > > > > + if (nr_cpus == 0) > > + return NULL; > > But allocation failure also returns NULL. Then callers should check > what's the expected result. Right, we don't have a habit of just aborting on memory allocation errors. In the case that NULL is returned it is assumed that an empty CPU map is appropriate. Adding checks throughout the code base that an empty CPU map is only returned when 0 is given is beyond the scope of this patch set. Thanks, Ian > Thanks, > Namhyung > > > + > > + cpus = malloc(sizeof(*cpus) + sizeof(struct perf_cpu) * nr_cpus); > > if (ADD_RC_CHK(result, cpus)) { > > cpus->nr = nr_cpus; > > refcount_set(&cpus->refcnt, 1); > > -- > > 2.43.0.594.gd9cf4e227d-goog > >
On 17/02/2024 00:52, Ian Rogers wrote: > On Fri, Feb 16, 2024 at 4:25 PM Namhyung Kim <namhyung@kernel.org> wrote: >> >> On Fri, Feb 2, 2024 at 3:41 PM Ian Rogers <irogers@google.com> wrote: >>> >>> Potential corner cases could cause a cpumap to be allocated with size >>> 0, but an empty cpumap should be represented as NULL. Add a path in >>> perf_cpu_map__alloc to ensure this. >>> >>> Suggested-by: James Clark <james.clark@arm.com> >>> Closes: https://lore.kernel.org/lkml/2cd09e7c-eb88-6726-6169-647dcd0a8101@arm.com/ >>> Signed-off-by: Ian Rogers <irogers@google.com> >>> --- >>> tools/lib/perf/cpumap.c | 6 +++++- >>> 1 file changed, 5 insertions(+), 1 deletion(-) >>> >>> diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c >>> index ba49552952c5..cae799ad44e1 100644 >>> --- a/tools/lib/perf/cpumap.c >>> +++ b/tools/lib/perf/cpumap.c >>> @@ -18,9 +18,13 @@ void perf_cpu_map__set_nr(struct perf_cpu_map *map, int nr_cpus) >>> >>> struct perf_cpu_map *perf_cpu_map__alloc(int nr_cpus) >>> { >>> - RC_STRUCT(perf_cpu_map) *cpus = malloc(sizeof(*cpus) + sizeof(struct perf_cpu) * nr_cpus); >>> + RC_STRUCT(perf_cpu_map) *cpus; >>> struct perf_cpu_map *result; >>> >>> + if (nr_cpus == 0) >>> + return NULL; >> >> But allocation failure also returns NULL. Then callers should check >> what's the expected result.> > Right, we don't have a habit of just aborting on memory allocation I'm not sure why we don't abort on allocation. It would simplify the code a lot and wouldn't change the behavior in any meaningful way. And it would also allow us to print out which line exactly failed which is much more useful than bubbling up the error and hiding it. If we're making the decision that an empty map == NULL rather than non-null but with 0 length then maybe it's time to start thinking about it. > errors. In the case that NULL is returned it is assumed that an empty > CPU map is appropriate. Adding checks throughout the code base that an > empty CPU map is only returned when 0 is given is beyond the scope of > this patch set. > > Thanks, > Ian > >> Thanks, >> Namhyung >> >>> + >>> + cpus = malloc(sizeof(*cpus) + sizeof(struct perf_cpu) * nr_cpus); >>> if (ADD_RC_CHK(result, cpus)) { >>> cpus->nr = nr_cpus; >>> refcount_set(&cpus->refcnt, 1); >>> -- >>> 2.43.0.594.gd9cf4e227d-goog >>>
diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c index ba49552952c5..cae799ad44e1 100644 --- a/tools/lib/perf/cpumap.c +++ b/tools/lib/perf/cpumap.c @@ -18,9 +18,13 @@ void perf_cpu_map__set_nr(struct perf_cpu_map *map, int nr_cpus) struct perf_cpu_map *perf_cpu_map__alloc(int nr_cpus) { - RC_STRUCT(perf_cpu_map) *cpus = malloc(sizeof(*cpus) + sizeof(struct perf_cpu) * nr_cpus); + RC_STRUCT(perf_cpu_map) *cpus; struct perf_cpu_map *result; + if (nr_cpus == 0) + return NULL; + + cpus = malloc(sizeof(*cpus) + sizeof(struct perf_cpu) * nr_cpus); if (ADD_RC_CHK(result, cpus)) { cpus->nr = nr_cpus; refcount_set(&cpus->refcnt, 1);