From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752275AbbJRU7K (ORCPT ); Sun, 18 Oct 2015 16:59:10 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:33810 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751178AbbJRU6x (ORCPT ); Sun, 18 Oct 2015 16:58:53 -0400 Subject: Re: [PATCH net-next 3/4] bpf: add support for persistent maps/progs To: Daniel Borkmann , "Eric W. Biederman" References: <1445016105.1251655.412231129.6574D430@webmail.messagingengine.com> <5621371C.2000507@plumgrid.com> <56213A61.40509@iogearbox.net> <87d1welkp8.fsf@x220.int.ebiederm.org> <56214FAC.5060704@plumgrid.com> <87y4f2io9l.fsf@x220.int.ebiederm.org> <5621649A.80403@plumgrid.com> <87mvviidku.fsf@x220.int.ebiederm.org> <5621B5BC.8020204@plumgrid.com> <56223F00.5030203@iogearbox.net> <562301F9.1030702@plumgrid.com> <5623B4B4.2010703@iogearbox.net> <5623CD8D.7000500@iogearbox.net> Cc: Hannes Frederic Sowa , davem@davemloft.net, viro@ZenIV.linux.org.uk, tgraf@suug.ch, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Alexei Starovoitov From: Alexei Starovoitov Message-ID: <56240814.8020105@plumgrid.com> Date: Sun, 18 Oct 2015 13:59:00 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5623CD8D.7000500@iogearbox.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/18/15 9:49 AM, Daniel Borkmann wrote: > Okay, I have pushed some rough working proof of concept here: > > https://git.breakpoint.cc/cgit/dborkman/net-next.git/log/?h=ebpf-fds-final5 > > So the idea eventually had to be slightly modified after giving this > further > thoughts and is the following: > > We have 3 commands (BPF_DEV_CREATE, BPF_DEV_DESTROY, BPF_DEV_CONNECT), and > related to that a bpf_attr extension with only a single __u32 fd member > in it. ... > The nice thing about it is that you can create/unlink as many as you > want, but > when you remove the real device from an application via > bpf_dev_destroy(fd), > then all links disappear with it. Just like in the case of a normal > device driver. interesting idea! What happens if user app creates a dev via bpf_dev_create(), exits and then admin does rm of that dev ? Looks like map/prog will leak ? So the only proper way to delete such cdevs is via bpf_dev_destroy ? > On device creation, the kernel will return the minor number via bpf(2), > so you > can access the file easily, f.e. /dev/bpf/bpf_map resp. > /dev/bpf/bpf_prog, > and then move on with mknod(2) or symlink(2) from there if wished. what if admin mknod in that dir with some arbitrary minor ? mknod will succeed, but it won't hold anything? looks like bpf_dev_connect will handle it gracefully. So these cdevs should only be created and destroyed via bpf syscall and only sensible operations on them is open() to get fd and pass to bpf_dev_connect and symlink. Anything else admin should be careful not to do. Right?