lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzZMC4LWpgOMBgKaLAGLPmt4rz0D7_sNC+i=yaVhEtDG9g@mail.gmail.com>
Date:   Mon, 10 Aug 2020 11:43:10 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next 0/5] BPF link force-detach support

On Mon, Aug 10, 2020 at 8:01 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> Andrii Nakryiko <andriin@...com> writes:
>
> > This patch set adds new BPF link operation, LINK_DETACH, allowing processes
> > with BPF link FD to force-detach it from respective BPF hook, similarly how
> > BPF link is auto-detached when such BPF hook (e.g., cgroup, net_device, netns,
> > etc) is removed. This facility allows admin to forcefully undo BPF link
> > attachment, while process that created BPF link in the first place is left
> > intact.
> >
> > Once force-detached, BPF link stays valid in the kernel as long as there is at
> > least one FD open against it. It goes into defunct state, just like
> > auto-detached BPF link.
> >
> > bpftool also got `link detach` command to allow triggering this in
> > non-programmatic fashion.
>
> I know this was already merged, but just wanted to add a belated 'thanks
> for adding this'!
>

You are welcome!

> > Cc: Toke Høiland-Jørgensen <toke@...hat.com>
>
> BTW, I've noticed that you tend to drop Ccs on later versions of your
> patch series (had to go and lookup v2 of this to check that it was in
> fact merged). Is that intentional? :)

Hm.. not sure about whether I tend to do that. But in this it was
intentional and I dropped you from CC because I've seen enough
reminders about your vacation, didn't need more ;)

In general, though, I try to keep CC list short, otherwise vger blocks
my patches. People directly CC'd get them, but they never appear on
bpf@...r mailing list. So it probably happened a few times where I
started off with longer CC and had to drop people from it just to get
my patches into patchworks.

>
> -Toke
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ