Bug 22330 - bpf: generate printf via event tuples, userspace formatting postprocessing
Summary: bpf: generate printf via event tuples, userspace formatting postprocessing
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: bpf (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Serhei Makarov
URL:
Keywords:
Depends on:
Blocks: 23559 23849 23435 23816
  Show dependency treegraph
 
Reported: 2017-10-20 22:33 UTC by Aaron Merey
Modified: 2019-03-19 21:33 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Merey 2017-10-20 22:33:15 UTC

    
Comment 1 Serhei Makarov 2018-07-05 15:49:13 UTC
This is also relevant because the current trace_printk() mechanism is discouraged on 'production kernels' and will log a prominent notice to that effect to dmesg.
Comment 2 Serhei Makarov 2018-08-20 15:58:21 UTC
As part of the reworking of printf() on stapbpf, large printf() invocations should also be split up into a series of manageable ones. The following example should work:

probe kernel.trace("netif_receive_skb"), kernel.trace("netif_rx"),
  kernel.trace("net_dev_queue"), kernel.trace("napi_gro_receive_entry") {
  printf("vars %s\n", $$vars);
}

Currently it fails with "too many arguments to print (19)".
Comment 3 Serhei Makarov 2018-10-17 21:28:04 UTC
Another reason to rework printf() -- the trace_printk() implementation hardcodes any string operands to 64 bytes:

https://github.com/torvalds/linux/blob/6b2edf27fe26c73cd67b6bf5ffb23dce882e1455/kernel/trace/bpf_trace.c#L226

Prioritizing this PR on account of the 64-byte trace_printk() limitation.
Comment 4 Serhei Makarov 2019-02-28 22:33:57 UTC
Committed an in-progress version of the code to branch stapbpf/pr22330, but there's more work to be done.
Comment 5 Serhei Makarov 2019-03-11 19:41:38 UTC
Pushing further work and fixes to stapbpf/pr22330. The following testcases are currently regressing:

- context-vars3.stp, task1.stp :: tapset function kernel_string() return type is marked string, but the variable it's assigned to remains as pe_unknown. Needs better type inference, probably need to check the format string to determine what to do with them.

- asm_tests involving printf() :: likewise, the embedded-code version of printf() takes pe_unknown args. Need to check the format string.

This does not seem a difficult fix, since the code in regular stap translate.cxx already uses preprocess_print_format() to distinguish what to do with different types of printf arguments. Just need to do the same in stapbpf.
Comment 6 Serhei Makarov 2019-03-12 17:42:53 UTC
One regression remains in string3.stp (which should work now, but doesn't).
There is an error in how stack space is allocated for printf args, which leads to earlier '%s' arguments being overwritten by later '%s' arguments but not others.
Comment 7 Serhei Makarov 2019-03-12 17:43:24 UTC
Last sentence should read 'overwritten by later %s arguments in some cases but not others'.
Comment 8 Serhei Makarov 2019-03-12 17:54:13 UTC
Worth noting that the argument overwriting only seems to happen in the userspace interpreter.
Comment 9 Serhei Makarov 2019-03-19 21:33:25 UTC
Merged in commit ab7f8b7ea.

Argument overwriting is filed as PR24329.