Re: Stable request: iwlwifi: mvm: don't send RFH_QUEUE_CONFIG_CMD with no queues

On Sun, Feb 07, 2021 at 09:19:07AM -0500, Jason Andryuk wrote: > Hi, > > commit 64f55156f7adedb1ac5bb9cdbcbc9ac05ff5a724 upstream > > The requested patch allows the iwlwifi driver to work with newer AX200 > wifi cards when MSI-X interrupts are not available. Without it, > bringing an interface "

Stable request: iwlwifi: mvm: don't send RFH_QUEUE_CONFIG_CMD with no queues

Hi, commit 64f55156f7adedb1ac5bb9cdbcbc9ac05ff5a724 upstream The requested patch allows the iwlwifi driver to work with newer AX200 wifi cards when MSI-X interrupts are not available. Without it, bringing an interface "up" fails with a Microcode SW error. Xen PCI passthrough with a linux stubdo

Re: Stable request

From: Edward Cree Date: Wed, 16 Oct 2019 16:26:50 +0100 > Hi, did this get missed or was my request improper in some way? > Our testing has been hitting this issue on distro kernels (Fedora, Debian, >  Ubuntu), we'd like the fix to get everywhere it's needed and AIUI -stable >  is the proper rout

Re: Stable request

From: Edward Cree Date: Wed, 16 Oct 2019 16:26:50 +0100 > On 04/10/2019 16:17, Edward Cree wrote: >> On 23/08/2019 22:42, David Miller wrote: >>> From: Xin Long >>> Date: Fri, 23 Aug 2019 19:33:03 +0800 >>> We need a similar fix for ipv6 as Commit 0761680d5215 ("net: ipv4: fix listify

Stable request (was Re: [PATCH net-next] net: ipv6: fix listify ip6_rcv_finish in case of forwarding)

On 04/10/2019 16:17, Edward Cree wrote: > On 23/08/2019 22:42, David Miller wrote: >> From: Xin Long >> Date: Fri, 23 Aug 2019 19:33:03 +0800 >> >>> We need a similar fix for ipv6 as Commit 0761680d5215 ("net: ipv4: fix >>> listify ip_rcv_finish in case of forwarding") does for ipv4. >>> >>> This

Re: stable request: ipv6: Consider sk_bound_dev_if when binding a socket to an address

From: David Ahern Date: Sun, 27 Jan 2019 09:17:17 -0700 > Hi Dave: > > Request for c5ee066333eb("ipv6: Consider sk_bound_dev_if when binding a > socket to an address") to be backported. > > The v4-mapped version - ec90ad334986 ("ipv6: Consider sk_bound_dev_if > when binding a socket to a v4 map

stable request: ipv6: Consider sk_bound_dev_if when binding a socket to an address

Hi Dave: Request for c5ee066333eb("ipv6: Consider sk_bound_dev_if when binding a socket to an address") to be backported. The v4-mapped version - ec90ad334986 ("ipv6: Consider sk_bound_dev_if when binding a socket to a v4 mapped address") - has been backported to stable releases, but the v6 socke

Re: Atlantic driver 4.16 stable request

From: Igor Russkikh Date: Fri, 13 Apr 2018 15:03:29 +0300 > Could you please consider queuing to v4.16: > > 9a11aff net: aquantia: oops when shutdown on already stopped device > cce96d1 net: aquantia: Regression on reset with 1.x firmware > > These are both critical and well tested by our team.

Atlantic driver 4.16 stable request

Hi David, Could you please consider queuing to v4.16: 9a11aff net: aquantia: oops when shutdown on already stopped device cce96d1 net: aquantia: Regression on reset with 1.x firmware These are both critical and well tested by our team. Thanks in advance!

ipv6: stable request

12d94a804946af291e24b80fc53ec86264765781 ipv6: fix NULL dereference in ip6_route_dev_notify() This BUG touches 4.1 4.4 4.9.

Re: bpf stable request

On 03/27/2018 01:52 AM, Chenbo Feng wrote: > 0fa4fe85f4724fff89b09741c437cbee9cf8b008 bpf: skip unnecessary capability > check > > This patch fixes the false alarms from security system such as selinux when > doing the capability check. The problem exists since the > sysctl_unprivileged_bpf_dis

bpf stable request

0fa4fe85f4724fff89b09741c437cbee9cf8b008 bpf: skip unnecessary capability check This patch fixes the false alarms from security system such as selinux when doing the capability check. The problem exists since the sysctl_unprivileged_bpf_disabled is added in linux 4.4. So I suggest to backport

Re: l2tp stable request

On Thu, Mar 22, 2018 at 05:55:30PM -0700, Daniel Rosenberg wrote: > f3c66d4e144a0904ea9b95d23ed9f8eb38c11bfb        l2tp: prevent creation of > sessions on terminated tunnels > 9ee369a405c57613d7c83a3967780c3e30c52ecc        l2tp: initialise session's > refcount before making it reachable > dbdbc73

l2tp stable request

f3c66d4e144a0904ea9b95d23ed9f8eb38c11bfb        l2tp: prevent creation of sessions on terminated tunnels 9ee369a405c57613d7c83a3967780c3e30c52ecc        l2tp: initialise session's refcount before making it reachable dbdbc73b44782e22b3b4b6e8b51e7a3d245f3086        l2tp: fix duplicate session crea

Re: 4.4 stable request for net: macb: fix default configuration for GMAC on AT91

From: Cyrille Pitchen Date: Thu, 23 Jun 2016 11:27:00 +0200 > For 4.4 -stable, can you please consider commit: > > commit 6bdaa5e9ed39b3b3328f35d218e8ad5a99cfc4d2 > Author: Nicolas Ferre > Date: Thu Mar 10 16:44:32 2016 +0100 > > net: macb: fix default configuration for GMAC on AT91 ...

4.4 stable request for net: macb: fix default configuration for GMAC on AT91

Hi David, For 4.4 -stable, can you please consider commit: commit 6bdaa5e9ed39b3b3328f35d218e8ad5a99cfc4d2 Author: Nicolas Ferre Date: Thu Mar 10 16:44:32 2016 +0100 net: macb: fix default configuration for GMAC on AT91 On AT91 SoCs, the User Register (USRIO) exposes a switch to

3.14 stable request for net: gso: use feature flag argument in all protocol gso handlers

For 3.14 -stable, please consider commit: commit 1e16aa3ddf863c6b9f37eddf52503230a62dedb3 Author: Florian Westphal Date: Mon Oct 20 13:49:16 2014 +0200 net: gso: use feature flag argument in all protocol gso handlers We have observed kernel panics when an openvswitch bri

Re: Stable request for gso feature flag and error handling fixes

From: Jay Vosburgh Date: Tue, 07 Jul 2015 22:10:53 -0700 > Are the other -stable tree maintainers picking up patches after > you've submitted to 4.1/3.18/3.14, or is it necessary to make separate > requests? I don't know and I frankly don't care. -- To unsubscribe from this list: send the

Re: Stable request for gso feature flag and error handling fixes

David Miller wrote: >From: Jay Vosburgh >Date: Tue, 07 Jul 2015 17:38:50 -0700 > >> Please consider commit > >When you ask me to consider commits for -stable you have to tell >me what -stable releases you want me to submit them for. > >Currently I am only doing -stable submissions for 4.1.x

Re: Stable request for gso feature flag and error handling fixes

From: Jay Vosburgh Date: Tue, 07 Jul 2015 17:38:50 -0700 > Please consider commit When you ask me to consider commits for -stable you have to tell me what -stable releases you want me to submit them for. Currently I am only doing -stable submissions for 4.1.x, 3.18.x and 3.14.x -- To unsu

Stable request for gso feature flag and error handling fixes

Please consider commit commit 1e16aa3ddf863c6b9f37eddf52503230a62dedb3 Author: Florian Westphal Date: Mon Oct 20 13:49:16 2014 +0200 net: gso: use feature flag argument in all protocol gso handlers and, at your discretion, the related commit commit 330966e501ffe282d7184f

Re: Stable request 9374e7d2 "rtlwifi: rtl8192cu: Add new device ID"

Please note that there are two commits just added to the mainline repo that should be propagated to all stable kernels. Both are addition of new USB IDs for an old driver, thus they will cause to side effects. Unfortunately, the Cc to stable was missed in the first of these, thus the need for th

Re: Stable request 9374e7d2 "rtlwifi: rtl8192cu: Add new device ID"

On Tuesday, April 28, 2015 at 04:22:34 PM, Anders Larsen wrote: > On 2015-04-28 16:10, Marek Vasut wrote: > > did you check [1] please? I might be wrong, but these are > > the official -stable submission guidelines to my knowledge. > > > > [1] https://www.kernel.org/doc/Documentation/stable_kernel

Re: Stable request 9374e7d2 "rtlwifi: rtl8192cu: Add new device ID"

On 2015-04-28 16:10, Marek Vasut wrote: did you check [1] please? I might be wrong, but these are the official -stable submission guidelines to my knowledge. [1] https://www.kernel.org/doc/Documentation/stable_kernel_rules.txt sure I did - networking has its own stable submission guidelines in

Re: Stable request 9374e7d2 "rtlwifi: rtl8192cu: Add new device ID"

On Tuesday, April 28, 2015 at 03:56:04 PM, Anders Larsen wrote: > Hi, > > commit 9374e7d2fdcad3c36dafc8d3effd554bc702c4b6 > Author: Marek Vasut > Date: 2015-03-26 02:16:06 +0100 > > rtlwifi: rtl8192cu: Add new device ID > > Add new ID for ASUS N10 WiFi dongle. > > in Linus' tree ha

Stable request 9374e7d2 "rtlwifi: rtl8192cu: Add new device ID"

Hi, commit 9374e7d2fdcad3c36dafc8d3effd554bc702c4b6 Author: Marek Vasut Date: 2015-03-26 02:16:06 +0100 rtlwifi: rtl8192cu: Add new device ID Add new ID for ASUS N10 WiFi dongle. in Linus' tree has been tested on 3.16.7 and 3.10.5x and applies cleanly all the way back to 3.2.68 Ple

Re: [stable request] mlx4 & dev_kfree_skb

From: Jiri Slaby Date: Mon, 27 Apr 2015 11:10:51 +0200 > On 04/21/2015, 08:30 PM, David Miller wrote: >> Please queue up the following networking bug fixes for 3.12, 3.14, 3.18, >> 3.19, and 4.0 -stable, respectively. > > Hi, > > similar to other "Call dev_kfree_skby_any instead of dev_kfree_sk

[stable request] mlx4 & dev_kfree_skb [was: [PATCHES] Networking]

On 04/21/2015, 08:30 PM, David Miller wrote: > Please queue up the following networking bug fixes for 3.12, 3.14, 3.18, > 3.19, and 4.0 -stable, respectively. Hi, similar to other "Call dev_kfree_skby_any instead of dev_kfree_skb.", I believe, that mlx4 (only) in 3.14 should receive the fix too: