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 4/8] printk: add type-printing %pT format specifier which uses BTF
Date: Tue, 23 Jun 2020 15:40:12 +0300 [thread overview]
Message-ID: <20200623124012.GV2428291@smile.fi.intel.com> (raw)
In-Reply-To: <1592914031-31049-5-git-send-email-alan.maguire@oracle.com>
On Tue, Jun 23, 2020 at 01:07:07PM +0100, Alan Maguire wrote:
> printk supports multiple pointer object type specifiers (printing
> netdev features etc). Extend this support using BTF to cover
> arbitrary types.
Is there any plans to cover (all?) existing %p extensions?
> "%pT"
One letter namespace is quite busy area. Perhaps %pOT ?
> specifies the typed format, and the pointer
> argument is a "struct btf_ptr *" where struct btf_ptr is as follows:
>
> struct btf_ptr {
> void *ptr;
> const char *type;
> u32 id;
> };
>
> Either the "type" string ("struct sk_buff") or the BTF "id" can be
> used to identify the type to use in displaying the associated "ptr"
> value. A convenience function to create and point at the struct
> is provided:
>
> printk(KERN_INFO "%pT", BTF_PTR_TYPE(skb, struct sk_buff));
>
> When invoked, BTF information is used to traverse the sk_buff *
> and display it. Support is present for structs, unions, enums,
> typedefs and core types (though in the latter case there's not
> much value in using this feature of course).
>
> Default output is indented, but compact output can be specified
> via the 'c' option. Type names/member values can be suppressed
> using the 'N' option. Zero values are not displayed by default
> but can be using the '0' option. Pointer values are obfuscated
> unless the 'x' option is specified. As an example:
>
> struct sk_buff *skb = alloc_skb(64, GFP_KERNEL);
> pr_info("%pT", BTF_PTR_TYPE(skb, struct sk_buff));
>
> ...gives us:
>
> (struct sk_buff){
> .transport_header = (__u16)65535,
> .mac_header = (__u16)65535,
> .end = (sk_buff_data_t)192,
> .head = (unsigned char *)0x000000006b71155a,
> .data = (unsigned char *)0x000000006b71155a,
> .truesize = (unsigned int)768,
> .users = (refcount_t){
> .refs = (atomic_t){
> .counter = (int)1,
> },
> },
> .extensions = (struct skb_ext *)0x00000000f486a130,
> }
I don't see how it looks on a real console when kernel dumps something.
Care to provide? These examples better to have documented.
> printk output is truncated at 1024 bytes. For cases where overflow
> is likely, the compact/no type names display modes may be used.
How * is handled? (I mean %*pOT case)
...
> +#define BTF_PTR_TYPE(ptrval, typeval) \
> + (&((struct btf_ptr){.ptr = ptrval, .type = #typeval}))
> +
> +#define BTF_PTR_ID(ptrval, idval) \
> + (&((struct btf_ptr){.ptr = ptrval, .id = idval}))
Wouldn't be better if these will leave in its own (linker) section?
...
> +static noinline_for_stack
> +char *btf_string(char *buf, char *end, void *ptr, struct printf_spec spec,
> + const char *fmt)
> +{
> + struct btf_ptr *bp = (struct btf_ptr *)ptr;
Unneeded casting.
> + u8 btf_kind = BTF_KIND_TYPEDEF;
> + const struct btf_type *t;
> + const struct btf *btf;
> + char *buf_start = buf;
> + const char *btf_type;
> + u64 flags = 0, mod;
> + s32 btf_id;
> +
> + if (check_pointer(&buf, end, ptr, spec))
> + return buf;
> +
> + if (check_pointer(&buf, end, bp->ptr, spec))
> + return buf;
> + while (isalnum(*fmt)) {
> + mod = btf_modifier_flag(*fmt);
> + if (!mod)
> + break;
> + flags |= mod;
> + fmt++;
> + }
Can't we have explicitly all handled flags here, like other extensions do?
> + btf = bpf_get_btf_vmlinux();
> + if (IS_ERR_OR_NULL(btf))
> + return ptr_to_id(buf, end, bp->ptr, spec);
> +
> + if (bp->type != NULL) {
> + btf_type = bp->type;
> +
> + if (strncmp(bp->type, "struct ", strlen("struct ")) == 0) {
> + btf_kind = BTF_KIND_STRUCT;
> + btf_type += strlen("struct ");
> + } else if (strncmp(btf_type, "union ", strlen("union ")) == 0) {
> + btf_kind = BTF_KIND_UNION;
> + btf_type += strlen("union ");
> + } else if (strncmp(btf_type, "enum ", strlen("enum ")) == 0) {
> + btf_kind = BTF_KIND_ENUM;
> + btf_type += strlen("enum ");
> + }
Can't you provide a simple structure and do this in a loop?
Or even something like match_[partial]string() to implement?
> + if (strlen(btf_type) == 0)
Interesting way of checking btf_type == '\0'.
> + return ptr_to_id(buf, end, bp->ptr, spec);
> +
> + /*
> + * Assume type specified is a typedef as there's not much
> + * benefit in specifying int types other than wasting time
> + * on BTF lookups; we optimize for the most useful path.
> + *
> + * Fall back to BTF_KIND_INT if this fails.
> + */
> + btf_id = btf_find_by_name_kind(btf, btf_type, btf_kind);
> + if (btf_id < 0)
> + btf_id = btf_find_by_name_kind(btf, btf_type,
> + BTF_KIND_INT);
> + } else if (bp->id > 0)
> + btf_id = bp->id;
> + else
> + return ptr_to_id(buf, end, bp->ptr, spec);
> +
> + if (btf_id > 0)
> + t = btf_type_by_id(btf, btf_id);
> + if (btf_id <= 0 || !t)
> + return ptr_to_id(buf, end, bp->ptr, spec);
This can be easily incorporated in previous conditional tree.
> + buf += btf_type_snprintf_show(btf, btf_id, bp->ptr, buf,
> + end - buf_start, flags);
> +
> + return widen_string(buf, buf - buf_start, end, spec);
> +}
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2020-06-23 12:40 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 [this message]
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
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=20200623124012.GV2428291@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).