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 > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
