From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932548AbbJPSuQ (ORCPT ); Fri, 16 Oct 2015 14:50:16 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:42591 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932101AbbJPSuO (ORCPT ); Fri, 16 Oct 2015 14:50:14 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Daniel Borkmann Cc: Alexei Starovoitov , 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 References: <1445016105.1251655.412231129.6574D430@webmail.messagingengine.com> <5621371C.2000507@plumgrid.com> <56213A61.40509@iogearbox.net> Date: Fri, 16 Oct 2015 13:41:55 -0500 In-Reply-To: <56213A61.40509@iogearbox.net> (Daniel Borkmann's message of "Fri, 16 Oct 2015 19:56:49 +0200") Message-ID: <87d1welkp8.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1+3UHNjavzhC1+nAbaekrbw61A0kfWprDo= X-SA-Exim-Connect-IP: 67.3.201.231 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Daniel Borkmann X-Spam-Relay-Country: X-Spam-Timing: total 572 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 4.0 (0.7%), b_tie_ro: 2.9 (0.5%), parse: 1.26 (0.2%), extract_message_metadata: 26 (4.5%), get_uri_detail_list: 2.9 (0.5%), tests_pri_-1000: 8 (1.4%), tests_pri_-950: 1.99 (0.3%), tests_pri_-900: 1.60 (0.3%), tests_pri_-400: 37 (6.5%), check_bayes: 35 (6.2%), b_tokenize: 12 (2.1%), b_tok_get_all: 11 (2.0%), b_comp_prob: 4.9 (0.9%), b_tok_touch_all: 3.5 (0.6%), b_finish: 0.92 (0.2%), tests_pri_0: 476 (83.3%), tests_pri_500: 10 (1.7%), poll_dns_idle: 0.21 (0.0%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH net-next 3/4] bpf: add support for persistent maps/progs X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Daniel Borkmann writes: > On 10/16/2015 07:42 PM, Alexei Starovoitov wrote: >> On 10/16/15 10:21 AM, Hannes Frederic Sowa wrote: >>> Another question: >>> Should multiple mount of the filesystem result in an empty fs (a new >>> instance) or in one were one can see other ebpf-fs entities? I think >>> Daniel wanted to already use the mountpoint as some kind of hierarchy >>> delimiter. I would have used directories for that and multiple mounts >>> would then have resulted in the same content of the filesystem. IMHO >>> this would remove some ambiguity but then the question arises how this >>> is handled in a namespaced environment. Was there some specific reason >>> to do so? >> >> That's an interesting question! >> I think all mounts should be independent. >> I can see tracing using one and networking using another one >> with different hierarchies suitable for their own use cases. >> What's an advantage to have the same content everywhere? >> Feels harder to manage, since different users would need to >> coordinate. > > I initially had it as a mount_single() file system, where I was thinking > to have an entry under /sys/fs/bpf/, so all subsystems would work on top > of that mount point, but for the same reasons above I lifted that restriction. I am missing something. When I suggested using a filesystem it was my thought there would be exactly one superblock per map, and the map would be specified at mount time. You clearly are not implementing that. A filesystem per map makes sense as you have a key-value store with one file per key. The idea is that something resembling your bpf_pin_fd function would be the mount system call for the filesystem. The the keys in the map could be read by "ls /mountpoint/". Key values could be inspected with "cat /mountpoint/key". That allows all hierarchy etc to be handled in userspace, just as with my files for namespaces. I do not understand why you have presented to userspace a magic filesystem that you allow binding to. That is not what I intended to suggest and I do not know how that makes any sense. Eric