Re: [PATCH v8 06/22] perf arm-spe: Refactor printing string to buffer

[Dave Martin <Dave.Martin@arm.com>]

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 <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
> :-/

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