Commit 95c9229e replaced the
blk_account_io_completion kprobe with blk_account_io_done. Unfortunately
the req->__data_len field is 0 in blk_account_io_done, therefore we need
to save the __data_len field in blk_start_request

Resolves #3099

Replace kprobe function "blk_account_io_completion" to "blk_account_io_done" for kernel version >= 5.8.0

The kernel function "blk_account_io_completion" is not available anymore as attach point of Kprobe as of kernel version 5.8.0. Therefore, after discussions, we decided to use function "blk_account_io_done" instead in every kprobe attachment to "blk_account_io_completion".

Previously, map.lookup_or_init() may cause unexpected
return from the function when lookup finds no element and
init failed e.g. due to unlikely racy update or
sometimes hash table full.
This has caught surprise from many users. So, the commit
  https://github.com/iovisor/bcc/commit/ba64f031f2435aad5a85f8f37dbbe2a982cbbe6b
attempts to remove the early return in map.lookup_or_init().
But then since NULL pointer could be returned,
user will need to change their bpf program to check return value,
otherwise, verifier will reject the program.

As described in the above, such an API behavior change may cause
verifier failure and reject previously loadable bpf programs.
bcc should try to maintain API stability, esp. to avoid subtle
API behavior change.

This patch propose to restore the behavior of map.lookup_or_init()
and introduce a new one map.lookup_or_try_init(), which will
avoid unexpected return. The name is suggested by Alexei
to reflect that init may fail. map.lookup_or_try_init() will be formally
documented and used in bcc. A warning will be generated if
map.lookup_or_init() is used. Documentation will make it clear
that map.lookup_or_try_init() is preferred over map.lookup_or_init().

```
-bash-4.4$ sudo ./syscount.py
/virtual/main.c:71:11: warning: lookup_or_init() may return from the function, use loopup_or_try_init() instead.
    val = data.lookup_or_init(&key, &zero);
          ^
1 warning generated.
Tracing syscalls, printing top 10... Ctrl+C to quit.
...
```

All uses in examples and tools are converted to use
lookup_or_try_init(). Most tests are converted to use
lookup_or_try_init() too except test_trace_maxactive.py
and test_tracepoint.py to test lookup_or_init()
functionality.

* Allow lookup_or_init to return NULL (rather than just returning from the current function)
* Fixed a couple of bad edits found when running tests. Also fixed a bug in the
test runner. Also fixed a bug in libbcc where the python signature did not match
the actual implementation.

* biosnoop: add -Q for queued time

* biotop: fix PID

Misc fixes on Python tools

* fixed shebangs in tools (and lib)

* fixed shebangs in examples

* do not mangle shebangs in rpm spec

* renamed style-check.sh to c-style-check.sh

* factored out python linter to a separate file

* added shebang validation to the py-style-check

* added shebangs to all python executables

Recent -next kernels don't have blk_start_request() function
anymore. It has been removed in a recent cleanup. bio* tools should be
able to handle the lack of this probe.

* tools: uses 'replace' error handler by default in decode()

Tools might encouter characters from non utf-8 charset (e.g. a file
name). When this happen, it's better to replace the unexpected
character by a question mark than crash the tool when all we do is
to print the string.

* tools: fix a bytes/string issue in attach_perf_event()

Use of this argparse constructor keyword is causing regression
test failures, and its use was nice-to-have - this means the -e
shorthand for --ebpf will be available iff its not been used in
another add_argument call.  Neither -e/--ebpf are advertised in
the usage message anyway.

As discussed in https://github.com/iovisor/bcc/pull/1531


review comments.

Signed-off-by: Nathan Scott <nathans@redhat.com>

Several python tools allow their eBPF code to be printed to
stdout for debugging.  There are other projects that would
like to share these program definitions however, instead of
duplicating code.  Formalise an -e/--ebpf option, and start
using it in several tools (more to come).

Signed-off-by: Nathan Scott <nathans@redhat.com>

This fixes the bcc module and all the affected tools for issues related to string handling in Python 3. Specifically, when passing Python strings to C libraries they are encoded as ASCII, and when constructing Python strings from C strings, they are decoded first.

This commit fixes #888.  The 2 scripts run the same check, and now run
basically the same code to do it.

Tested on 4.10-rc2.