Elegible stable v4.9.x commits used by OpenWrt

Elegible stable v4.9.x commits used by OpenWrt

[Linus Walleij]

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

Re: Elegible stable v4.9.x commits used by OpenWrt

[Greg KH]

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

Re: Elegible stable v4.9.x commits used by OpenWrt

[Linus Walleij]

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

Re: Elegible stable v4.9.x commits used by OpenWrt

[Koen Vandeputte]

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

Re: Elegible stable v4.9.x commits used by OpenWrt

[Hauke Mehrtens]

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

Re: Elegible stable v4.9.x commits used by OpenWrt

[Linus Walleij]

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

Re: Elegible stable v4.9.x commits used by OpenWrt

[Stefano Brivio]

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.

-- 
Stefano

Re: Elegible stable v4.9.x commits used by OpenWrt

[Linus Walleij]

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