linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: ast@kernel.org, daniel@iogearbox.net, yhs@fb.com, andriin@fb.com,
	arnaldo.melo@gmail.com, kafai@fb.com, songliubraving@fb.com,
	john.fastabend@gmail.com, kpsingh@chromium.org,
	linux@rasmusvillemoes.dk, joe@perches.com, pmladek@suse.com,
	rostedt@goodmis.org, sergey.senozhatsky@gmail.com,
	corbet@lwn.net, bpf@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v3 bpf-next 6/8] printk: extend test_printf to test %pT BTF-based format specifier
Date: Tue, 23 Jun 2020 16:02:16 +0300	[thread overview]
Message-ID: <20200623130216.GW2428291@smile.fi.intel.com> (raw)
In-Reply-To: <1592914031-31049-7-git-send-email-alan.maguire@oracle.com>

On Tue, Jun 23, 2020 at 01:07:09PM +0100, Alan Maguire wrote:
> Add tests to verify basic type display and to iterate through all
> enums, structs, unions and typedefs ensuring expected behaviour
> occurs.  Since test_printf can be built as a module we need to
> export a BTF kind iterator function to allow us to iterate over
> all names of a particular BTF kind.
> 
> These changes add up to approximately 20,000 new tests covering
> all enum, struct, union and typedefs in vmlinux BTF.
> 
> Individual tests are also added for int, char, struct, enum
> and typedefs which verify output is as expected.

...

>  #include <linux/mm.h>
>  
>  #include <linux/property.h>

+ blank line, you see, headers are grouped.

> +#include <linux/bpf.h>
> +#include <linux/btf.h>
> +#include <linux/skbuff.h>

> +#define	__TEST_BTF(fmt, type, ptr, expected)				       \
> +	test(expected, "%pT"fmt, ptr)
> +
> +#define TEST_BTF_C(type, var, ...)					       \
> +	do {								       \
> +		type var = __VA_ARGS__;					       \
> +		struct btf_ptr *ptr = BTF_PTR_TYPE(&var, type);		       \

> +		pr_debug("type %s: %pTc", #type, ptr);			       \

Hmm... Can't we modify test() (or underneath macros / functions) to do this?

> +		__TEST_BTF("c", type, ptr, "(" #type ")" #__VA_ARGS__);	       \
> +	} while (0)
> +
> +#define TEST_BTF(fmt, type, var, expected, ...)				       \
> +	do {								       \
> +		type var = __VA_ARGS__;					       \
> +		struct btf_ptr *ptr = BTF_PTR_TYPE(&var, type);		       \
> +		pr_debug("type %s: %pT"fmt, #type, ptr);		       \
> +		__TEST_BTF(fmt, type, ptr, expected);			       \
> +	} while (0)

...

> +static void __init
> +btf_print_kind(u8 kind, const char *kind_name, u64 fillval)
> +{

> +	const char *fmt1 = "%pT", *fmt2 = "%pTN", *fmt3 = "%pT0";

This is hard to read. Provide a simple data structure or an array.

> +	const char *name, *fmt = fmt1;
> +	int i, res1, res2, res3, res4;
> +	char type_name[256];
> +	char *buf, *buf2;
> +	u8 *dummy_data;
> +	s32 id = 0;
> +
> +	dummy_data = kzalloc(BTF_MAX_DATA_SIZE, GFP_KERNEL);

check?

> +	/* fill our dummy data with supplied fillval. */
> +	for (i = 0; i < BTF_MAX_DATA_SIZE; i++)
> +		dummy_data[i] = fillval;

> +	buf = kzalloc(BTF_MAX_DATA_SIZE, GFP_KERNEL);
> +	buf2 = kzalloc(BTF_MAX_DATA_SIZE, GFP_KERNEL);

Ditto.

> +	for (;;) {
> +		name = btf_vmlinux_next_type_name(kind, &id);
> +		if (!name)
> +			break;
> +
> +		total_tests++;
> +
> +		snprintf(type_name, sizeof(type_name), "%s%s",
> +			 kind_name, name);
> +
> +		res1 = snprintf(buf, BTF_MAX_DATA_SIZE, fmt1,
> +				BTF_PTR_TYPE(dummy_data, type_name));
> +		res2 = snprintf(buf, 0, fmt1,
> +				BTF_PTR_TYPE(dummy_data, type_name));
> +		res3 = snprintf(buf, BTF_MAX_DATA_SIZE, fmt2,
> +				BTF_PTR_TYPE(dummy_data, type_name));
> +		res4 = snprintf(buf, BTF_MAX_DATA_SIZE, fmt3,
> +				BTF_PTR_TYPE(dummy_data, type_name));
> +
> +		(void) snprintf(buf, BTF_MAX_DATA_SIZE, "%pT",
> +				BTF_PTR_TYPE(dummy_data, type_name));
> +		(void) snprintf(buf2, BTF_MAX_DATA_SIZE, "%pT",
> +				BTF_PTR_TYPE(dummy_data, type_name));
> +
> +		/*
> +		 * Ensure return value is > 0 and identical irrespective
> +		 * of whether we pass in a big enough buffer;
> +		 * also ensure that printing names always results in as
> +		 * long/longer buffer length.
> +		 */
> +		if (res1 <= 0 || res2 <= 0 || res3 <= 0 || res4 <= 0) {
> +			if (res3 <= 0)
> +				fmt = fmt2;
> +			if (res4 <= 0)
> +				fmt = fmt3;

> +			pr_warn("snprintf(%s%s); %d <= 0 (fmt %s)",
> +				kind_name, name,
> +				res1 <= 0 ? res1 : res2 <= 0 ? res2 :
> +				res3 <= 0 ? res3 : res4, fmt);
> +			failed_tests++;

For these kind of prints you can use a new macro, right?

> +		} else if (res1 != res2) {

> +			pr_warn("snprintf(%s%s): %d (to buf) != %d (no buf)",
> +				kind_name, name, res1, res2);
> +			failed_tests++;

Ditto.

> +		} else if (res3 > res2) {

> +			pr_warn("snprintf(%s%s); %d (no names) > %d (names)",
> +				kind_name, name, res3, res2);
> +			failed_tests++;

Ditto.

> +		} else if (strcmp(buf, buf2) != 0) {

> +			/* Safe and unsafe buffers should match. */
> +			pr_warn("snprintf(%s%s); safe != unsafe",
> +				kind_name, name);
> +			pr_warn("safe: %s", buf);
> +			pr_warn("unsafe: %s", buf2);
> +			failed_tests++;

Perhaps also makes sense in a macro then somebody may reuse in the future.
That said, the first warning here somehow cryptic, please be more human friendly.

> +		} else {
> +			pr_debug("Printed %s%s (%d bytes)",
> +				 kind_name, name, res1);
> +		}
> +	}
> +	kfree(dummy_data);
> +	kfree(buf);
> +	kfree(buf2);
> +}

...

> +	TEST_BTF_C(int, testint, 1234);
> +	TEST_BTF("cN", int, testint, "1234", 1234);

We use small letter macros in other cases. So can you?


...

> +	/* typedef struct */
> +	TEST_BTF_C(atomic_t, testtype, {.counter = (int)1,});
> +	TEST_BTF("cN", atomic_t, testtype, "{1,}", {.counter = 1,});
> +	/* typedef with 0 value should be printed at toplevel */
> +	TEST_BTF("c", atomic_t, testtype, "(atomic_t){}", {.counter = 0,});
> +	TEST_BTF("cN", atomic_t, testtype, "{}", {.counter = 0,});
> +	TEST_BTF("c0", atomic_t, testtype, "(atomic_t){.counter = (int)0,}",
> +		 {.counter = 0,});
> +	TEST_BTF("cN0", atomic_t, testtype, "{0,}", {.counter = 0,});

For one type, provide a data structure filled with test data and use loops.
Same for all similar places over the code.

...

> +	u64 fillvals[] = { 0x0, 0xffffffffffffffff, 0x0123456789abcdef };

U64_MAX?

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2020-06-23 13:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-23 12:07 [PATCH v3 bpf-next 0/8] bpf, printk: add BTF-based type printing Alan Maguire
2020-06-23 12:07 ` [PATCH v3 bpf-next 1/8] bpf: provide function to get vmlinux BTF information Alan Maguire
2020-06-23 12:07 ` [PATCH v3 bpf-next 2/8] bpf: move to generic BTF show support, apply it to seq files/strings Alan Maguire
2020-06-23 12:07 ` [PATCH v3 bpf-next 3/8] checkpatch: add new BTF pointer format specifier Alan Maguire
2020-06-23 12:07 ` [PATCH v3 bpf-next 4/8] printk: add type-printing %pT format specifier which uses BTF Alan Maguire
2020-06-23 12:40   ` Andy Shevchenko
2020-06-23 13:11   ` Rasmus Villemoes
2020-06-26 10:15   ` Petr Mladek
2020-06-26 11:37     ` Alan Maguire
2020-06-29  9:43       ` Petr Mladek
2020-06-23 12:07 ` [PATCH v3 bpf-next 5/8] printk: initialize vmlinux BTF outside of printk in late_initcall() Alan Maguire
2020-06-23 12:07 ` [PATCH v3 bpf-next 6/8] printk: extend test_printf to test %pT BTF-based format specifier Alan Maguire
2020-06-23 13:02   ` Andy Shevchenko [this message]
2020-06-23 12:07 ` [PATCH v3 bpf-next 7/8] bpf: add support for %pT format specifier for bpf_trace_printk() helper Alan Maguire
2020-06-23 13:04   ` Andy Shevchenko
2020-06-23 12:07 ` [PATCH v3 bpf-next 8/8] bpf/selftests: add tests for %pT format specifier Alan Maguire
2020-06-23 18:16   ` Andrii Nakryiko
2020-06-30 11:31 ` [PATCH v3 bpf-next 0/8] bpf, printk: add BTF-based type printing Sergey Senozhatsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200623130216.GW2428291@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=alan.maguire@oracle.com \
    --cc=andriin@fb.com \
    --cc=arnaldo.melo@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=joe@perches.com \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@chromium.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=netdev@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).