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
| ||
|
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
Powered by blists - more mailing lists