| Message ID | 1489812702-17339-1-git-send-email-yszhou4tech@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
On 03/17/2017 09:51 PM, Yousong Zhou wrote: > The bug appeared in v4.1.0 and was fixed since v4.8.0 > > Fixes FS#620 > > Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com> Is there a reason not to upgrade to a newer iproute2 then? Maybe not for the 17.01 branch but for the master branch would not that be preferred?
>>>>> "Florian" == Florian Fainelli <f.fainelli@gmail.com> writes: Florian> On 03/17/2017 09:51 PM, Yousong Zhou wrote: >> The bug appeared in v4.1.0 and was fixed since v4.8.0 >> >> Fixes FS#620 >> >> Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com> Florian> Is there a reason not to upgrade to a newer iproute2 then? Florian> Maybe not for the 17.01 branch but for the master branch would Florian> not that be preferred? -- Florian There are some unresolved (at least I haven't resolved them) UAPI problems. I have taken a few runs at it, thus far unsuccessful. Any help on that would be welcome.
On 19 March 2017 at 07:41, Russell Senior <russell@personaltelco.net> wrote: >>>>>> "Florian" == Florian Fainelli <f.fainelli@gmail.com> writes: > > Florian> On 03/17/2017 09:51 PM, Yousong Zhou wrote: >>> The bug appeared in v4.1.0 and was fixed since v4.8.0 >>> >>> Fixes FS#620 >>> >>> Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com> > > Florian> Is there a reason not to upgrade to a newer iproute2 then? > Florian> Maybe not for the 17.01 branch but for the master branch would > Florian> not that be preferred? -- Florian > > There are some unresolved (at least I haven't resolved them) UAPI > problems. I have taken a few runs at it, thus far unsuccessful. Any > help on that would be welcome. > Fixing the issue at hand was my intention. To be honest, I did not think much about bumping the version ;) but can you elaborate what's the UAPI issue with that? Thanks, yousong > > -- > Russell Senior > russell@personaltelco.net
>>>>> "Yousong" == Yousong Zhou <yszhou4tech@gmail.com> writes: Florian> On 03/17/2017 09:51 PM, Yousong Zhou wrote: >>>> The bug appeared in v4.1.0 and was fixed since v4.8.0 >>>> >>>> Fixes FS#620 >>>> >>>> Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com> Florian> Is there a reason not to upgrade to a newer iproute2 then? Florian> Maybe not for the 17.01 branch but for the master branch would Florian> not that be preferred? -- Florian >> There are some unresolved (at least I haven't resolved them) UAPI >> problems. I have taken a few runs at it, thus far unsuccessful. Any >> help on that would be welcome. Yousong> Fixing the issue at hand was my intention. Yousong> To be honest, I did not think much about bumping the version ;) Yousong> but can you elaborate what's the UAPI issue with that? This is the build log from my last run at the problem: http://sprunge.us/ceIL It was a build for alix2 on the 4.9 kernel using iproute2-4.10, with updated patches.
On 19 March 2017 at 14:19, Russell Senior <russell@personaltelco.net> wrote: >>>>>> "Yousong" == Yousong Zhou <yszhou4tech@gmail.com> writes: > > Florian> On 03/17/2017 09:51 PM, Yousong Zhou wrote: >>>>> The bug appeared in v4.1.0 and was fixed since v4.8.0 >>>>> >>>>> Fixes FS#620 >>>>> >>>>> Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com> > > Florian> Is there a reason not to upgrade to a newer iproute2 then? > Florian> Maybe not for the 17.01 branch but for the master branch would > Florian> not that be preferred? -- Florian > >>> There are some unresolved (at least I haven't resolved them) UAPI >>> problems. I have taken a few runs at it, thus far unsuccessful. Any >>> help on that would be welcome. > > Yousong> Fixing the issue at hand was my intention. > > Yousong> To be honest, I did not think much about bumping the version ;) > Yousong> but can you elaborate what's the UAPI issue with that? > > This is the build log from my last run at the problem: > > http://sprunge.us/ceIL > > It was a build for alix2 on the 4.9 kernel using iproute2-4.10, with > updated patches. > It seems that those __UAPI_DEF_xx are private macros that should be defined and used by the kernel uapi headers and are not intended to be defined by others to tailor uapi headers' behaviour. Looking through the history, the issue should be already there since the following musl commit: "make netinet/in.h suppress clashing definitions from kernel headers" http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258 But it reveals itself only after the following kernel commit: "uapi glibc compat: fix compile errors when glibc net/if.h included before linux/if.h" https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a91cb61bb995e5571098188092e296192309c77 I would suggest reverting the musl change and see if it will work for iproute2 and how bad it will affect other packages... A related discussion: http://www.openwall.com/lists/musl/2016/03/03/6 Cheers, yousong
My point is to respect musl-libc changes and patch iproute2 as how we patch kernel. I take two patches[0] from generic kernel patch dir and change glibc check to libc check. If you have any interest, you can check mine[1], it is based on iproute2 4.7.0 [0]: 271-uapi-libc-compat.h-do-not-rely-on-__GLIBC__.patch and 272-uapi-if_ether.h-prevent-redefinition-of-struct-ethhd.patch [1]: https://github.com/wongsyrone/lede-1/commit/85f2c5dde96fc90e7984182529c7cb72b88adbf9 Best Regards, Syrone Wong On Sun, Mar 19, 2017 at 4:30 PM, Yousong Zhou <yszhou4tech@gmail.com> wrote: > On 19 March 2017 at 14:19, Russell Senior <russell@personaltelco.net> wrote: >>>>>>> "Yousong" == Yousong Zhou <yszhou4tech@gmail.com> writes: >> >> Florian> On 03/17/2017 09:51 PM, Yousong Zhou wrote: >>>>>> The bug appeared in v4.1.0 and was fixed since v4.8.0 >>>>>> >>>>>> Fixes FS#620 >>>>>> >>>>>> Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com> >> >> Florian> Is there a reason not to upgrade to a newer iproute2 then? >> Florian> Maybe not for the 17.01 branch but for the master branch would >> Florian> not that be preferred? -- Florian >> >>>> There are some unresolved (at least I haven't resolved them) UAPI >>>> problems. I have taken a few runs at it, thus far unsuccessful. Any >>>> help on that would be welcome. >> >> Yousong> Fixing the issue at hand was my intention. >> >> Yousong> To be honest, I did not think much about bumping the version ;) >> Yousong> but can you elaborate what's the UAPI issue with that? >> >> This is the build log from my last run at the problem: >> >> http://sprunge.us/ceIL >> >> It was a build for alix2 on the 4.9 kernel using iproute2-4.10, with >> updated patches. >> > > It seems that those __UAPI_DEF_xx are private macros that should be > defined and used by the kernel uapi headers and are not intended to be > defined by others to tailor uapi headers' behaviour. > > Looking through the history, the issue should be already there since > the following musl commit: "make netinet/in.h suppress clashing > definitions from kernel headers" > > http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258 > > But it reveals itself only after the following kernel commit: "uapi > glibc compat: fix compile errors when glibc net/if.h included before > linux/if.h" > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a91cb61bb995e5571098188092e296192309c77 > > I would suggest reverting the musl change and see if it will work for > iproute2 and how bad it will affect other packages... > > A related discussion: http://www.openwall.com/lists/musl/2016/03/03/6 > > Cheers, > yousong > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev
diff --git a/package/network/utils/iproute2/Makefile b/package/network/utils/iproute2/Makefile index af8e64c..1c1ee3f 100644 --- a/package/network/utils/iproute2/Makefile +++ b/package/network/utils/iproute2/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=iproute2 PKG_VERSION:=4.4.0 -PKG_RELEASE:=8 +PKG_RELEASE:=9 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=@KERNEL/linux/utils/net/iproute2 diff --git a/package/network/utils/iproute2/patches/960-ipmonitor-fix-ip-monitor-can-t-work-when-NET_NS-is-n.patch b/package/network/utils/iproute2/patches/960-ipmonitor-fix-ip-monitor-can-t-work-when-NET_NS-is-n.patch new file mode 100644 index 0000000..52be021 --- /dev/null +++ b/package/network/utils/iproute2/patches/960-ipmonitor-fix-ip-monitor-can-t-work-when-NET_NS-is-n.patch @@ -0,0 +1,40 @@ +From c44003f7e7254ac972eaa1b22a686471ea4ce2d7 Mon Sep 17 00:00:00 2001 +From: Liping Zhang <liping.zhang@spreadtrum.com> +Date: Tue, 20 Sep 2016 02:09:02 -0700 +Subject: [PATCH] ipmonitor: fix ip monitor can't work when NET_NS is not + enabled + +In ip monitor, netns_map_init will check getnsid is supported or not. +But when /proc/self/ns/net does not exist, we just print out error +messages and exit. So user cannot use ip monitor anymore when +CONFIG_NET_NS is disabled: + # ip monitor + open("/proc/self/ns/net"): No such file or directory + +If open "/proc/self/ns/net" failed, set have_rtnl_getnsid to false. + +Fixes: d652ccbf8195 ("netns: allow to dump and monitor nsid") +Signed-off-by: Liping Zhang <liping.zhang@spreadtrum.com> +Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> +--- + ip/ipnetns.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/ip/ipnetns.c b/ip/ipnetns.c +index af87065..ccc652c 100644 +--- a/ip/ipnetns.c ++++ b/ip/ipnetns.c +@@ -72,8 +72,8 @@ static int ipnetns_have_nsid(void) + if (have_rtnl_getnsid < 0) { + fd = open("/proc/self/ns/net", O_RDONLY); + if (fd < 0) { +- perror("open(\"/proc/self/ns/net\")"); +- exit(1); ++ have_rtnl_getnsid = 0; ++ return 0; + } + + addattr32(&req.n, 1024, NETNSA_FD, fd); +-- +2.6.4 +
The bug appeared in v4.1.0 and was fixed since v4.8.0 Fixes FS#620 Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com> --- I am also going to backport this to lede-17.01 branch package/network/utils/iproute2/Makefile | 2 +- ...ix-ip-monitor-can-t-work-when-NET_NS-is-n.patch | 40 ++++++++++++++++++++++ 2 files changed, 41 insertions(+), 1 deletion(-) create mode 100644 package/network/utils/iproute2/patches/960-ipmonitor-fix-ip-monitor-can-t-work-when-NET_NS-is-n.patch