[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2ad6289d-d454-8dc8-a5f9-7ddddf070dcd@netronome.com>
Date: Thu, 17 Jan 2019 10:06:18 +0000
From: Quentin Monnet <quentin.monnet@...ronome.com>
To: Stanislav Fomichev <sdf@...ichev.me>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
oss-drivers@...ronome.com,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Stanislav Fomichev <sdf@...gle.com>
Subject: Re: [PATCH bpf-next v4 0/9] tools: bpftool: add probes for system and
device
2019-01-16 09:15 UTC-0800 ~ Stanislav Fomichev <sdf@...ichev.me>
> On 01/16, Quentin Monnet wrote:
>> Hi,
>> This set adds a new command to bpftool in order to dump a list of
>> eBPF-related parameters for the system (or for a specific network
>> device) to the console. Once again, this is based on a suggestion from
>> Daniel.
>>
>> At this time, output includes:
>>
>> - Availability of bpf() system call
>> - Availability of bpf() system call for unprivileged users
>> - JIT status (enabled or not, with or without debugging traces)
>> - JIT hardening status
>> - JIT kallsyms exports status
>> - Global memory limit for JIT compiler for unprivileged users
>> - Status of kernel compilation options related to BPF features
>> - Availability of known eBPF program types
>> - Availability of known eBPF map types
>> - Availability of known eBPF helper functions
>>
>> There are three different ways to dump this information at this time:
>>
>> - Plain output dumps probe results in plain text. It is the most
>> flexible options for providing descriptive output to the user, but
>> should not be relied upon for parsing the output.
>> - JSON output is supported.
>> - A third mode, available through the "macros" keyword appended to the
>> command line, dumps some of those parameters (not all) as a series of
>> "#define" directives, that can be included into a C header file for
>> example.
>>
>> Probes for supported program and map types, and supported helpers, are
>> directly added to libbpf, so that other applications (or selftests) can
>> reuse them as necessary.
>>
>> If the user does not have root privileges (or more precisely, the
>> CAP_SYS_ADMIN capability) detection will be erroneous for most
>> parameters. Therefore, forbid non-root users to run the command.
>>
>> v4:
>> - Probe bpf_jit_limit parameter (patch 2).
>> - Probe some additional kernel config options (patch 3).
>> - Minor fixes on patch 6.
> Looks great! For the whole series:
>
> Reviewed-by: Stanislav Fomichev <sdf@...gle.com>
Thanks for the reviews! :)
Powered by blists - more mailing lists