linux-kernel - Re: [Regression?] fib_rules: Added NLM_F_EXCL support to fib_nl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALAqxLVNRg2wyFrrYdKzetHeD-=5mY1mjX5t=8z4Edzjf7F=Yg@mail.gmail.com>
Date:	Tue, 2 Aug 2016 11:22:08 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	David Miller <davem@...emloft.net>
Cc:	David Ahern <dsa@...ulusnetworks.com>,
	Lorenzo Colitti <lorenzo@...gle.com>,
	Mateusz Bajorski <mateusz.bajorski@...ia.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Guodong Xu <guodong.xu@...aro.org>,
	Dmitry Shmidt <dimitrysh@...gle.com>,
	Chih-hung Hsieh <chh@...gle.com>,
	Eric Caruso <ejcaruso@...gle.com>,
	Rom Lemarchand <romlem@...gle.com>
Subject: Re: [Regression?] fib_rules: Added NLM_F_EXCL support to
 fib_nl_newrule breaks Android userspace

On Tue, Aug 2, 2016 at 11:00 AM, David Miller <davem@...emloft.net> wrote:
> From: John Stultz <john.stultz@...aro.org>
> 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