On Wed, 01 Jun 2016 23:21:40 +0200, Daniel Borkmann wrote: > On 06/01/2016 11:05 PM, Jakub Kicinski wrote: > > On Wed, 01 Jun 2016 21:40:23 +0200, Daniel Borkmann wrote: > [...] > >>> @@ -400,8 +406,11 @@ static int cls_bpf_modify_existing(struct net *net, > >>> struct tcf_proto *tp, > >>> > >>> have_exts = bpf_flags & TCA_BPF_FLAG_ACT_DIRECT; > >>> } > >>> + if (tb[TCA_BPF_GEN_TCA_FLAGS]) > >>> + gen_flags = nla_get_u32(tb[TCA_BPF_GEN_TCA_FLAGS]); > >>> > >>> prog->exts_integrated = have_exts; > >>> + prog->gen_flags = gen_flags & CLS_BPF_SUPPORTED_GEN_FLAGS; > >> > >> Invalid flags should probably be rejected here with -EINVAL or something. > > > > Indeed, that would be more in line with what is done for "the other" > > flags attribute, but not so much with how flower and u32 handles > > flags. I like the stricter approach better, though, so unless someone > > speaks up I'll do as you suggest. > > If I see this correctly, in patch 4 you're already following up on that > with the tc_flags_valid() check, it's probably okay to leave it as-is then.
My concern was that if someone adds a new flag for u32/flower tc_flags_valid() will have to accept it but cls_bpf will ignore it. So I went with clearing things we don't support so that the user can at least see in tc show that the flags he thrown at us did not stick...
