Re: [Regression?] fib_rules: Added NLM_F_EXCL support to fib_nl_newrule breaks Android userspace

From: John Stultz
Date: Tue Aug 02 2016 - 14:30:07 EST


On Tue, Aug 2, 2016 at 11:00 AM, David Miller <davem@xxxxxxxxxxxxx> wrote:
> From: John Stultz <john.stultz@xxxxxxxxxx>
> Date: Tue, 2 Aug 2016 10:51:26 -0700
>
>> Yea, it looks like they do in their tree w/ their uid based routing:
>> https://android.googlesource.com/kernel/common.git/+/fd2cf795f3ab193752781be7372949ac1780d0ed%5E%21/
>>
>> index 96161b8..ce19c5b 100644
>> --- a/include/uapi/linux/fib_rules.h
>> +++ b/include/uapi/linux/fib_rules.h
>> @@ -49,6 +49,8 @@ enum {
>> FRA_TABLE, /* Extended table id */
>> FRA_FWMASK, /* mask for netfilter mark */
>> FRA_OIFNAME,
>> + FRA_UID_START, /* UID range */
>> + FRA_UID_END,
>> __FRA_MAX
>> };
> ...
>> Lorenzo/Rom: Fyi, you've got another upstream feature collision to work out.
>
> It is very difficult for us to take Android networking bug reports
> against upstream seriously as long as these kind of situations
> continue to exist.
>
> Just FYI...

Very much agreed, its frustrating.

Part of my efforts trying to run Android environments against mainline
kernels (including reporting apparent regressions) is to try to
improve interactions with the upstream community since if there is a
real regression (like we've seen with cgroup locking performance
recently), learning about it a year or two later when vendors start
using a kernel isn't super helpful. And I feel like I've got a number
of real issues with this approach recently (asix and wlcore driver
regressions, iptables alignment issue on arm, etc).

But trying to filter out these sorts of issues where a lot of testing
can work w/o the android features, until the collision occurs, isn't
trivial w/o being a domain expert. So, again, my apologies.
Generating noise like this is the *opposite* of what I'm trying to do.

thanks
-john