This patch set adds new libbpf APIs and their bpftool integration that allows
to perform static linking of BPF object files. Currently no extern resolution
across object files is performed. This is going to be the focus of the follow
up patches. But, given amount of code and logic necessary to perf
Hello:
This series was applied to bpf/bpf-next.git (refs/heads/master):
On Wed, 4 Nov 2020 20:33:50 -0800 you wrote:
> This patch set adds support for generating and deduplicating split BTF. This
> is an enhancement to the BTF, which allows to designate one BTF as the "base
> BTF" (e.g., vmlinux
On Thu, Nov 5, 2020 at 11:38 AM Saeed Mahameed wrote:
>
> On Thu, 2020-11-05 at 11:16 -0800, Andrii Nakryiko wrote:
> > > > This split approach is necessary if we are to have a reasonably-
> > > > sized kernel
> > > > module BTFs. By deduping each kernel module's BTF individually,
> > > > resultin
On Thu, 2020-11-05 at 11:16 -0800, Andrii Nakryiko wrote:
> > > This split approach is necessary if we are to have a reasonably-
> > > sized kernel
> > > module BTFs. By deduping each kernel module's BTF individually,
> > > resulting
> > > module BTFs contain copies of a lot of kernel types that ar
On Thu, Nov 5, 2020 at 1:53 AM Jesper Dangaard Brouer wrote:
>
> On Wed, 4 Nov 2020 20:33:50 -0800
> Andrii Nakryiko wrote:
>
> > This patch set adds support for generating and deduplicating split BTF. This
> > is an enhancement to the BTF, which allows to designate one BTF as the "base
> > BTF"
On Wed, 4 Nov 2020 20:33:50 -0800
Andrii Nakryiko wrote:
> This patch set adds support for generating and deduplicating split BTF. This
> is an enhancement to the BTF, which allows to designate one BTF as the "base
> BTF" (e.g., vmlinux BTF), and one or more other BTFs as "split BTF" (e.g.,
> ker
This patch set adds support for generating and deduplicating split BTF. This
is an enhancement to the BTF, which allows to designate one BTF as the "base
BTF" (e.g., vmlinux BTF), and one or more other BTFs as "split BTF" (e.g.,
kernel module BTF), which are building upon and extending base BTF wit
On Tue, Apr 28, 2020 at 06:21:00PM -0700, Andrii Nakryiko wrote:
> Add necessary infra to build selftests with ASAN (or any other sanitizer). Fix
> a bunch of found memory leaks and other memory access issues.
>
> v1->v2:
> - don't add ASAN flavor, but allow extra flags for build (Alexei);
> -
Add necessary infra to build selftests with ASAN (or any other sanitizer). Fix
a bunch of found memory leaks and other memory access issues.
v1->v2:
- don't add ASAN flavor, but allow extra flags for build (Alexei);
- fix few more found issues, which somehow were missed first time.
Andrii Nak
On Fri, Jun 21, 2019 at 10:56 AM Andrii Nakryiko
wrote:
>
> On Fri, Jun 21, 2019 at 3:29 AM Lorenz Bauer wrote:
> >
> > On Fri, 21 Jun 2019 at 05:20, Andrii Nakryiko
> > wrote:
> > >
> > > On Thu, Jun 20, 2019 at 7:49 AM Lorenz Bauer wrote:
> > > >
> > > > On Tue, 18 Jun 2019 at 22:37, Andrii
On Fri, Jun 21, 2019 at 3:29 AM Lorenz Bauer wrote:
>
> On Fri, 21 Jun 2019 at 05:20, Andrii Nakryiko
> wrote:
> >
> > On Thu, Jun 20, 2019 at 7:49 AM Lorenz Bauer wrote:
> > >
> > > On Tue, 18 Jun 2019 at 22:37, Andrii Nakryiko
> > > wrote:
> > >
> > > > > I would just drop the object-scope
On Fri, 21 Jun 2019 at 05:20, Andrii Nakryiko wrote:
>
> On Thu, Jun 20, 2019 at 7:49 AM Lorenz Bauer wrote:
> >
> > On Tue, 18 Jun 2019 at 22:37, Andrii Nakryiko
> > wrote:
> >
> > > > I would just drop the object-scope pinning. We avoided using it and I'm
> > > > not
> > > > aware if anyone
On Thu, Jun 20, 2019 at 7:49 AM Lorenz Bauer wrote:
>
> On Tue, 18 Jun 2019 at 22:37, Andrii Nakryiko
> wrote:
>
> > > I would just drop the object-scope pinning. We avoided using it and I'm
> > > not
> > > aware if anyone else make use. It also has the ugly side-effect that this
> > > relies o
On Tue, 18 Jun 2019 at 22:37, Andrii Nakryiko wrote:
> > I would just drop the object-scope pinning. We avoided using it and I'm not
> > aware if anyone else make use. It also has the ugly side-effect that this
> > relies on AF_ALG which e.g. on some cloud provider shipped kernels is
> > disable
On Mon, Jun 17, 2019 at 2:17 PM Daniel Borkmann wrote:
>
> On 06/17/2019 09:26 PM, Andrii Nakryiko wrote:
> > This patch set implements initial version (as discussed at LSF/MM2019
> > conference) of a new way to specify BPF maps, relying on BTF type
> > information,
> > which allows for easy exte
On 06/17/2019 11:17 PM, Daniel Borkmann wrote:
> On 06/17/2019 09:26 PM, Andrii Nakryiko wrote:
>> This patch set implements initial version (as discussed at LSF/MM2019
>> conference) of a new way to specify BPF maps, relying on BTF type
>> information,
>> which allows for easy extensibility, pres
On 06/17/2019 09:26 PM, Andrii Nakryiko wrote:
> This patch set implements initial version (as discussed at LSF/MM2019
> conference) of a new way to specify BPF maps, relying on BTF type information,
> which allows for easy extensibility, preserving forward and backward
> compatibility. See details
This patch set implements initial version (as discussed at LSF/MM2019
conference) of a new way to specify BPF maps, relying on BTF type information,
which allows for easy extensibility, preserving forward and backward
compatibility. See details and examples in description for patch #6.
[0] contain
This patchset adds support for:
- direct R or R/W access to many tcp_sock fields
- passing up to 4 arguments to sock_ops BPF functions
- tcp_sock field bpf_sock_ops_flags for controlling callbacks
- optionally calling sock_ops BPF program when RTO fires
- optionally calling sock_ops BPF program wh
19 matches
Mail list logo