On Tue, Dec 22, 2020 at 09:17:41PM +0100, Florent Revest wrote:
> On Tue, Dec 22, 2020 at 3:18 PM Christoph Hellwig wrote:
> >
> > FYI, there is a reason why kallsyms_lookup is not exported any more.
> > I don't think adding that back through a backdoor is a good idea.
>
> Did you maybe mean
On Fri, Dec 18, 2020 at 4:20 AM Alexei Starovoitov
wrote:
> As far as 6 arg issue:
> long bpf_snprintf(const char *out, u32 out_size,
> const char *fmt, u32 fmt_size,
> const void *data, u32 data_len);
> Yeah. It won't work as-is, but fmt_size is unnecessary
On Fri, Dec 18, 2020 at 9:47 PM Andrii Nakryiko
wrote:
>
> On Fri, Dec 18, 2020 at 12:36 PM Alexei Starovoitov
> wrote:
> >
> > On Fri, Dec 18, 2020 at 10:53:57AM -0800, Andrii Nakryiko wrote:
> > > On Thu, Dec 17, 2020 at 7:20 PM Alexei Starovoitov
> > > wrote:
> > > >
> > > > On Thu, Dec 17,
On Tue, Dec 22, 2020 at 3:18 PM Christoph Hellwig wrote:
>
> FYI, there is a reason why kallsyms_lookup is not exported any more.
> I don't think adding that back through a backdoor is a good idea.
Did you maybe mean kallsyms_lookup_name (the one that looks an address
up based on a symbol name)
FYI, there is a reason why kallsyms_lookup is not exported any more.
I don't think adding that back through a backdoor is a good idea.
On Fri, Dec 18, 2020 at 12:36 PM Alexei Starovoitov
wrote:
>
> On Fri, Dec 18, 2020 at 10:53:57AM -0800, Andrii Nakryiko wrote:
> > On Thu, Dec 17, 2020 at 7:20 PM Alexei Starovoitov
> > wrote:
> > >
> > > On Thu, Dec 17, 2020 at 09:26:09AM -0800, Yonghong Song wrote:
> > > >
> > > >
> > > > On
On Fri, Dec 18, 2020 at 10:53:57AM -0800, Andrii Nakryiko wrote:
> On Thu, Dec 17, 2020 at 7:20 PM Alexei Starovoitov
> wrote:
> >
> > On Thu, Dec 17, 2020 at 09:26:09AM -0800, Yonghong Song wrote:
> > >
> > >
> > > On 12/17/20 7:31 AM, Florent Revest wrote:
> > > > On Mon, Dec 14, 2020 at 7:47
On Thu, Dec 17, 2020 at 7:20 PM Alexei Starovoitov
wrote:
>
> On Thu, Dec 17, 2020 at 09:26:09AM -0800, Yonghong Song wrote:
> >
> >
> > On 12/17/20 7:31 AM, Florent Revest wrote:
> > > On Mon, Dec 14, 2020 at 7:47 AM Yonghong Song wrote:
> > > > On 12/11/20 6:40 AM, Florent Revest wrote:
> > >
On 12/17/20 7:20 PM, Alexei Starovoitov wrote:
On Thu, Dec 17, 2020 at 09:26:09AM -0800, Yonghong Song wrote:
On 12/17/20 7:31 AM, Florent Revest wrote:
On Mon, Dec 14, 2020 at 7:47 AM Yonghong Song wrote:
On 12/11/20 6:40 AM, Florent Revest wrote:
On Wed, Dec 2, 2020 at 10:18 PM
On Thu, Dec 17, 2020 at 09:26:09AM -0800, Yonghong Song wrote:
>
>
> On 12/17/20 7:31 AM, Florent Revest wrote:
> > On Mon, Dec 14, 2020 at 7:47 AM Yonghong Song wrote:
> > > On 12/11/20 6:40 AM, Florent Revest wrote:
> > > > On Wed, Dec 2, 2020 at 10:18 PM Alexei Starovoitov
> > > > wrote:
>
On 12/17/20 7:31 AM, Florent Revest wrote:
On Mon, Dec 14, 2020 at 7:47 AM Yonghong Song wrote:
On 12/11/20 6:40 AM, Florent Revest wrote:
On Wed, Dec 2, 2020 at 10:18 PM Alexei Starovoitov
wrote:
I still think that adopting printk/vsnprintf for this instead of
reinventing the wheel
is
On Mon, Dec 14, 2020 at 7:47 AM Yonghong Song wrote:
> On 12/11/20 6:40 AM, Florent Revest wrote:
> > On Wed, Dec 2, 2020 at 10:18 PM Alexei Starovoitov
> > wrote:
> >> I still think that adopting printk/vsnprintf for this instead of
> >> reinventing the wheel
> >> is more flexible and easier to
On 12/11/20 6:40 AM, Florent Revest wrote:
On Wed, Dec 2, 2020 at 10:18 PM Alexei Starovoitov
wrote:
I still think that adopting printk/vsnprintf for this instead of
reinventing the wheel
is more flexible and easier to maintain long term.
Almost the same layout can be done with vsnprintf
On Wed, Dec 2, 2020 at 10:18 PM Alexei Starovoitov
wrote:
> I still think that adopting printk/vsnprintf for this instead of
> reinventing the wheel
> is more flexible and easier to maintain long term.
> Almost the same layout can be done with vsnprintf
> with exception of \0 char.
> More
On Wed, Dec 2, 2020 at 12:32 PM Florent Revest wrote:
>
> On Tue, 2020-12-01 at 16:55 -0800, Andrii Nakryiko wrote:
> > On Fri, Nov 27, 2020 at 8:09 AM Yonghong Song wrote:
> > >
> > >
> > > On 11/27/20 3:20 AM, KP Singh wrote:
> > > > On Fri, Nov 27, 2020 at 8:35 AM Yonghong Song wrote:
> > >
On Tue, 2020-12-01 at 16:55 -0800, Andrii Nakryiko wrote:
> On Fri, Nov 27, 2020 at 8:09 AM Yonghong Song wrote:
> >
> >
> > On 11/27/20 3:20 AM, KP Singh wrote:
> > > On Fri, Nov 27, 2020 at 8:35 AM Yonghong Song wrote:
> > > >
> > > > In this case, module name may be truncated and user did
On Fri, Nov 27, 2020 at 8:09 AM Yonghong Song wrote:
>
>
>
> On 11/27/20 3:20 AM, KP Singh wrote:
> > On Fri, Nov 27, 2020 at 8:35 AM Yonghong Song wrote:
> >>
> >>
> >>
> >> On 11/26/20 8:57 AM, Florent Revest wrote:
> >>> This helper exposes the kallsyms_lookup function to eBPF tracing
> >>>
On Fri, Nov 27, 2020 at 3:20 AM KP Singh wrote:
>
> On Fri, Nov 27, 2020 at 8:35 AM Yonghong Song wrote:
> >
> >
> >
> > On 11/26/20 8:57 AM, Florent Revest wrote:
> > > This helper exposes the kallsyms_lookup function to eBPF tracing
> > > programs. This can be used to retrieve the name of the
On Mon, 2020-11-30 at 18:41 -0800, Alexei Starovoitov wrote:
> On Mon, Nov 30, 2020 at 05:23:22PM +0100, Florent Revest wrote:
> > On Sat, 2020-11-28 at 17:07 -0800, Alexei Starovoitov wrote:
> > > Looks like debug-only helper.
> > > I cannot think of a way to use in production code.
> > > What
On Mon, Nov 30, 2020 at 05:23:22PM +0100, Florent Revest wrote:
> On Sat, 2020-11-28 at 17:07 -0800, Alexei Starovoitov wrote:
> > On Thu, Nov 26, 2020 at 05:57:47PM +0100, Florent Revest wrote:
> > > This helper exposes the kallsyms_lookup function to eBPF tracing
> > > programs. This can be used
On Sat, 2020-11-28 at 17:07 -0800, Alexei Starovoitov wrote:
> On Thu, Nov 26, 2020 at 05:57:47PM +0100, Florent Revest wrote:
> > This helper exposes the kallsyms_lookup function to eBPF tracing
> > programs. This can be used to retrieve the name of the symbol at an
> > address. For example, when
On Thu, Nov 26, 2020 at 05:57:47PM +0100, Florent Revest wrote:
> This helper exposes the kallsyms_lookup function to eBPF tracing
> programs. This can be used to retrieve the name of the symbol at an
> address. For example, when hooking into nf_register_net_hook, one can
> audit the name of the
Hi Florent,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bpf-next/master]
url:
https://github.com/0day-ci/linux/commits/Florent-Revest/bpf-Add-a-bpf_kallsyms_lookup-helper/20201127-010044
base:
On 11/27/20 3:20 AM, KP Singh wrote:
On Fri, Nov 27, 2020 at 8:35 AM Yonghong Song wrote:
On 11/26/20 8:57 AM, Florent Revest wrote:
This helper exposes the kallsyms_lookup function to eBPF tracing
programs. This can be used to retrieve the name of the symbol at an
address. For example,
On Fri, Nov 27, 2020 at 8:35 AM Yonghong Song wrote:
>
>
>
> On 11/26/20 8:57 AM, Florent Revest wrote:
> > This helper exposes the kallsyms_lookup function to eBPF tracing
> > programs. This can be used to retrieve the name of the symbol at an
> > address. For example, when hooking into
On Fri, 2020-11-27 at 10:25 +0100, Florent Revest wrote:
> I prefer Yongonhong's suggestion of having two helpers.
Argh! I hit enter too fast! Yonghong*, sorry :|
On Fri, 2020-11-27 at 03:32 +0100, KP Singh wrote:
> > + ret = strlen(name) + 1;
> > + if (symbol_size) {
> > + strncpy(symbol, name, symbol_size);
> > + symbol[symbol_size - 1] = '\0';
> > + }
> > +
> > + if (modname && module_size) {
> > +
On Thu, 2020-11-26 at 23:35 -0800, Yonghong Song wrote:
> On 11/26/20 8:57 AM, Florent Revest wrote:
> > +BPF_CALL_5(bpf_kallsyms_lookup, u64, address, char *, symbol, u32,
> > symbol_size,
> > + char *, module, u32, module_size)
> > +{
> > + char buffer[KSYM_SYMBOL_LEN];
> > + unsigned
On 11/26/20 8:57 AM, Florent Revest wrote:
This helper exposes the kallsyms_lookup function to eBPF tracing
programs. This can be used to retrieve the name of the symbol at an
address. For example, when hooking into nf_register_net_hook, one can
audit the name of the registered netfilter hook
[...]
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index c3458ec1f30a..670998635eac 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -3817,6 +3817,21 @@ union bpf_attr {
> * The **hash_algo** is returned on success,
> *
This helper exposes the kallsyms_lookup function to eBPF tracing
programs. This can be used to retrieve the name of the symbol at an
address. For example, when hooking into nf_register_net_hook, one can
audit the name of the registered netfilter hook and potentially also
the name of the module in
31 matches
Mail list logo
