Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp1201087ybh; Sat, 3 Aug 2019 20:29:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqxTQlLGItg1EGV0irVRNW4DGfFET1P0Yhz9SPDL8eJsh1asv1PHBPy+VdvM4e9Y8MsMTmCZ X-Received: by 2002:a17:90a:d817:: with SMTP id a23mr11619566pjv.54.1564889343852; Sat, 03 Aug 2019 20:29:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564889343; cv=none; d=google.com; s=arc-20160816; b=EVdUy6m/Jh7pTSD5ch64O7+1t+CLCuE8riGVmCNhKgHngsSlwmDK7LtMG5y6E85NsJ 197ppFUwCTRd98UTF9UIFqbkRvRJw6Xfcj2fxmCu3RVJwJG+osKFgm7VsOY7jX4IK+2Y qDi/NfRYJcnGvJCkj0Qs3V7T8zESwzTNtFlJqvS97CFsn/ERu3XIOpX66kjmTIL2/Tfz Vg7ehoXC6CeB4z/9GAFUclMrlpG6xIISKhPDfOJeO8uwZlDms92IRZGMpr0/5jWHW1Ll Yg68ACxkkxp2p6OrLiH0EKJJn5oKOtwPa/gWQdKYGdG2DQxi1FJGv6Xkb3e2pzdmx8Ph 6aDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=r7noMB6pC8Ua1ic6UJHUgth7ZDESUS0oGxn/kD/rTeA=; b=XFdf24QWE96BlnNnmwr3R0ZP/28KUwz4E2/ntjXnaxy81VsQOLXIbOtXW49oYGdbgd 844qXcTdSfaw2RoH70wgmc1o4MsIUfvV5wFavedD/qDOdU/GVWHUgylWH4sT5u6mGbs5 GXLMqpWw2SXDPpmRVxFvvCLnez/aVJ2POZ8tqyjLU6WUQ4IUfbocrwlrzNFgz9bIrZxx 3s6sT7H40CF7FbPkD6zsin6oA8XEhmzXcQY6b6Buh6Xn+ib3z9qQRIkpBZhf3TLtbz6l 6uro4fCZCX7APFv1aAXEB/FV881TubTr22yazqTdaiHHpmN0vruCjsAbKa/xbiO2QznE tO1A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t27si39893440pgk.502.2019.08.03.20.28.48; Sat, 03 Aug 2019 20:29:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726420AbfHCFen (ORCPT + 99 others); Sat, 3 Aug 2019 01:34:43 -0400 Received: from mail1.windriver.com ([147.11.146.13]:41367 "EHLO mail1.windriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726358AbfHCFen (ORCPT ); Sat, 3 Aug 2019 01:34:43 -0400 Received: from ALA-HCA.corp.ad.wrs.com ([147.11.189.40]) by mail1.windriver.com (8.15.2/8.15.1) with ESMTPS id x735YGQ7021285 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Aug 2019 22:34:16 -0700 (PDT) Received: from [128.224.162.221] (128.224.162.221) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server (TLS) id 14.3.468.0; Fri, 2 Aug 2019 22:34:16 -0700 Subject: Re: [PATCH 1/2] perf: Fix failure to set cpumask when only one cpu To: Jiri Olsa CC: , , , , , , , , References: <1564734592-15624-1-git-send-email-zhe.he@windriver.com> <20190802130607.GA27223@krava> From: He Zhe Message-ID: <70e58ead-f152-5697-d24c-45a8c8fa7a83@windriver.com> Date: Sat, 3 Aug 2019 13:34:11 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190802130607.GA27223@krava> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [128.224.162.221] Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/2/19 9:06 PM, Jiri Olsa wrote: > On Fri, Aug 02, 2019 at 04:29:51PM +0800, zhe.he@windriver.com wrote: >> From: He Zhe >> >> The buffer containing string used to set cpumask is overwritten by end of >> string later in cpu_map__snprint_mask due to not enough memory space, when >> there is only one cpu. And thus causes the following failure. >> >> $ perf ftrace ls >> failed to reset ftrace >> >> This patch fixes the calculation of cpumask string size. >> >> Signed-off-by: He Zhe >> --- >> tools/perf/builtin-ftrace.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c >> index 66d5a66..0193128 100644 >> --- a/tools/perf/builtin-ftrace.c >> +++ b/tools/perf/builtin-ftrace.c >> @@ -173,7 +173,7 @@ static int set_tracing_cpumask(struct cpu_map *cpumap) >> int last_cpu; >> >> last_cpu = cpu_map__cpu(cpumap, cpumap->nr - 1); >> - mask_size = (last_cpu + 3) / 4 + 1; >> + mask_size = last_cpu / 4 + 2; /* one more byte for EOS */ >> mask_size += last_cpu / 32; /* ',' is needed for every 32th cpus */ > ugh.. why do we care about last_cpu value in here at all? > > feels like using static buffer would be more reasonable Thanks, and yes, a static buffer would be easy to handle. A 2KB buffer is enough to cover 8196 cpus, the maximum numbers of cpus we can run with for now. Let's see if there is any other concerns. Zhe > > jirka > >> >> cpumask = malloc(mask_size); >> -- >> 2.7.4 >>