Re: [PATCH v2 net-next 1/2] bpf: allow extended BPF programs access skb fields
From: Daniel Borkmann <daniel@iogearbox.net>
Date: 2015-03-14 09:35:39
Also in:
lkml, netdev
On 03/14/2015 05:59 AM, Alexei Starovoitov wrote:
On 3/13/15 7:27 PM, Alexei Starovoitov wrote:quoted
On 3/13/15 7:16 PM, Daniel Borkmann wrote:quoted
On 03/14/2015 03:08 AM, Alexei Starovoitov wrote:quoted
On 3/13/15 7:06 PM, Daniel Borkmann wrote:quoted
On 03/14/2015 02:46 AM, Daniel Borkmann wrote: ...quoted
Previously, it was much more consistent, which I like better. And only because of the simple BUILD_BUG_ON()? :/Alternative is to move all of them into a central place, something like in twsk_build_assert() or __mld2_query_bugs[].nope. that defeats the purpose of bug_on.Well, it doesn't. ;) It throws a build error thus the user is forced to investigate that further.according to this distorted logic all build_bug_on can be in one file across the whole tree, since 'user is forced to investigate' ?!
That was not what I was suggesting, and I assume you know that ...
also note that this case and twsk_build_assert are different. twsk_build_assert has no other choice then to have one function that covers logic in the whole file, whereas in this patch: + BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, mark) != 4); + *insn++ = BPF_LDX_MEM(BPF_W, dst_reg, src_reg, + offsetof(struct sk_buff, mark)); the build_bug_on protect the line directly below. Separating them just doesn't make sense at all.
I also like the above approach better, I only suggested that as a possible alternative since you were saying earlier in this thread: I thought about it, but didn't add it, since we already have them in the same file several lines above this spot. I think one build error per .c file should be enough to attract attention. Though I'll add a comment to convert_bpf_extensions() that build_bug_on errors should be addressed in two places. Cheers, Daniel