On Thu, Sep 18, 2014 at 7:50 AM, Daniel Borkmann <dborkman@xxxxxxxxxx> wrote: > On 09/18/2014 04:34 PM, Alexei Starovoitov wrote: >> >> On Wed, Sep 17, 2014 at 11:44 PM, Daniel Borkmann <dborkman@xxxxxxxxxx> >> wrote: > > ... >>> >>> Sure, you will never get a full compatibility on that regard >>> while backwards compatibility needs to be guaranteed on the >>> other hand. I looked at perf_copy_attr() implementation and I >>> think that we should mimic it in a very similar way as it >>> exactly solves what we need. >>> >>> For example, it will return with -EINVAL for (size > PAGE_SIZE) >>> and (size < PERF_ATTR_SIZE_VER0) where PAGE_SIZE has been chosen >>> as an arbitrary hard upper limit where it is believed that it will >>> never grow beyond that large limit in future. >>> >>> So this is a more loose constraint than what we currently do, >>> that is, -EINVAL on (size > sizeof(attr)) where attr is the >>> currently known size of a specific kernel. That would at least >>> be a start, you won't be able to cover everything though, but >>> it would allow to address the issue raised when running with >>> a basic feature set. >> >> >> you missed my point. We should not 'do a start', since it >> doesn't help user space in the long run and only makes >> kernel more complex. > > > Sorry, I don't think I missed your point. But if you see things > differently, fair enough, it was just a suggestion. now you probably think I'm shutting you up. Sorry. Was not my intention. Let me rephrase what I meant: I think we should decide right now whether 'new user + old kernel' is really a problem we're going to 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. So we either decide that we're going to spend time to solve all of them (not necessarily today, but over long haul) or we're not doing any of it. -- 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
