This is a note to let you know that I've just added the patch titled
net: mpls: Fix nexthop alive tracking on down events
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-mpls-fix-nexthop-alive-tracking-on-down-events.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 Mon Dec 18 14:12:34 CET 2017
From: David Ahern <dsa(a)cumulusnetworks.com>
Date: Mon, 13 Mar 2017 16:49:10 -0700
Subject: net: mpls: Fix nexthop alive tracking on down events
From: David Ahern <dsa(a)cumulusnetworks.com>
[ Upstream commit 61733c91c454a61be0ffc93fe46a5d5f2f048c1c ]
Alive tracking of nexthops can account for a link twice if the carrier
goes down followed by an admin down of the same link rendering multipath
routes useless. This is similar to 79099aab38c8 for UNREGISTER events and
DOWN events.
Fix by tracking number of alive nexthops in mpls_ifdown similar to the
logic in mpls_ifup. Checking the flags per nexthop once after all events
have been processed is simpler than trying to maintian a running count
through all event combinations.
Also, WRITE_ONCE is used instead of ACCESS_ONCE to set rt_nhn_alive
per a comment from checkpatch:
WARNING: Prefer WRITE_ONCE(<FOO>, <BAR>) over ACCESS_ONCE(<FOO>) = <BAR>
Fixes: c89359a42e2a4 ("mpls: support for dead routes")
Signed-off-by: David Ahern <dsa(a)cumulusnetworks.com>
Acked-by: Robert Shearman <rshearma(a)brocade.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mpls/af_mpls.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -937,6 +937,8 @@ static void mpls_ifdown(struct net_devic
{
struct mpls_route __rcu **platform_label;
struct net *net = dev_net(dev);
+ unsigned int nh_flags = RTNH_F_DEAD | RTNH_F_LINKDOWN;
+ unsigned int alive;
unsigned index;
platform_label = rtnl_dereference(net->mpls.platform_label);
@@ -946,9 +948,11 @@ static void mpls_ifdown(struct net_devic
if (!rt)
continue;
+ alive = 0;
change_nexthops(rt) {
if (rtnl_dereference(nh->nh_dev) != dev)
- continue;
+ goto next;
+
switch (event) {
case NETDEV_DOWN:
case NETDEV_UNREGISTER:
@@ -956,13 +960,16 @@ static void mpls_ifdown(struct net_devic
/* fall through */
case NETDEV_CHANGE:
nh->nh_flags |= RTNH_F_LINKDOWN;
- if (event != NETDEV_UNREGISTER)
- ACCESS_ONCE(rt->rt_nhn_alive) = rt->rt_nhn_alive - 1;
break;
}
if (event == NETDEV_UNREGISTER)
RCU_INIT_POINTER(nh->nh_dev, NULL);
+next:
+ if (!(nh->nh_flags & nh_flags))
+ alive++;
} endfor_nexthops(rt);
+
+ WRITE_ONCE(rt->rt_nhn_alive, alive);
}
}
Patches currently in stable-queue which might be from dsa(a)cumulusnetworks.com are
queue-4.9/net-mpls-fix-nexthop-alive-tracking-on-down-events.patch
This is a note to let you know that I've just added the patch titled
net/mlx5: Fix create autogroup prev initializer
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-mlx5-fix-create-autogroup-prev-initializer.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 Mon Dec 18 14:12:34 CET 2017
From: Paul Blakey <paulb(a)mellanox.com>
Date: Fri, 10 Mar 2017 14:33:01 +0200
Subject: net/mlx5: Fix create autogroup prev initializer
From: Paul Blakey <paulb(a)mellanox.com>
[ Upstream commit af36370569eb37420e1e78a2e60c277b781fcd00 ]
The autogroups list is a list of non overlapping group boundaries
sorted by their start index. If the autogroups list wasn't empty
and an empty group slot was found at the start of the list,
the new group was added to the end of the list instead of the
beginning, as the prev initializer was incorrect.
When this was repeated, it caused multiple groups to have
overlapping boundaries.
Fixed that by correctly initializing the prev pointer to the
start of the list.
Fixes: eccec8da3b4e ('net/mlx5: Keep autogroups list ordered')
Signed-off-by: Paul Blakey <paulb(a)mellanox.com>
Reviewed-by: Mark Bloch <markb(a)mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
@@ -1015,7 +1015,7 @@ static struct mlx5_flow_group *create_au
u32 *match_criteria)
{
int inlen = MLX5_ST_SZ_BYTES(create_flow_group_in);
- struct list_head *prev = ft->node.children.prev;
+ struct list_head *prev = &ft->node.children;
unsigned int candidate_index = 0;
struct mlx5_flow_group *fg;
void *match_criteria_addr;
Patches currently in stable-queue which might be from paulb(a)mellanox.com are
queue-4.9/net-mlx5-fix-create-autogroup-prev-initializer.patch
This is a note to let you know that I've just added the patch titled
net/mlx5: Don't save PCI state when PCI error is detected
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-mlx5-don-t-save-pci-state-when-pci-error-is-detected.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 Mon Dec 18 14:12:34 CET 2017
From: Daniel Jurgens <danielj(a)mellanox.com>
Date: Fri, 10 Mar 2017 14:33:02 +0200
Subject: net/mlx5: Don't save PCI state when PCI error is detected
From: Daniel Jurgens <danielj(a)mellanox.com>
[ Upstream commit 5d47f6c89d568ab61712d8c40676fbb020b68752 ]
When a PCI error is detected the PCI state could be corrupt, don't save
it in that flow. Save the state after initialization. After restoring the
PCI state during slot reset save it again, restoring the state destroys
the previously saved state info.
Fixes: 05ac2c0b7438 ('net/mlx5: Fix race between PCI error handlers and
health work')
Signed-off-by: Daniel Jurgens <danielj(a)mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -1283,6 +1283,7 @@ static int init_one(struct pci_dev *pdev
if (err)
goto clean_load;
+ pci_save_state(pdev);
return 0;
clean_load:
@@ -1331,9 +1332,8 @@ static pci_ers_result_t mlx5_pci_err_det
mlx5_enter_error_state(dev);
mlx5_unload_one(dev, priv, false);
- /* In case of kernel call save the pci state and drain the health wq */
+ /* In case of kernel call drain the health wq */
if (state) {
- pci_save_state(pdev);
mlx5_drain_health_wq(dev);
mlx5_pci_disable_device(dev);
}
@@ -1385,6 +1385,7 @@ static pci_ers_result_t mlx5_pci_slot_re
pci_set_master(pdev);
pci_restore_state(pdev);
+ pci_save_state(pdev);
if (wait_vital(pdev)) {
dev_err(&pdev->dev, "%s: wait_vital timed out\n", __func__);
Patches currently in stable-queue which might be from danielj(a)mellanox.com are
queue-4.9/ib-core-fix-calculation-of-maximum-roce-mtu.patch
queue-4.9/net-mlx5-don-t-save-pci-state-when-pci-error-is-detected.patch
This is a note to let you know that I've just added the patch titled
net/mlx4_core: Avoid delays during VF driver device shutdown
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-mlx4_core-avoid-delays-during-vf-driver-device-shutdown.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 Mon Dec 18 14:12:34 CET 2017
From: Jack Morgenstein <jackm(a)dev.mellanox.co.il>
Date: Mon, 13 Mar 2017 19:29:08 +0200
Subject: net/mlx4_core: Avoid delays during VF driver device shutdown
From: Jack Morgenstein <jackm(a)dev.mellanox.co.il>
[ Upstream commit 4cbe4dac82e423ecc9a0ba46af24a860853259f4 ]
Some Hypervisors detach VFs from VMs by instantly causing an FLR event
to be generated for a VF.
In the mlx4 case, this will cause that VF's comm channel to be disabled
before the VM has an opportunity to invoke the VF device's "shutdown"
method.
For such Hypervisors, there is a race condition between the VF's
shutdown method and its internal-error detection/reset thread.
The internal-error detection/reset thread (which runs every 5 seconds) also
detects a disabled comm channel. If the internal-error detection/reset
flow wins the race, we still get delays (while that flow tries repeatedly
to detect comm-channel recovery).
The cited commit fixed the command timeout problem when the
internal-error detection/reset flow loses the race.
This commit avoids the unneeded delays when the internal-error
detection/reset flow wins.
Fixes: d585df1c5ccf ("net/mlx4_core: Avoid command timeouts during VF driver device shutdown")
Signed-off-by: Jack Morgenstein <jackm(a)dev.mellanox.co.il>
Reported-by: Simon Xiao <sixiao(a)microsoft.com>
Signed-off-by: Tariq Toukan <tariqt(a)mellanox.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx4/cmd.c | 11 +++++++++++
drivers/net/ethernet/mellanox/mlx4/main.c | 11 +++++++++++
include/linux/mlx4/device.h | 1 +
3 files changed, 23 insertions(+)
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -2304,6 +2304,17 @@ static int sync_toggles(struct mlx4_dev
rd_toggle = swab32(readl(&priv->mfunc.comm->slave_read));
if (wr_toggle == 0xffffffff || rd_toggle == 0xffffffff) {
/* PCI might be offline */
+
+ /* If device removal has been requested,
+ * do not continue retrying.
+ */
+ if (dev->persist->interface_state &
+ MLX4_INTERFACE_STATE_NOWAIT) {
+ mlx4_warn(dev,
+ "communication channel is offline\n");
+ return -EIO;
+ }
+
msleep(100);
wr_toggle = swab32(readl(&priv->mfunc.comm->
slave_write));
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -1940,6 +1940,14 @@ static int mlx4_comm_check_offline(struc
(u32)(1 << COMM_CHAN_OFFLINE_OFFSET));
if (!offline_bit)
return 0;
+
+ /* If device removal has been requested,
+ * do not continue retrying.
+ */
+ if (dev->persist->interface_state &
+ MLX4_INTERFACE_STATE_NOWAIT)
+ break;
+
/* There are cases as part of AER/Reset flow that PF needs
* around 100 msec to load. We therefore sleep for 100 msec
* to allow other tasks to make use of that CPU during this
@@ -3954,6 +3962,9 @@ static void mlx4_remove_one(struct pci_d
struct devlink *devlink = priv_to_devlink(priv);
int active_vfs = 0;
+ if (mlx4_is_slave(dev))
+ persist->interface_state |= MLX4_INTERFACE_STATE_NOWAIT;
+
mutex_lock(&persist->interface_state_mutex);
persist->interface_state |= MLX4_INTERFACE_STATE_DELETION;
mutex_unlock(&persist->interface_state_mutex);
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -476,6 +476,7 @@ enum {
enum {
MLX4_INTERFACE_STATE_UP = 1 << 0,
MLX4_INTERFACE_STATE_DELETION = 1 << 1,
+ MLX4_INTERFACE_STATE_NOWAIT = 1 << 2,
};
#define MSTR_SM_CHANGE_MASK (MLX4_EQ_PORT_INFO_MSTR_SM_SL_CHANGE_MASK | \
Patches currently in stable-queue which might be from jackm(a)dev.mellanox.co.il are
queue-4.9/net-mlx4_core-avoid-delays-during-vf-driver-device-shutdown.patch
This is a note to let you know that I've just added the patch titled
net: initialize msg.msg_flags in recvfrom
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-initialize-msg.msg_flags-in-recvfrom.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 Mon Dec 18 14:12:34 CET 2017
From: Alexander Potapenko <glider(a)google.com>
Date: Wed, 8 Mar 2017 18:08:16 +0100
Subject: net: initialize msg.msg_flags in recvfrom
From: Alexander Potapenko <glider(a)google.com>
[ Upstream commit 9f138fa609c47403374a862a08a41394be53d461 ]
KMSAN reports a use of uninitialized memory in put_cmsg() because
msg.msg_flags in recvfrom haven't been initialized properly.
The flag values don't affect the result on this path, but it's still a
good idea to initialize them explicitly.
Signed-off-by: Alexander Potapenko <glider(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/socket.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/socket.c
+++ b/net/socket.c
@@ -1702,6 +1702,7 @@ SYSCALL_DEFINE6(recvfrom, int, fd, void
/* We assume all kernel code knows the size of sockaddr_storage */
msg.msg_namelen = 0;
msg.msg_iocb = NULL;
+ msg.msg_flags = 0;
if (sock->file->f_flags & O_NONBLOCK)
flags |= MSG_DONTWAIT;
err = sock_recvmsg(sock, &msg, flags);
Patches currently in stable-queue which might be from glider(a)google.com are
queue-4.9/net-initialize-msg.msg_flags-in-recvfrom.patch
This is a note to let you know that I've just added the patch titled
net: bcmgenet: reserved phy revisions must be checked first
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-bcmgenet-reserved-phy-revisions-must-be-checked-first.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 Mon Dec 18 14:12:34 CET 2017
From: Doug Berger <opendmb(a)gmail.com>
Date: Thu, 9 Mar 2017 16:58:45 -0800
Subject: net: bcmgenet: reserved phy revisions must be checked first
From: Doug Berger <opendmb(a)gmail.com>
[ Upstream commit eca4bad73409aedc6ff22f823c18b67a4f08c851 ]
The reserved gphy_rev value of 0x01ff must be tested before the old
or new scheme for GPHY major versioning are tested, otherwise it will
be treated as 0xff00 according to the old scheme.
Fixes: b04a2f5b9ff5 ("net: bcmgenet: add support for new GENET PHY revision scheme")
Signed-off-by: Doug Berger <opendmb(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -3233,6 +3233,12 @@ static void bcmgenet_set_hw_params(struc
*/
gphy_rev = reg & 0xffff;
+ /* This is reserved so should require special treatment */
+ if (gphy_rev == 0 || gphy_rev == 0x01ff) {
+ pr_warn("Invalid GPHY revision detected: 0x%04x\n", gphy_rev);
+ return;
+ }
+
/* This is the good old scheme, just GPHY major, no minor nor patch */
if ((gphy_rev & 0xf0) != 0)
priv->gphy_rev = gphy_rev << 8;
@@ -3241,12 +3247,6 @@ static void bcmgenet_set_hw_params(struc
else if ((gphy_rev & 0xff00) != 0)
priv->gphy_rev = gphy_rev;
- /* This is reserved so should require special treatment */
- else if (gphy_rev == 0 || gphy_rev == 0x01ff) {
- pr_warn("Invalid GPHY revision detected: 0x%04x\n", gphy_rev);
- return;
- }
-
#ifdef CONFIG_PHYS_ADDR_T_64BIT
if (!(params->flags & GENET_HAS_40BITS))
pr_warn("GENET does not support 40-bits PA\n");
Patches currently in stable-queue which might be from opendmb(a)gmail.com are
queue-4.9/net-bcmgenet-synchronize-irq0-status-between-the-isr-and-task.patch
queue-4.9/net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch
queue-4.9/net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch
queue-4.9/net-bcmgenet-power-down-internal-phy-if-open-or-resume-fails.patch
queue-4.9/net-bcmgenet-reserved-phy-revisions-must-be-checked-first.patch
queue-4.9/net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch
This is a note to let you know that I've just added the patch titled
net: bcmgenet: Power up the internal PHY before probing the MII
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-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.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 Mon Dec 18 14:12:34 CET 2017
From: Doug Berger <opendmb(a)gmail.com>
Date: Thu, 9 Mar 2017 16:58:48 -0800
Subject: net: bcmgenet: Power up the internal PHY before probing the MII
From: Doug Berger <opendmb(a)gmail.com>
[ Upstream commit 6be371b053dc86f11465cc1abce2e99bda0a0574 ]
When using the internal PHY it must be powered up when the MII is probed
or the PHY will not be detected. Since the PHY is powered up at reset
this has not been a problem. However, when the kernel is restarted with
kexec the PHY will likely be powered down when the kernel starts so it
will not be detected and the Ethernet link will not be established.
This commit explicitly powers up the internal PHY when the GENET driver
is probed to correct this behavior.
Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger <opendmb(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -3296,6 +3296,7 @@ static int bcmgenet_probe(struct platfor
const void *macaddr;
struct resource *r;
int err = -EIO;
+ const char *phy_mode_str;
/* Up to GENET_MAX_MQ_CNT + 1 TX queues and RX queues */
dev = alloc_etherdev_mqs(sizeof(*priv), GENET_MAX_MQ_CNT + 1,
@@ -3403,6 +3404,13 @@ static int bcmgenet_probe(struct platfor
priv->clk_eee = NULL;
}
+ /* If this is an internal GPHY, power it on now, before UniMAC is
+ * brought out of reset as absolutely no UniMAC activity is allowed
+ */
+ if (dn && !of_property_read_string(dn, "phy-mode", &phy_mode_str) &&
+ !strcasecmp(phy_mode_str, "internal"))
+ bcmgenet_power_up(priv, GENET_POWER_PASSIVE);
+
err = reset_umac(priv);
if (err)
goto err_clk_disable;
Patches currently in stable-queue which might be from opendmb(a)gmail.com are
queue-4.9/net-bcmgenet-synchronize-irq0-status-between-the-isr-and-task.patch
queue-4.9/net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch
queue-4.9/net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch
queue-4.9/net-bcmgenet-power-down-internal-phy-if-open-or-resume-fails.patch
queue-4.9/net-bcmgenet-reserved-phy-revisions-must-be-checked-first.patch
queue-4.9/net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch
This is a note to let you know that I've just added the patch titled
net: bcmgenet: power down internal phy if open or resume fails
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-bcmgenet-power-down-internal-phy-if-open-or-resume-fails.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 Mon Dec 18 14:12:34 CET 2017
From: Doug Berger <opendmb(a)gmail.com>
Date: Thu, 9 Mar 2017 16:58:46 -0800
Subject: net: bcmgenet: power down internal phy if open or resume fails
From: Doug Berger <opendmb(a)gmail.com>
[ Upstream commit 7627409cc4970e8c8b9de6945ad86a575290a94e ]
Since the internal PHY is powered up during the open and resume
functions it should be powered back down if the functions fail.
Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger <opendmb(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2857,6 +2857,8 @@ err_irq0:
err_fini_dma:
bcmgenet_fini_dma(priv);
err_clk_disable:
+ if (priv->internal_phy)
+ bcmgenet_power_down(priv, GENET_POWER_PASSIVE);
clk_disable_unprepare(priv->clk);
return ret;
}
@@ -3560,6 +3562,8 @@ static int bcmgenet_resume(struct device
return 0;
out_clk_disable:
+ if (priv->internal_phy)
+ bcmgenet_power_down(priv, GENET_POWER_PASSIVE);
clk_disable_unprepare(priv->clk);
return ret;
}
Patches currently in stable-queue which might be from opendmb(a)gmail.com are
queue-4.9/net-bcmgenet-synchronize-irq0-status-between-the-isr-and-task.patch
queue-4.9/net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch
queue-4.9/net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch
queue-4.9/net-bcmgenet-power-down-internal-phy-if-open-or-resume-fails.patch
queue-4.9/net-bcmgenet-reserved-phy-revisions-must-be-checked-first.patch
queue-4.9/net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch
This is a note to let you know that I've just added the patch titled
net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values
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-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.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 Mon Dec 18 14:12:34 CET 2017
From: Doug Berger <opendmb(a)gmail.com>
Date: Thu, 9 Mar 2017 16:58:43 -0800
Subject: net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values
From: Doug Berger <opendmb(a)gmail.com>
[ Upstream commit ffff71328a3c321f7c14cc1edd33577717037744 ]
The location of the RBUF overflow and error counters has moved between
different version of the GENET MAC. This commit corrects the driver to
read from the correct locations depending on the version of the GENET
MAC.
Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger <opendmb(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 60 ++++++++++++++++++++++---
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 10 ++--
2 files changed, 60 insertions(+), 10 deletions(-)
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1,7 +1,7 @@
/*
* Broadcom GENET (Gigabit Ethernet) controller driver
*
- * Copyright (c) 2014 Broadcom Corporation
+ * Copyright (c) 2014-2017 Broadcom
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -778,8 +778,9 @@ static const struct bcmgenet_stats bcmge
STAT_GENET_RUNT("rx_runt_bytes", mib.rx_runt_bytes),
/* Misc UniMAC counters */
STAT_GENET_MISC("rbuf_ovflow_cnt", mib.rbuf_ovflow_cnt,
- UMAC_RBUF_OVFL_CNT),
- STAT_GENET_MISC("rbuf_err_cnt", mib.rbuf_err_cnt, UMAC_RBUF_ERR_CNT),
+ UMAC_RBUF_OVFL_CNT_V1),
+ STAT_GENET_MISC("rbuf_err_cnt", mib.rbuf_err_cnt,
+ UMAC_RBUF_ERR_CNT_V1),
STAT_GENET_MISC("mdf_err_cnt", mib.mdf_err_cnt, UMAC_MDF_ERR_CNT),
STAT_GENET_SOFT_MIB("alloc_rx_buff_failed", mib.alloc_rx_buff_failed),
STAT_GENET_SOFT_MIB("rx_dma_failed", mib.rx_dma_failed),
@@ -821,6 +822,45 @@ static void bcmgenet_get_strings(struct
}
}
+static u32 bcmgenet_update_stat_misc(struct bcmgenet_priv *priv, u16 offset)
+{
+ u16 new_offset;
+ u32 val;
+
+ switch (offset) {
+ case UMAC_RBUF_OVFL_CNT_V1:
+ if (GENET_IS_V2(priv))
+ new_offset = RBUF_OVFL_CNT_V2;
+ else
+ new_offset = RBUF_OVFL_CNT_V3PLUS;
+
+ val = bcmgenet_rbuf_readl(priv, new_offset);
+ /* clear if overflowed */
+ if (val == ~0)
+ bcmgenet_rbuf_writel(priv, 0, new_offset);
+ break;
+ case UMAC_RBUF_ERR_CNT_V1:
+ if (GENET_IS_V2(priv))
+ new_offset = RBUF_ERR_CNT_V2;
+ else
+ new_offset = RBUF_ERR_CNT_V3PLUS;
+
+ val = bcmgenet_rbuf_readl(priv, new_offset);
+ /* clear if overflowed */
+ if (val == ~0)
+ bcmgenet_rbuf_writel(priv, 0, new_offset);
+ break;
+ default:
+ val = bcmgenet_umac_readl(priv, offset);
+ /* clear if overflowed */
+ if (val == ~0)
+ bcmgenet_umac_writel(priv, 0, offset);
+ break;
+ }
+
+ return val;
+}
+
static void bcmgenet_update_mib_counters(struct bcmgenet_priv *priv)
{
int i, j = 0;
@@ -845,10 +885,16 @@ static void bcmgenet_update_mib_counters
UMAC_MIB_START + j + offset);
break;
case BCMGENET_STAT_MISC:
- val = bcmgenet_umac_readl(priv, s->reg_offset);
- /* clear if overflowed */
- if (val == ~0)
- bcmgenet_umac_writel(priv, 0, s->reg_offset);
+ if (GENET_IS_V1(priv)) {
+ val = bcmgenet_umac_readl(priv, s->reg_offset);
+ /* clear if overflowed */
+ if (val == ~0)
+ bcmgenet_umac_writel(priv, 0,
+ s->reg_offset);
+ } else {
+ val = bcmgenet_update_stat_misc(priv,
+ s->reg_offset);
+ }
break;
}
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014 Broadcom Corporation
+ * Copyright (c) 2014-2017 Broadcom
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -214,7 +214,9 @@ struct bcmgenet_mib_counters {
#define MDIO_REG_SHIFT 16
#define MDIO_REG_MASK 0x1F
-#define UMAC_RBUF_OVFL_CNT 0x61C
+#define UMAC_RBUF_OVFL_CNT_V1 0x61C
+#define RBUF_OVFL_CNT_V2 0x80
+#define RBUF_OVFL_CNT_V3PLUS 0x94
#define UMAC_MPD_CTRL 0x620
#define MPD_EN (1 << 0)
@@ -224,7 +226,9 @@ struct bcmgenet_mib_counters {
#define UMAC_MPD_PW_MS 0x624
#define UMAC_MPD_PW_LS 0x628
-#define UMAC_RBUF_ERR_CNT 0x634
+#define UMAC_RBUF_ERR_CNT_V1 0x634
+#define RBUF_ERR_CNT_V2 0x84
+#define RBUF_ERR_CNT_V3PLUS 0x98
#define UMAC_MDF_ERR_CNT 0x638
#define UMAC_MDF_CTRL 0x650
#define UMAC_MDF_ADDR 0x654
Patches currently in stable-queue which might be from opendmb(a)gmail.com are
queue-4.9/net-bcmgenet-synchronize-irq0-status-between-the-isr-and-task.patch
queue-4.9/net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch
queue-4.9/net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch
queue-4.9/net-bcmgenet-power-down-internal-phy-if-open-or-resume-fails.patch
queue-4.9/net-bcmgenet-reserved-phy-revisions-must-be-checked-first.patch
queue-4.9/net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch
This is a note to let you know that I've just added the patch titled
net: bcmgenet: correct MIB access of UniMAC RUNT counters
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-bcmgenet-correct-mib-access-of-unimac-runt-counters.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 Mon Dec 18 14:12:34 CET 2017
From: Doug Berger <opendmb(a)gmail.com>
Date: Thu, 9 Mar 2017 16:58:44 -0800
Subject: net: bcmgenet: correct MIB access of UniMAC RUNT counters
From: Doug Berger <opendmb(a)gmail.com>
[ Upstream commit 1ad3d225e5a40ca6c586989b4baaca710544c15a ]
The gap between the Tx status counters and the Rx RUNT counters is now
being added to allow correct reporting of the registers.
Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger <opendmb(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -876,13 +876,16 @@ static void bcmgenet_update_mib_counters
case BCMGENET_STAT_NETDEV:
case BCMGENET_STAT_SOFT:
continue;
- case BCMGENET_STAT_MIB_RX:
- case BCMGENET_STAT_MIB_TX:
case BCMGENET_STAT_RUNT:
- if (s->type != BCMGENET_STAT_MIB_RX)
- offset = BCMGENET_STAT_OFFSET;
+ offset += BCMGENET_STAT_OFFSET;
+ /* fall through */
+ case BCMGENET_STAT_MIB_TX:
+ offset += BCMGENET_STAT_OFFSET;
+ /* fall through */
+ case BCMGENET_STAT_MIB_RX:
val = bcmgenet_umac_readl(priv,
UMAC_MIB_START + j + offset);
+ offset = 0; /* Reset Offset */
break;
case BCMGENET_STAT_MISC:
if (GENET_IS_V1(priv)) {
Patches currently in stable-queue which might be from opendmb(a)gmail.com are
queue-4.9/net-bcmgenet-synchronize-irq0-status-between-the-isr-and-task.patch
queue-4.9/net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch
queue-4.9/net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch
queue-4.9/net-bcmgenet-power-down-internal-phy-if-open-or-resume-fails.patch
queue-4.9/net-bcmgenet-reserved-phy-revisions-must-be-checked-first.patch
queue-4.9/net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch
This is a note to let you know that I've just added the patch titled
mmc: mediatek: Fixed bug where clock frequency could be set wrong
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:
mmc-mediatek-fixed-bug-where-clock-frequency-could-be-set-wrong.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 Mon Dec 18 14:12:34 CET 2017
From: yong mao <yong.mao(a)mediatek.com>
Date: Sat, 4 Mar 2017 15:10:03 +0800
Subject: mmc: mediatek: Fixed bug where clock frequency could be set wrong
From: yong mao <yong.mao(a)mediatek.com>
[ Upstream commit 40ceda09c8c84694c2ca6b00bcc6dc71e8e62d96 ]
This patch can fix two issues:
Issue 1:
In previous code, div may be overflow when setting clock frequency
as f_min. We can use DIV_ROUND_UP to fix this boundary related
issue.
Issue 2:
In previous code, we can not set the correct clock frequency when
div equals 0xff.
Signed-off-by: Yong Mao <yong.mao(a)mediatek.com>
Signed-off-by: Chaotian Jing <chaotian.jing(a)mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz(a)chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/mtk-sd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -579,7 +579,7 @@ static void msdc_set_mclk(struct msdc_ho
}
}
sdr_set_field(host->base + MSDC_CFG, MSDC_CFG_CKMOD | MSDC_CFG_CKDIV,
- (mode << 8) | (div % 0xff));
+ (mode << 8) | div);
sdr_set_bits(host->base + MSDC_CFG, MSDC_CFG_CKPDN);
while (!(readl(host->base + MSDC_CFG) & MSDC_CFG_CKSTB))
cpu_relax();
@@ -1562,7 +1562,7 @@ static int msdc_drv_probe(struct platfor
host->src_clk_freq = clk_get_rate(host->src_clk);
/* Set host parameters to mmc */
mmc->ops = &mt_msdc_ops;
- mmc->f_min = host->src_clk_freq / (4 * 255);
+ mmc->f_min = DIV_ROUND_UP(host->src_clk_freq, 4 * 255);
mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23;
/* MMC core transfer sizes tunable parameters */
Patches currently in stable-queue which might be from yong.mao(a)mediatek.com are
queue-4.9/mmc-mediatek-fixed-bug-where-clock-frequency-could-be-set-wrong.patch
This is a note to let you know that I've just added the patch titled
mm: Handle 0 flags in _calc_vm_trans() macro
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:
mm-handle-0-flags-in-_calc_vm_trans-macro.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 Mon Dec 18 14:12:35 CET 2017
From: Jan Kara <jack(a)suse.cz>
Date: Fri, 3 Nov 2017 12:21:21 +0100
Subject: mm: Handle 0 flags in _calc_vm_trans() macro
From: Jan Kara <jack(a)suse.cz>
[ Upstream commit 592e254502041f953e84d091eae2c68cba04c10b ]
_calc_vm_trans() does not handle the situation when some of the passed
flags are 0 (which can happen if these VM flags do not make sense for
the architecture). Improve the _calc_vm_trans() macro to return 0 in
such situation. Since all passed flags are constant, this does not add
any runtime overhead.
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/mman.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/include/linux/mman.h
+++ b/include/linux/mman.h
@@ -63,8 +63,9 @@ static inline bool arch_validate_prot(un
* ("bit1" and "bit2" must be single bits)
*/
#define _calc_vm_trans(x, bit1, bit2) \
+ ((!(bit1) || !(bit2)) ? 0 : \
((bit1) <= (bit2) ? ((x) & (bit1)) * ((bit2) / (bit1)) \
- : ((x) & (bit1)) / ((bit1) / (bit2)))
+ : ((x) & (bit1)) / ((bit1) / (bit2))))
/*
* Combine the mmap "prot" argument into "vm_flags" used internally.
Patches currently in stable-queue which might be from jack(a)suse.cz are
queue-4.9/writeback-fix-memory-leak-in-wb_queue_work.patch
queue-4.9/mm-handle-0-flags-in-_calc_vm_trans-macro.patch
queue-4.9/udf-avoid-overflow-when-session-starts-at-large-offset.patch
This is a note to let you know that I've just added the patch titled
mlxsw: reg: Fix SPVMLR max record count
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-reg-fix-spvmlr-max-record-count.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 Mon Dec 18 14:12:34 CET 2017
From: Jiri Pirko <jiri(a)mellanox.com>
Date: Tue, 14 Mar 2017 14:00:01 +0100
Subject: mlxsw: reg: Fix SPVMLR max record count
From: Jiri Pirko <jiri(a)mellanox.com>
[ Upstream commit e9093b1183bbac462d2caef3eac165778c0b1bf1 ]
The num_rec field is 8 bit, so the maximal count number is 255.
This fixes vlans learning not being enabled for wider ranges than 255.
Fixes: a4feea74cd7a ("mlxsw: reg: Add Switch Port VLAN MAC Learning register definition")
Signed-off-by: Jiri Pirko <jiri(a)mellanox.com>
Reviewed-by: Ido Schimmel <idosch(a)mellanox.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlxsw/reg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/mellanox/mlxsw/reg.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/reg.h
@@ -1757,7 +1757,7 @@ static inline void mlxsw_reg_sfmr_pack(c
#define MLXSW_REG_SPVMLR_ID 0x2020
#define MLXSW_REG_SPVMLR_BASE_LEN 0x04 /* base length, without records */
#define MLXSW_REG_SPVMLR_REC_LEN 0x04 /* record length */
-#define MLXSW_REG_SPVMLR_REC_MAX_COUNT 256
+#define MLXSW_REG_SPVMLR_REC_MAX_COUNT 255
#define MLXSW_REG_SPVMLR_LEN (MLXSW_REG_SPVMLR_BASE_LEN + \
MLXSW_REG_SPVMLR_REC_LEN * \
MLXSW_REG_SPVMLR_REC_MAX_COUNT)
Patches currently in stable-queue which might be from jiri(a)mellanox.com are
queue-4.9/mlxsw-reg-fix-spvmlr-max-record-count.patch
queue-4.9/mlxsw-reg-fix-spvm-max-record-count.patch
This is a note to let you know that I've just added the patch titled
mlxsw: reg: Fix SPVM max record count
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-reg-fix-spvm-max-record-count.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 Mon Dec 18 14:12:34 CET 2017
From: Jiri Pirko <jiri(a)mellanox.com>
Date: Tue, 14 Mar 2017 14:00:00 +0100
Subject: mlxsw: reg: Fix SPVM max record count
From: Jiri Pirko <jiri(a)mellanox.com>
[ Upstream commit f004ec065b4879d6bc9ba0211af2169b3ce3097f ]
The num_rec field is 8 bit, so the maximal count number is 255. This
fixes vlans not being enabled for wider ranges than 255.
Fixes: b2e345f9a454 ("mlxsw: reg: Add Switch Port VID and Switch Port VLAN Membership registers definitions")
Signed-off-by: Jiri Pirko <jiri(a)mellanox.com>
Reviewed-by: Ido Schimmel <idosch(a)mellanox.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlxsw/reg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/mellanox/mlxsw/reg.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/reg.h
@@ -788,7 +788,7 @@ static inline void mlxsw_reg_spvid_pack(
#define MLXSW_REG_SPVM_ID 0x200F
#define MLXSW_REG_SPVM_BASE_LEN 0x04 /* base length, without records */
#define MLXSW_REG_SPVM_REC_LEN 0x04 /* record length */
-#define MLXSW_REG_SPVM_REC_MAX_COUNT 256
+#define MLXSW_REG_SPVM_REC_MAX_COUNT 255
#define MLXSW_REG_SPVM_LEN (MLXSW_REG_SPVM_BASE_LEN + \
MLXSW_REG_SPVM_REC_LEN * MLXSW_REG_SPVM_REC_MAX_COUNT)
Patches currently in stable-queue which might be from jiri(a)mellanox.com are
queue-4.9/mlxsw-reg-fix-spvmlr-max-record-count.patch
queue-4.9/mlxsw-reg-fix-spvm-max-record-count.patch
This is a note to let you know that I've just added the patch titled
md-cluster: free md_cluster_info if node leave cluster
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:
md-cluster-free-md_cluster_info-if-node-leave-cluster.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 Mon Dec 18 14:12:34 CET 2017
From: Guoqing Jiang <gqjiang(a)suse.com>
Date: Fri, 24 Feb 2017 11:15:12 +0800
Subject: md-cluster: free md_cluster_info if node leave cluster
From: Guoqing Jiang <gqjiang(a)suse.com>
[ Upstream commit 9c8043f337f14d1743006dfc59c03e80a42e3884 ]
To avoid memory leak, we need to free the cinfo which
is allocated when node join cluster.
Reviewed-by: NeilBrown <neilb(a)suse.com>
Signed-off-by: Guoqing Jiang <gqjiang(a)suse.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/md-cluster.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/md/md-cluster.c
+++ b/drivers/md/md-cluster.c
@@ -974,6 +974,7 @@ static int leave(struct mddev *mddev)
lockres_free(cinfo->bitmap_lockres);
unlock_all_bitmaps(mddev);
dlm_release_lockspace(cinfo->lockspace, 2);
+ kfree(cinfo);
return 0;
}
Patches currently in stable-queue which might be from gqjiang(a)suse.com are
queue-4.9/md-cluster-free-md_cluster_info-if-node-leave-cluster.patch
queue-4.9/badblocks-fix-wrong-return-value-in-badblocks_set-if-badblocks-are-disabled.patch
This is a note to let you know that I've just added the patch titled
macvlan: Only deliver one copy of the frame to the macvlan interface
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:
macvlan-only-deliver-one-copy-of-the-frame-to-the-macvlan-interface.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 Mon Dec 18 14:12:35 CET 2017
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
Date: Fri, 13 Oct 2017 13:40:24 -0700
Subject: macvlan: Only deliver one copy of the frame to the macvlan interface
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
[ Upstream commit dd6b9c2c332b40f142740d1b11fb77c653ff98ea ]
This patch intoduces a slight adjustment for macvlan to address the fact
that in source mode I was seeing two copies of any packet addressed to the
macvlan interface being delivered where there should have been only one.
The issue appears to be that one copy was delivered based on the source MAC
address and then the second copy was being delivered based on the
destination MAC address. To fix it I am just treating a unicast address
match as though it is not a match since source based macvlan isn't supposed
to be matching based on the destination MAC anyway.
Fixes: 79cf79abce71 ("macvlan: add source mode")
Signed-off-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/macvlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -452,7 +452,7 @@ static rx_handler_result_t macvlan_handl
struct macvlan_dev, list);
else
vlan = macvlan_hash_lookup(port, eth->h_dest);
- if (vlan == NULL)
+ if (!vlan || vlan->mode == MACVLAN_MODE_SOURCE)
return RX_HANDLER_PASS;
dev = vlan->dev;
Patches currently in stable-queue which might be from alexander.h.duyck(a)intel.com are
queue-4.9/macvlan-only-deliver-one-copy-of-the-frame-to-the-macvlan-interface.patch
This is a note to let you know that I've just added the patch titled
l2tp: cleanup l2tp_tunnel_delete calls
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:
l2tp-cleanup-l2tp_tunnel_delete-calls.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 Mon Dec 18 14:12:35 CET 2017
From: Jiri Slaby <jslaby(a)suse.cz>
Date: Wed, 25 Oct 2017 15:57:55 +0200
Subject: l2tp: cleanup l2tp_tunnel_delete calls
From: Jiri Slaby <jslaby(a)suse.cz>
[ Upstream commit 4dc12ffeaeac939097a3f55c881d3dc3523dff0c ]
l2tp_tunnel_delete does not return anything since commit 62b982eeb458
("l2tp: fix race condition in l2tp_tunnel_delete"). But call sites of
l2tp_tunnel_delete still do casts to void to avoid unused return value
warnings.
Kill these now useless casts.
Signed-off-by: Jiri Slaby <jslaby(a)suse.cz>
Cc: Sabrina Dubroca <sd(a)queasysnail.net>
Cc: Guillaume Nault <g.nault(a)alphalink.fr>
Cc: David S. Miller <davem(a)davemloft.net>
Cc: netdev(a)vger.kernel.org
Acked-by: Guillaume Nault <g.nault(a)alphalink.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/l2tp/l2tp_core.c | 2 +-
net/l2tp/l2tp_netlink.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1944,7 +1944,7 @@ static __net_exit void l2tp_exit_net(str
rcu_read_lock_bh();
list_for_each_entry_rcu(tunnel, &pn->l2tp_tunnel_list, list) {
- (void)l2tp_tunnel_delete(tunnel);
+ l2tp_tunnel_delete(tunnel);
}
rcu_read_unlock_bh();
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -287,7 +287,7 @@ static int l2tp_nl_cmd_tunnel_delete(str
l2tp_tunnel_notify(&l2tp_nl_family, info,
tunnel, L2TP_CMD_TUNNEL_DELETE);
- (void) l2tp_tunnel_delete(tunnel);
+ l2tp_tunnel_delete(tunnel);
out:
return ret;
Patches currently in stable-queue which might be from jslaby(a)suse.cz are
queue-4.9/l2tp-cleanup-l2tp_tunnel_delete-calls.patch
This is a note to let you know that I've just added the patch titled
KVM: nVMX: do not warn when MSR bitmap address is not backed
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:
kvm-nvmx-do-not-warn-when-msr-bitmap-address-is-not-backed.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 Mon Dec 18 14:12:34 CET 2017
From: Radim Krčmář <rkrcmar(a)redhat.com>
Date: Tue, 7 Mar 2017 17:51:49 +0100
Subject: KVM: nVMX: do not warn when MSR bitmap address is not backed
From: Radim Krčmář <rkrcmar(a)redhat.com>
[ Upstream commit 05d8d34611139f8435af90ac54b65eb31e82e388 ]
Before trying to do nested_get_page() in nested_vmx_merge_msr_bitmap(),
we have already checked that the MSR bitmap address is valid (4k aligned
and within physical limits). SDM doesn't specify what happens if the
there is no memory mapped at the valid address, but Intel CPUs treat the
situation as if the bitmap was configured to trap all MSRs.
KVM already does that by returning false and a correct handling doesn't
need the guest-trigerrable warning that was reported by syzkaller:
(The warning was originally there to catch some possible bugs in nVMX.)
------------[ cut here ]------------
WARNING: CPU: 0 PID: 7832 at arch/x86/kvm/vmx.c:9709
nested_vmx_merge_msr_bitmap arch/x86/kvm/vmx.c:9709 [inline]
WARNING: CPU: 0 PID: 7832 at arch/x86/kvm/vmx.c:9709
nested_get_vmcs12_pages+0xfb6/0x15c0 arch/x86/kvm/vmx.c:9640
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 7832 Comm: syz-executor1 Not tainted 4.10.0+ #229
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:15 [inline]
dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
panic+0x1fb/0x412 kernel/panic.c:179
__warn+0x1c4/0x1e0 kernel/panic.c:540
warn_slowpath_null+0x2c/0x40 kernel/panic.c:583
nested_vmx_merge_msr_bitmap arch/x86/kvm/vmx.c:9709 [inline]
nested_get_vmcs12_pages+0xfb6/0x15c0 arch/x86/kvm/vmx.c:9640
enter_vmx_non_root_mode arch/x86/kvm/vmx.c:10471 [inline]
nested_vmx_run+0x6186/0xaab0 arch/x86/kvm/vmx.c:10561
handle_vmlaunch+0x1a/0x20 arch/x86/kvm/vmx.c:7312
vmx_handle_exit+0xfc0/0x3f00 arch/x86/kvm/vmx.c:8526
vcpu_enter_guest arch/x86/kvm/x86.c:6982 [inline]
vcpu_run arch/x86/kvm/x86.c:7044 [inline]
kvm_arch_vcpu_ioctl_run+0x1418/0x4840 arch/x86/kvm/x86.c:7205
kvm_vcpu_ioctl+0x673/0x1120 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2570
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Reviewed-by: Jim Mattson <jmattson(a)google.com>
[Jim Mattson explained the bare metal behavior: "I believe this behavior
would be documented in the chipset data sheet rather than the SDM,
since the chipset returns all 1s for an unclaimed read."]
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -9543,10 +9543,8 @@ static inline bool nested_vmx_merge_msr_
return false;
page = nested_get_page(vcpu, vmcs12->msr_bitmap);
- if (!page) {
- WARN_ON(1);
+ if (!page)
return false;
- }
msr_bitmap_l1 = (unsigned long *)kmap(page);
if (!msr_bitmap_l1) {
nested_release_page_clean(page);
Patches currently in stable-queue which might be from rkrcmar(a)redhat.com are
queue-4.9/kvm-nvmx-do-not-warn-when-msr-bitmap-address-is-not-backed.patch
This is a note to let you know that I've just added the patch titled
iwlwifi: mvm: cleanup pending frames in DQA mode
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:
iwlwifi-mvm-cleanup-pending-frames-in-dqa-mode.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 Mon Dec 18 14:12:34 CET 2017
From: Sara Sharon <sara.sharon(a)intel.com>
Date: Tue, 14 Mar 2017 09:50:35 +0200
Subject: iwlwifi: mvm: cleanup pending frames in DQA mode
From: Sara Sharon <sara.sharon(a)intel.com>
[ Upstream commit 9a3fcf912ef7f5c6e18f9af6875dd13f7311f7aa ]
When a station is asleep, the fw will set it as "asleep".
All queues that are used only by one station will be stopped by
the fw.
In pre-DQA mode this was relevant for aggregation queues. However,
in DQA mode a queue is owned by one station only, so all queues
will be stopped.
As a result, we don't expect to get filtered frames back to
mac80211 and don't have to maintain the entire pending_frames
state logic, the same way as we do in aggregations.
The correct behavior is to align DQA behavior with the aggregation
queue behaviour pre-DQA:
- Don't count pending frames.
- Let mac80211 know we have frames in these queues so that it can
properly handle trigger frames.
When a trigger frame is received, mac80211 tells the driver to send
frames from the queues using release_buffered_frames.
The driver will tell the fw to let frames out even if the station
is asleep. This is done by iwl_mvm_sta_modify_sleep_tx_count.
Reported-and-tested-by: Jens Axboe <axboe(a)kernel.dk>
Reported-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Sara Sharon <sara.sharon(a)intel.com>
Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 5 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 11 +++--
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 2 -
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 41 +++++++++-------------
4 files changed, 28 insertions(+), 31 deletions(-)
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -2320,7 +2320,7 @@ iwl_mvm_mac_release_buffered_frames(stru
{
struct iwl_mvm *mvm = IWL_MAC80211_GET_MVM(hw);
- /* Called when we need to transmit (a) frame(s) from agg queue */
+ /* Called when we need to transmit (a) frame(s) from agg or dqa queue */
iwl_mvm_sta_modify_sleep_tx_count(mvm, sta, reason, num_frames,
tids, more_data, true);
@@ -2340,7 +2340,8 @@ static void iwl_mvm_mac_sta_notify(struc
for (tid = 0; tid < IWL_MAX_TID_COUNT; tid++) {
struct iwl_mvm_tid_data *tid_data = &mvmsta->tid_data[tid];
- if (tid_data->state != IWL_AGG_ON &&
+ if (!iwl_mvm_is_dqa_supported(mvm) &&
+ tid_data->state != IWL_AGG_ON &&
tid_data->state != IWL_EMPTYING_HW_QUEUE_DELBA)
continue;
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -3032,7 +3032,7 @@ void iwl_mvm_sta_modify_sleep_tx_count(s
struct ieee80211_sta *sta,
enum ieee80211_frame_release_type reason,
u16 cnt, u16 tids, bool more_data,
- bool agg)
+ bool single_sta_queue)
{
struct iwl_mvm_sta *mvmsta = iwl_mvm_sta_from_mac80211(sta);
struct iwl_mvm_add_sta_cmd cmd = {
@@ -3052,14 +3052,14 @@ void iwl_mvm_sta_modify_sleep_tx_count(s
for_each_set_bit(tid, &_tids, IWL_MAX_TID_COUNT)
cmd.awake_acs |= BIT(tid_to_ucode_ac[tid]);
- /* If we're releasing frames from aggregation queues then check if the
- * all queues combined that we're releasing frames from have
+ /* If we're releasing frames from aggregation or dqa queues then check
+ * if all the queues that we're releasing frames from, combined, have:
* - more frames than the service period, in which case more_data
* needs to be set
* - fewer than 'cnt' frames, in which case we need to adjust the
* firmware command (but do that unconditionally)
*/
- if (agg) {
+ if (single_sta_queue) {
int remaining = cnt;
int sleep_tx_count;
@@ -3069,7 +3069,8 @@ void iwl_mvm_sta_modify_sleep_tx_count(s
u16 n_queued;
tid_data = &mvmsta->tid_data[tid];
- if (WARN(tid_data->state != IWL_AGG_ON &&
+ if (WARN(!iwl_mvm_is_dqa_supported(mvm) &&
+ tid_data->state != IWL_AGG_ON &&
tid_data->state != IWL_EMPTYING_HW_QUEUE_DELBA,
"TID %d state is %d\n",
tid, tid_data->state)) {
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.h
@@ -545,7 +545,7 @@ void iwl_mvm_sta_modify_sleep_tx_count(s
struct ieee80211_sta *sta,
enum ieee80211_frame_release_type reason,
u16 cnt, u16 tids, bool more_data,
- bool agg);
+ bool single_sta_queue);
int iwl_mvm_drain_sta(struct iwl_mvm *mvm, struct iwl_mvm_sta *mvmsta,
bool drain);
void iwl_mvm_sta_modify_disable_tx(struct iwl_mvm *mvm,
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -7,7 +7,7 @@
*
* Copyright(c) 2012 - 2014 Intel Corporation. All rights reserved.
* Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
- * Copyright(c) 2016 Intel Deutschland GmbH
+ * Copyright(c) 2016 - 2017 Intel Deutschland GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of version 2 of the GNU General Public License as
@@ -34,6 +34,7 @@
*
* Copyright(c) 2012 - 2014 Intel Corporation. All rights reserved.
* Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
+ * Copyright(c) 2016 - 2017 Intel Deutschland GmbH
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -621,8 +622,10 @@ int iwl_mvm_tx_skb_non_sta(struct iwl_mv
* values.
* Note that we don't need to make sure it isn't agg'd, since we're
* TXing non-sta
+ * For DQA mode - we shouldn't increase it though
*/
- atomic_inc(&mvm->pending_frames[sta_id]);
+ if (!iwl_mvm_is_dqa_supported(mvm))
+ atomic_inc(&mvm->pending_frames[sta_id]);
return 0;
}
@@ -1009,11 +1012,8 @@ static int iwl_mvm_tx_mpdu(struct iwl_mv
spin_unlock(&mvmsta->lock);
- /* Increase pending frames count if this isn't AMPDU */
- if ((iwl_mvm_is_dqa_supported(mvm) &&
- mvmsta->tid_data[tx_cmd->tid_tspec].state != IWL_AGG_ON &&
- mvmsta->tid_data[tx_cmd->tid_tspec].state != IWL_AGG_STARTING) ||
- (!iwl_mvm_is_dqa_supported(mvm) && !is_ampdu))
+ /* Increase pending frames count if this isn't AMPDU or DQA queue */
+ if (!iwl_mvm_is_dqa_supported(mvm) && !is_ampdu)
atomic_inc(&mvm->pending_frames[mvmsta->sta_id]);
return 0;
@@ -1083,12 +1083,13 @@ static void iwl_mvm_check_ratid_empty(st
lockdep_assert_held(&mvmsta->lock);
if ((tid_data->state == IWL_AGG_ON ||
- tid_data->state == IWL_EMPTYING_HW_QUEUE_DELBA) &&
+ tid_data->state == IWL_EMPTYING_HW_QUEUE_DELBA ||
+ iwl_mvm_is_dqa_supported(mvm)) &&
iwl_mvm_tid_queued(tid_data) == 0) {
/*
- * Now that this aggregation queue is empty tell mac80211 so it
- * knows we no longer have frames buffered for the station on
- * this TID (for the TIM bitmap calculation.)
+ * Now that this aggregation or DQA queue is empty tell
+ * mac80211 so it knows we no longer have frames buffered for
+ * the station on this TID (for the TIM bitmap calculation.)
*/
ieee80211_sta_set_buffered(sta, tid, false);
}
@@ -1261,7 +1262,6 @@ static void iwl_mvm_rx_tx_cmd_single(str
u8 skb_freed = 0;
u16 next_reclaimed, seq_ctl;
bool is_ndp = false;
- bool txq_agg = false; /* Is this TXQ aggregated */
__skb_queue_head_init(&skbs);
@@ -1287,6 +1287,10 @@ static void iwl_mvm_rx_tx_cmd_single(str
info->flags |= IEEE80211_TX_STAT_ACK;
break;
case TX_STATUS_FAIL_DEST_PS:
+ /* In DQA, the FW should have stopped the queue and not
+ * return this status
+ */
+ WARN_ON(iwl_mvm_is_dqa_supported(mvm));
info->flags |= IEEE80211_TX_STAT_TX_FILTERED;
break;
default:
@@ -1391,15 +1395,6 @@ static void iwl_mvm_rx_tx_cmd_single(str
bool send_eosp_ndp = false;
spin_lock_bh(&mvmsta->lock);
- if (iwl_mvm_is_dqa_supported(mvm)) {
- enum iwl_mvm_agg_state state;
-
- state = mvmsta->tid_data[tid].state;
- txq_agg = (state == IWL_AGG_ON ||
- state == IWL_EMPTYING_HW_QUEUE_DELBA);
- } else {
- txq_agg = txq_id >= mvm->first_agg_queue;
- }
if (!is_ndp) {
tid_data->next_reclaimed = next_reclaimed;
@@ -1456,11 +1451,11 @@ static void iwl_mvm_rx_tx_cmd_single(str
* If the txq is not an AMPDU queue, there is no chance we freed
* several skbs. Check that out...
*/
- if (txq_agg)
+ if (iwl_mvm_is_dqa_supported(mvm) || txq_id >= mvm->first_agg_queue)
goto out;
/* We can't free more than one frame at once on a shared queue */
- WARN_ON(!iwl_mvm_is_dqa_supported(mvm) && (skb_freed > 1));
+ WARN_ON(skb_freed > 1);
/* If we have still frames for this STA nothing to do here */
if (!atomic_sub_and_test(skb_freed, &mvm->pending_frames[sta_id]))
Patches currently in stable-queue which might be from sara.sharon(a)intel.com are
queue-4.9/iwlwifi-mvm-cleanup-pending-frames-in-dqa-mode.patch
This is a note to let you know that I've just added the patch titled
iscsi-target: fix memory leak in lio_target_tiqn_addtpg()
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:
iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.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 Mon Dec 18 14:12:35 CET 2017
From: tangwenji <tang.wenji(a)zte.com.cn>
Date: Fri, 15 Sep 2017 16:03:13 +0800
Subject: iscsi-target: fix memory leak in lio_target_tiqn_addtpg()
From: tangwenji <tang.wenji(a)zte.com.cn>
[ Upstream commit 12d5a43b2dffb6cd28062b4e19024f7982393288 ]
tpg must free when call core_tpg_register() return fail
Signed-off-by: tangwenji <tang.wenji(a)zte.com.cn>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/iscsi/iscsi_target_configfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/target/iscsi/iscsi_target_configfs.c
+++ b/drivers/target/iscsi/iscsi_target_configfs.c
@@ -1144,7 +1144,7 @@ static struct se_portal_group *lio_targe
ret = core_tpg_register(wwn, &tpg->tpg_se_tpg, SCSI_PROTOCOL_ISCSI);
if (ret < 0)
- return NULL;
+ goto free_out;
ret = iscsit_tpg_add_portal_group(tiqn, tpg);
if (ret != 0)
@@ -1156,6 +1156,7 @@ static struct se_portal_group *lio_targe
return &tpg->tpg_se_tpg;
out:
core_tpg_deregister(&tpg->tpg_se_tpg);
+free_out:
kfree(tpg);
return NULL;
}
Patches currently in stable-queue which might be from tang.wenji(a)zte.com.cn are
queue-4.9/target-fix-condition-return-in-core_pr_dump_initiator_port.patch
queue-4.9/iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch
This is a note to let you know that I've just added the patch titled
irqchip/mvebu-odmi: Select GENERIC_MSI_IRQ_DOMAIN
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:
irqchip-mvebu-odmi-select-generic_msi_irq_domain.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 Mon Dec 18 14:12:34 CET 2017
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 14 Mar 2017 13:54:12 +0100
Subject: irqchip/mvebu-odmi: Select GENERIC_MSI_IRQ_DOMAIN
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit fa23b9d1b89fdc34f296f02e496a20aeff5736be ]
This driver uses the MSI domain but has no strict dependency on PCI_MSI, so we
may run into a build failure when CONFIG_GENERIC_MSI_IRQ_DOMAIN is disabled:
drivers/irqchip/irq-mvebu-odmi.c:152:15: error: variable 'odmi_msi_ops' has initializer but incomplete type
static struct msi_domain_ops odmi_msi_ops = {
^~~~~~~~~~~~~~
drivers/irqchip/irq-mvebu-odmi.c:155:15: error: variable 'odmi_msi_domain_info' has initializer but incomplete type
static struct msi_domain_info odmi_msi_domain_info = {
^~~~~~~~~~~~~~~
drivers/irqchip/irq-mvebu-odmi.c:156:3: error: 'struct msi_domain_info' has no member named 'flags'
.flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
^~~~~
drivers/irqchip/irq-mvebu-odmi.c:156:12: error: 'MSI_FLAG_USE_DEF_DOM_OPS' undeclared here (not in a function)
.flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/irqchip/irq-mvebu-odmi.c:156:39: error: 'MSI_FLAG_USE_DEF_CHIP_OPS' undeclared here (not in a function); did you mean 'MSI_FLAG_USE_DEF_DOM_OPS'?
Selecting the option from this driver seems to solve this nicely, though I could
not find any other instance of this in irqchip drivers.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Acked-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -258,6 +258,7 @@ config IRQ_MXS
config MVEBU_ODMI
bool
+ select GENERIC_MSI_IRQ_DOMAIN
config MVEBU_PIC
bool
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/irqchip-mvebu-odmi-select-generic_msi_irq_domain.patch
queue-4.9/drm-amd-remove-broken-include-path.patch
This is a note to let you know that I've just added the patch titled
iommu/mediatek: Fix driver name
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:
iommu-mediatek-fix-driver-name.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 Mon Dec 18 14:12:35 CET 2017
From: Matthias Brugger <matthias.bgg(a)gmail.com>
Date: Mon, 30 Oct 2017 12:37:55 +0100
Subject: iommu/mediatek: Fix driver name
From: Matthias Brugger <matthias.bgg(a)gmail.com>
[ Upstream commit 395df08d2e1de238a9c8c33fdcd0e2160efd63a9 ]
There exist two Mediatek iommu drivers for the two different
generations of the device. But both drivers have the same name
"mtk-iommu". This breaks the registration of the second driver:
Error: Driver 'mtk-iommu' is already registered, aborting...
Fix this by changing the name for first generation to
"mtk-iommu-v1".
Fixes: b17336c55d89 ("iommu/mediatek: add support for mtk iommu generation one HW")
Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com>
Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iommu/mtk_iommu_v1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -703,7 +703,7 @@ static struct platform_driver mtk_iommu_
.probe = mtk_iommu_probe,
.remove = mtk_iommu_remove,
.driver = {
- .name = "mtk-iommu",
+ .name = "mtk-iommu-v1",
.of_match_table = mtk_iommu_of_ids,
.pm = &mtk_iommu_pm_ops,
}
Patches currently in stable-queue which might be from matthias.bgg(a)gmail.com are
queue-4.9/soc-mediatek-pwrap-fix-compiler-errors.patch
queue-4.9/iommu-mediatek-fix-driver-name.patch
This is a note to let you know that I've just added the patch titled
iommu/io-pgtable-arm-v7s: Check for leaf entry before dereferencing it
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:
iommu-io-pgtable-arm-v7s-check-for-leaf-entry-before-dereferencing-it.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 Mon Dec 18 14:12:34 CET 2017
From: Oleksandr Tyshchenko <oleksandr_tyshchenko(a)epam.com>
Date: Mon, 27 Feb 2017 14:30:26 +0200
Subject: iommu/io-pgtable-arm-v7s: Check for leaf entry before dereferencing it
From: Oleksandr Tyshchenko <oleksandr_tyshchenko(a)epam.com>
[ Upstream commit a03849e7210277fa212779b7cd9c30e1ab6194b2 ]
Do a check for already installed leaf entry at the current level before
dereferencing it in order to avoid walking the page table down with
wrong pointer to the next level.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko(a)epam.com>
CC: Will Deacon <will.deacon(a)arm.com>
CC: Robin Murphy <robin.murphy(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iommu/io-pgtable-arm-v7s.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -418,8 +418,12 @@ static int __arm_v7s_map(struct arm_v7s_
pte |= ARM_V7S_ATTR_NS_TABLE;
__arm_v7s_set_pte(ptep, pte, 1, cfg);
- } else {
+ } else if (ARM_V7S_PTE_IS_TABLE(pte, lvl)) {
cptep = iopte_deref(pte, lvl);
+ } else {
+ /* We require an unmap first */
+ WARN_ON(!selftest_running);
+ return -EEXIST;
}
/* Rinse, repeat */
Patches currently in stable-queue which might be from oleksandr_tyshchenko(a)epam.com are
queue-4.9/iommu-io-pgtable-arm-v7s-check-for-leaf-entry-before-dereferencing-it.patch
This is a note to let you know that I've just added the patch titled
iommu/amd: Limit the IOVA page range to the specified addresses
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:
iommu-amd-limit-the-iova-page-range-to-the-specified-addresses.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 Mon Dec 18 14:12:35 CET 2017
From: Gary R Hook <gary.hook(a)amd.com>
Date: Fri, 3 Nov 2017 10:50:34 -0600
Subject: iommu/amd: Limit the IOVA page range to the specified addresses
From: Gary R Hook <gary.hook(a)amd.com>
[ Upstream commit b92b4fb5c14257c0e7eae291ecc1f7b1962e1699 ]
The extent of pages specified when applying a reserved region should
include up to the last page of the range, but not the page following
the range.
Signed-off-by: Gary R Hook <gary.hook(a)amd.com>
Fixes: 8d54d6c8b8f3 ('iommu/amd: Implement apply_dm_region call-back')
Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iommu/amd_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -3211,7 +3211,7 @@ static void amd_iommu_apply_dm_region(st
unsigned long start, end;
start = IOVA_PFN(region->start);
- end = IOVA_PFN(region->start + region->length);
+ end = IOVA_PFN(region->start + region->length - 1);
WARN_ON_ONCE(reserve_iova(&dma_dom->iovad, start, end) == NULL);
}
Patches currently in stable-queue which might be from gary.hook(a)amd.com are
queue-4.9/iommu-amd-limit-the-iova-page-range-to-the-specified-addresses.patch