Hi Greg,
I recently sifted through the OpenWrt stack of backports to v4.9 and made a list of upstream commits that exist in their kernel but are not in the stable tree for v4.9.
Out of 104 patches I classified:
Number backported from later kernels that should possibly/probably go into stable: 17
Backported from later kernels to gain performance: 13
Backported because of new hardware support or convinent new frameworks: 74
The performance commits are a bit inbetween: if they fix a performance regression they should go upstream whereas if they are just there to speed up the devices using OpenWrt it's fine as distribution "icing" (IMO). The HW support and framework enhancements are clearly just a distribution add-on and not regressions. I left them out for now so we can focus on the most important stuff.
Here is the list I think you could consider for cherry-picking to stable v4.9 and where applicable also to later stable kernels (giving the OpenWrt maintainers and patch authors some day(s) to comment):
Multicast to unicast:
021-bridge-multicast-to-unicast.patch Upstream commit 6db6f0eae6052b70885562e1733896647ec1d807 "bridge: multicast to unicast" Merged in v4.11
A series dealing with cloned SKBs:
023-1-smsc95xx-Use-skb_cow_head-to-deal-with-cloned-skbs.patch 023-6-ch9200-use-skb_cow_head-to-deal-with-cloned-skbs.patch 023-7-kaweth-use-skb_cow_head-to-deal-with-cloned-skbs.patch Upstream committs e9156cd26a495a18706e796f02a81fee41ec14f4 "smsc95xx: Use skb_cow_head to deal with cloned skbs" 6bc6895bdd6744e0136eaa4a11fbdb20a7db4e40 "ch9200: use skb_cow_head() to deal with cloned skbs" 39fba7835aacda65284a86e611774cbba71dac20 "kaweth: use skb_cow_head() to deal with cloned skbs" Merged in v4.11
Adjustable dirty writeback intervals for UBIFS:
030-01-ubifs-Drop-softlimit-and-delta-fields-from-struct-ub.patch 030-02-ubifs-Use-dirty_writeback_interval-value-for-wbuf-ti.patch Upstream commits 854826c9d526fd81077742c3b000e3f7fcaef3ce "ubifs: Drop softlimit and delta fields from struct ubifs_wbuf" 1b7fc2c0069f3864a3dda15430b7aded31c0bfcc "ubifs: Use dirty_writeback_interval value for wbuf timer" Merged in v4.10
Dangling kfree on errorpath:
050-usb-dwc2-Remove-unnecessary-kfree.patch Upstream commit cd4b1e34655d46950c065d9284b596cd8d7b28cd "usb: dwc2: Remove unnecessary kfree" Merged in v4.10
nf_tables fix for BE systems:
092-netfilter-nf_tables-fix-mismatch-in-big-endian-syste.patch Upstream commit 10596608c4d62cb8c1c2b806debcbd32fe657e71 "netfilter: nf_tables: fix mismatch in big-endian system" Merged in v4.11
Userspace break for Class E address assignment. This looks like it should DEFINATELY go into stable:
095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch Upstream commit 65cab850f0eeaa9180bd2e10a231964f33743edf "net: Allow class-e address assignment via ifconfig ioctl" Merged in v4.20
PCI breakage on cns3xxx:
100-arm-cns3xxx-fix-writing-to-wrong-PCI-registers-after.patch 101-arm-cns3xxx-use-actual-size-reads-for-PCIe.patch Upstream commits 65dbb423cf28232fed1732b779249d6164c5999b "ARM: cns3xxx: Fix writing to wrong PCI config registers after alignment" 432dd7064aa1c030a488745917cfa4ebc6c8c060 "ARM: cns3xxx: Use actual size reads for PCIe" Merged in v5.0-rc5
UAPI bug on if_ether.h definately looks like stable material:
272-uapi-if_ether.h-prevent-redefinition-of-struct-ethhd.patch Upstream commit 6926e041a8920c8ec27e4e155efa760aa01551fd "uapi/if_ether.h: prevent redefinition of struct ethhdr" Merged in v4.15
I would consider these ONLY if the authors greenlight them, as they seem to have been fixed after fixing:
Preserve link scope:
096-v4.20-netfilter-ipv6-Preserve-link-scope-traffic-original-.patch Upstream commit 508b09046c0f21678652fb66fd1e9959d55591d2 "netfilter: ipv6: Preserve link scope traffic original oif" Merged in v4.20 Fix seems to have been dangerous and to also require: commit 15df03c661cb362366ecfc3a21820cb934f3e4ca "netfilter: ipv6: Don't preserve original oif for loopback address" Merged in v5.0-rc6
Tunnel encapsulation fixes:
094-v4.12-0001-ip6_tunnel-Fix-missing-tunnel-encapsulation-limit-op.patch 094-v4.12-0002-ipv6-Need-to-export-ipv6_push_frag_opts-for-tunnelin.patch Upstream commits 89a23c8b528bd2c89f3981573d6cd7d23840c8a6 "ip6_tunnel: Fix missing tunnel encapsulation limit option" 5b8481fa42ac58484d633b558579e302aead64c1 "ipv6: Need to export ipv6_push_frag_opts for tunneling now." Which then seems to be further fixed in commit d4d576f5ab7edcb757bb33e6a5600666a0b1232d "ip6_tunnel: Fix encapsulation layout"
Yours, Linus Walleij
On Tue, Feb 12, 2019 at 04:39:08PM +0100, Linus Walleij wrote:
Hi Greg,
I recently sifted through the OpenWrt stack of backports to v4.9 and made a list of upstream commits that exist in their kernel but are not in the stable tree for v4.9.
Out of 104 patches I classified:
Number backported from later kernels that should possibly/probably go into stable: 17
Backported from later kernels to gain performance: 13
Backported because of new hardware support or convinent new frameworks: 74
<snip>
You have a lot of information here, but it's hard to sift through it properly. Some of the patches you list here have already been merged in stable releases, so adding them again is odd :)
Can you just send a series of patches that you think should be merged based on these commits?
thanks,
greg k-h
On Wed, Feb 13, 2019 at 3:17 PM Greg KH gregkh@linuxfoundation.org wrote:
You have a lot of information here, but it's hard to sift through it properly. Some of the patches you list here have already been merged in stable releases, so adding them again is odd :)
Yeah I guess some have been merged for say other than v4.9 and are not in v4.9 because of various reasons.
Can you just send a series of patches that you think should be merged based on these commits?
Yes that is a good idea, because if something is already there and/or not mergeing etc, I will surely notice.
The other point of the mail is to get feedback from people on CC whether they agree these are commits that would be good for stable, so I guess I prepare a bunch of backports, wait a little and then send a patch train for v4.9.x.
Yours, Linus Walleij
On 13.02.19 15:37, Linus Walleij wrote:
On Wed, Feb 13, 2019 at 3:17 PM Greg KH gregkh@linuxfoundation.org wrote:
You have a lot of information here, but it's hard to sift through it properly. Some of the patches you list here have already been merged in stable releases, so adding them again is odd :)
Yeah I guess some have been merged for say other than v4.9 and are not in v4.9 because of various reasons.
Can you just send a series of patches that you think should be merged based on these commits?
Yes that is a good idea, because if something is already there and/or not mergeing etc, I will surely notice.
The other point of the mail is to get feedback from people on CC whether they agree these are commits that would be good for stable, so I guess I prepare a bunch of backports, wait a little and then send a patch train for v4.9.x.
Yours, Linus Walleij
Linus,
Regarding:
PCI breakage on cns3xxx:
100-arm-cns3xxx-fix-writing-to-wrong-PCI-registers-after.patch 101-arm-cns3xxx-use-actual-size-reads-for-PCIe.patch Upstream commits 65dbb423cf28232fed1732b779249d6164c5999b "ARM: cns3xxx: Fix writing to wrong PCI config registers after alignment" 432dd7064aa1c030a488745917cfa4ebc6c8c060 "ARM: cns3xxx: Use actual size reads for PCIe" Merged in v5.0-rc5
These 2 can be skipped.
It was agreed with Bjorn Helgaas to only submit ("100-arm-cns3xxx-fix-writing-to-wrong-PCI-registers-after.patch") to stable, and it has already been merged there.
The 2nd one ("101-arm-cns3xxx-use-actual-size-reads-for-PCIe.patch") is considered to be a cleanup.
Regards,
Koen
On 2/12/19 4:39 PM, Linus Walleij wrote:
Hi Greg,
I recently sifted through the OpenWrt stack of backports to v4.9 and made a list of upstream commits that exist in their kernel but are not in the stable tree for v4.9.
Out of 104 patches I classified:
Number backported from later kernels that should possibly/probably go into stable: 17
Backported from later kernels to gain performance: 13
Backported because of new hardware support or convinent new frameworks: 74
The performance commits are a bit inbetween: if they fix a performance regression they should go upstream whereas if they are just there to speed up the devices using OpenWrt it's fine as distribution "icing" (IMO). The HW support and framework enhancements are clearly just a distribution add-on and not regressions. I left them out for now so we can focus on the most important stuff.
Here is the list I think you could consider for cherry-picking to stable v4.9 and where applicable also to later stable kernels (giving the OpenWrt maintainers and patch authors some day(s) to comment):
....
nf_tables fix for BE systems:
092-netfilter-nf_tables-fix-mismatch-in-big-endian-syste.patch Upstream commit 10596608c4d62cb8c1c2b806debcbd32fe657e71 "netfilter: nf_tables: fix mismatch in big-endian system" Merged in v4.11
I tried to get this into 4.9 stable but failed to get the process right, it looks it is somehow special for network patches. Just cherry-picking the upstream patch will not work because it does not apply cleanly on kernel 4.9 any more, but you can take the patch for OpenWrt.
....
UAPI bug on if_ether.h definately looks like stable material:
272-uapi-if_ether.h-prevent-redefinition-of-struct-ethhd.patch Upstream commit 6926e041a8920c8ec27e4e155efa760aa01551fd "uapi/if_ether.h: prevent redefinition of struct ethhdr" Merged in v4.15
As of now this is only needed for musl libc, but would be nice to have it in stable.
....
Hauke
On Wed, Feb 13, 2019 at 11:43 PM Hauke Mehrtens hauke@hauke-m.de wrote:
On 2/12/19 4:39 PM, Linus Walleij wrote:
092-netfilter-nf_tables-fix-mismatch-in-big-endian-syste.patch Upstream commit 10596608c4d62cb8c1c2b806debcbd32fe657e71 "netfilter: nf_tables: fix mismatch in big-endian system" Merged in v4.11
I tried to get this into 4.9 stable but failed to get the process right, it looks it is somehow special for network patches. Just cherry-picking the upstream patch will not work because it does not apply cleanly on kernel 4.9 any more, but you can take the patch for OpenWrt.
HM Okay...
UAPI bug on if_ether.h definately looks like stable material:
272-uapi-if_ether.h-prevent-redefinition-of-struct-ethhd.patch Upstream commit 6926e041a8920c8ec27e4e155efa760aa01551fd "uapi/if_ether.h: prevent redefinition of struct ethhdr" Merged in v4.15
As of now this is only needed for musl libc, but would be nice to have it in stable.
Yeah, my whole puzzlement here is that stable is for all stuff that distributions need to have to work without regressions with the current hardware support and software stack, if we include a patch into a distribution that is backported from a later kernel and it's not about specific hardware enablement or say new frameworks, it is pretty much by definition stable material, so that is why I am taking this sweep.
BTW OpenWrt is among the best in class using stable, the whole operation is just a bit of polishing the already shiny surface.
Yours, Linus Walleij
Hi Linus,
On Tue, 12 Feb 2019 16:39:08 +0100 Linus Walleij linus.walleij@linaro.org wrote:
Tunnel encapsulation fixes:
094-v4.12-0001-ip6_tunnel-Fix-missing-tunnel-encapsulation-limit-op.patch 094-v4.12-0002-ipv6-Need-to-export-ipv6_push_frag_opts-for-tunnelin.patch Upstream commits 89a23c8b528bd2c89f3981573d6cd7d23840c8a6 "ip6_tunnel: Fix missing tunnel encapsulation limit option" 5b8481fa42ac58484d633b558579e302aead64c1 "ipv6: Need to export ipv6_push_frag_opts for tunneling now."
These are needed to get the IPv6 Tunnel Encapsulation Limit option (RFC 2473) actually sent in packets. As a side effect, FoU and GUE IPv6 tunnels wouldn't work anymore unless you include...
Which then seems to be further fixed in commit d4d576f5ab7edcb757bb33e6a5600666a0b1232d "ip6_tunnel: Fix encapsulation layout"
this one. But, for those tunnels to work, commit 84dad55951b0 ("udp6: fix encap return code for resubmitting") is also needed.
I think making sure all those four commits are there would be the safest option.
On Thu, Feb 14, 2019 at 10:50 AM Stefano Brivio sbrivio@redhat.com wrote:
Hi Linus,
On Tue, 12 Feb 2019 16:39:08 +0100 Linus Walleij linus.walleij@linaro.org wrote:
Tunnel encapsulation fixes:
094-v4.12-0001-ip6_tunnel-Fix-missing-tunnel-encapsulation-limit-op.patch 094-v4.12-0002-ipv6-Need-to-export-ipv6_push_frag_opts-for-tunnelin.patch Upstream commits 89a23c8b528bd2c89f3981573d6cd7d23840c8a6 "ip6_tunnel: Fix missing tunnel encapsulation limit option" 5b8481fa42ac58484d633b558579e302aead64c1 "ipv6: Need to export ipv6_push_frag_opts for tunneling now."
These are needed to get the IPv6 Tunnel Encapsulation Limit option (RFC 2473) actually sent in packets. As a side effect, FoU and GUE IPv6 tunnels wouldn't work anymore unless you include...
Which then seems to be further fixed in commit d4d576f5ab7edcb757bb33e6a5600666a0b1232d "ip6_tunnel: Fix encapsulation layout"
this one. But, for those tunnels to work, commit 84dad55951b0 ("udp6: fix encap return code for resubmitting") is also needed.
I think making sure all those four commits are there would be the safest option.
You're certainly right.
Sadly some of the cherry-picks yield nontrivial conflicts so without proper domain knowledge I should simply stay off this tunneling business. I could use OpenWrts backport for the first two commits but then I'm kind of lost.
If we want this for stable v4.9 it'd better be someone who knows what they are doing backporting it.
Yours, Linus Walleij
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Hauke Mehrtens -
Koen Vandeputte -
Linus Walleij -
Stefano Brivio