On Mon, Aug 10, 2020 at 06:09:48AM -0700, Jiang Yu wrote:
> skb distinguished by uid can only recorded to user who consume them.
> in many case, skb should been recorded more specific to process who
> consume them. E.g, the unexpected large data traffic of illegal process
> in metered network.
>
> this helper is used in tracing task comm of the sock to which a skb
> belongs.
>
> Signed-off-by: Jiang Yu <jyu.ji...@vivo.com>
> ---
> include/net/sock.h | 1 +
> include/uapi/linux/bpf.h | 1 +
> net/core/filter.c | 32 ++++++++++++++++++++++++++++++++
> net/core/sock.c | 20 ++++++++++++++++++++
> tools/include/uapi/linux/bpf.h | 1 +
> 5 files changed, 55 insertions(+)
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 064637d1ddf6..9c6e8e61940f 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -519,6 +519,7 @@ struct sock {
> #ifdef CONFIG_BPF_SYSCALL
> struct bpf_sk_storage __rcu *sk_bpf_storage;
> #endif
> + char sk_task_com[TASK_COMM_LEN];
One possibility is to use the "sk_bpf_storage" member immediately above
instead of adding "sk_task_com[]".
It is an extensible sk storage for bpf. There are examples in selftests,
e.g tools/testing/selftests/bpf/progs/udp_limits.c which creates sk storage
at socket creation time. Another hook point option could be "connect()"
for tcp, i.e. "cgroup/connect[46]".
Search "BPF_MAP_TYPE_SK_STORAGE" under the selftests/bpf for other examples.
It seems there is already a "bpf_get_current_comm()" helper which
could be used to initialize the task comm string in the bpf sk storage.
btw, bpf-next is still closed.
