On Fri, Nov 20, 2015 at 11:30:13AM +0100, Hannes Frederic Sowa wrote: > Hi Alexei, > > > If user space can be see both 'count' and 'max_entries', it can be very > > tempting to start assuming 'full' and 'empty' state of the map which will > > lead to race conditions and bad design. > > bpf programs and maps are inherently multi-thread and concurrent. > > If userapp wants to do the counting of elements it needs to do so on its > > own > > and shoot itself in the foot eventually. > > For the same reason I don't want to see BPF_MAP_GET_COUNT command. > > Hmmm... I don't understand your argument. This is the same with memory > management in general and we still report memory statistics to user > space. I really would find it helpful to have a feeling if a map is > nearly full or nearly empty.
memory is not the same, since it's a shared resource and knowledge about consumption by the process gives no insight whether next malloc() will succeed or not. > We can also count collisions or the load in the buckets, but some > evidence what is going on would be nice, wouldn't it? reporting collisions may be ok, since it's probably hard to exploit such stats, but security may become a concern in some use cases, so may not be such a good idea at the end. In general when user space passed kernel some numbers (like type, element size, max_entries) it's ok to report it back via fdinfo. Anything else I'd rather keep private. debugging in general should be done by debugging tools. Like I often use kprobe+bpf to debug networking+bpf :) Unfortunately kprobe+bpf doesn't work to debug itself, but then regular tracing and kprobe comes to rescue. -- 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
