[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAADnVQ+HFjn9+cXM9PRLEsopiEVfJ5vjVDBNrWUjZT8P8_kiVA@mail.gmail.com>
Date: Wed, 1 Jul 2020 08:34:09 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Song Liu <songliubraving@...com>
Cc: bpf <bpf@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Kernel Team <kernel-team@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...omium.org>
Subject: Re: [PATCH v5 bpf-next 0/4] bpf: introduce bpf_get_task_stack()
On Mon, Jun 29, 2020 at 11:28 PM Song Liu <songliubraving@...com> wrote:
>
> This set introduces a new helper bpf_get_task_stack(). The primary use case
> is to dump all /proc/*/stack to seq_file via bpf_iter__task.
>
> A few different approaches have been explored and compared:
>
> 1. A simple wrapper around stack_trace_save_tsk(), as v1 [1].
>
> This approach introduces new syntax, which is different to existing
> helper bpf_get_stack(). Therefore, this is not ideal.
>
> 2. Extend get_perf_callchain() to support "task" as argument.
>
> This approach reuses most of bpf_get_stack(). However, extending
> get_perf_callchain() requires non-trivial changes to architecture
> specific code. Which is error prone.
>
> 3. Current (v2) approach, leverages most of existing bpf_get_stack(), and
> uses stack_trace_save_tsk() to handle architecture specific logic.
>
> [1] https://lore.kernel.org/netdev/20200623070802.2310018-1-songliubraving@fb.com/
>
> Changes v4 => v5:
> 1. Rebase and work around git-am issue. (Alexei)
> 2. Update commit log for 4/4. (Yonghong)
Applied. Thanks
I've added /* */ tweak to BPF_FUNC_MAPPER, so we stop having
ongoing merge conflicts and preserve better 'git blame' for helpers.
Powered by blists - more mailing lists