lkml.org 
[lkml]   [2020]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH v8 06/22] perf arm-spe: Refactor printing string to buffer
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 <Dave.Martin@arm.com>
> >> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> >> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> >> ---
> >> .../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 <endian.h>
> >> #include <byteswap.h>
> >> #include <linux/bitops.h>
> >> +#include <stdarg.h>
> >>
> >> #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
:-/

> That redundancy gets cleaned up in the next patch.

I'll fixup the bitops part and try to continue.

- Arnaldo

> This patch split is somewhat cumbersome, but was done to simplify review
> (originally 06 and 07 were one patch). The combined patch made it hard
> to match the individual changes. If you feel unsure about it, or you
> feel it looks better, you could also merge both 06/22 and 07/22 into a
> single patch.
>
> Hope that helps.

\
 
 \ /
  Last update: 2020-11-11 18:40    [W:0.143 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site