From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Fastabend Subject: Re: [PATCH net-next] bpf: add show_fdinfo handler for maps Date: Mon, 23 Nov 2015 11:18:29 -0800 Message-ID: <56536685.8000001@gmail.com> References: <1447957164.2292053.444566657.27F336C7@webmail.messagingengine.com> <20151119183240.GA5993@ast-mbp.thefacebook.com> <1447963950.3032383.444676081.5CE47461@webmail.messagingengine.com> <20151120033040.GA13060@ast-mbp.thefacebook.com> <1448015413.2300190.445198593.6A586A15@webmail.messagingengine.com> <20151121231829.GA51711@ast-mbp.thefacebook.com> <1448295118.4062584.447768561.3963C28E@webmail.messagingengine.com> <20151123180333.GB78190@ast-mbp.thefacebook.com> <5653647D.7020903@gmail.com> <1448305939.1624527.447961889.5D80B022@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Daniel Borkmann , davem@davemloft.net, netdev@vger.kernel.org To: Hannes Frederic Sowa , Alexei Starovoitov Return-path: Received: from mail-pa0-f54.google.com ([209.85.220.54]:34411 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752835AbbKWTSu (ORCPT ); Mon, 23 Nov 2015 14:18:50 -0500 Received: by padhx2 with SMTP id hx2so199997675pad.1 for ; Mon, 23 Nov 2015 11:18:49 -0800 (PST) In-Reply-To: <1448305939.1624527.447961889.5D80B022@webmail.messagingengine.com> Sender: netdev-owner@vger.kernel.org List-ID: On 15-11-23 11:12 AM, Hannes Frederic Sowa wrote: > On Mon, Nov 23, 2015, at 20:09, John Fastabend wrote: >> On 15-11-23 10:03 AM, Alexei Starovoitov wrote: >>> On Mon, Nov 23, 2015 at 05:11:58PM +0100, Hannes Frederic Sowa wrote: >>>> >>>> Actually, that is the reason why I mentioned it, so *the admin* can see >>>> something is going on. Do you want to protect ebpf from root? Skynet? ;) >>> >>> correct. To me both root and non-root are users in the first place and >>> they both shouldn't be allowed to misuse it. >>> >>>> In my opinion the kernel never should hide any information of the admin >>>> if they are accessible easily. Sampling the number of failed updates to >>>> a map or printing it via procfs/ebpffs seems to be just a matter of how >>>> difficult it should be done. The map has a lock, so the number is fairly >>> >>> map_lookup is actually lockless. It's a critical path and should be >>> as fast as possible. No extra stats just for debugging. >>> >>>> accurate. Sampling and plotting size of hash maps without having kprobes >>>> installed would be a nice thing, because it reduces complexity and this >>>> is nice to have. >>> >>> doing 'cat' from procfs is, of course, easier to use, but it's an extra >>> code that permenanetly lives in memory, whereas kprobe+bpf is a run-time >>> debugging. >> >> Hopefully not jumping in off-base here (I've read most the thread), but >> what I've been doing is loading programs with debug ebpf code in them >> to keep a statistics map(s) and then I read that from userspace for >> stats. It works pretty well and lets me compile out the debug code when >> I want and also doesn't need kprobe at all. Also I can implement >> sampling so that the debug code only runs every .01% or something like >> that so it can be used in "real" systems. My "real" systems are just a >> couple node test setup but it seems to be ok ;) > > Ok, I am fine to wait until there is user demand. > > Anyway, all you refer to is code you have under your control. I am > worried about bpf code that is not under my control. > Right, I've not gotten this far. To date everything I've been looking at is owned by the admin. So probably some more use cases there I haven't looked at. > Thanks, > Hannes >