Patch "net: fix harmonize_features() vs NETIF_F_HIGHDMA" has been added to the 4.9-stable tree
Subsystems (2)
This is a note to let you know that I've just added the patch titled
net: fix harmonize_features() vs NETIF_F_HIGHDMA
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
net-fix-harmonize_features-vs-netif_f_highdma.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From foo@baz Wed Feb 1 08:50:24 CET 2017
From: Eric Dumazet <[email protected]>
Date: Wed, 18 Jan 2017 12:12:17 -0800
Subject: net: fix harmonize_features() vs NETIF_F_HIGHDMA
From: Eric Dumazet <[email protected]>
[ Upstream commit 7be2c82cfd5d28d7adb66821a992604eb6dd112e ]
Ashizuka reported a highmem oddity and sent a patch for freescale fec driver.
But the problem root cause is that core networking stack must ensure no skb with highmem fragment is ever sent through a device that does not assert NETIF_F_HIGHDMA in its features.
We need to call illegal_highdma() from harmonize_features() regardless of CSUM checks.
--- net/core/dev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/core/dev.c +2 -2
@@ -2815,9 +2815,9 @@ static netdev_features_t harmonize_featuif (skb->ip_summed !=CHECKSUM_NONE && !can_checksum_protocol (features, type)) { features &= ~(NETIF_F_CSUM_MASK |NETIF_F_GSO_MASK ); - }else if (illegal_highdma (skb->dev, skb)) { - features &= ~NETIF_F_SG ; } +if (illegal_highdma (skb->dev, skb)) + features &= ~NETIF_F_SG ;return features; }
Patches currently in stable-queue which might be from [email protected] are
queue-4.9/mlx4-do-not-call-napi_schedule-without-care.patch queue-4.9/net-mlx5e-do-not-recycle-pages-from-emergency-reserve.patch queue-4.9/net-fix-harmonize_features-vs-netif_f_highdma.patch queue-4.9/tcp-fix-tcp_fastopen-unaligned-access-complaints-on-sparc.patch queue-4.9/tcp-initialize-max-window-for-a-new-fastopen-socket.patch