This is a note to let you know that I've just added the patch titled
net/sched: Fix update of lastuse in act modules implementing stats_update
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=sum…
The filename of the patch is:
net-sched-fix-update-of-lastuse-in-act-modules-implementing-stats_update.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 <stable(a)vger.kernel.org> know about it.
>From foo@baz Sat Jan 13 10:51:19 CET 2018
From: Roi Dayan <roid(a)mellanox.com>
Date: Tue, 26 Dec 2017 07:48:51 +0200
Subject: net/sched: Fix update of lastuse in act modules implementing stats_update
From: Roi Dayan <roid(a)mellanox.com>
[ Upstream commit 3bb23421a504f01551b7cb9dff0e41dbf16656b0 ]
We need to update lastuse to to the most updated value between what
is already set and the new value.
If HW matching fails, i.e. because of an issue, the stats are not updated
but it could be that software did match and updated lastuse.
Fixes: 5712bf9c5c30 ("net/sched: act_mirred: Use passed lastuse argument")
Fixes: 9fea47d93bcc ("net/sched: act_gact: Update statistics when offloaded to hardware")
Signed-off-by: Roi Dayan <roid(a)mellanox.com>
Reviewed-by: Paul Blakey <paulb(a)mellanox.com>
Acked-by: Jiri Pirko <jiri(a)mellanox.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sched/act_gact.c | 2 +-
net/sched/act_mirred.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/net/sched/act_gact.c
+++ b/net/sched/act_gact.c
@@ -161,7 +161,7 @@ static void tcf_gact_stats_update(struct
if (action == TC_ACT_SHOT)
this_cpu_ptr(gact->common.cpu_qstats)->drops += packets;
- tm->lastuse = lastuse;
+ tm->lastuse = max_t(u64, tm->lastuse, lastuse);
}
static int tcf_gact_dump(struct sk_buff *skb, struct tc_action *a,
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -211,7 +211,7 @@ static void tcf_stats_update(struct tc_a
struct tcf_t *tm = &m->tcf_tm;
_bstats_cpu_update(this_cpu_ptr(a->cpu_bstats), bytes, packets);
- tm->lastuse = lastuse;
+ tm->lastuse = max_t(u64, tm->lastuse, lastuse);
}
static int tcf_mirred_dump(struct sk_buff *skb, struct tc_action *a, int bind,
Patches currently in stable-queue which might be from roid(a)mellanox.com are
queue-4.9/net-sched-fix-update-of-lastuse-in-act-modules-implementing-stats_update.patch
This is a note to let you know that I've just added the patch titled
net: core: fix module type in sock_diag_bind
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=sum…
The filename of the patch is:
net-core-fix-module-type-in-sock_diag_bind.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 <stable(a)vger.kernel.org> know about it.
>From foo@baz Sat Jan 13 10:51:19 CET 2018
From: Andrii Vladyka <tulup(a)mail.ru>
Date: Thu, 4 Jan 2018 13:09:17 +0200
Subject: net: core: fix module type in sock_diag_bind
From: Andrii Vladyka <tulup(a)mail.ru>
[ Upstream commit b8fd0823e0770c2d5fdbd865bccf0d5e058e5287 ]
Use AF_INET6 instead of AF_INET in IPv6-related code path
Signed-off-by: Andrii Vladyka <tulup(a)mail.ru>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/sock_diag.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/sock_diag.c
+++ b/net/core/sock_diag.c
@@ -295,7 +295,7 @@ static int sock_diag_bind(struct net *ne
case SKNLGRP_INET6_UDP_DESTROY:
if (!sock_diag_handlers[AF_INET6])
request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
- NETLINK_SOCK_DIAG, AF_INET);
+ NETLINK_SOCK_DIAG, AF_INET6);
break;
}
return 0;
Patches currently in stable-queue which might be from tulup(a)mail.ru are
queue-4.9/net-core-fix-module-type-in-sock_diag_bind.patch
This is a note to let you know that I've just added the patch titled
mlxsw: spectrum_router: Fix NULL pointer deref
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=sum…
The filename of the patch is:
mlxsw-spectrum_router-fix-null-pointer-deref.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 <stable(a)vger.kernel.org> know about it.
>From foo@baz Sat Jan 13 10:51:19 CET 2018
From: Ido Schimmel <idosch(a)mellanox.com>
Date: Mon, 25 Dec 2017 08:57:35 +0100
Subject: mlxsw: spectrum_router: Fix NULL pointer deref
From: Ido Schimmel <idosch(a)mellanox.com>
[ Upstream commit 8764a8267b128405cf383157d5e9a4a3735d2409 ]
When we remove the neighbour associated with a nexthop we should always
refuse to write the nexthop to the adjacency table. Regardless if it is
already present in the table or not.
Otherwise, we risk dereferencing the NULL pointer that was set instead
of the neighbour.
Fixes: a7ff87acd995 ("mlxsw: spectrum_router: Implement next-hop routing")
Signed-off-by: Ido Schimmel <idosch(a)mellanox.com>
Reported-by: Alexander Petrovskiy <alexpe(a)mellanox.com>
Signed-off-by: Jiri Pirko <jiri(a)mellanox.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -1328,9 +1328,9 @@ set_trap:
static void __mlxsw_sp_nexthop_neigh_update(struct mlxsw_sp_nexthop *nh,
bool removing)
{
- if (!removing && !nh->should_offload)
+ if (!removing)
nh->should_offload = 1;
- else if (removing && nh->offloaded)
+ else
nh->should_offload = 0;
nh->update = 1;
}
Patches currently in stable-queue which might be from idosch(a)mellanox.com are
queue-4.9/mlxsw-spectrum_router-fix-null-pointer-deref.patch
This is a note to let you know that I've just added the patch titled
ipv6: fix possible mem leaks in ipv6_make_skb()
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=sum…
The filename of the patch is:
ipv6-fix-possible-mem-leaks-in-ipv6_make_skb.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 <stable(a)vger.kernel.org> know about it.
>From foo@baz Sat Jan 13 10:51:19 CET 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 10 Jan 2018 03:45:49 -0800
Subject: ipv6: fix possible mem leaks in ipv6_make_skb()
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 862c03ee1deb7e19e0f9931682e0294ecd1fcaf9 ]
ip6_setup_cork() might return an error, while memory allocations have
been done and must be rolled back.
Fixes: 6422398c2ab0 ("ipv6: introduce ipv6_make_skb")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Cc: Vlad Yasevich <vyasevich(a)gmail.com>
Reported-by: Mike Maloney <maloney(a)google.com>
Acked-by: Mike Maloney <maloney(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_output.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1800,9 +1800,10 @@ struct sk_buff *ip6_make_skb(struct sock
cork.base.opt = NULL;
v6_cork.opt = NULL;
err = ip6_setup_cork(sk, &cork, &v6_cork, ipc6, rt, fl6);
- if (err)
+ if (err) {
+ ip6_cork_release(&cork, &v6_cork);
return ERR_PTR(err);
-
+ }
if (ipc6->dontfrag < 0)
ipc6->dontfrag = inet6_sk(sk)->dontfrag;
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.9/lan78xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/cx82310_eth-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/sr9700-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/smsc75xx-use-skb_cow_head-to-deal-with-cloned-skbs.patch
queue-4.9/ipv6-fix-possible-mem-leaks-in-ipv6_make_skb.patch
This is a note to let you know that I've just added the patch titled
ip6_tunnel: disable dst caching if tunnel is dual-stack
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=sum…
The filename of the patch is:
ip6_tunnel-disable-dst-caching-if-tunnel-is-dual-stack.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 <stable(a)vger.kernel.org> know about it.
>From foo@baz Sat Jan 13 10:51:19 CET 2018
From: Eli Cooper <elicooper(a)gmx.com>
Date: Mon, 25 Dec 2017 10:43:49 +0800
Subject: ip6_tunnel: disable dst caching if tunnel is dual-stack
From: Eli Cooper <elicooper(a)gmx.com>
[ Upstream commit 23263ec86a5f44312d2899323872468752324107 ]
When an ip6_tunnel is in mode 'any', where the transport layer
protocol can be either 4 or 41, dst_cache must be disabled.
This is because xfrm policies might apply to only one of the two
protocols. Caching dst would cause xfrm policies for one protocol
incorrectly used for the other.
Signed-off-by: Eli Cooper <elicooper(a)gmx.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_tunnel.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1080,10 +1080,11 @@ int ip6_tnl_xmit(struct sk_buff *skb, st
memcpy(&fl6->daddr, addr6, sizeof(fl6->daddr));
neigh_release(neigh);
}
- } else if (!(t->parms.flags &
- (IP6_TNL_F_USE_ORIG_TCLASS | IP6_TNL_F_USE_ORIG_FWMARK))) {
- /* enable the cache only only if the routing decision does
- * not depend on the current inner header value
+ } else if (t->parms.proto != 0 && !(t->parms.flags &
+ (IP6_TNL_F_USE_ORIG_TCLASS |
+ IP6_TNL_F_USE_ORIG_FWMARK))) {
+ /* enable the cache only if neither the outer protocol nor the
+ * routing decision depends on the current inner header value
*/
use_cache = true;
}
Patches currently in stable-queue which might be from elicooper(a)gmx.com are
queue-4.9/ip6_tunnel-disable-dst-caching-if-tunnel-is-dual-stack.patch
This is a note to let you know that I've just added the patch titled
ethtool: do not print warning for applications using legacy API
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=sum…
The filename of the patch is:
ethtool-do-not-print-warning-for-applications-using-legacy-api.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 <stable(a)vger.kernel.org> know about it.
>From foo@baz Sat Jan 13 10:51:19 CET 2018
From: Stephen Hemminger <stephen(a)networkplumber.org>
Date: Fri, 29 Dec 2017 10:02:52 -0800
Subject: ethtool: do not print warning for applications using legacy API
From: Stephen Hemminger <stephen(a)networkplumber.org>
[ Upstream commit 71891e2dab6b55a870f8f7735e44a2963860b5c6 ]
In kernel log ths message appears on every boot:
"warning: `NetworkChangeNo' uses legacy ethtool link settings API,
link modes are only partially reported"
When ethtool link settings API changed, it started complaining about
usages of old API. Ironically, the original patch was from google but
the application using the legacy API is chrome.
Linux ABI is fixed as much as possible. The kernel must not break it
and should not complain about applications using legacy API's.
This patch just removes the warning since using legacy API's
in Linux is perfectly acceptable.
Fixes: 3f1ac7a700d0 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API")
Signed-off-by: Stephen Hemminger <stephen(a)networkplumber.org>
Signed-off-by: David Decotigny <decot(a)googlers.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/ethtool.c | 15 ++-------------
1 file changed, 2 insertions(+), 13 deletions(-)
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -742,15 +742,6 @@ static int ethtool_set_link_ksettings(st
return dev->ethtool_ops->set_link_ksettings(dev, &link_ksettings);
}
-static void
-warn_incomplete_ethtool_legacy_settings_conversion(const char *details)
-{
- char name[sizeof(current->comm)];
-
- pr_info_once("warning: `%s' uses legacy ethtool link settings API, %s\n",
- get_task_comm(name, current), details);
-}
-
/* Query device for its ethtool_cmd settings.
*
* Backward compatibility note: for compatibility with legacy ethtool,
@@ -777,10 +768,8 @@ static int ethtool_get_settings(struct n
&link_ksettings);
if (err < 0)
return err;
- if (!convert_link_ksettings_to_legacy_settings(&cmd,
- &link_ksettings))
- warn_incomplete_ethtool_legacy_settings_conversion(
- "link modes are only partially reported");
+ convert_link_ksettings_to_legacy_settings(&cmd,
+ &link_ksettings);
/* send a sensible cmd tag back to user */
cmd.cmd = ETHTOOL_GSET;
Patches currently in stable-queue which might be from stephen(a)networkplumber.org are
queue-4.9/ethtool-do-not-print-warning-for-applications-using-legacy-api.patch
This is a note to let you know that I've just added the patch titled
8021q: fix a memory leak for VLAN 0 device
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=sum…
The filename of the patch is:
8021q-fix-a-memory-leak-for-vlan-0-device.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 <stable(a)vger.kernel.org> know about it.
>From foo@baz Sat Jan 13 10:51:19 CET 2018
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Tue, 9 Jan 2018 13:40:41 -0800
Subject: 8021q: fix a memory leak for VLAN 0 device
From: Cong Wang <xiyou.wangcong(a)gmail.com>
[ Upstream commit 78bbb15f2239bc8e663aa20bbe1987c91a0b75f6 ]
A vlan device with vid 0 is allow to creat by not able to be fully
cleaned up by unregister_vlan_dev() which checks for vlan_id!=0.
Also, VLAN 0 is probably not a valid number and it is kinda
"reserved" for HW accelerating devices, but it is probably too
late to reject it from creation even if makes sense. Instead,
just remove the check in unregister_vlan_dev().
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)")
Cc: Vlad Yasevich <vyasevich(a)gmail.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/8021q/vlan.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -111,12 +111,7 @@ void unregister_vlan_dev(struct net_devi
vlan_gvrp_uninit_applicant(real_dev);
}
- /* Take it out of our own structures, but be sure to interlock with
- * HW accelerating devices or SW vlan input packet processing if
- * VLAN is not 0 (leave it there for 802.1p).
- */
- if (vlan_id)
- vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id);
+ vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id);
/* Get rid of the vlan's reference to real_dev */
dev_put(real_dev);
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.9/8021q-fix-a-memory-leak-for-vlan-0-device.patch
This is a note to let you know that I've just added the patch titled
sh_eth: fix TSU resource handling
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sh_eth-fix-tsu-resource-handling.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sat Jan 13 10:51:05 CET 2018
From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Date: Wed, 3 Jan 2018 20:09:49 +0300
Subject: sh_eth: fix TSU resource handling
From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
[ Upstream commit dfe8266b8dd10e12a731c985b725fcf7f0e537f0 ]
When switching the driver to the managed device API, I managed to break
the case of a dual Ether devices sharing a single TSU: the 2nd Ether port
wouldn't probe. Iwamatsu-san has tried to fix this but his patch was buggy
and he then dropped the ball...
The solution is to limit calling devm_request_mem_region() to the first
of the two ports sharing the same TSU, so devm_ioremap_resource() can't
be used anymore for the TSU resource...
Fixes: d5e07e69218f ("sh_eth: use managed device API")
Reported-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj(a)renesas.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/renesas/sh_eth.c | 25 ++++++++++++++++++++++---
1 file changed, 22 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -3212,10 +3212,29 @@ static int sh_eth_drv_probe(struct platf
/* ioremap the TSU registers */
if (mdp->cd->tsu) {
struct resource *rtsu;
+
rtsu = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- mdp->tsu_addr = devm_ioremap_resource(&pdev->dev, rtsu);
- if (IS_ERR(mdp->tsu_addr)) {
- ret = PTR_ERR(mdp->tsu_addr);
+ if (!rtsu) {
+ dev_err(&pdev->dev, "no TSU resource\n");
+ ret = -ENODEV;
+ goto out_release;
+ }
+ /* We can only request the TSU region for the first port
+ * of the two sharing this TSU for the probe to succeed...
+ */
+ if (devno % 2 == 0 &&
+ !devm_request_mem_region(&pdev->dev, rtsu->start,
+ resource_size(rtsu),
+ dev_name(&pdev->dev))) {
+ dev_err(&pdev->dev, "can't request TSU resource.\n");
+ ret = -EBUSY;
+ goto out_release;
+ }
+ mdp->tsu_addr = devm_ioremap(&pdev->dev, rtsu->start,
+ resource_size(rtsu));
+ if (!mdp->tsu_addr) {
+ dev_err(&pdev->dev, "TSU region ioremap() failed.\n");
+ ret = -ENOMEM;
goto out_release;
}
mdp->port = devno % 2;
Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are
queue-4.14/sh_eth-fix-sh7757-gether-initialization.patch
queue-4.14/sh_eth-fix-tsu-resource-handling.patch
This is a note to let you know that I've just added the patch titled
sh_eth: fix SH7757 GEther initialization
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sh_eth-fix-sh7757-gether-initialization.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sat Jan 13 10:51:05 CET 2018
From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Date: Thu, 4 Jan 2018 21:06:49 +0300
Subject: sh_eth: fix SH7757 GEther initialization
From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
[ Upstream commit 5133550296d43236439494aa955bfb765a89f615 ]
Renesas SH7757 has 2 Fast and 2 Gigabit Ether controllers, while the
'sh_eth' driver can only reset and initialize TSU of the first controller
pair. Shimoda-san tried to solve that adding the 'needs_init' member to the
'struct sh_eth_plat_data', however the platform code still never sets this
flag. I think that we can infer this information from the 'devno' variable
(set to 'platform_device::id') and reset/init the Ether controller pair
only for an even 'devno'; therefore 'sh_eth_plat_data::needs_init' can be
removed...
Fixes: 150647fb2c31 ("net: sh_eth: change the condition of initialization")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/renesas/sh_eth.c | 4 ++--
include/linux/sh_eth.h | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -3241,8 +3241,8 @@ static int sh_eth_drv_probe(struct platf
ndev->features = NETIF_F_HW_VLAN_CTAG_FILTER;
}
- /* initialize first or needed device */
- if (!devno || pd->needs_init) {
+ /* Need to init only the first port of the two sharing a TSU */
+ if (devno % 2 == 0) {
if (mdp->cd->chip_reset)
mdp->cd->chip_reset(ndev);
--- a/include/linux/sh_eth.h
+++ b/include/linux/sh_eth.h
@@ -17,7 +17,6 @@ struct sh_eth_plat_data {
unsigned char mac_addr[ETH_ALEN];
unsigned no_ether_link:1;
unsigned ether_link_active_low:1;
- unsigned needs_init:1;
};
#endif
Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are
queue-4.14/sh_eth-fix-sh7757-gether-initialization.patch
queue-4.14/sh_eth-fix-tsu-resource-handling.patch
This is a note to let you know that I've just added the patch titled
sfp: fix sfp-bus oops when removing socket/upstream
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sfp-fix-sfp-bus-oops-when-removing-socket-upstream.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sat Jan 13 10:51:05 CET 2018
From: Russell King <rmk+kernel(a)armlinux.org.uk>
Date: Tue, 26 Dec 2017 23:15:17 +0000
Subject: sfp: fix sfp-bus oops when removing socket/upstream
From: Russell King <rmk+kernel(a)armlinux.org.uk>
[ Upstream commit 0b2122e4934c7783d336397864e34ee53aad0965 ]
When we remove a socket or upstream, and the other side isn't
registered, we dereference a NULL pointer, causing a kernel oops.
Fix this.
Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages")
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/phy/sfp-bus.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -359,7 +359,8 @@ EXPORT_SYMBOL_GPL(sfp_register_upstream)
void sfp_unregister_upstream(struct sfp_bus *bus)
{
rtnl_lock();
- sfp_unregister_bus(bus);
+ if (bus->sfp)
+ sfp_unregister_bus(bus);
bus->upstream = NULL;
bus->netdev = NULL;
rtnl_unlock();
@@ -464,7 +465,8 @@ EXPORT_SYMBOL_GPL(sfp_register_socket);
void sfp_unregister_socket(struct sfp_bus *bus)
{
rtnl_lock();
- sfp_unregister_bus(bus);
+ if (bus->netdev)
+ sfp_unregister_bus(bus);
bus->sfp_dev = NULL;
bus->sfp = NULL;
bus->socket_ops = NULL;
Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are
queue-4.14/sfp-fix-sfp-bus-oops-when-removing-socket-upstream.patch
queue-4.14/phylink-ensure-we-report-link-down-when-los-asserted.patch