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
next prev parent 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).