Kris Katterjohn wrote:
From: Patrick McHardy
Because it means a check was missing. We had a number of bad bugs
in there before, better to find them quick than have them lurking
around until someone does an code audit. But in this case I tend
to agree with you, it doesn't seem to affect anything critical.
So keep the return statement, then?
Lets agree on adding WARN_ON(1) before the return statement.
Well, I'm not convinced that there is a problem, but I do agree that its
good to return an error for invalid filters - if they are actually
invalid and its not documented behaviour to accept unknown instructions
and treat them as return.
After some googling, I found this OpenBSD kernel code which does a lot of what
my
patch would add, but uses BPF_CLASS as you suggested earlier:
http://fxr.watson.org/fxr/source//net/bpf_filter.c?v=OPENBSD
My guess would be there isn't any requirement to return for a bad instruction
while running the filter.
No, the paper doesn't mention anything like that, so your patch seems
fine. Interestingly it does mention that a division by 0 should abort
the filter with a return value of 0 - but the BSDs also catch this
during validation.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
