Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp548095pxb; Wed, 11 Nov 2020 10:00:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJwzuJoe2q6opoIfpZ70XWAM52AcvsdG8xEBjIhI44s6HpVoj6kP+J56FFNuHbJ5nJRqseY8 X-Received: by 2002:a50:ec1a:: with SMTP id g26mr759621edr.10.1605117638211; Wed, 11 Nov 2020 10:00:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605117638; cv=none; d=google.com; s=arc-20160816; b=W1A02xqIVQDSQ3T+BVvzD9bZIl1aBwM3SE+WY34bEmxSY4G91gJaDipHLXL2zrc9Kv +t8CCYJAm3x08MoJBCPzxWv8hFoOmDPYQJI66LUyZqmmWEzZ+Hksl20fOAvYdwKtfX3M qwhxFEtFahlvCt7f5CrQpEYnWmwFU1oXkL765uIbjNVNYZTp/MLN4QAWbb+9gJLjwFkw NzWXUZ0cT5GSHkLj/xQZYaV85DawgKiIHkzbZlk7FBGrUrAQdR3hWN4FR6Tmi9L48RQp TXjV7yQD9hWGWRnH9k6lkWo0xTSKVB9KMnsCaVtO/Fn0kWWhSO3rOOHl4vRX2pQJq+wZ RsEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=H2R9hfoOyT6dW1gdoUJrtjO/dwctD6zuAxqkEZwYEjM=; b=i+AQnWZE/zgPN6rOUNVPuiyJPJL9wbyor1QlM2HyajMnj5NfLHkNYo7Vm0CeNplzEQ /ljG3MR8UbNXlhTNjVvPT6EmpXb+aWQrCUc8HogHJ01GS2hx8uge5o07igdj4GDzI/ZE M5Id3UTBuPPeaJnMAbEMqqXphG4YgSKKgbJRF26zB6TQPHF8mvyO1rnctHAsS2Z0y2Qj 82dxvvJpZMTjPlPGW5B05PHmdhbpfRcgE5I66k4Gt2sssPr6G3jFIaKDKRuORMhSNCwW 3X6PsioXwN7N2gIyZfEzyZtxI7avkGLy7RYQWD/P9Uz8+00xrVagdKM9cgm7bR5gWOgP OUqw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u26si1816075ejc.249.2020.11.11.10.00.10; Wed, 11 Nov 2020 10:00:38 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726104AbgKKR6e (ORCPT + 99 others); Wed, 11 Nov 2020 12:58:34 -0500 Received: from foss.arm.com ([217.140.110.172]:59202 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725900AbgKKR6e (ORCPT ); Wed, 11 Nov 2020 12:58:34 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 35F8D139F; Wed, 11 Nov 2020 09:58:33 -0800 (PST) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 334C13F718; Wed, 11 Nov 2020 09:58:31 -0800 (PST) Date: Wed, 11 Nov 2020 17:58:27 +0000 From: Dave Martin To: Arnaldo Carvalho de Melo Cc: Andre Przywara , "leo.yan@linaro.org" , James Clark , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Al Grant , Wei Li , John Garry , Will Deacon , Mathieu Poirier , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v8 06/22] perf arm-spe: Refactor printing string to buffer Message-ID: <20201111175827.GR6882@arm.com> References: <20201111071149.815-1-leo.yan@linaro.org> <20201111071149.815-7-leo.yan@linaro.org> <20201111153555.GG355344@kernel.org> <20201111173922.GA380127@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201111173922.GA380127@kernel.org> User-Agent: Mutt/1.5.23 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 11, 2020 at 05:39:22PM +0000, Arnaldo Carvalho de Melo wrote: > Em Wed, Nov 11, 2020 at 03:45:23PM +0000, Andr� Przywara escreveu: > > On 11/11/2020 15:35, Arnaldo Carvalho de Melo wrote: > > > > Hi Arnaldo, > > > > thanks for taking a look! > > > > > Em Wed, Nov 11, 2020 at 03:11:33PM +0800, Leo Yan escreveu: > > >> When outputs strings to the decoding buffer with function snprintf(), > > >> SPE decoder needs to detects if any error returns from snprintf() and if > > >> so needs to directly bail out. If snprintf() returns success, it needs > > >> to update buffer pointer and reduce the buffer length so can continue to > > >> output the next string into the consequent memory space. > > >> > > >> This complex logics are spreading in the function arm_spe_pkt_desc() so > > >> there has many duplicate codes for handling error detecting, increment > > >> buffer pointer and decrement buffer size. > > >> > > >> To avoid the duplicate code, this patch introduces a new helper function > > >> arm_spe_pkt_snprintf() which is used to wrap up the complex logics, and > > >> it's used by the caller arm_spe_pkt_desc(). > > >> > > >> This patch also moves the variable 'blen' as the function's local > > >> variable, this allows to remove the unnecessary braces and improve the > > >> readability. > > >> > > >> Suggested-by: Dave Martin > > >> Signed-off-by: Leo Yan > > >> Reviewed-by: Andre Przywara > > >> --- > > >> .../arm-spe-decoder/arm-spe-pkt-decoder.c | 260 +++++++++--------- > > >> 1 file changed, 126 insertions(+), 134 deletions(-) > > >> > > >> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c > > >> index 04fd7fd7c15f..1970686f7020 100644 > > >> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c > > >> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c > > >> @@ -9,6 +9,7 @@ > > >> #include > > >> #include > > >> #include > > >> +#include > > >> > > >> #include "arm-spe-pkt-decoder.h" > > >> > > >> @@ -258,192 +259,183 @@ int arm_spe_get_packet(const unsigned char *buf, size_t len, > > >> return ret; > > >> } > > >> > > >> +static int arm_spe_pkt_snprintf(int *err, char **buf_p, size_t *blen, > > >> + const char *fmt, ...) > > >> +{ > > >> + va_list ap; > > >> + int ret; > > >> + > > >> + /* Bail out if any error occurred */ > > >> + if (err && *err) > > >> + return *err; > > >> + > > >> + va_start(ap, fmt); > > >> + ret = vsnprintf(*buf_p, *blen, fmt, ap); > > >> + va_end(ap); > > >> + > > >> + if (ret < 0) { > > >> + if (err && !*err) > > >> + *err = ret; > > >> + > > >> + /* > > >> + * A return value of (*blen - 1) or more means that the > > >> + * output was truncated and the buffer is overrun. > > >> + */ > > >> + } else if (ret >= ((int)*blen - 1)) { > > >> + (*buf_p)[*blen - 1] = '\0'; > > >> + > > >> + /* > > >> + * Set *err to 'ret' to avoid overflow if tries to > > >> + * fill this buffer sequentially. > > >> + */ > > >> + if (err && !*err) > > >> + *err = ret; > > >> + } else { > > >> + *buf_p += ret; > > >> + *blen -= ret; > > >> + } > > >> + > > >> + return ret; > > >> +} > > >> + > > >> int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, > > >> size_t buf_len) > > >> { > > >> int ret, ns, el, idx = packet->index; > > >> unsigned long long payload = packet->payload; > > >> const char *name = arm_spe_pkt_name(packet->type); > > >> + size_t blen = buf_len; > > >> + int err = 0; > > >> > > >> switch (packet->type) { > > >> case ARM_SPE_BAD: > > >> case ARM_SPE_PAD: > > >> case ARM_SPE_END: > > >> - return snprintf(buf, buf_len, "%s", name); > > >> - case ARM_SPE_EVENTS: { > > >> - size_t blen = buf_len; > > >> - > > >> - ret = 0; > > >> - ret = snprintf(buf, buf_len, "EV"); > > >> - buf += ret; > > >> - blen -= ret; > > >> - if (payload & 0x1) { > > >> - ret = snprintf(buf, buf_len, " EXCEPTION-GEN"); > > >> - buf += ret; > > >> - blen -= ret; > > >> - } > > >> - if (payload & 0x2) { > > >> - ret = snprintf(buf, buf_len, " RETIRED"); > > >> - buf += ret; > > >> - blen -= ret; > > >> - } > > >> - if (payload & 0x4) { > > >> - ret = snprintf(buf, buf_len, " L1D-ACCESS"); > > >> - buf += ret; > > >> - blen -= ret; > > >> - } > > >> - if (payload & 0x8) { > > >> - ret = snprintf(buf, buf_len, " L1D-REFILL"); > > >> - buf += ret; > > >> - blen -= ret; > > >> - } > > >> - if (payload & 0x10) { > > >> - ret = snprintf(buf, buf_len, " TLB-ACCESS"); > > >> - buf += ret; > > >> - blen -= ret; > > >> - } > > >> - if (payload & 0x20) { > > >> - ret = snprintf(buf, buf_len, " TLB-REFILL"); > > >> - buf += ret; > > >> - blen -= ret; > > >> - } > > >> - if (payload & 0x40) { > > >> - ret = snprintf(buf, buf_len, " NOT-TAKEN"); > > >> - buf += ret; > > >> - blen -= ret; > > >> - } > > >> - if (payload & 0x80) { > > >> - ret = snprintf(buf, buf_len, " MISPRED"); > > >> - buf += ret; > > >> - blen -= ret; > > >> - } > > >> + return arm_spe_pkt_snprintf(&err, &buf, &blen, "%s", name); > > >> + case ARM_SPE_EVENTS: > > >> + ret = arm_spe_pkt_snprintf(&err, &buf, &blen, "EV"); > > >> + > > >> + if (payload & 0x1) > > >> + ret = arm_spe_pkt_snprintf(&err, &buf, &blen, " EXCEPTION-GEN"); > > > > > > Isn't this 'ret +=' ? Otherwise if any of these arm_spe_pkt_snprintf() > > > calls are made the previous 'ret' value is simply discarded. Can you > > > clarify this? > > > > ret is the same as err. If err is negative (from previous calls), we > > return that straight away, so it does nothing but propagating the error. > > Usually the return of a snprintf is used to account for buffer space, ok > I'll have to read it, which I shouldn't as snprintf has a well defined > meaning... > > Ok, now that I look at it, I realize it is not a snprintf() routine, but > something with different semantics, that will look at a pointer to an > integer and then do nothing if it comes with some error, etc, confusing > :-/ Would you be happier if the function were renamed? Originally we were aiming for snprintf() semantics, but this still spawns a lot of boilerplate code and encourages mistakes in the local caller here -- hence the current sticky error approach. So maybe the name should now be less "snprintf"-like. Cheers ---Dave