On 09/18/2014 05:24 PM, Alexei Starovoitov wrote: ...
solve or not. If we decide to solve it, we need to have a plan to solve it all the way. Partial fix for size of bpf_attr is not a plan. It's something that is not addressing the problem completely. Little bit of help is not useful for userspace. It would need to deal with new types, verifier differences and other things that I mentioned earlier.
Hm, I don't think it would be a strict requirement to solve it all the way, and I think that perf_event_open() with perf_copy_attr() is not trying to do so either. It, however, is trying on a ``best effort basis'' to still load something if new features are unused by the binary (I guess you saw the comment in perf_copy_attr()). Iff, e.g. due to new types we fail at the verifier stage, sure, that's life since we only have backwards-compatible guarantee, but in case we tried to use features we support, we're still able to load the eBPF program while right now, we're rejecting it right up-front. That's just my $0.02 ... -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
