This is a note to let you know that I've just added the patch titled
mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM
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:
mtd-nand-gpmi-fix-failure-when-a-erased-page-has-a-bitflip-at-bbm.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 Wed Feb 28 16:23:28 CET 2018
From: Sascha Hauer <s.hauer(a)pengutronix.de>
Date: Tue, 5 Dec 2017 11:51:40 +0100
Subject: mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM
From: Sascha Hauer <s.hauer(a)pengutronix.de>
[ Upstream commit fdf2e821052958a114618a95ab18a300d0b080cb ]
When erased subpages are read then the BCH decoder returns STATUS_ERASED
if they are all empty, or STATUS_UNCORRECTABLE if there are bitflips.
When there are bitflips, we have to set these bits again to show the
upper layers a completely erased page. When a bitflip happens in the
exact byte where the bad block marker is, then this byte is swapped
with another byte in block_mark_swapping(). The correction code then
detects a bitflip in another subpage and no longer corrects the bitflip
where it really happens.
Correct this behaviour by calling block_mark_swapping() after the
bitflips have been corrected.
In our case UBIFS failed with this bug because it expects erased
pages to be really empty:
UBIFS error (pid 187): ubifs_scan: corrupt empty space at LEB 36:118735
UBIFS error (pid 187): ubifs_scanned_corruption: corruption at LEB 36:118735
UBIFS error (pid 187): ubifs_scanned_corruption: first 8192 bytes from LEB 36:118735
UBIFS error (pid 187): ubifs_scan: LEB 36 scanning failed
UBIFS error (pid 187): do_commit: commit failed, error -117
Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de>
Reviewed-by: Richard Weinberger <richard(a)nod.at>
Acked-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1067,9 +1067,6 @@ static int gpmi_ecc_read_page(struct mtd
return ret;
}
- /* handle the block mark swapping */
- block_mark_swapping(this, payload_virt, auxiliary_virt);
-
/* Loop over status bytes, accumulating ECC status. */
status = auxiliary_virt + nfc_geo->auxiliary_status_offset;
@@ -1158,6 +1155,9 @@ static int gpmi_ecc_read_page(struct mtd
max_bitflips = max_t(unsigned int, max_bitflips, *status);
}
+ /* handle the block mark swapping */
+ block_mark_swapping(this, buf, auxiliary_virt);
+
if (oob_required) {
/*
* It's time to deliver the OOB bytes. See gpmi_ecc_read_oob()
Patches currently in stable-queue which might be from s.hauer(a)pengutronix.de are
queue-4.14/mtd-nand-gpmi-fix-failure-when-a-erased-page-has-a-bitflip-at-bbm.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: brcmnand: Zero bitflip is not an error
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:
mtd-nand-brcmnand-zero-bitflip-is-not-an-error.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 Wed Feb 28 16:23:28 CET 2018
From: Albert Hsieh <wen.hsieh(a)broadcom.com>
Date: Mon, 20 Nov 2017 11:26:26 +0800
Subject: mtd: nand: brcmnand: Zero bitflip is not an error
From: Albert Hsieh <wen.hsieh(a)broadcom.com>
[ Upstream commit e44b9a9c135727f3410e029910275f40681dc8bc ]
A negative return value of brcmstb_nand_verify_erased_page() indicates a
real bitflip error of an erased page, and other return values (>= 0) show
the corrected bitflip number. Zero return value means no bitflip, but the
current driver code treats it as an error, and eventually leads to
falsely reported ECC error.
Fixes: 02b88eea9f9c ("mtd: brcmnand: Add check for erased page bitflip")
Signed-off-by: Albert Hsieh <wen.hsieh(a)broadcom.com>
Acked-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/brcmnand/brcmnand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1763,7 +1763,7 @@ try_dmaread:
err = brcmstb_nand_verify_erased_page(mtd, chip, buf,
addr);
/* erased page bitflips corrected */
- if (err > 0)
+ if (err >= 0)
return err;
}
Patches currently in stable-queue which might be from wen.hsieh(a)broadcom.com are
queue-4.14/mtd-nand-brcmnand-zero-bitflip-is-not-an-error.patch
This is a note to let you know that I've just added the patch titled
mm/frame_vector.c: release a semaphore in 'get_vaddr_frames()'
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:
mm-frame_vector.c-release-a-semaphore-in-get_vaddr_frames.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 Wed Feb 28 16:23:28 CET 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Thu, 14 Dec 2017 15:33:08 -0800
Subject: mm/frame_vector.c: release a semaphore in 'get_vaddr_frames()'
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 1f704fd0d14043e76e80f6b8b2251b9b2cedcca6 ]
A semaphore is acquired before this check, so we must release it before
leaving.
Link: http://lkml.kernel.org/r/20171211211009.4971-1-christophe.jaillet@wanadoo.fr
Fixes: b7f0554a56f2 ("mm: fail get_vaddr_frames() for filesystem-dax mappings")
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: Christian Borntraeger <borntraeger(a)de.ibm.com>
Cc: David Sterba <dsterba(a)suse.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/frame_vector.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/mm/frame_vector.c
+++ b/mm/frame_vector.c
@@ -62,8 +62,10 @@ int get_vaddr_frames(unsigned long start
* get_user_pages_longterm() and disallow it for filesystem-dax
* mappings.
*/
- if (vma_is_fsdax(vma))
- return -EOPNOTSUPP;
+ if (vma_is_fsdax(vma)) {
+ ret = -EOPNOTSUPP;
+ goto out;
+ }
if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
vec->got_ref = true;
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.14/mdio-sun4i-fix-a-memory-leak.patch
queue-4.14/mm-frame_vector.c-release-a-semaphore-in-get_vaddr_frames.patch
This is a note to let you know that I've just added the patch titled
mlxsw: pci: Wait after reset before accessing HW
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:
mlxsw-pci-wait-after-reset-before-accessing-hw.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 Wed Feb 28 16:23:28 CET 2018
From: Yuval Mintz <yuvalm(a)mellanox.com>
Date: Wed, 10 Jan 2018 11:42:43 +0100
Subject: mlxsw: pci: Wait after reset before accessing HW
From: Yuval Mintz <yuvalm(a)mellanox.com>
[ Upstream commit 8e033a93b37f37aa9fca71a370a895155320af60 ]
After performing reset driver polls on HW indication until learning
that the reset is done, but immediately after reset the device becomes
unresponsive which might lead to completion timeout on the first read.
Wait for 100ms before starting the polling.
Fixes: 233fa44bd67a ("mlxsw: pci: Implement reset done check")
Signed-off-by: Yuval Mintz <yuvalm(a)mellanox.com>
Reviewed-by: Ido Schimmel <idosch(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: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlxsw/pci.c | 7 ++++++-
drivers/net/ethernet/mellanox/mlxsw/pci_hw.h | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.c
@@ -1643,7 +1643,12 @@ static int mlxsw_pci_sw_reset(struct mlx
return 0;
}
- wmb(); /* reset needs to be written before we read control register */
+ /* Reset needs to be written before we read control register, and
+ * we must wait for the HW to become responsive once again
+ */
+ wmb();
+ msleep(MLXSW_PCI_SW_RESET_WAIT_MSECS);
+
end = jiffies + msecs_to_jiffies(MLXSW_PCI_SW_RESET_TIMEOUT_MSECS);
do {
u32 val = mlxsw_pci_read32(mlxsw_pci, FW_READY);
--- a/drivers/net/ethernet/mellanox/mlxsw/pci_hw.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci_hw.h
@@ -59,6 +59,7 @@
#define MLXSW_PCI_SW_RESET 0xF0010
#define MLXSW_PCI_SW_RESET_RST_BIT BIT(0)
#define MLXSW_PCI_SW_RESET_TIMEOUT_MSECS 5000
+#define MLXSW_PCI_SW_RESET_WAIT_MSECS 100
#define MLXSW_PCI_FW_READY 0xA1844
#define MLXSW_PCI_FW_READY_MASK 0xFFFF
#define MLXSW_PCI_FW_READY_MAGIC 0x5E
Patches currently in stable-queue which might be from yuvalm(a)mellanox.com are
queue-4.14/mlxsw-pci-wait-after-reset-before-accessing-hw.patch
This is a note to let you know that I've just added the patch titled
mdio-sun4i: Fix a memory leak
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:
mdio-sun4i-fix-a-memory-leak.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 Wed Feb 28 16:23:28 CET 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sat, 6 Jan 2018 09:00:09 +0100
Subject: mdio-sun4i: Fix a memory leak
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 56c0290202ab94a2f2780c449395d4ae8495fab4 ]
If the probing of the regulator is deferred, the memory allocated by
'mdiobus_alloc_size()' will be leaking.
It should be freed before the next call to 'sun4i_mdio_probe()' which will
reallocate it.
Fixes: 4bdcb1dd9feb ("net: Add MDIO bus driver for the Allwinner EMAC")
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.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>
---
drivers/net/phy/mdio-sun4i.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/phy/mdio-sun4i.c
+++ b/drivers/net/phy/mdio-sun4i.c
@@ -118,8 +118,10 @@ static int sun4i_mdio_probe(struct platf
data->regulator = devm_regulator_get(&pdev->dev, "phy");
if (IS_ERR(data->regulator)) {
- if (PTR_ERR(data->regulator) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
+ if (PTR_ERR(data->regulator) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto err_out_free_mdiobus;
+ }
dev_info(&pdev->dev, "no regulator found\n");
data->regulator = NULL;
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.14/mdio-sun4i-fix-a-memory-leak.patch
queue-4.14/mm-frame_vector.c-release-a-semaphore-in-get_vaddr_frames.patch
This is a note to let you know that I've just added the patch titled
macvlan: Fix one possible double free
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:
macvlan-fix-one-possible-double-free.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 Wed Feb 28 16:23:28 CET 2018
From: Gao Feng <gfree.wind(a)vip.163.com>
Date: Tue, 26 Dec 2017 21:44:32 +0800
Subject: macvlan: Fix one possible double free
From: Gao Feng <gfree.wind(a)vip.163.com>
[ Upstream commit d02fd6e7d2933ede6478a15f9e4ce8a93845824e ]
Because the macvlan_uninit would free the macvlan port, so there is one
double free case in macvlan_common_newlink. When the macvlan port is just
created, then register_netdevice or netdev_upper_dev_link failed and they
would invoke macvlan_uninit. Then it would reach the macvlan_port_destroy
which triggers the double free.
Signed-off-by: Gao Feng <gfree.wind(a)vip.163.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 | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -1441,9 +1441,14 @@ int macvlan_common_newlink(struct net *s
return 0;
unregister_netdev:
+ /* macvlan_uninit would free the macvlan port */
unregister_netdevice(dev);
+ return err;
destroy_macvlan_port:
- if (create)
+ /* the macvlan port may be freed by macvlan_uninit when fail to register.
+ * so we destroy the macvlan port only when it's valid.
+ */
+ if (create && macvlan_port_get_rtnl(dev))
macvlan_port_destroy(port->dev);
return err;
}
Patches currently in stable-queue which might be from gfree.wind(a)vip.163.com are
queue-4.14/macvlan-fix-one-possible-double-free.patch
This is a note to let you know that I've just added the patch titled
mac80211_hwsim: Fix a possible sleep-in-atomic bug in hwsim_get_radio_nl
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:
mac80211_hwsim-fix-a-possible-sleep-in-atomic-bug-in-hwsim_get_radio_nl.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 Wed Feb 28 16:23:28 CET 2018
From: Jia-Ju Bai <baijiaju1990(a)163.com>
Date: Tue, 12 Dec 2017 17:26:36 +0800
Subject: mac80211_hwsim: Fix a possible sleep-in-atomic bug in hwsim_get_radio_nl
From: Jia-Ju Bai <baijiaju1990(a)163.com>
[ Upstream commit 162bd5e5fd921785077b5862d8f2ffabe2fe11e5 ]
The driver may sleep under a spinlock.
The function call path is:
hwsim_get_radio_nl (acquire the spinlock)
nlmsg_new(GFP_KERNEL) --> may sleep
To fix it, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool(DSAC) and checked by my code review.
Signed-off-by: Jia-Ju Bai <baijiaju1990(a)163.com>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/mac80211_hwsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3220,7 +3220,7 @@ static int hwsim_get_radio_nl(struct sk_
if (!net_eq(wiphy_net(data->hw->wiphy), genl_info_net(info)))
continue;
- skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
if (!skb) {
res = -ENOMEM;
goto out_err;
Patches currently in stable-queue which might be from baijiaju1990(a)163.com are
queue-4.14/mac80211_hwsim-fix-a-possible-sleep-in-atomic-bug-in-hwsim_get_radio_nl.patch
This is a note to let you know that I've just added the patch titled
mac80211: mesh: drop frames appearing to be from us
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:
mac80211-mesh-drop-frames-appearing-to-be-from-us.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 Wed Feb 28 16:23:28 CET 2018
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Thu, 4 Jan 2018 15:51:53 +0100
Subject: mac80211: mesh: drop frames appearing to be from us
From: Johannes Berg <johannes.berg(a)intel.com>
[ Upstream commit 736a80bbfda709fb3631f5f62056f250a38e5804 ]
If there are multiple mesh stations with the same MAC address,
they will both get confused and start throwing warnings.
Obviously in this case nothing can actually work anyway, so just
drop frames that look like they're from ourselves early on.
Reported-by: Gui Iribarren <gui(a)altermundi.net>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/rx.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3632,6 +3632,8 @@ static bool ieee80211_accept_frame(struc
}
return true;
case NL80211_IFTYPE_MESH_POINT:
+ if (ether_addr_equal(sdata->vif.addr, hdr->addr2))
+ return false;
if (multicast)
return true;
return ether_addr_equal(sdata->vif.addr, hdr->addr1);
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.14/mac80211_hwsim-fix-a-possible-sleep-in-atomic-bug-in-hwsim_get_radio_nl.patch
queue-4.14/nl80211-check-for-the-required-netlink-attribute-presence.patch
queue-4.14/mac80211-mesh-drop-frames-appearing-to-be-from-us.patch
This is a note to let you know that I've just added the patch titled
lib/mpi: Fix umul_ppmm() for MIPS64r6
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:
lib-mpi-fix-umul_ppmm-for-mips64r6.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 Wed Feb 28 16:23:28 CET 2018
From: James Hogan <jhogan(a)kernel.org>
Date: Tue, 5 Dec 2017 23:31:35 +0000
Subject: lib/mpi: Fix umul_ppmm() for MIPS64r6
From: James Hogan <jhogan(a)kernel.org>
[ Upstream commit bbc25bee37d2b32cf3a1fab9195b6da3a185614a ]
Current MIPS64r6 toolchains aren't able to generate efficient
DMULU/DMUHU based code for the C implementation of umul_ppmm(), which
performs an unsigned 64 x 64 bit multiply and returns the upper and
lower 64-bit halves of the 128-bit result. Instead it widens the 64-bit
inputs to 128-bits and emits a __multi3 intrinsic call to perform a 128
x 128 multiply. This is both inefficient, and it results in a link error
since we don't include __multi3 in MIPS linux.
For example commit 90a53e4432b1 ("cfg80211: implement regdb signature
checking") merged in v4.15-rc1 recently broke the 64r6_defconfig and
64r6el_defconfig builds by indirectly selecting MPILIB. The same build
errors can be reproduced on older kernels by enabling e.g. CRYPTO_RSA:
lib/mpi/generic_mpih-mul1.o: In function `mpihelp_mul_1':
lib/mpi/generic_mpih-mul1.c:50: undefined reference to `__multi3'
lib/mpi/generic_mpih-mul2.o: In function `mpihelp_addmul_1':
lib/mpi/generic_mpih-mul2.c:49: undefined reference to `__multi3'
lib/mpi/generic_mpih-mul3.o: In function `mpihelp_submul_1':
lib/mpi/generic_mpih-mul3.c:49: undefined reference to `__multi3'
lib/mpi/mpih-div.o In function `mpihelp_divrem':
lib/mpi/mpih-div.c:205: undefined reference to `__multi3'
lib/mpi/mpih-div.c:142: undefined reference to `__multi3'
Therefore add an efficient MIPS64r6 implementation of umul_ppmm() using
inline assembly and the DMULU/DMUHU instructions, to prevent __multi3
calls being emitted.
Fixes: 7fd08ca58ae6 ("MIPS: Add build support for the MIPS R6 ISA")
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Herbert Xu <herbert(a)gondor.apana.org.au>
Cc: "David S. Miller" <davem(a)davemloft.net>
Cc: linux-mips(a)linux-mips.org
Cc: linux-crypto(a)vger.kernel.org
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/mpi/longlong.h | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
--- a/lib/mpi/longlong.h
+++ b/lib/mpi/longlong.h
@@ -671,7 +671,23 @@ do { \
************** MIPS/64 **************
***************************************/
#if (defined(__mips) && __mips >= 3) && W_TYPE_SIZE == 64
-#if (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4)
+#if defined(__mips_isa_rev) && __mips_isa_rev >= 6
+/*
+ * GCC ends up emitting a __multi3 intrinsic call for MIPS64r6 with the plain C
+ * code below, so we special case MIPS64r6 until the compiler can do better.
+ */
+#define umul_ppmm(w1, w0, u, v) \
+do { \
+ __asm__ ("dmulu %0,%1,%2" \
+ : "=d" ((UDItype)(w0)) \
+ : "d" ((UDItype)(u)), \
+ "d" ((UDItype)(v))); \
+ __asm__ ("dmuhu %0,%1,%2" \
+ : "=d" ((UDItype)(w1)) \
+ : "d" ((UDItype)(u)), \
+ "d" ((UDItype)(v))); \
+} while (0)
+#elif (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4)
#define umul_ppmm(w1, w0, u, v) \
do { \
typedef unsigned int __ll_UTItype __attribute__((mode(TI))); \
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-4.14/lib-mpi-fix-umul_ppmm-for-mips64r6.patch
This is a note to let you know that I've just added the patch titled
leds: core: Fix regression caused by commit 2b83ff96f51d
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:
leds-core-fix-regression-caused-by-commit-2b83ff96f51d.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 Wed Feb 28 16:23:28 CET 2018
From: Jacek Anaszewski <jacek.anaszewski(a)gmail.com>
Date: Wed, 3 Jan 2018 21:13:45 +0100
Subject: leds: core: Fix regression caused by commit 2b83ff96f51d
From: Jacek Anaszewski <jacek.anaszewski(a)gmail.com>
[ Upstream commit 7b6af2c53192f1766892ef40c8f48a413509ed72 ]
Commit 2b83ff96f51d ("led: core: Fix brightness setting when setting delay_off=0")
replaced del_timer_sync(&led_cdev->blink_timer) with led_stop_software_blink()
in led_blink_set(), which additionally clears LED_BLINK_SW flag as well as
zeroes blink_delay_on and blink_delay_off properties of the struct led_classdev.
Cleansing of the latter ones wasn't required to fix the original issue but
wasn't considered harmful. It nonetheless turned out to be so in case when
pointer to one or both props is passed to led_blink_set() like in the
ledtrig-timer.c. In such cases zeroes are passed later in delay_on and/or
delay_off arguments to led_blink_setup(), which results either in stopping
the software blinking or setting blinking frequency always to 1Hz.
Avoid using led_stop_software_blink() and add a single call required
to clear LED_BLINK_SW flag, which was the only needed modification to
fix the original issue.
Fixes 2b83ff96f51d ("led: core: Fix brightness setting when setting delay_off=0")
Signed-off-by: Jacek Anaszewski <jacek.anaszewski(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/leds/led-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -187,8 +187,9 @@ void led_blink_set(struct led_classdev *
unsigned long *delay_on,
unsigned long *delay_off)
{
- led_stop_software_blink(led_cdev);
+ del_timer_sync(&led_cdev->blink_timer);
+ clear_bit(LED_BLINK_SW, &led_cdev->work_flags);
clear_bit(LED_BLINK_ONESHOT, &led_cdev->work_flags);
clear_bit(LED_BLINK_ONESHOT_STOP, &led_cdev->work_flags);
Patches currently in stable-queue which might be from jacek.anaszewski(a)gmail.com are
queue-4.14/leds-core-fix-regression-caused-by-commit-2b83ff96f51d.patch
This is a note to let you know that I've just added the patch titled
led: core: Fix brightness setting when setting delay_off=0
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:
led-core-fix-brightness-setting-when-setting-delay_off-0.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 Wed Feb 28 16:23:28 CET 2018
From: Matthieu CASTET <matthieu.castet(a)parrot.com>
Date: Tue, 12 Dec 2017 11:10:44 +0100
Subject: led: core: Fix brightness setting when setting delay_off=0
From: Matthieu CASTET <matthieu.castet(a)parrot.com>
[ Upstream commit 2b83ff96f51d0b039c4561b9f95c824d7bddb85c ]
With the current code, the following sequence won't work :
echo timer > trigger
echo 0 > delay_off
* at this point we call
** led_delay_off_store
** led_blink_set
---
drivers/leds/led-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -187,7 +187,7 @@ void led_blink_set(struct led_classdev *
unsigned long *delay_on,
unsigned long *delay_off)
{
- del_timer_sync(&led_cdev->blink_timer);
+ led_stop_software_blink(led_cdev);
clear_bit(LED_BLINK_ONESHOT, &led_cdev->work_flags);
clear_bit(LED_BLINK_ONESHOT_STOP, &led_cdev->work_flags);
Patches currently in stable-queue which might be from matthieu.castet(a)parrot.com are
queue-4.14/led-core-fix-brightness-setting-when-setting-delay_off-0.patch
This is a note to let you know that I've just added the patch titled
ipv6: icmp6: Allow icmp messages to be looped back
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:
ipv6-icmp6-allow-icmp-messages-to-be-looped-back.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 Wed Feb 28 16:23:28 CET 2018
From: Brendan McGrath <redmcg(a)redmandi.dyndns.org>
Date: Wed, 13 Dec 2017 22:14:57 +1100
Subject: ipv6: icmp6: Allow icmp messages to be looped back
From: Brendan McGrath <redmcg(a)redmandi.dyndns.org>
[ Upstream commit 588753f1eb18978512b1c9b85fddb457d46f9033 ]
One example of when an ICMPv6 packet is required to be looped back is
when a host acts as both a Multicast Listener and a Multicast Router.
A Multicast Router will listen on address ff02::16 for MLDv2 messages.
Currently, MLDv2 messages originating from a Multicast Listener running
on the same host as the Multicast Router are not being delivered to the
Multicast Router. This is due to dst.input being assigned the default
value of dst_discard.
This results in the packet being looped back but discarded before being
delivered to the Multicast Router.
This patch sets dst.input to ip6_input to ensure a looped back packet
is delivered to the Multicast Router.
Signed-off-by: Brendan McGrath <redmcg(a)redmandi.dyndns.org>
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/ipv6/route.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1755,6 +1755,7 @@ struct dst_entry *icmp6_dst_alloc(struct
}
rt->dst.flags |= DST_HOST;
+ rt->dst.input = ip6_input;
rt->dst.output = ip6_output;
rt->rt6i_gateway = fl6->daddr;
rt->rt6i_dst.addr = fl6->daddr;
Patches currently in stable-queue which might be from redmcg(a)redmandi.dyndns.org are
queue-4.14/ipv6-icmp6-allow-icmp-messages-to-be-looped-back.patch
This is a note to let you know that I've just added the patch titled
ip_gre: remove the incorrect mtu limit for ipgre tap
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:
ip_gre-remove-the-incorrect-mtu-limit-for-ipgre-tap.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 Wed Feb 28 16:23:28 CET 2018
From: Xin Long <lucien.xin(a)gmail.com>
Date: Mon, 18 Dec 2017 14:24:35 +0800
Subject: ip_gre: remove the incorrect mtu limit for ipgre tap
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit cfddd4c33c254954927942599d299b3865743146 ]
ipgre tap driver calls ether_setup(), after commit 61e84623ace3
("net: centralize net_device min/max MTU checking"), the range
of mtu is [min_mtu, max_mtu], which is [68, 1500] by default.
It causes the dev mtu of the ipgre tap device to not be greater
than 1500, this limit value is not correct for ipgre tap device.
Besides, it's .change_mtu already does the right check. So this
patch is just to set max_mtu as 0, and leave the check to it's
.change_mtu.
Fixes: 61e84623ace3 ("net: centralize net_device min/max MTU checking")
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Signed-off-by: Xin Long <lucien.xin(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>
---
net/ipv4/ip_gre.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1274,6 +1274,7 @@ static const struct net_device_ops erspa
static void ipgre_tap_setup(struct net_device *dev)
{
ether_setup(dev);
+ dev->max_mtu = 0;
dev->netdev_ops = &gre_tap_netdev_ops;
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.14/ip_gre-remove-the-incorrect-mtu-limit-for-ipgre-tap.patch
queue-4.14/ip6_gre-remove-the-incorrect-mtu-limit-for-ipgre-tap.patch
queue-4.14/ip6_tunnel-allow-ip6gre-dev-mtu-to-be-set-below-1280.patch
queue-4.14/vxlan-update-skb-dst-pmtu-on-tx-path.patch
queue-4.14/ip6_tunnel-get-the-min-mtu-properly-in-ip6_tnl_xmit.patch
queue-4.14/sctp-fix-the-issue-that-a-__u16-variable-may-overflow-in-sctp_ulpq_renege.patch
This is a note to let you know that I've just added the patch titled
ip6_tunnel: get the min mtu properly in ip6_tnl_xmit
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:
ip6_tunnel-get-the-min-mtu-properly-in-ip6_tnl_xmit.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 Wed Feb 28 16:23:28 CET 2018
From: Xin Long <lucien.xin(a)gmail.com>
Date: Mon, 18 Dec 2017 14:26:21 +0800
Subject: ip6_tunnel: get the min mtu properly in ip6_tnl_xmit
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit c9fefa08190fc879fb2e681035d7774e0a8c5170 ]
Now it's using IPV6_MIN_MTU as the min mtu in ip6_tnl_xmit, but
IPV6_MIN_MTU actually only works when the inner packet is ipv6.
With IPV6_MIN_MTU for ipv4 packets, the new pmtu for inner dst
couldn't be set less than 1280. It would cause tx_err and the
packet to be dropped when the outer dst pmtu is close to 1280.
Jianlin found it by running ipv4 traffic with the topo:
(client) gre6 <---> eth1 (route) eth2 <---> gre6 (server)
After changing eth2 mtu to 1300, the performance became very
low, or the connection was even broken. The issue also affects
ip4ip6 and ip6ip6 tunnels.
So if the inner packet is ipv4, 576 should be considered as the
min mtu.
Note that for ip4ip6 and ip6ip6 tunnels, the inner packet can
only be ipv4 or ipv6, but for gre6 tunnel, it may also be ARP.
This patch using 576 as the min mtu for non-ipv6 packet works
for all those cases.
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Signed-off-by: Xin Long <lucien.xin(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>
---
net/ipv6/ip6_tunnel.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1131,8 +1131,13 @@ route_lookup:
max_headroom += 8;
mtu -= 8;
}
- if (mtu < IPV6_MIN_MTU)
- mtu = IPV6_MIN_MTU;
+ if (skb->protocol == htons(ETH_P_IPV6)) {
+ if (mtu < IPV6_MIN_MTU)
+ mtu = IPV6_MIN_MTU;
+ } else if (mtu < 576) {
+ mtu = 576;
+ }
+
if (skb_dst(skb) && !t->parms.collect_md)
skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu);
if (skb->len - t->tun_hlen - eth_hlen > mtu && !skb_is_gso(skb)) {
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.14/ip_gre-remove-the-incorrect-mtu-limit-for-ipgre-tap.patch
queue-4.14/ip6_gre-remove-the-incorrect-mtu-limit-for-ipgre-tap.patch
queue-4.14/ip6_tunnel-allow-ip6gre-dev-mtu-to-be-set-below-1280.patch
queue-4.14/vxlan-update-skb-dst-pmtu-on-tx-path.patch
queue-4.14/ip6_tunnel-get-the-min-mtu-properly-in-ip6_tnl_xmit.patch
queue-4.14/sctp-fix-the-issue-that-a-__u16-variable-may-overflow-in-sctp_ulpq_renege.patch
This is a note to let you know that I've just added the patch titled
ip6_tunnel: allow ip6gre dev mtu to be set below 1280
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:
ip6_tunnel-allow-ip6gre-dev-mtu-to-be-set-below-1280.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 Wed Feb 28 16:23:28 CET 2018
From: Xin Long <lucien.xin(a)gmail.com>
Date: Mon, 25 Dec 2017 14:45:12 +0800
Subject: ip6_tunnel: allow ip6gre dev mtu to be set below 1280
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit 2fa771be953a17f8e0a9c39103464c2574444c62 ]
Commit 582442d6d5bc ("ipv6: Allow the MTU of ipip6 tunnel to be set
below 1280") fixed a mtu setting issue. It works for ipip6 tunnel.
But ip6gre dev updates the mtu also with ip6_tnl_change_mtu. Since
the inner packet over ip6gre can be ipv4 and it's mtu should also
be allowed to set below 1280, the same issue also exists on ip6gre.
This patch is to fix it by simply changing to check if parms.proto
is IPPROTO_IPV6 in ip6_tnl_change_mtu instead, to make ip6gre to
go to 'else' branch.
Signed-off-by: Xin Long <lucien.xin(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>
---
net/ipv6/ip6_tunnel.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1684,11 +1684,11 @@ int ip6_tnl_change_mtu(struct net_device
{
struct ip6_tnl *tnl = netdev_priv(dev);
- if (tnl->parms.proto == IPPROTO_IPIP) {
- if (new_mtu < ETH_MIN_MTU)
+ if (tnl->parms.proto == IPPROTO_IPV6) {
+ if (new_mtu < IPV6_MIN_MTU)
return -EINVAL;
} else {
- if (new_mtu < IPV6_MIN_MTU)
+ if (new_mtu < ETH_MIN_MTU)
return -EINVAL;
}
if (new_mtu > 0xFFF8 - dev->hard_header_len)
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.14/ip_gre-remove-the-incorrect-mtu-limit-for-ipgre-tap.patch
queue-4.14/ip6_gre-remove-the-incorrect-mtu-limit-for-ipgre-tap.patch
queue-4.14/ip6_tunnel-allow-ip6gre-dev-mtu-to-be-set-below-1280.patch
queue-4.14/vxlan-update-skb-dst-pmtu-on-tx-path.patch
queue-4.14/ip6_tunnel-get-the-min-mtu-properly-in-ip6_tnl_xmit.patch
queue-4.14/sctp-fix-the-issue-that-a-__u16-variable-may-overflow-in-sctp_ulpq_renege.patch
This is a note to let you know that I've just added the patch titled
ip6_gre: remove the incorrect mtu limit for ipgre tap
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:
ip6_gre-remove-the-incorrect-mtu-limit-for-ipgre-tap.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 Wed Feb 28 16:23:28 CET 2018
From: Xin Long <lucien.xin(a)gmail.com>
Date: Mon, 18 Dec 2017 14:25:09 +0800
Subject: ip6_gre: remove the incorrect mtu limit for ipgre tap
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit 2c52129a7d74d017320804c6928de770815c5f4a ]
The same fix as the patch "ip_gre: remove the incorrect mtu limit for
ipgre tap" is also needed for ip6_gre.
Fixes: 61e84623ace3 ("net: centralize net_device min/max MTU checking")
Signed-off-by: Xin Long <lucien.xin(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>
---
net/ipv6/ip6_gre.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -1335,6 +1335,7 @@ static void ip6gre_tap_setup(struct net_
ether_setup(dev);
+ dev->max_mtu = 0;
dev->netdev_ops = &ip6gre_tap_netdev_ops;
dev->needs_free_netdev = true;
dev->priv_destructor = ip6gre_dev_free;
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.14/ip_gre-remove-the-incorrect-mtu-limit-for-ipgre-tap.patch
queue-4.14/ip6_gre-remove-the-incorrect-mtu-limit-for-ipgre-tap.patch
queue-4.14/ip6_tunnel-allow-ip6gre-dev-mtu-to-be-set-below-1280.patch
queue-4.14/vxlan-update-skb-dst-pmtu-on-tx-path.patch
queue-4.14/ip6_tunnel-get-the-min-mtu-properly-in-ip6_tnl_xmit.patch
queue-4.14/sctp-fix-the-issue-that-a-__u16-variable-may-overflow-in-sctp_ulpq_renege.patch
This is a note to let you know that I've just added the patch titled
Input: xen-kbdfront - do not advertise multi-touch pressure support
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:
input-xen-kbdfront-do-not-advertise-multi-touch-pressure-support.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 Wed Feb 28 16:23:28 CET 2018
From: Oleksandr Andrushchenko <oleksandr_andrushchenko(a)epam.com>
Date: Tue, 2 Jan 2018 09:39:25 -0800
Subject: Input: xen-kbdfront - do not advertise multi-touch pressure support
From: Oleksandr Andrushchenko <oleksandr_andrushchenko(a)epam.com>
[ Upstream commit 02a0d9216d4daf6a58d88642bd2da2c78c327552 ]
Some user-space applications expect multi-touch pressure
on contact to be reported if it is advertised in device
properties. Otherwise, such applications may treat reports
not as actual touches, but hovering. Currently this is
only advertised, but not reported.
Fix this by not advertising that ABS_MT_PRESSURE is supported.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko(a)epam.com>
Signed-off-by: Andrii Chepurnyi <andrii_chepurnyi(a)epam.com>
Patchwork-Id: 10140017
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/misc/xen-kbdfront.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -326,8 +326,6 @@ static int xenkbd_probe(struct xenbus_de
0, width, 0, 0);
input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
0, height, 0, 0);
- input_set_abs_params(mtouch, ABS_MT_PRESSURE,
- 0, 255, 0, 0);
ret = input_mt_init_slots(mtouch, num_cont, INPUT_MT_DIRECT);
if (ret) {
Patches currently in stable-queue which might be from oleksandr_andrushchenko(a)epam.com are
queue-4.14/input-xen-kbdfront-do-not-advertise-multi-touch-pressure-support.patch
This is a note to let you know that I've just added the patch titled
IB/mlx5: Fix mlx5_ib_alloc_mr error flow
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:
ib-mlx5-fix-mlx5_ib_alloc_mr-error-flow.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 Wed Feb 28 16:23:28 CET 2018
From: Nitzan Carmi <nitzanc(a)mellanox.com>
Date: Tue, 26 Dec 2017 11:20:20 +0200
Subject: IB/mlx5: Fix mlx5_ib_alloc_mr error flow
From: Nitzan Carmi <nitzanc(a)mellanox.com>
[ Upstream commit 45e6ae7ef21b907dacb18da62d5787d74a31d860 ]
ibmr.device is being set only after ib_alloc_mr() is
(successfully) complete. Therefore, in case mlx5_core_create_mkey()
return with error, the error flow calls mlx5_free_priv_descs()
which uses ibmr.device (which doesn't exist yet), causing
a NULL dereference oops.
To fix this, the IB device should be set in the mr struct earlier
stage (e.g. prior to calling mlx5_core_create_mkey()).
Fixes: 8a187ee52b04 ("IB/mlx5: Support the new memory registration API")
Signed-off-by: Max Gurtovoy <maxg(a)mellanox.com>
Signed-off-by: Nitzan Carmi <nitzanc(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx5/mr.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1637,6 +1637,7 @@ struct ib_mr *mlx5_ib_alloc_mr(struct ib
MLX5_SET(mkc, mkc, access_mode, mr->access_mode);
MLX5_SET(mkc, mkc, umr_en, 1);
+ mr->ibmr.device = pd->device;
err = mlx5_core_create_mkey(dev->mdev, &mr->mmkey, in, inlen);
if (err)
goto err_destroy_psv;
Patches currently in stable-queue which might be from nitzanc(a)mellanox.com are
queue-4.14/ib-mlx5-fix-mlx5_ib_alloc_mr-error-flow.patch
queue-4.14/ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch
This is a note to let you know that I've just added the patch titled
IB/mlx4: Fix mlx4_ib_alloc_mr error flow
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:
ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.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 Wed Feb 28 16:23:28 CET 2018
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Sun, 31 Dec 2017 15:33:14 +0200
Subject: IB/mlx4: Fix mlx4_ib_alloc_mr error flow
From: Leon Romanovsky <leonro(a)mellanox.com>
[ Upstream commit 5a371cf87e145b86efd32007e46146e78c1eff6d ]
ibmr.device is being set only after ib_alloc_mr() is successfully complete.
Therefore, in case imlx4_mr_enable() returns with error, the error flow
unwinder calls to mlx4_free_priv_pages(), which uses ibmr.device.
Such usage causes to NULL dereference oops and to fix it, the IB device
should be set in the mr struct earlier stage (e.g. prior to calling
mlx4_free_priv_pages()).
Fixes: 1b2cd0fc673c ("IB/mlx4: Support the new memory registration API")
Signed-off-by: Nitzan Carmi <nitzanc(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx4/mr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/hw/mlx4/mr.c
+++ b/drivers/infiniband/hw/mlx4/mr.c
@@ -406,7 +406,6 @@ struct ib_mr *mlx4_ib_alloc_mr(struct ib
goto err_free_mr;
mr->max_pages = max_num_sg;
-
err = mlx4_mr_enable(dev->dev, &mr->mmr);
if (err)
goto err_free_pl;
@@ -417,6 +416,7 @@ struct ib_mr *mlx4_ib_alloc_mr(struct ib
return &mr->ibmr;
err_free_pl:
+ mr->ibmr.device = pd->device;
mlx4_free_priv_pages(mr);
err_free_mr:
(void) mlx4_mr_free(dev->dev, &mr->mmr);
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.14/ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch
queue-4.14/rdma-netlink-fix-locking-around-__ib_get_device_by_index.patch
This is a note to let you know that I've just added the patch titled
IB/ipoib: Fix race condition in neigh creation
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:
ib-ipoib-fix-race-condition-in-neigh-creation.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 Wed Feb 28 16:23:28 CET 2018
From: Erez Shitrit <erezsh(a)mellanox.com>
Date: Sun, 31 Dec 2017 15:33:15 +0200
Subject: IB/ipoib: Fix race condition in neigh creation
From: Erez Shitrit <erezsh(a)mellanox.com>
[ Upstream commit 16ba3defb8bd01a9464ba4820a487f5b196b455b ]
When using enhanced mode for IPoIB, two threads may execute xmit in
parallel to two different TX queues while the target is the same.
In this case, both of them will add the same neighbor to the path's
neigh link list and we might see the following message:
list_add double add: new=ffff88024767a348, prev=ffff88024767a348...
WARNING: lib/list_debug.c:31__list_add_valid+0x4e/0x70
ipoib_start_xmit+0x477/0x680 [ib_ipoib]
dev_hard_start_xmit+0xb9/0x3e0
sch_direct_xmit+0xf9/0x250
__qdisc_run+0x176/0x5d0
__dev_queue_xmit+0x1f5/0xb10
__dev_queue_xmit+0x55/0xb10
Analysis:
Two SKB are scheduled to be transmitted from two cores.
In ipoib_start_xmit, both gets NULL when calling ipoib_neigh_get.
Two calls to neigh_add_path are made. One thread takes the spin-lock
and calls ipoib_neigh_alloc which creates the neigh structure,
then (after the __path_find) the neigh is added to the path's neigh
link list. When the second thread enters the critical section it also
calls ipoib_neigh_alloc but in this case it gets the already allocated
ipoib_neigh structure, which is already linked to the path's neigh
link list and adds it again to the list. Which beside of triggering
the list, it creates a loop in the linked list. This loop leads to
endless loop inside path_rec_completion.
Solution:
Check list_empty(&neigh->list) before adding to the list.
Add a similar fix in "ipoib_multicast.c::ipoib_mcast_send"
Fixes: b63b70d87741 ('IPoIB: Use a private hash table for path lookup in xmit path')
Signed-off-by: Erez Shitrit <erezsh(a)mellanox.com>
Reviewed-by: Alex Vesker <valex(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 25 ++++++++++++++++++-------
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 5 ++++-
2 files changed, 22 insertions(+), 8 deletions(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -903,8 +903,8 @@ static int path_rec_start(struct net_dev
return 0;
}
-static void neigh_add_path(struct sk_buff *skb, u8 *daddr,
- struct net_device *dev)
+static struct ipoib_neigh *neigh_add_path(struct sk_buff *skb, u8 *daddr,
+ struct net_device *dev)
{
struct ipoib_dev_priv *priv = ipoib_priv(dev);
struct rdma_netdev *rn = netdev_priv(dev);
@@ -918,7 +918,15 @@ static void neigh_add_path(struct sk_buf
spin_unlock_irqrestore(&priv->lock, flags);
++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
- return;
+ return NULL;
+ }
+
+ /* To avoid race condition, make sure that the
+ * neigh will be added only once.
+ */
+ if (unlikely(!list_empty(&neigh->list))) {
+ spin_unlock_irqrestore(&priv->lock, flags);
+ return neigh;
}
path = __path_find(dev, daddr + 4);
@@ -957,7 +965,7 @@ static void neigh_add_path(struct sk_buf
path->ah->last_send = rn->send(dev, skb, path->ah->ah,
IPOIB_QPN(daddr));
ipoib_neigh_put(neigh);
- return;
+ return NULL;
}
} else {
neigh->ah = NULL;
@@ -974,7 +982,7 @@ static void neigh_add_path(struct sk_buf
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_neigh_put(neigh);
- return;
+ return NULL;
err_path:
ipoib_neigh_free(neigh);
@@ -984,6 +992,8 @@ err_drop:
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_neigh_put(neigh);
+
+ return NULL;
}
static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev,
@@ -1092,8 +1102,9 @@ static int ipoib_start_xmit(struct sk_bu
case htons(ETH_P_TIPC):
neigh = ipoib_neigh_get(dev, phdr->hwaddr);
if (unlikely(!neigh)) {
- neigh_add_path(skb, phdr->hwaddr, dev);
- return NETDEV_TX_OK;
+ neigh = neigh_add_path(skb, phdr->hwaddr, dev);
+ if (likely(!neigh))
+ return NETDEV_TX_OK;
}
break;
case htons(ETH_P_ARP):
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -816,7 +816,10 @@ void ipoib_mcast_send(struct net_device
spin_lock_irqsave(&priv->lock, flags);
if (!neigh) {
neigh = ipoib_neigh_alloc(daddr, dev);
- if (neigh) {
+ /* Make sure that the neigh will be added only
+ * once to mcast list.
+ */
+ if (neigh && list_empty(&neigh->list)) {
kref_get(&mcast->ah->ref);
neigh->ah = mcast->ah;
list_add_tail(&neigh->list, &mcast->neigh_list);
Patches currently in stable-queue which might be from erezsh(a)mellanox.com are
queue-4.14/ib-ipoib-fix-race-condition-in-neigh-creation.patch
This is a note to let you know that I've just added the patch titled
ia64, sched/cputime: Fix build error if CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y
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:
ia64-sched-cputime-fix-build-error-if-config_virt_cpu_accounting_native-y.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 Wed Feb 28 16:23:28 CET 2018
From: Valentin Ilie <valentin.ilie(a)gmail.com>
Date: Fri, 5 Jan 2018 23:12:59 +0000
Subject: ia64, sched/cputime: Fix build error if CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y
From: Valentin Ilie <valentin.ilie(a)gmail.com>
[ Upstream commit 7729bebc619307a0233c86f8585a4bf3eadc7ce4 ]
Remove the extra parenthesis.
This bug was introduced by:
e2339a4caa5e: ("ia64: Convert vtime to use nsec units directly")
Signed-off-by: Valentin Ilie <valentin.ilie(a)gmail.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: fenghua.yu(a)intel.com
Cc: linux-ia64(a)vger.kernel.org
Cc: tony.luck(a)intel.com
Link: http://lkml.kernel.org/r/1515193979-24873-1-git-send-email-valentin.ilie@gm…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/ia64/kernel/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/ia64/kernel/time.c
+++ b/arch/ia64/kernel/time.c
@@ -88,7 +88,7 @@ void vtime_flush(struct task_struct *tsk
}
if (ti->softirq_time) {
- delta = cycle_to_nsec(ti->softirq_time));
+ delta = cycle_to_nsec(ti->softirq_time);
account_system_index_time(tsk, delta, CPUTIME_SOFTIRQ);
}
Patches currently in stable-queue which might be from valentin.ilie(a)gmail.com are
queue-4.14/ia64-sched-cputime-fix-build-error-if-config_virt_cpu_accounting_native-y.patch
This is a note to let you know that I've just added the patch titled
i915: Reject CCS modifiers for pipe C on Geminilake
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:
i915-reject-ccs-modifiers-for-pipe-c-on-geminilake.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 Wed Feb 28 16:23:28 CET 2018
From: Gabriel Krisman Bertazi <krisman(a)collabora.co.uk>
Date: Tue, 19 Dec 2017 22:24:10 -0200
Subject: i915: Reject CCS modifiers for pipe C on Geminilake
From: Gabriel Krisman Bertazi <krisman(a)collabora.co.uk>
[ Upstream commit 8bc0d7ac934b6f2d0dc8f38a3104d281c9db1e98 ]
Current code advertises (on the modifiers blob property) support for CCS
modifier for pipe C on GLK, only to reject it later when validating the
request before the atomic commit.
This fixes the tests igt@kms_ccs@pipe-c-*, which should skip on GLK for
pipe C (see bug 104096).
A relevant discussion is archived at:
https://lists.freedesktop.org/archives/intel-gfx/2017-December/150646.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104096
Signed-off-by: Gabriel Krisman Bertazi <krisman(a)collabora.co.uk>
Cc: Ben Widawsky <ben(a)bwidawsk.net>
Reviewed-by: Ben Widawsky <ben(a)bwidawsk.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171220002410.5604-1-krisman…
(cherry picked from commit f0cbd8bd877f3d8c5b80a6b1add9ca9010d7f9d8)
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13240,7 +13240,7 @@ intel_primary_plane_create(struct drm_i9
primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe);
primary->check_plane = intel_check_primary_plane;
- if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+ if (INTEL_GEN(dev_priv) >= 10) {
intel_primary_formats = skl_primary_formats;
num_formats = ARRAY_SIZE(skl_primary_formats);
modifiers = skl_format_modifiers_ccs;
Patches currently in stable-queue which might be from krisman(a)collabora.co.uk are
queue-4.14/i915-reject-ccs-modifiers-for-pipe-c-on-geminilake.patch
This is a note to let you know that I've just added the patch titled
i40e/i40evf: Account for frags split over multiple descriptors in check linearize
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:
i40e-i40evf-account-for-frags-split-over-multiple-descriptors-in-check-linearize.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 Wed Feb 28 16:23:28 CET 2018
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
Date: Fri, 8 Dec 2017 10:55:04 -0800
Subject: i40e/i40evf: Account for frags split over multiple descriptors in check linearize
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
[ Upstream commit 248de22e638f10bd5bfc7624a357f940f66ba137 ]
The original code for __i40e_chk_linearize didn't take into account the
fact that if a fragment is 16K in size or larger it has to be split over 2
descriptors and the smaller of those 2 descriptors will be on the trailing
edge of the transmit. As a result we can get into situations where we didn't
catch requests that could result in a Tx hang.
This patch takes care of that by subtracting the length of all but the
trailing edge of the stale fragment before we test for sum. By doing this
we can guarantee that we have all cases covered, including the case of a
fragment that spans multiple descriptors. We don't need to worry about
checking the inner portions of this since 12K is the maximum aligned DMA
size and that is larger than any MSS will ever be since the MTU limit for
jumbos is something on the order of 9K.
Signed-off-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 26 +++++++++++++++++++++++---
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 26 +++++++++++++++++++++++---
2 files changed, 46 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -3048,10 +3048,30 @@ bool __i40e_chk_linearize(struct sk_buff
/* Walk through fragments adding latest fragment, testing it, and
* then removing stale fragments from the sum.
*/
- stale = &skb_shinfo(skb)->frags[0];
- for (;;) {
+ for (stale = &skb_shinfo(skb)->frags[0];; stale++) {
+ int stale_size = skb_frag_size(stale);
+
sum += skb_frag_size(frag++);
+ /* The stale fragment may present us with a smaller
+ * descriptor than the actual fragment size. To account
+ * for that we need to remove all the data on the front and
+ * figure out what the remainder would be in the last
+ * descriptor associated with the fragment.
+ */
+ if (stale_size > I40E_MAX_DATA_PER_TXD) {
+ int align_pad = -(stale->page_offset) &
+ (I40E_MAX_READ_REQ_SIZE - 1);
+
+ sum -= align_pad;
+ stale_size -= align_pad;
+
+ do {
+ sum -= I40E_MAX_DATA_PER_TXD_ALIGNED;
+ stale_size -= I40E_MAX_DATA_PER_TXD_ALIGNED;
+ } while (stale_size > I40E_MAX_DATA_PER_TXD);
+ }
+
/* if sum is negative we failed to make sufficient progress */
if (sum < 0)
return true;
@@ -3059,7 +3079,7 @@ bool __i40e_chk_linearize(struct sk_buff
if (!nr_frags--)
break;
- sum -= skb_frag_size(stale++);
+ sum -= stale_size;
}
return false;
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
@@ -2014,10 +2014,30 @@ bool __i40evf_chk_linearize(struct sk_bu
/* Walk through fragments adding latest fragment, testing it, and
* then removing stale fragments from the sum.
*/
- stale = &skb_shinfo(skb)->frags[0];
- for (;;) {
+ for (stale = &skb_shinfo(skb)->frags[0];; stale++) {
+ int stale_size = skb_frag_size(stale);
+
sum += skb_frag_size(frag++);
+ /* The stale fragment may present us with a smaller
+ * descriptor than the actual fragment size. To account
+ * for that we need to remove all the data on the front and
+ * figure out what the remainder would be in the last
+ * descriptor associated with the fragment.
+ */
+ if (stale_size > I40E_MAX_DATA_PER_TXD) {
+ int align_pad = -(stale->page_offset) &
+ (I40E_MAX_READ_REQ_SIZE - 1);
+
+ sum -= align_pad;
+ stale_size -= align_pad;
+
+ do {
+ sum -= I40E_MAX_DATA_PER_TXD_ALIGNED;
+ stale_size -= I40E_MAX_DATA_PER_TXD_ALIGNED;
+ } while (stale_size > I40E_MAX_DATA_PER_TXD);
+ }
+
/* if sum is negative we failed to make sufficient progress */
if (sum < 0)
return true;
@@ -2025,7 +2045,7 @@ bool __i40evf_chk_linearize(struct sk_bu
if (!nr_frags--)
break;
- sum -= skb_frag_size(stale++);
+ sum -= stale_size;
}
return false;
Patches currently in stable-queue which might be from alexander.h.duyck(a)intel.com are
queue-4.14/i40e-i40evf-account-for-frags-split-over-multiple-descriptors-in-check-linearize.patch
This is a note to let you know that I've just added the patch titled
i40e: don't remove netdev->dev_addr when syncing uc list
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:
i40e-don-t-remove-netdev-dev_addr-when-syncing-uc-list.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 Wed Feb 28 16:23:28 CET 2018
From: Jacob Keller <jacob.e.keller(a)intel.com>
Date: Wed, 20 Dec 2017 11:04:36 -0500
Subject: i40e: don't remove netdev->dev_addr when syncing uc list
From: Jacob Keller <jacob.e.keller(a)intel.com>
[ Upstream commit 458867b2ca0c987445c5d9adccd1642970e1ba07 ]
In some circumstances, such as with bridging, it is possible that the
stack will add a devices own MAC address to its unicast address list.
If, later, the stack deletes this address, then the i40e driver will
receive a request to remove this address.
The driver stores its current MAC address as part of the MAC/VLAN hash
array, since it is convenient and matches exactly how the hardware
expects to be told which traffic to receive.
This causes a problem, since for more devices, the MAC address is stored
separately, and requests to delete a unicast address should not have the
ability to remove the filter for the MAC address.
Fix this by forcing a check on every address sync to ensure we do not
remove the device address.
There is a very narrow possibility of a race between .set_mac and
.set_rx_mode, if we don't change netdev->dev_addr before updating our
internal MAC list in .set_mac. This might be possible if .set_rx_mode is
going to remove MAC "XYZ" from the list, at the same time as .set_mac
changes our dev_addr to MAC "XYZ", we might possibly queue a delete,
then an add in .set_mac, then queue a delete in .set_rx_mode's
dev_uc_sync and then update netdev->dev_addr. We can avoid this by
moving the copy into dev_addr prior to the changes to the MAC filter
list.
A similar race on the other side does not cause problems, as if we're
changing our MAC form A to B, and we race with .set_rx_mode, it could
queue a delete from A, we'd update our address, and allow the delete.
This seems like a race, but in reality we're about to queue a delete of
A anyways, so it would not cause any issues.
A race in the initialization code is unlikely because the netdevice has
not yet been fully initialized and the stack should not be adding or
removing addresses yet.
Note that we don't (yet) need similar code for the VF driver because it
does not make use of __dev_uc_sync and __dev_mc_sync, but instead roles
its own method for handling updates to the MAC/VLAN list, which already
has code to protect against removal of the hardware address.
Signed-off-by: Jacob Keller <jacob.e.keller(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -1553,11 +1553,18 @@ static int i40e_set_mac(struct net_devic
else
netdev_info(netdev, "set new mac address %pM\n", addr->sa_data);
+ /* Copy the address first, so that we avoid a possible race with
+ * .set_rx_mode(). If we copy after changing the address in the filter
+ * list, we might open ourselves to a narrow race window where
+ * .set_rx_mode could delete our dev_addr filter and prevent traffic
+ * from passing.
+ */
+ ether_addr_copy(netdev->dev_addr, addr->sa_data);
+
spin_lock_bh(&vsi->mac_filter_hash_lock);
i40e_del_mac_filter(vsi, netdev->dev_addr);
i40e_add_mac_filter(vsi, addr->sa_data);
spin_unlock_bh(&vsi->mac_filter_hash_lock);
- ether_addr_copy(netdev->dev_addr, addr->sa_data);
if (vsi->type == I40E_VSI_MAIN) {
i40e_status ret;
@@ -1739,6 +1746,14 @@ static int i40e_addr_unsync(struct net_d
struct i40e_netdev_priv *np = netdev_priv(netdev);
struct i40e_vsi *vsi = np->vsi;
+ /* Under some circumstances, we might receive a request to delete
+ * our own device address from our uc list. Because we store the
+ * device address in the VSI's MAC/VLAN filter list, we need to ignore
+ * such requests and not delete our device address from this list.
+ */
+ if (ether_addr_equal(addr, netdev->dev_addr))
+ return 0;
+
i40e_del_mac_filter(vsi, addr);
return 0;
Patches currently in stable-queue which might be from jacob.e.keller(a)intel.com are
queue-4.14/i40e-don-t-remove-netdev-dev_addr-when-syncing-uc-list.patch
This is a note to let you know that I've just added the patch titled
genirq: Guard handle_bad_irq log messages
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:
genirq-guard-handle_bad_irq-log-messages.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 Wed Feb 28 16:23:28 CET 2018
From: Guenter Roeck <linux(a)roeck-us.net>
Date: Sat, 2 Dec 2017 09:13:04 -0800
Subject: genirq: Guard handle_bad_irq log messages
From: Guenter Roeck <linux(a)roeck-us.net>
[ Upstream commit 11bca0a83f83f6093d816295668e74ef24595944 ]
An interrupt storm on a bad interrupt will cause the kernel
log to be clogged.
[ 60.089234] ->handle_irq(): ffffffffbe2f803f,
[ 60.090455] 0xffffffffbf2af380
[ 60.090510] handle_bad_irq+0x0/0x2e5
[ 60.090522] ->irq_data.chip(): ffffffffbf2af380,
[ 60.090553] IRQ_NOPROBE set
[ 60.090584] ->handle_irq(): ffffffffbe2f803f,
[ 60.090590] handle_bad_irq+0x0/0x2e5
[ 60.090596] ->irq_data.chip(): ffffffffbf2af380,
[ 60.090602] 0xffffffffbf2af380
[ 60.090608] ->action(): (null)
[ 60.090779] handle_bad_irq+0x0/0x2e5
This was seen when running an upstream kernel on Acer Chromebook R11. The
system was unstable as result.
Guard the log message with __printk_ratelimit to reduce the impact. This
won't prevent the interrupt storm from happening, but at least the system
remains stable.
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Dmitry Torokhov <dtor(a)chromium.org>
Cc: Joe Perches <joe(a)perches.com>
Cc: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=197953
Link: https://lkml.kernel.org/r/1512234784-21038-1-git-send-email-linux@roeck-us.…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/irq/debug.h | 5 +++++
1 file changed, 5 insertions(+)
--- a/kernel/irq/debug.h
+++ b/kernel/irq/debug.h
@@ -12,6 +12,11 @@
static inline void print_irq_desc(unsigned int irq, struct irq_desc *desc)
{
+ static DEFINE_RATELIMIT_STATE(ratelimit, 5 * HZ, 5);
+
+ if (!__ratelimit(&ratelimit))
+ return;
+
printk("irq %d, desc: %p, depth: %d, count: %d, unhandled: %d\n",
irq, desc, desc->depth, desc->irq_count, desc->irqs_unhandled);
printk("->handle_irq(): %p, ", desc->handle_irq);
Patches currently in stable-queue which might be from linux(a)roeck-us.net are
queue-4.14/genirq-guard-handle_bad_irq-log-messages.patch
This is a note to let you know that I've just added the patch titled
exec: avoid gcc-8 warning for get_task_comm
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:
exec-avoid-gcc-8-warning-for-get_task_comm.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 Wed Feb 28 16:23:28 CET 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 14 Dec 2017 15:32:41 -0800
Subject: exec: avoid gcc-8 warning for get_task_comm
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 3756f6401c302617c5e091081ca4d26ab604bec5 ]
gcc-8 warns about using strncpy() with the source size as the limit:
fs/exec.c:1223:32: error: argument to 'sizeof' in 'strncpy' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
This is indeed slightly suspicious, as it protects us from source
arguments without NUL-termination, but does not guarantee that the
destination is terminated.
This keeps the strncpy() to ensure we have properly padded target
buffer, but ensures that we use the correct length, by passing the
actual length of the destination buffer as well as adding a build-time
check to ensure it is exactly TASK_COMM_LEN.
There are only 23 callsites which I all reviewed to ensure this is
currently the case. We could get away with doing only the check or
passing the right length, but it doesn't hurt to do both.
Link: http://lkml.kernel.org/r/20171205151724.1764896-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Suggested-by: Kees Cook <keescook(a)chromium.org>
Acked-by: Kees Cook <keescook(a)chromium.org>
Acked-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Serge Hallyn <serge(a)hallyn.com>
Cc: James Morris <james.l.morris(a)oracle.com>
Cc: Aleksa Sarai <asarai(a)suse.de>
Cc: "Eric W. Biederman" <ebiederm(a)xmission.com>
Cc: Frederic Weisbecker <frederic(a)kernel.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/exec.c | 7 +++----
include/linux/sched.h | 6 +++++-
2 files changed, 8 insertions(+), 5 deletions(-)
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1216,15 +1216,14 @@ killed:
return -EAGAIN;
}
-char *get_task_comm(char *buf, struct task_struct *tsk)
+char *__get_task_comm(char *buf, size_t buf_size, struct task_struct *tsk)
{
- /* buf must be at least sizeof(tsk->comm) in size */
task_lock(tsk);
- strncpy(buf, tsk->comm, sizeof(tsk->comm));
+ strncpy(buf, tsk->comm, buf_size);
task_unlock(tsk);
return buf;
}
-EXPORT_SYMBOL_GPL(get_task_comm);
+EXPORT_SYMBOL_GPL(__get_task_comm);
/*
* These functions flushes out all traces of the currently running executable
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1502,7 +1502,11 @@ static inline void set_task_comm(struct
__set_task_comm(tsk, from, false);
}
-extern char *get_task_comm(char *to, struct task_struct *tsk);
+extern char *__get_task_comm(char *to, size_t len, struct task_struct *tsk);
+#define get_task_comm(buf, tsk) ({ \
+ BUILD_BUG_ON(sizeof(buf) != TASK_COMM_LEN); \
+ __get_task_comm(buf, sizeof(buf), tsk); \
+})
#ifdef CONFIG_SMP
void scheduler_ipi(void);
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/exec-avoid-gcc-8-warning-for-get_task_comm.patch
queue-4.14/x86-asm-allow-again-using-asm.h-when-building-for-the-bpf-clang-target.patch
queue-4.14/arm-dts-ls1021a-fix-incorrect-clock-references.patch
This is a note to let you know that I've just added the patch titled
drm/ttm: check the return value of kzalloc
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:
drm-ttm-check-the-return-value-of-kzalloc.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 Wed Feb 28 16:23:28 CET 2018
From: Xiongwei Song <sxwjean(a)gmail.com>
Date: Tue, 2 Jan 2018 21:24:55 +0800
Subject: drm/ttm: check the return value of kzalloc
From: Xiongwei Song <sxwjean(a)gmail.com>
[ Upstream commit 19d859a7205bc59ffc38303eb25ae394f61d21dc ]
In the function ttm_page_alloc_init, kzalloc call is made for variable
_manager, we need to check its return value, it may return NULL.
Signed-off-by: Xiongwei Song <sxwjean(a)gmail.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -821,6 +821,8 @@ int ttm_page_alloc_init(struct ttm_mem_g
pr_info("Initializing pool allocator\n");
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
+ if (!_manager)
+ return -ENOMEM;
ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");
Patches currently in stable-queue which might be from sxwjean(a)gmail.com are
queue-4.14/drm-ttm-check-the-return-value-of-kzalloc.patch
This is a note to let you know that I've just added the patch titled
drm/nouveau/pci: do a msi rearm on init
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:
drm-nouveau-pci-do-a-msi-rearm-on-init.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 Wed Feb 28 16:23:28 CET 2018
From: Karol Herbst <kherbst(a)redhat.com>
Date: Fri, 24 Nov 2017 03:56:26 +0100
Subject: drm/nouveau/pci: do a msi rearm on init
From: Karol Herbst <kherbst(a)redhat.com>
[ Upstream commit a121027d2747168df0aac0c3da35509eea39f61c ]
On my GP107 when I load nouveau after unloading it, for some reason the
GPU stopped sending or the CPU stopped receiving interrupts if MSI was
enabled.
Doing a rearm once before getting any interrupts fixes this.
Signed-off-by: Karol Herbst <kherbst(a)redhat.com>
Reviewed-by: Thierry Reding <treding(a)nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
@@ -136,6 +136,13 @@ nvkm_pci_init(struct nvkm_subdev *subdev
return ret;
pci->irq = pdev->irq;
+
+ /* Ensure MSI interrupts are armed, for the case where there are
+ * already interrupts pending (for whatever reason) at load time.
+ */
+ if (pci->msi)
+ pci->func->msi_rearm(pci);
+
return ret;
}
Patches currently in stable-queue which might be from kherbst(a)redhat.com are
queue-4.14/drm-nouveau-pci-do-a-msi-rearm-on-init.patch
This is a note to let you know that I've just added the patch titled
dmaengine: fsl-edma: disable clks on all error paths
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:
dmaengine-fsl-edma-disable-clks-on-all-error-paths.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 Wed Feb 28 16:23:28 CET 2018
From: Andreas Platschek <andreas.platschek(a)opentech.at>
Date: Thu, 14 Dec 2017 12:50:51 +0100
Subject: dmaengine: fsl-edma: disable clks on all error paths
From: Andreas Platschek <andreas.platschek(a)opentech.at>
[ Upstream commit 2610acf46b9ed528ec2cacd717bc9d354e452b73 ]
Previously enabled clks are only disabled if clk_prepare_enable() fails.
However, there are other error paths were the previously enabled
clocks are not disabled.
To fix the problem, fsl_disable_clocks() now takes the number of clocks
that shall be disabled + unprepared. For existing calls were all clocks
were already successfully prepared + enabled, DMAMUX_NR is passed to
disable + unprepare all clocks.
In error paths were only some clocks were successfully prepared +
enabled the loop counter is passed, in order to disable + unprepare
all successfully prepared + enabled clocks.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Andreas Platschek <andreas.platschek(a)opentech.at>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/fsl-edma.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
--- a/drivers/dma/fsl-edma.c
+++ b/drivers/dma/fsl-edma.c
@@ -863,11 +863,11 @@ static void fsl_edma_irq_exit(
}
}
-static void fsl_disable_clocks(struct fsl_edma_engine *fsl_edma)
+static void fsl_disable_clocks(struct fsl_edma_engine *fsl_edma, int nr_clocks)
{
int i;
- for (i = 0; i < DMAMUX_NR; i++)
+ for (i = 0; i < nr_clocks; i++)
clk_disable_unprepare(fsl_edma->muxclk[i]);
}
@@ -904,25 +904,25 @@ static int fsl_edma_probe(struct platfor
res = platform_get_resource(pdev, IORESOURCE_MEM, 1 + i);
fsl_edma->muxbase[i] = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(fsl_edma->muxbase[i]))
+ if (IS_ERR(fsl_edma->muxbase[i])) {
+ /* on error: disable all previously enabled clks */
+ fsl_disable_clocks(fsl_edma, i);
return PTR_ERR(fsl_edma->muxbase[i]);
+ }
sprintf(clkname, "dmamux%d", i);
fsl_edma->muxclk[i] = devm_clk_get(&pdev->dev, clkname);
if (IS_ERR(fsl_edma->muxclk[i])) {
dev_err(&pdev->dev, "Missing DMAMUX block clock.\n");
+ /* on error: disable all previously enabled clks */
+ fsl_disable_clocks(fsl_edma, i);
return PTR_ERR(fsl_edma->muxclk[i]);
}
ret = clk_prepare_enable(fsl_edma->muxclk[i]);
- if (ret) {
- /* disable only clks which were enabled on error */
- for (; i >= 0; i--)
- clk_disable_unprepare(fsl_edma->muxclk[i]);
-
- dev_err(&pdev->dev, "DMAMUX clk block failed.\n");
- return ret;
- }
+ if (ret)
+ /* on error: disable all previously enabled clks */
+ fsl_disable_clocks(fsl_edma, i);
}
@@ -976,7 +976,7 @@ static int fsl_edma_probe(struct platfor
if (ret) {
dev_err(&pdev->dev,
"Can't register Freescale eDMA engine. (%d)\n", ret);
- fsl_disable_clocks(fsl_edma);
+ fsl_disable_clocks(fsl_edma, DMAMUX_NR);
return ret;
}
@@ -985,7 +985,7 @@ static int fsl_edma_probe(struct platfor
dev_err(&pdev->dev,
"Can't register Freescale eDMA of_dma. (%d)\n", ret);
dma_async_device_unregister(&fsl_edma->dma_dev);
- fsl_disable_clocks(fsl_edma);
+ fsl_disable_clocks(fsl_edma, DMAMUX_NR);
return ret;
}
@@ -1015,7 +1015,7 @@ static int fsl_edma_remove(struct platfo
fsl_edma_cleanup_vchan(&fsl_edma->dma_dev);
of_dma_controller_free(np);
dma_async_device_unregister(&fsl_edma->dma_dev);
- fsl_disable_clocks(fsl_edma);
+ fsl_disable_clocks(fsl_edma, DMAMUX_NR);
return 0;
}
Patches currently in stable-queue which might be from andreas.platschek(a)opentech.at are
queue-4.14/dmaengine-fsl-edma-disable-clks-on-all-error-paths.patch
This is a note to let you know that I've just added the patch titled
crypto: inside-secure - free requests even if their handling failed
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:
crypto-inside-secure-free-requests-even-if-their-handling-failed.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 Wed Feb 28 16:23:28 CET 2018
From: "Antoine Ténart" <antoine.tenart(a)free-electrons.com>
Date: Mon, 11 Dec 2017 12:10:56 +0100
Subject: crypto: inside-secure - free requests even if their handling failed
From: "Antoine Ténart" <antoine.tenart(a)free-electrons.com>
[ Upstream commit 0a02dcca126280595950f3ea809f77c9cb0a235c ]
This patch frees the request private data even if its handling failed,
as it would never be freed otherwise.
Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver")
Suggested-by: Ofer Heifetz <oferh(a)marvell.com>
Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/inside-secure/safexcel.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/crypto/inside-secure/safexcel.c
+++ b/drivers/crypto/inside-secure/safexcel.c
@@ -607,6 +607,7 @@ static inline void safexcel_handle_resul
ndesc = ctx->handle_result(priv, ring, sreq->req,
&should_complete, &ret);
if (ndesc < 0) {
+ kfree(sreq);
dev_err(priv->dev, "failed to handle result (%d)", ndesc);
return;
}
Patches currently in stable-queue which might be from antoine.tenart(a)free-electrons.com are
queue-4.14/crypto-inside-secure-per-request-invalidation.patch
queue-4.14/crypto-inside-secure-fix-request-allocations-in-invalidation-path.patch
queue-4.14/crypto-inside-secure-free-requests-even-if-their-handling-failed.patch
This is a note to let you know that I've just added the patch titled
cgroup: Fix deadlock in cpu hotplug path
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:
cgroup-fix-deadlock-in-cpu-hotplug-path.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 Wed Feb 28 16:23:28 CET 2018
From: Prateek Sood <prsood(a)codeaurora.org>
Date: Tue, 19 Dec 2017 12:56:57 +0530
Subject: cgroup: Fix deadlock in cpu hotplug path
From: Prateek Sood <prsood(a)codeaurora.org>
[ Upstream commit 116d2f7496c51b2e02e8e4ecdd2bdf5fb9d5a641 ]
Deadlock during cgroup migration from cpu hotplug path when a task T is
being moved from source to destination cgroup.
kworker/0:0
cpuset_hotplug_workfn()
cpuset_hotplug_update_tasks()
hotplug_update_tasks_legacy()
remove_tasks_in_empty_cpuset()
cgroup_transfer_tasks() // stuck in iterator loop
cgroup_migrate()
cgroup_migrate_add_task()
In cgroup_migrate_add_task() it checks for PF_EXITING flag of task T.
Task T will not migrate to destination cgroup. css_task_iter_start()
will keep pointing to task T in loop waiting for task T cg_list node
to be removed.
Task T
do_exit()
exit_signals() // sets PF_EXITING
exit_task_namespaces()
switch_task_namespaces()
free_nsproxy()
put_mnt_ns()
drop_collected_mounts()
namespace_unlock()
synchronize_rcu()
_synchronize_rcu_expedited()
schedule_work() // on cpu0 low priority worker pool
wait_event() // waiting for work item to execute
Task T inserted a work item in the worklist of cpu0 low priority
worker pool. It is waiting for expedited grace period work item
to execute. This work item will only be executed once kworker/0:0
complete execution of cpuset_hotplug_workfn().
kworker/0:0 ==> Task T ==>kworker/0:0
In case of PF_EXITING task being migrated from source to destination
cgroup, migrate next available task in source cgroup.
Signed-off-by: Prateek Sood <prsood(a)codeaurora.org>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/cgroup/cgroup-v1.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -123,7 +123,11 @@ int cgroup_transfer_tasks(struct cgroup
*/
do {
css_task_iter_start(&from->self, 0, &it);
- task = css_task_iter_next(&it);
+
+ do {
+ task = css_task_iter_next(&it);
+ } while (task && (task->flags & PF_EXITING));
+
if (task)
get_task_struct(task);
css_task_iter_end(&it);
Patches currently in stable-queue which might be from prsood(a)codeaurora.org are
queue-4.14/cgroup-fix-deadlock-in-cpu-hotplug-path.patch
This is a note to let you know that I've just added the patch titled
can: flex_can: Correct the checking for frame length in flexcan_start_xmit()
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:
can-flex_can-correct-the-checking-for-frame-length-in-flexcan_start_xmit.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 Wed Feb 28 16:23:28 CET 2018
From: Luu An Phu <phu.luuan(a)nxp.com>
Date: Tue, 2 Jan 2018 10:44:18 +0700
Subject: can: flex_can: Correct the checking for frame length in flexcan_start_xmit()
From: Luu An Phu <phu.luuan(a)nxp.com>
[ Upstream commit 13454c14550065fcc1705d6bd4ee6d40e057099f ]
The flexcan_start_xmit() function compares the frame length with data
register length to write frame content into data[0] and data[1]
register. Data register length is 4 bytes and frame maximum length is 8
bytes.
Fix the check that compares frame length with 3. Because the register
length is 4.
Signed-off-by: Luu An Phu <phu.luuan(a)nxp.com>
Reviewed-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/flexcan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -526,7 +526,7 @@ static int flexcan_start_xmit(struct sk_
data = be32_to_cpup((__be32 *)&cf->data[0]);
flexcan_write(data, &priv->tx_mb->data[0]);
}
- if (cf->can_dlc > 3) {
+ if (cf->can_dlc > 4) {
data = be32_to_cpup((__be32 *)&cf->data[4]);
flexcan_write(data, &priv->tx_mb->data[1]);
}
Patches currently in stable-queue which might be from phu.luuan(a)nxp.com are
queue-4.14/can-flex_can-correct-the-checking-for-frame-length-in-flexcan_start_xmit.patch
This is a note to let you know that I've just added the patch titled
btrfs: Fix flush bio leak
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:
btrfs-fix-flush-bio-leak.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 Wed Feb 28 16:23:28 CET 2018
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Wed, 13 Dec 2017 13:50:07 +0200
Subject: btrfs: Fix flush bio leak
From: Nikolay Borisov <nborisov(a)suse.com>
[ Upstream commit beed9263f4000c48a5c48912f26576f6fa091181 ]
Commit e0ae99941423 ("btrfs: preallocate device flush bio") reworked
the way the flush bio is allocated and used. Concretely it allocates
the bio in __alloc_device and then re-uses it multiple times with a
very simple endio routine that just calls complete() without consuming
a reference. Allocated bios by default come with a ref count of 1,
which is then consumed by the endio routine (or not, in which case they
should be bio_put by the caller). The way the impleementation works now
is that the flush bio has a refcount of 2 and we only ever bio_put it
once, leaving it to hang indefinitely. Fix this by removing the extra
bio_get in __alloc_device.
Fixes: e0ae99941423 ("btrfs: preallocate device flush bio")
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -236,7 +236,6 @@ static struct btrfs_device *__alloc_devi
kfree(dev);
return ERR_PTR(-ENOMEM);
}
- bio_get(dev->flush_bio);
INIT_LIST_HEAD(&dev->dev_list);
INIT_LIST_HEAD(&dev->dev_alloc_list);
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.14/btrfs-fix-flush-bio-leak.patch
This is a note to let you know that I've just added the patch titled
bpf: sockmap missing NULL psock check
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:
bpf-sockmap-missing-null-psock-check.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 Wed Feb 28 16:23:28 CET 2018
From: John Fastabend <john.fastabend(a)gmail.com>
Date: Thu, 4 Jan 2018 20:02:09 -0800
Subject: bpf: sockmap missing NULL psock check
From: John Fastabend <john.fastabend(a)gmail.com>
[ Upstream commit 5731a879d03bdaa00265f8ebc32dfd0e65d25276 ]
Add psock NULL check to handle a racing sock event that can get the
sk_callback_lock before this case but after xchg happens causing the
refcnt to hit zero and sock user data (psock) to be null and queued
for garbage collection.
Also add a comment in the code because this is a bit subtle and
not obvious in my opinion.
Signed-off-by: John Fastabend <john.fastabend(a)gmail.com>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/bpf/sockmap.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -588,8 +588,15 @@ static void sock_map_free(struct bpf_map
write_lock_bh(&sock->sk_callback_lock);
psock = smap_psock_sk(sock);
- smap_list_remove(psock, &stab->sock_map[i]);
- smap_release_sock(psock, sock);
+ /* This check handles a racing sock event that can get the
+ * sk_callback_lock before this case but after xchg happens
+ * causing the refcnt to hit zero and sock user data (psock)
+ * to be null and queued for garbage collection.
+ */
+ if (likely(psock)) {
+ smap_list_remove(psock, &stab->sock_map[i]);
+ smap_release_sock(psock, sock);
+ }
write_unlock_bh(&sock->sk_callback_lock);
}
rcu_read_unlock();
Patches currently in stable-queue which might be from john.fastabend(a)gmail.com are
queue-4.14/bpf-sockmap-missing-null-psock-check.patch
This is a note to let you know that I've just added the patch titled
bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine.
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:
bnxt_en-fix-the-invalid-vf-id-check-in-bnxt_vf_ndo_prep-routine.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 Wed Feb 28 16:23:28 CET 2018
From: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com>
Date: Thu, 4 Jan 2018 18:46:55 -0500
Subject: bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine.
From: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com>
[ Upstream commit 78f300049335ae81a5cc6b4b232481dc5e1f9d41 ]
In bnxt_vf_ndo_prep (which is called by bnxt_get_vf_config ndo), there is a
check for "Invalid VF id". Currently, the check is done against max_vfs.
However, the user doesn't always create max_vfs. So, the check should be
against the created number of VFs. The number of bnxt_vf_info structures
that are allocated in bnxt_alloc_vf_resources routine is the "number of
requested VFs". So, if an "invalid VF id" falls between the requested
number of VFs and the max_vfs, the driver will be dereferencing an invalid
pointer.
Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Venkat Devvuru <venkatkumar.duvvuru(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.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/bnxt/bnxt_sriov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
@@ -70,7 +70,7 @@ static int bnxt_vf_ndo_prep(struct bnxt
netdev_err(bp->dev, "vf ndo called though sriov is disabled\n");
return -EINVAL;
}
- if (vf_id >= bp->pf.max_vfs) {
+ if (vf_id >= bp->pf.active_vfs) {
netdev_err(bp->dev, "Invalid VF id %d\n", vf_id);
return -EINVAL;
}
Patches currently in stable-queue which might be from venkatkumar.duvvuru(a)broadcom.com are
queue-4.14/bnxt_en-fix-population-of-flow_type-in-bnxt_hwrm_cfa_flow_alloc.patch
queue-4.14/bnxt_en-fix-the-invalid-vf-id-check-in-bnxt_vf_ndo_prep-routine.patch
This is a note to let you know that I've just added the patch titled
bnxt_en: Fix population of flow_type in bnxt_hwrm_cfa_flow_alloc()
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:
bnxt_en-fix-population-of-flow_type-in-bnxt_hwrm_cfa_flow_alloc.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 Wed Feb 28 16:23:28 CET 2018
From: Sunil Challa <sunilkumar.challa(a)broadcom.com>
Date: Thu, 4 Jan 2018 18:46:54 -0500
Subject: bnxt_en: Fix population of flow_type in bnxt_hwrm_cfa_flow_alloc()
From: Sunil Challa <sunilkumar.challa(a)broadcom.com>
[ Upstream commit 7deea450eb912f269d999de62c8ab922d1461748 ]
flow_type in HWRM_FLOW_ALLOC is not being populated correctly due to
incorrect passing of pointer and size of l3_mask argument of is_wildcard().
Fixed this.
Fixes: db1d36a27324 ("bnxt_en: add TC flower offload flow_alloc/free FW cmds")
Signed-off-by: Sunil Challa <sunilkumar.challa(a)broadcom.com>
Reviewed-by: Sathya Perla <sathya.perla(a)broadcom.com>
Reviewed-by: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.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/bnxt/bnxt_tc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
@@ -327,7 +327,7 @@ static int bnxt_hwrm_cfa_flow_alloc(stru
}
/* If all IP and L4 fields are wildcarded then this is an L2 flow */
- if (is_wildcard(&l3_mask, sizeof(l3_mask)) &&
+ if (is_wildcard(l3_mask, sizeof(*l3_mask)) &&
is_wildcard(&flow->l4_mask, sizeof(flow->l4_mask))) {
flow_flags |= CFA_FLOW_ALLOC_REQ_FLAGS_FLOWTYPE_L2;
} else {
Patches currently in stable-queue which might be from sunilkumar.challa(a)broadcom.com are
queue-4.14/bnxt_en-fix-population-of-flow_type-in-bnxt_hwrm_cfa_flow_alloc.patch
This is a note to let you know that I've just added the patch titled
bnx2x: Improve reliability in case of nested PCI errors
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:
bnx2x-improve-reliability-in-case-of-nested-pci-errors.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 Wed Feb 28 16:23:28 CET 2018
From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com>
Date: Fri, 22 Dec 2017 13:01:39 -0200
Subject: bnx2x: Improve reliability in case of nested PCI errors
From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com>
[ Upstream commit f7084059a9cb9e56a186e1677b1dcffd76c2cd24 ]
While in recovery process of PCI error (called EEH on PowerPC arch),
another PCI transaction could be corrupted causing a situation of
nested PCI errors. Also, this scenario could be reproduced with
error injection mechanisms (for debug purposes).
We observe that in case of nested PCI errors, bnx2x might attempt to
initialize its shmem and cause a kernel crash due to bad addresses
read from MCP. Multiple different stack traces were observed depending
on the point the second PCI error happens.
This patch avoids the crashes by:
* failing PCI recovery in case of nested errors (since multiple
PCI errors in a row are not expected to lead to a functional
adapter anyway), and by,
* preventing access to adapter FW when MCP is failed (we mark it as
failed when shmem cannot get initialized properly).
Reported-by: Abdul Haleem <abdhalee(a)linux.vnet.ibm.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com>
Acked-by: Shahed Shaikh <Shahed.Shaikh(a)cavium.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/bnx2x/bnx2x_cmn.c | 4 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 +++++++++++++-
2 files changed, 15 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -3030,7 +3030,7 @@ int bnx2x_nic_unload(struct bnx2x *bp, i
del_timer_sync(&bp->timer);
- if (IS_PF(bp)) {
+ if (IS_PF(bp) && !BP_NOMCP(bp)) {
/* Set ALWAYS_ALIVE bit in shmem */
bp->fw_drv_pulse_wr_seq |= DRV_PULSE_ALWAYS_ALIVE;
bnx2x_drv_pulse(bp);
@@ -3116,7 +3116,7 @@ int bnx2x_nic_unload(struct bnx2x *bp, i
bp->cnic_loaded = false;
/* Clear driver version indication in shmem */
- if (IS_PF(bp))
+ if (IS_PF(bp) && !BP_NOMCP(bp))
bnx2x_update_mng_version(bp);
/* Check if there are pending parity attentions. If there are - set
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -9578,6 +9578,15 @@ static int bnx2x_init_shmem(struct bnx2x
do {
bp->common.shmem_base = REG_RD(bp, MISC_REG_SHARED_MEM_ADDR);
+
+ /* If we read all 0xFFs, means we are in PCI error state and
+ * should bail out to avoid crashes on adapter's FW reads.
+ */
+ if (bp->common.shmem_base == 0xFFFFFFFF) {
+ bp->flags |= NO_MCP_FLAG;
+ return -ENODEV;
+ }
+
if (bp->common.shmem_base) {
val = SHMEM_RD(bp, validity_map[BP_PORT(bp)]);
if (val & SHR_MEM_VALIDITY_MB)
@@ -14315,7 +14324,10 @@ static pci_ers_result_t bnx2x_io_slot_re
BNX2X_ERR("IO slot reset --> driver unload\n");
/* MCP should have been reset; Need to wait for validity */
- bnx2x_init_shmem(bp);
+ if (bnx2x_init_shmem(bp)) {
+ rtnl_unlock();
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
if (IS_PF(bp) && SHMEM2_HAS(bp, drv_capabilities_flag)) {
u32 v;
Patches currently in stable-queue which might be from gpiccoli(a)linux.vnet.ibm.com are
queue-4.14/bnx2x-improve-reliability-in-case-of-nested-pci-errors.patch
This is a note to let you know that I've just added the patch titled
block: drain queue before waiting for q_usage_counter becoming zero
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:
block-drain-queue-before-waiting-for-q_usage_counter-becoming-zero.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 Wed Feb 28 16:23:28 CET 2018
From: Ming Lei <ming.lei(a)redhat.com>
Date: Thu, 30 Nov 2017 07:56:35 +0800
Subject: block: drain queue before waiting for q_usage_counter becoming zero
From: Ming Lei <ming.lei(a)redhat.com>
[ Upstream commit 454be724f6f99cc7e7bbf15067128be9868186c6 ]
Now we track legacy requests with .q_usage_counter in commit 055f6e18e08f
("block: Make q_usage_counter also track legacy requests"), but that
commit never runs and drains legacy queue before waiting for this counter
becoming zero, then IO hang is caused in the test of pulling disk during IO.
This patch fixes the issue by draining requests before waiting for
q_usage_counter becoming zero, both Mauricio and chenxiang reported this
issue, and observed that it can be fixed by this patch.
Link: https://marc.info/?l=linux-block&m=151192424731797&w=2
Fixes: 055f6e18e08f("block: Make q_usage_counter also track legacy requests")
Cc: Wen Xiong <wenxiong(a)us.ibm.com>
Tested-by: "chenxiang (M)" <chenxiang66(a)hisilicon.com>
Tested-by: Mauricio Faria de Oliveira <mauricfo(a)linux.vnet.ibm.com>
Signed-off-by: Ming Lei <ming.lei(a)redhat.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-core.c | 9 +++++++--
block/blk-mq.c | 2 ++
block/blk.h | 2 ++
3 files changed, 11 insertions(+), 2 deletions(-)
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -531,6 +531,13 @@ static void __blk_drain_queue(struct req
}
}
+void blk_drain_queue(struct request_queue *q)
+{
+ spin_lock_irq(q->queue_lock);
+ __blk_drain_queue(q, true);
+ spin_unlock_irq(q->queue_lock);
+}
+
/**
* blk_queue_bypass_start - enter queue bypass mode
* @q: queue of interest
@@ -655,8 +662,6 @@ void blk_cleanup_queue(struct request_qu
*/
blk_freeze_queue(q);
spin_lock_irq(lock);
- if (!q->mq_ops)
- __blk_drain_queue(q, true);
queue_flag_set(QUEUE_FLAG_DEAD, q);
spin_unlock_irq(lock);
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -159,6 +159,8 @@ void blk_freeze_queue(struct request_que
* exported to drivers as the only user for unfreeze is blk_mq.
*/
blk_freeze_queue_start(q);
+ if (!q->mq_ops)
+ blk_drain_queue(q);
blk_mq_freeze_queue_wait(q);
}
--- a/block/blk.h
+++ b/block/blk.h
@@ -362,4 +362,6 @@ static inline void blk_queue_bounce(stru
}
#endif /* CONFIG_BOUNCE */
+extern void blk_drain_queue(struct request_queue *q);
+
#endif /* BLK_INTERNAL_H */
Patches currently in stable-queue which might be from ming.lei(a)redhat.com are
queue-4.14/block-drain-queue-before-waiting-for-q_usage_counter-becoming-zero.patch
This is a note to let you know that I've just added the patch titled
ASoC: nau8825: fix issue that pop noise when start capture
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:
asoc-nau8825-fix-issue-that-pop-noise-when-start-capture.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 Wed Feb 28 16:23:28 CET 2018
From: Abhijeet Kumar <abhijeet.kumar(a)intel.com>
Date: Tue, 12 Dec 2017 00:40:25 +0530
Subject: ASoC: nau8825: fix issue that pop noise when start capture
From: Abhijeet Kumar <abhijeet.kumar(a)intel.com>
[ Upstream commit d070f7c703ef26e3db613f24206823f916272fc6 ]
In skylake platform, we hear a loud pop noise(0 dB) at start of
audio capture power up sequence. This patch removes the pop noise
from the recording by adding a delay before enabling ADC.
Signed-off-by: Abhijeet Kumar <abhijeet.kumar(a)intel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/nau8825.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/soc/codecs/nau8825.c
+++ b/sound/soc/codecs/nau8825.c
@@ -905,6 +905,7 @@ static int nau8825_adc_event(struct snd_
switch (event) {
case SND_SOC_DAPM_POST_PMU:
+ msleep(125);
regmap_update_bits(nau8825->regmap, NAU8825_REG_ENA_CTRL,
NAU8825_ENABLE_ADC, NAU8825_ENABLE_ADC);
break;
Patches currently in stable-queue which might be from abhijeet.kumar(a)intel.com are
queue-4.14/asoc-nau8825-fix-issue-that-pop-noise-when-start-capture.patch
This is a note to let you know that I've just added the patch titled
ASoC: rsnd: fixup ADG register mask
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:
asoc-rsnd-fixup-adg-register-mask.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 Wed Feb 28 16:23:28 CET 2018
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Date: Wed, 20 Dec 2017 06:11:59 +0000
Subject: ASoC: rsnd: fixup ADG register mask
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
[ Upstream commit d5aa24825da5711f8cb829f873160ddf1a29b19c ]
BRGCKR should use 0x80770000, instead of 0x80FF0000.
R-Car Gen2 xxx_TIMSEL should use 0x0F1F,
R-Car Gen3 xxx_TIMSEL should use 0x1F1F.
Here, Gen3 doesn't support AVD, thus, both case can use 0x0F1F.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Reviewed-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/sh/rcar/adg.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/sound/soc/sh/rcar/adg.c
+++ b/sound/soc/sh/rcar/adg.c
@@ -216,7 +216,7 @@ int rsnd_adg_set_cmd_timsel_gen2(struct
NULL, &val, NULL);
val = val << shift;
- mask = 0xffff << shift;
+ mask = 0x0f1f << shift;
rsnd_mod_bset(adg_mod, CMDOUT_TIMSEL, mask, val);
@@ -244,7 +244,7 @@ int rsnd_adg_set_src_timesel_gen2(struct
in = in << shift;
out = out << shift;
- mask = 0xffff << shift;
+ mask = 0x0f1f << shift;
switch (id / 2) {
case 0:
@@ -374,7 +374,7 @@ int rsnd_adg_ssi_clk_try_start(struct rs
ckr = 0x80000000;
}
- rsnd_mod_bset(adg_mod, BRGCKR, 0x80FF0000, adg->ckr | ckr);
+ rsnd_mod_bset(adg_mod, BRGCKR, 0x80770000, adg->ckr | ckr);
rsnd_mod_write(adg_mod, BRRA, adg->rbga);
rsnd_mod_write(adg_mod, BRRB, adg->rbgb);
Patches currently in stable-queue which might be from kuninori.morimoto.gx(a)renesas.com are
queue-4.14/asoc-rsnd-fixup-adg-register-mask.patch
This is a note to let you know that I've just added the patch titled
arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property
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:
arm64-dts-renesas-ulcb-remove-renesas-no-ether-link-property.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 Wed Feb 28 16:23:28 CET 2018
From: Bogdan Mirea <Bogdan-Stefan_Mirea(a)mentor.com>
Date: Thu, 21 Dec 2017 17:18:59 +0200
Subject: arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property
From: Bogdan Mirea <Bogdan-Stefan_Mirea(a)mentor.com>
[ Upstream commit 7d2901f809c110bd9a261e879d59efe62e3bc758 ]
The present change is a bug fix for AVB link iteratively up/down.
Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
without user interaction,
- this may heal after some seconds or even stay for minutes.
As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.
Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
the RX & TX are enabled/disabled directly from adjust_link function
without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
HW interrogation. The HW check is made through the LMON pin in PSR
register which specifies AVB_LINK signal value (0 - at low level;
1 - at high level).
In conclusion, the present change is also a safety improvement because
it removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.
Fixes: dc36965a8905 ("arm64: dts: r8a7796: salvator-x: Enable EthernetAVB")
Fixes: 6fa501c549aa ("arm64: dts: r8a7795: enable EthernetAVB on Salvator-X")
Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea(a)mentor.com>
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy(a)mentor.com>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 -
1 file changed, 1 deletion(-)
--- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
@@ -145,7 +145,6 @@
&avb {
pinctrl-0 = <&avb_pins>;
pinctrl-names = "default";
- renesas,no-ether-link;
phy-handle = <&phy0>;
status = "okay";
Patches currently in stable-queue which might be from Bogdan-Stefan_Mirea(a)mentor.com are
queue-4.14/arm64-dts-renesas-ulcb-remove-renesas-no-ether-link-property.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: ls1021a: fix incorrect clock references
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:
arm-dts-ls1021a-fix-incorrect-clock-references.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 Wed Feb 28 16:23:28 CET 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 21 Dec 2017 22:35:19 +0100
Subject: ARM: dts: ls1021a: fix incorrect clock references
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 506e8a912661c97b41adc8a286b875d01323ec45 ]
dtc warns about two 'clocks' properties that have an extraneous '1'
at the end:
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a:clocks[1])
Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2190000/sgtl5000@a
arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2190000/sgtl5000@a:clocks[1])
The clocks that get referenced here are fixed-rate, so they do not
take any argument, and dtc interprets the next cell as a phandle, which
is invalid.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/ls1021a-qds.dts | 2 +-
arch/arm/boot/dts/ls1021a-twr.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -215,7 +215,7 @@
reg = <0x2a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
};
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -187,7 +187,7 @@
reg = <0x0a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/exec-avoid-gcc-8-warning-for-get_task_comm.patch
queue-4.14/x86-asm-allow-again-using-asm.h-when-building-for-the-bpf-clang-target.patch
queue-4.14/arm-dts-ls1021a-fix-incorrect-clock-references.patch
This is a note to let you know that I've just added the patch titled
ARM: 8731/1: Fix csum_partial_copy_from_user() stack mismatch
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:
arm-8731-1-fix-csum_partial_copy_from_user-stack-mismatch.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 Wed Feb 28 16:23:28 CET 2018
From: Chunyan Zhang <zhang.lyra(a)gmail.com>
Date: Fri, 1 Dec 2017 03:51:04 +0100
Subject: ARM: 8731/1: Fix csum_partial_copy_from_user() stack mismatch
From: Chunyan Zhang <zhang.lyra(a)gmail.com>
[ Upstream commit 36b0cb84ee858f02c256d26f0cb4229c78e3399e ]
An additional 'ip' will be pushed to the stack, for restoring the
DACR later, if CONFIG_CPU_SW_DOMAIN_PAN defined.
However, the fixup still get the err_ptr by add #8*4 to sp, which
results in the fact that the code area pointed by the LR will be
overwritten, or the kernel will crash if CONFIG_DEBUG_RODATA is enabled.
This patch fixes the stack mismatch.
Fixes: a5e090acbf54 ("ARM: software-based priviledged-no-access support")
Signed-off-by: Lvqiang Huang <Lvqiang.Huang(a)spreadtrum.com>
Signed-off-by: Chunyan Zhang <zhang.lyra(a)gmail.com>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/lib/csumpartialcopyuser.S | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/arm/lib/csumpartialcopyuser.S
+++ b/arch/arm/lib/csumpartialcopyuser.S
@@ -85,7 +85,11 @@
.pushsection .text.fixup,"ax"
.align 4
9001: mov r4, #-EFAULT
+#ifdef CONFIG_CPU_SW_DOMAIN_PAN
+ ldr r5, [sp, #9*4] @ *err_ptr
+#else
ldr r5, [sp, #8*4] @ *err_ptr
+#endif
str r4, [r5]
ldmia sp, {r1, r2} @ retrieve dst, len
add r2, r2, r1
Patches currently in stable-queue which might be from zhang.lyra(a)gmail.com are
queue-4.14/arm-8731-1-fix-csum_partial_copy_from_user-stack-mismatch.patch
This is a note to let you know that I've just added the patch titled
afs: Fix missing error handling in afs_write_end()
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:
afs-fix-missing-error-handling-in-afs_write_end.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 Wed Feb 28 16:23:28 CET 2018
From: David Howells <dhowells(a)redhat.com>
Date: Tue, 2 Jan 2018 10:02:19 +0000
Subject: afs: Fix missing error handling in afs_write_end()
From: David Howells <dhowells(a)redhat.com>
[ Upstream commit afae457d874860a7e299d334f59eede5f3ad4b47 ]
afs_write_end() is missing page unlock and put if afs_fill_page() fails.
Reported-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/afs/write.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/fs/afs/write.c
+++ b/fs/afs/write.c
@@ -282,7 +282,7 @@ int afs_write_end(struct file *file, str
ret = afs_fill_page(vnode, key, pos + copied,
len - copied, page);
if (ret < 0)
- return ret;
+ goto out;
}
SetPageUptodate(page);
}
@@ -290,10 +290,12 @@ int afs_write_end(struct file *file, str
set_page_dirty(page);
if (PageDirty(page))
_debug("dirtied");
+ ret = copied;
+
+out:
unlock_page(page);
put_page(page);
-
- return copied;
+ return ret;
}
/*
Patches currently in stable-queue which might be from dhowells(a)redhat.com are
queue-4.14/afs-fix-missing-error-handling-in-afs_write_end.patch
This is a note to let you know that I've just added the patch titled
xfs: quota: fix missed destroy of qi_tree_lock
to the 4.4-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:
xfs-quota-fix-missed-destroy-of-qi_tree_lock.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Date: Thu, 21 Dec 2017 13:18:26 -0800
Subject: xfs: quota: fix missed destroy of qi_tree_lock
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[ Upstream commit 2196881566225f3c3428d1a5f847a992944daa5b ]
xfs_qm_destroy_quotainfo() does not destroy quotainfo->qi_tree_lock
while destroys quotainfo->qi_quotaofflock.
Signed-off-by: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/xfs/xfs_qm.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/xfs/xfs_qm.c
+++ b/fs/xfs/xfs_qm.c
@@ -701,6 +701,7 @@ xfs_qm_destroy_quotainfo(
IRELE(qi->qi_pquotaip);
qi->qi_pquotaip = NULL;
}
+ mutex_destroy(&qi->qi_tree_lock);
mutex_destroy(&qi->qi_quotaofflock);
kmem_free(qi);
mp->m_quotainfo = NULL;
Patches currently in stable-queue which might be from akaraliou.dev(a)gmail.com are
queue-4.4/xfs-quota-fix-missed-destroy-of-qi_tree_lock.patch
queue-4.4/xfs-quota-check-result-of-register_shrinker.patch
This is a note to let you know that I've just added the patch titled
xen-netfront: enable device after manual module load
to the 4.4-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:
xen-netfront-enable-device-after-manual-module-load.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Eduardo Otubo <otubo(a)redhat.com>
Date: Fri, 5 Jan 2018 09:42:16 +0100
Subject: xen-netfront: enable device after manual module load
From: Eduardo Otubo <otubo(a)redhat.com>
[ Upstream commit b707fda2df4070785d0fa8a278aa13944c5f51f8 ]
When loading the module after unloading it, the network interface would
not be enabled and thus wouldn't have a backend counterpart and unable
to be used by the guest.
The guest would face errors like:
[root@guest ~]# ethtool -i eth0
Cannot get driver information: No such device
[root@guest ~]# ifconfig eth0
eth0: error fetching interface information: Device not found
This patch initializes the state of the netfront device whenever it is
loaded manually, this state would communicate the netback to create its
device and establish the connection between them.
Signed-off-by: Eduardo Otubo <otubo(a)redhat.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/xen-netfront.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1331,6 +1331,7 @@ static struct net_device *xennet_create_
netif_carrier_off(netdev);
+ xenbus_switch_state(dev, XenbusStateInitialising);
return netdev;
exit:
Patches currently in stable-queue which might be from otubo(a)redhat.com are
queue-4.4/xen-netfront-enable-device-after-manual-module-load.patch
This is a note to let you know that I've just added the patch titled
xfs: quota: check result of register_shrinker()
to the 4.4-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:
xfs-quota-check-result-of-register_shrinker.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Date: Thu, 21 Dec 2017 13:18:26 -0800
Subject: xfs: quota: check result of register_shrinker()
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[ Upstream commit 3a3882ff26fbdbaf5f7e13f6a0bccfbf7121041d ]
xfs_qm_init_quotainfo() does not check result of register_shrinker()
which was tagged as __must_check recently, reported by sparse.
Signed-off-by: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[darrick: move xfs_qm_destroy_quotainos nearer xfs_qm_init_quotainos]
Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/xfs/xfs_qm.c | 45 +++++++++++++++++++++++++++++----------------
1 file changed, 29 insertions(+), 16 deletions(-)
--- a/fs/xfs/xfs_qm.c
+++ b/fs/xfs/xfs_qm.c
@@ -47,7 +47,7 @@
STATIC int xfs_qm_init_quotainos(xfs_mount_t *);
STATIC int xfs_qm_init_quotainfo(xfs_mount_t *);
-
+STATIC void xfs_qm_destroy_quotainos(xfs_quotainfo_t *qi);
STATIC void xfs_qm_dqfree_one(struct xfs_dquot *dqp);
/*
* We use the batch lookup interface to iterate over the dquots as it
@@ -660,9 +660,17 @@ xfs_qm_init_quotainfo(
qinf->qi_shrinker.scan_objects = xfs_qm_shrink_scan;
qinf->qi_shrinker.seeks = DEFAULT_SEEKS;
qinf->qi_shrinker.flags = SHRINKER_NUMA_AWARE;
- register_shrinker(&qinf->qi_shrinker);
+
+ error = register_shrinker(&qinf->qi_shrinker);
+ if (error)
+ goto out_free_inos;
+
return 0;
+out_free_inos:
+ mutex_destroy(&qinf->qi_quotaofflock);
+ mutex_destroy(&qinf->qi_tree_lock);
+ xfs_qm_destroy_quotainos(qinf);
out_free_lru:
list_lru_destroy(&qinf->qi_lru);
out_free_qinf:
@@ -671,7 +679,6 @@ out_free_qinf:
return error;
}
-
/*
* Gets called when unmounting a filesystem or when all quotas get
* turned off.
@@ -688,19 +695,7 @@ xfs_qm_destroy_quotainfo(
unregister_shrinker(&qi->qi_shrinker);
list_lru_destroy(&qi->qi_lru);
-
- if (qi->qi_uquotaip) {
- IRELE(qi->qi_uquotaip);
- qi->qi_uquotaip = NULL; /* paranoia */
- }
- if (qi->qi_gquotaip) {
- IRELE(qi->qi_gquotaip);
- qi->qi_gquotaip = NULL;
- }
- if (qi->qi_pquotaip) {
- IRELE(qi->qi_pquotaip);
- qi->qi_pquotaip = NULL;
- }
+ xfs_qm_destroy_quotainos(qi);
mutex_destroy(&qi->qi_tree_lock);
mutex_destroy(&qi->qi_quotaofflock);
kmem_free(qi);
@@ -1563,6 +1558,24 @@ error_rele:
}
STATIC void
+xfs_qm_destroy_quotainos(
+ xfs_quotainfo_t *qi)
+{
+ if (qi->qi_uquotaip) {
+ IRELE(qi->qi_uquotaip);
+ qi->qi_uquotaip = NULL; /* paranoia */
+ }
+ if (qi->qi_gquotaip) {
+ IRELE(qi->qi_gquotaip);
+ qi->qi_gquotaip = NULL;
+ }
+ if (qi->qi_pquotaip) {
+ IRELE(qi->qi_pquotaip);
+ qi->qi_pquotaip = NULL;
+ }
+}
+
+STATIC void
xfs_qm_dqfree_one(
struct xfs_dquot *dqp)
{
Patches currently in stable-queue which might be from akaraliou.dev(a)gmail.com are
queue-4.4/xfs-quota-fix-missed-destroy-of-qi_tree_lock.patch
queue-4.4/xfs-quota-check-result-of-register_shrinker.patch
This is a note to let you know that I've just added the patch titled
xen/gntdev: Fix partial gntdev_mmap() cleanup
to the 4.4-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:
xen-gntdev-fix-partial-gntdev_mmap-cleanup.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Date: Tue, 9 Jan 2018 12:10:22 +0000
Subject: xen/gntdev: Fix partial gntdev_mmap() cleanup
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
[ Upstream commit cf2acf66ad43abb39735568f55e1f85f9844e990 ]
When cleaning up after a partially successful gntdev_mmap(), unmap the
successfully mapped grant pages otherwise Xen will kill the domain if
in debug mode (Attempt to implicitly unmap a granted PTE) or Linux will
kill the process and emit "BUG: Bad page map in process" if Xen is in
release mode.
This is only needed when use_ptemod is true because gntdev_put_map()
will unmap grant pages itself when use_ptemod is false.
Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/xen/gntdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -874,8 +874,10 @@ unlock_out:
out_unlock_put:
mutex_unlock(&priv->lock);
out_put_map:
- if (use_ptemod)
+ if (use_ptemod) {
map->vma = NULL;
+ unmap_grant_pages(map, 0, map->count);
+ }
gntdev_put_map(priv, map);
return err;
}
Patches currently in stable-queue which might be from ross.lagerwall(a)citrix.com are
queue-4.4/xen-gntdev-fix-off-by-one-error-when-unmapping-with-holes.patch
queue-4.4/xen-gntdev-fix-partial-gntdev_mmap-cleanup.patch
This is a note to let you know that I've just added the patch titled
xen/gntdev: Fix off-by-one error when unmapping with holes
to the 4.4-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:
xen-gntdev-fix-off-by-one-error-when-unmapping-with-holes.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Date: Tue, 9 Jan 2018 12:10:21 +0000
Subject: xen/gntdev: Fix off-by-one error when unmapping with holes
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
[ Upstream commit 951a010233625b77cde3430b4b8785a9a22968d1 ]
If the requested range has a hole, the calculation of the number of
pages to unmap is off by one. Fix it.
Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/xen/gntdev.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -378,10 +378,8 @@ static int unmap_grant_pages(struct gran
}
range = 0;
while (range < pages) {
- if (map->unmap_ops[offset+range].handle == -1) {
- range--;
+ if (map->unmap_ops[offset+range].handle == -1)
break;
- }
range++;
}
err = __unmap_grant_pages(map, offset, range);
Patches currently in stable-queue which might be from ross.lagerwall(a)citrix.com are
queue-4.4/xen-gntdev-fix-off-by-one-error-when-unmapping-with-holes.patch
queue-4.4/xen-gntdev-fix-partial-gntdev_mmap-cleanup.patch
This is a note to let you know that I've just added the patch titled
tg3: Add workaround to restrict 5762 MRRS to 2048
to the 4.4-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:
tg3-add-workaround-to-restrict-5762-mrrs-to-2048.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Date: Fri, 22 Dec 2017 16:05:28 +0530
Subject: tg3: Add workaround to restrict 5762 MRRS to 2048
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
[ Upstream commit 4419bb1cedcda0272e1dc410345c5a1d1da0e367 ]
One of AMD based server with 5762 hangs with jumbo frame traffic.
This AMD platform has southbridge limitation which is restricting MRRS
to 4000. As a work around, driver to restricts the MRRS to 2048 for
this particular 5762 NX1 card.
Signed-off-by: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/tg3.c | 10 ++++++++++
drivers/net/ethernet/broadcom/tg3.h | 4 ++++
2 files changed, 14 insertions(+)
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -10051,6 +10051,16 @@ static int tg3_reset_hw(struct tg3 *tp,
tw32(GRC_MODE, tp->grc_mode | val);
+ /* On one of the AMD platform, MRRS is restricted to 4000 because of
+ * south bridge limitation. As a workaround, Driver is setting MRRS
+ * to 2048 instead of default 4096.
+ */
+ if (tp->pdev->subsystem_vendor == PCI_VENDOR_ID_DELL &&
+ tp->pdev->subsystem_device == TG3PCI_SUBDEVICE_ID_DELL_5762) {
+ val = tr32(TG3PCI_DEV_STATUS_CTRL) & ~MAX_READ_REQ_MASK;
+ tw32(TG3PCI_DEV_STATUS_CTRL, val | MAX_READ_REQ_SIZE_2048);
+ }
+
/* Setup the timer prescalar register. Clock is always 66Mhz. */
val = tr32(GRC_MISC_CFG);
val &= ~0xff;
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -95,6 +95,7 @@
#define TG3PCI_SUBDEVICE_ID_DELL_JAGUAR 0x0106
#define TG3PCI_SUBDEVICE_ID_DELL_MERLOT 0x0109
#define TG3PCI_SUBDEVICE_ID_DELL_SLIM_MERLOT 0x010a
+#define TG3PCI_SUBDEVICE_ID_DELL_5762 0x07f0
#define TG3PCI_SUBVENDOR_ID_COMPAQ PCI_VENDOR_ID_COMPAQ
#define TG3PCI_SUBDEVICE_ID_COMPAQ_BANSHEE 0x007c
#define TG3PCI_SUBDEVICE_ID_COMPAQ_BANSHEE_2 0x009a
@@ -280,6 +281,9 @@
#define TG3PCI_STD_RING_PROD_IDX 0x00000098 /* 64-bit */
#define TG3PCI_RCV_RET_RING_CON_IDX 0x000000a0 /* 64-bit */
/* 0xa8 --> 0xb8 unused */
+#define TG3PCI_DEV_STATUS_CTRL 0x000000b4
+#define MAX_READ_REQ_SIZE_2048 0x00004000
+#define MAX_READ_REQ_MASK 0x00007000
#define TG3PCI_DUAL_MAC_CTRL 0x000000b8
#define DUAL_MAC_CTRL_CH_MASK 0x00000003
#define DUAL_MAC_CTRL_ID 0x00000004
Patches currently in stable-queue which might be from siva.kallam(a)broadcom.com are
queue-4.4/tg3-enable-phy-reset-in-mtu-change-path-for-5720.patch
queue-4.4/tg3-add-workaround-to-restrict-5762-mrrs-to-2048.patch
This is a note to let you know that I've just added the patch titled
tg3: Enable PHY reset in MTU change path for 5720
to the 4.4-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:
tg3-enable-phy-reset-in-mtu-change-path-for-5720.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Date: Fri, 22 Dec 2017 16:05:29 +0530
Subject: tg3: Enable PHY reset in MTU change path for 5720
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
[ Upstream commit e60ee41aaf898584205a6af5c996860d0fe6a836 ]
A customer noticed RX path hang when MTU is changed on the fly while
running heavy traffic with NCSI enabled for 5717 and 5719. Since 5720
belongs to same ASIC family, we observed same issue and same fix
could solve this problem for 5720.
Signed-off-by: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/tg3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -14240,7 +14240,8 @@ static int tg3_change_mtu(struct net_dev
*/
if (tg3_asic_rev(tp) == ASIC_REV_57766 ||
tg3_asic_rev(tp) == ASIC_REV_5717 ||
- tg3_asic_rev(tp) == ASIC_REV_5719)
+ tg3_asic_rev(tp) == ASIC_REV_5719 ||
+ tg3_asic_rev(tp) == ASIC_REV_5720)
reset_phy = true;
err = tg3_restart_hw(tp, reset_phy);
Patches currently in stable-queue which might be from siva.kallam(a)broadcom.com are
queue-4.4/tg3-enable-phy-reset-in-mtu-change-path-for-5720.patch
queue-4.4/tg3-add-workaround-to-restrict-5762-mrrs-to-2048.patch
This is a note to let you know that I've just added the patch titled
spi: atmel: fixed spin_lock usage inside atmel_spi_remove
to the 4.4-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:
spi-atmel-fixed-spin_lock-usage-inside-atmel_spi_remove.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Radu Pirea <radu.pirea(a)microchip.com>
Date: Fri, 15 Dec 2017 17:40:17 +0200
Subject: spi: atmel: fixed spin_lock usage inside atmel_spi_remove
From: Radu Pirea <radu.pirea(a)microchip.com>
[ Upstream commit 66e900a3d225575c8b48b59ae1fe74bb6e5a65cc ]
The only part of atmel_spi_remove which needs to be atomic is hardware
reset.
atmel_spi_stop_dma calls dma_terminate_all and this needs interrupts
enabled.
atmel_spi_release_dma calls dma_release_channel and dma_release_channel
locks a mutex inside of spin_lock.
So the call of these functions can't be inside a spin_lock.
Reported-by: Jia-Ju Bai <baijiaju1990(a)gmail.com>
Signed-off-by: Radu Pirea <radu.pirea(a)microchip.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/spi/spi-atmel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1669,12 +1669,12 @@ static int atmel_spi_remove(struct platf
pm_runtime_get_sync(&pdev->dev);
/* reset the hardware and block queue progress */
- spin_lock_irq(&as->lock);
if (as->use_dma) {
atmel_spi_stop_dma(as);
atmel_spi_release_dma(as);
}
+ spin_lock_irq(&as->lock);
spi_writel(as, CR, SPI_BIT(SWRST));
spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
spi_readl(as, SR);
Patches currently in stable-queue which might be from radu.pirea(a)microchip.com are
queue-4.4/spi-atmel-fixed-spin_lock-usage-inside-atmel_spi_remove.patch
This is a note to let you know that I've just added the patch titled
SolutionEngine771x: fix Ether platform data
to the 4.4-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:
solutionengine771x-fix-ether-platform-data.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Date: Sat, 6 Jan 2018 21:53:26 +0300
Subject: SolutionEngine771x: fix Ether platform data
From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
[ Upstream commit 195e2addbce09e5afbc766efc1e6567c9ce840d3 ]
The 'sh_eth' driver's probe() method would fail on the SolutionEngine7710
board and crash on SolutionEngine7712 board as the platform code is
hopelessly behind the driver's platform data -- it passes the PHY address
instead of 'struct sh_eth_plat_data *'; pass the latter to the driver in
order to fix the bug...
Fixes: 71557a37adb5 ("[netdrvr] sh_eth: Add SH7619 support")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/sh/boards/mach-se/770x/setup.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/arch/sh/boards/mach-se/770x/setup.c
+++ b/arch/sh/boards/mach-se/770x/setup.c
@@ -8,6 +8,7 @@
*/
#include <linux/init.h>
#include <linux/platform_device.h>
+#include <linux/sh_eth.h>
#include <mach-se/mach/se.h>
#include <mach-se/mach/mrshpc.h>
#include <asm/machvec.h>
@@ -114,6 +115,11 @@ static struct platform_device heartbeat_
#if defined(CONFIG_CPU_SUBTYPE_SH7710) ||\
defined(CONFIG_CPU_SUBTYPE_SH7712)
/* SH771X Ethernet driver */
+static struct sh_eth_plat_data sh_eth_plat = {
+ .phy = PHY_ID,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+};
+
static struct resource sh_eth0_resources[] = {
[0] = {
.start = SH_ETH0_BASE,
@@ -131,7 +137,7 @@ static struct platform_device sh_eth0_de
.name = "sh771x-ether",
.id = 0,
.dev = {
- .platform_data = PHY_ID,
+ .platform_data = &sh_eth_plat,
},
.num_resources = ARRAY_SIZE(sh_eth0_resources),
.resource = sh_eth0_resources,
@@ -154,7 +160,7 @@ static struct platform_device sh_eth1_de
.name = "sh771x-ether",
.id = 1,
.dev = {
- .platform_data = PHY_ID,
+ .platform_data = &sh_eth_plat,
},
.num_resources = ARRAY_SIZE(sh_eth1_resources),
.resource = sh_eth1_resources,
Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are
queue-4.4/solutionengine771x-fix-ether-platform-data.patch
This is a note to let you know that I've just added the patch titled
sget(): handle failures of register_shrinker()
to the 4.4-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:
sget-handle-failures-of-register_shrinker.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Al Viro <viro(a)zeniv.linux.org.uk>
Date: Mon, 18 Dec 2017 15:05:07 -0500
Subject: sget(): handle failures of register_shrinker()
From: Al Viro <viro(a)zeniv.linux.org.uk>
[ Upstream commit 9ee332d99e4d5a97548943b81c54668450ce641b ]
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/super.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/super.c
+++ b/fs/super.c
@@ -497,7 +497,11 @@ retry:
hlist_add_head(&s->s_instances, &type->fs_supers);
spin_unlock(&sb_lock);
get_filesystem(type);
- register_shrinker(&s->s_shrink);
+ err = register_shrinker(&s->s_shrink);
+ if (err) {
+ deactivate_locked_super(s);
+ s = ERR_PTR(err);
+ }
return s;
}
Patches currently in stable-queue which might be from viro(a)zeniv.linux.org.uk are
queue-4.4/sget-handle-failures-of-register_shrinker.patch
This is a note to let you know that I've just added the patch titled
scsi: storvsc: Fix scsi_cmd error assignments in storvsc_handle_error
to the 4.4-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:
scsi-storvsc-fix-scsi_cmd-error-assignments-in-storvsc_handle_error.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Cathy Avery <cavery(a)redhat.com>
Date: Tue, 19 Dec 2017 13:32:48 -0500
Subject: scsi: storvsc: Fix scsi_cmd error assignments in storvsc_handle_error
From: Cathy Avery <cavery(a)redhat.com>
[ Upstream commit d1b8b2391c24751e44f618fcf86fb55d9a9247fd ]
When an I/O is returned with an srb_status of SRB_STATUS_INVALID_LUN
which has zero good_bytes it must be assigned an error. Otherwise the
I/O will be continuously requeued and will cause a deadlock in the case
where disks are being hot added and removed. sd_probe_async will wait
forever for its I/O to complete while holding scsi_sd_probe_domain.
Also returning the default error of DID_TARGET_FAILURE causes multipath
to not retry the I/O resulting in applications receiving I/O errors
before a failover can occur.
Signed-off-by: Cathy Avery <cavery(a)redhat.com>
Signed-off-by: Long Li <longli(a)microsoft.com>
Reviewed-by: Stephen Hemminger <stephen(a)networkplumber.org>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/storvsc_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -890,10 +890,11 @@ static void storvsc_handle_error(struct
case TEST_UNIT_READY:
break;
default:
- set_host_byte(scmnd, DID_TARGET_FAILURE);
+ set_host_byte(scmnd, DID_ERROR);
}
break;
case SRB_STATUS_INVALID_LUN:
+ set_host_byte(scmnd, DID_NO_CONNECT);
do_work = true;
process_err_fn = storvsc_remove_lun;
break;
Patches currently in stable-queue which might be from cavery(a)redhat.com are
queue-4.4/scsi-storvsc-fix-scsi_cmd-error-assignments-in-storvsc_handle_error.patch
This is a note to let you know that I've just added the patch titled
sctp: make use of pre-calculated len
to the 4.4-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:
sctp-make-use-of-pre-calculated-len.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Date: Mon, 8 Jan 2018 19:02:29 -0200
Subject: sctp: make use of pre-calculated len
From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
[ Upstream commit c76f97c99ae6d26d14c7f0e50e074382bfbc9f98 ]
Some sockopt handling functions were calculating the length of the
buffer to be written to userspace and then calculating it again when
actually writing the buffer, which could lead to some write not using
an up-to-date length.
This patch updates such places to just make use of the len variable.
Also, replace some sizeof(type) to sizeof(var).
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/socket.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4445,7 +4445,7 @@ static int sctp_getsockopt_autoclose(str
len = sizeof(int);
if (put_user(len, optlen))
return -EFAULT;
- if (copy_to_user(optval, &sctp_sk(sk)->autoclose, sizeof(int)))
+ if (copy_to_user(optval, &sctp_sk(sk)->autoclose, len))
return -EFAULT;
return 0;
}
@@ -5022,6 +5022,9 @@ copy_getaddrs:
err = -EFAULT;
goto out;
}
+ /* XXX: We should have accounted for sizeof(struct sctp_getaddrs) too,
+ * but we can't change it anymore.
+ */
if (put_user(bytes_copied, optlen))
err = -EFAULT;
out:
@@ -5458,7 +5461,7 @@ static int sctp_getsockopt_maxseg(struct
params.assoc_id = 0;
} else if (len >= sizeof(struct sctp_assoc_value)) {
len = sizeof(struct sctp_assoc_value);
- if (copy_from_user(¶ms, optval, sizeof(params)))
+ if (copy_from_user(¶ms, optval, len))
return -EFAULT;
} else
return -EINVAL;
@@ -5627,7 +5630,9 @@ static int sctp_getsockopt_active_key(st
if (len < sizeof(struct sctp_authkeyid))
return -EINVAL;
- if (copy_from_user(&val, optval, sizeof(struct sctp_authkeyid)))
+
+ len = sizeof(struct sctp_authkeyid);
+ if (copy_from_user(&val, optval, len))
return -EFAULT;
asoc = sctp_id2assoc(sk, val.scact_assoc_id);
@@ -5639,7 +5644,6 @@ static int sctp_getsockopt_active_key(st
else
val.scact_keynumber = ep->active_key_id;
- len = sizeof(struct sctp_authkeyid);
if (put_user(len, optlen))
return -EFAULT;
if (copy_to_user(optval, &val, len))
@@ -5665,7 +5669,7 @@ static int sctp_getsockopt_peer_auth_chu
if (len < sizeof(struct sctp_authchunks))
return -EINVAL;
- if (copy_from_user(&val, optval, sizeof(struct sctp_authchunks)))
+ if (copy_from_user(&val, optval, sizeof(val)))
return -EFAULT;
to = p->gauth_chunks;
@@ -5710,7 +5714,7 @@ static int sctp_getsockopt_local_auth_ch
if (len < sizeof(struct sctp_authchunks))
return -EINVAL;
- if (copy_from_user(&val, optval, sizeof(struct sctp_authchunks)))
+ if (copy_from_user(&val, optval, sizeof(val)))
return -EFAULT;
to = p->gauth_chunks;
Patches currently in stable-queue which might be from marcelo.leitner(a)gmail.com are
queue-4.4/sctp-make-use-of-pre-calculated-len.patch
This is a note to let you know that I've just added the patch titled
s390/dasd: fix wrongly assigned configuration data
to the 4.4-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:
s390-dasd-fix-wrongly-assigned-configuration-data.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Stefan Haberland <sth(a)linux.vnet.ibm.com>
Date: Wed, 6 Dec 2017 10:30:39 +0100
Subject: s390/dasd: fix wrongly assigned configuration data
From: Stefan Haberland <sth(a)linux.vnet.ibm.com>
[ Upstream commit 8a9bd4f8ebc6800bfc0596e28631ff6809a2f615 ]
We store per path and per device configuration data to identify the
path or device correctly. The per path configuration data might get
mixed up if the original request gets into error recovery and is
started with a random path mask.
This would lead to a wrong identification of a path in case of a CUIR
event for example.
Fix by copying the path mask from the original request to the error
recovery request in case it is a path verification request.
Signed-off-by: Stefan Haberland <sth(a)linux.vnet.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner(a)linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/block/dasd_3990_erp.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/s390/block/dasd_3990_erp.c
+++ b/drivers/s390/block/dasd_3990_erp.c
@@ -2743,6 +2743,16 @@ dasd_3990_erp_action(struct dasd_ccw_req
erp = dasd_3990_erp_handle_match_erp(cqr, erp);
}
+
+ /*
+ * For path verification work we need to stick with the path that was
+ * originally chosen so that the per path configuration data is
+ * assigned correctly.
+ */
+ if (test_bit(DASD_CQR_VERIFY_PATH, &erp->flags) && cqr->lpm) {
+ erp->lpm = cqr->lpm;
+ }
+
if (device->features & DASD_FEATURE_ERPLOG) {
/* print current erp_chain */
dev_err(&device->cdev->dev,
Patches currently in stable-queue which might be from sth(a)linux.vnet.ibm.com are
queue-4.4/s390-dasd-fix-wrongly-assigned-configuration-data.patch
This is a note to let you know that I've just added the patch titled
net: arc_emac: fix arc_emac_rx() error paths
to the 4.4-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-arc_emac-fix-arc_emac_rx-error-paths.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Alexander Kochetkov <al.kochet(a)gmail.com>
Date: Fri, 15 Dec 2017 20:20:06 +0300
Subject: net: arc_emac: fix arc_emac_rx() error paths
From: Alexander Kochetkov <al.kochet(a)gmail.com>
[ Upstream commit e688822d035b494071ecbadcccbd6f3325fb0f59 ]
arc_emac_rx() has some issues found by code review.
In case netdev_alloc_skb_ip_align() or dma_map_single() failure
rx fifo entry will not be returned to EMAC.
In case dma_map_single() failure previously allocated skb became
lost to driver. At the same time address of newly allocated skb
will not be provided to EMAC.
Signed-off-by: Alexander Kochetkov <al.kochet(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/arc/emac_main.c | 53 ++++++++++++++++++++---------------
1 file changed, 31 insertions(+), 22 deletions(-)
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -250,39 +250,48 @@ static int arc_emac_rx(struct net_device
continue;
}
- pktlen = info & LEN_MASK;
- stats->rx_packets++;
- stats->rx_bytes += pktlen;
- skb = rx_buff->skb;
- skb_put(skb, pktlen);
- skb->dev = ndev;
- skb->protocol = eth_type_trans(skb, ndev);
-
- dma_unmap_single(&ndev->dev, dma_unmap_addr(rx_buff, addr),
- dma_unmap_len(rx_buff, len), DMA_FROM_DEVICE);
-
- /* Prepare the BD for next cycle */
- rx_buff->skb = netdev_alloc_skb_ip_align(ndev,
- EMAC_BUFFER_SIZE);
- if (unlikely(!rx_buff->skb)) {
+ /* Prepare the BD for next cycle. netif_receive_skb()
+ * only if new skb was allocated and mapped to avoid holes
+ * in the RX fifo.
+ */
+ skb = netdev_alloc_skb_ip_align(ndev, EMAC_BUFFER_SIZE);
+ if (unlikely(!skb)) {
+ if (net_ratelimit())
+ netdev_err(ndev, "cannot allocate skb\n");
+ /* Return ownership to EMAC */
+ rxbd->info = cpu_to_le32(FOR_EMAC | EMAC_BUFFER_SIZE);
stats->rx_errors++;
- /* Because receive_skb is below, increment rx_dropped */
stats->rx_dropped++;
continue;
}
- /* receive_skb only if new skb was allocated to avoid holes */
- netif_receive_skb(skb);
-
- addr = dma_map_single(&ndev->dev, (void *)rx_buff->skb->data,
+ addr = dma_map_single(&ndev->dev, (void *)skb->data,
EMAC_BUFFER_SIZE, DMA_FROM_DEVICE);
if (dma_mapping_error(&ndev->dev, addr)) {
if (net_ratelimit())
- netdev_err(ndev, "cannot dma map\n");
- dev_kfree_skb(rx_buff->skb);
+ netdev_err(ndev, "cannot map dma buffer\n");
+ dev_kfree_skb(skb);
+ /* Return ownership to EMAC */
+ rxbd->info = cpu_to_le32(FOR_EMAC | EMAC_BUFFER_SIZE);
stats->rx_errors++;
+ stats->rx_dropped++;
continue;
}
+
+ /* unmap previosly mapped skb */
+ dma_unmap_single(&ndev->dev, dma_unmap_addr(rx_buff, addr),
+ dma_unmap_len(rx_buff, len), DMA_FROM_DEVICE);
+
+ pktlen = info & LEN_MASK;
+ stats->rx_packets++;
+ stats->rx_bytes += pktlen;
+ skb_put(rx_buff->skb, pktlen);
+ rx_buff->skb->dev = ndev;
+ rx_buff->skb->protocol = eth_type_trans(rx_buff->skb, ndev);
+
+ netif_receive_skb(rx_buff->skb);
+
+ rx_buff->skb = skb;
dma_unmap_addr_set(rx_buff, addr, addr);
dma_unmap_len_set(rx_buff, len, EMAC_BUFFER_SIZE);
Patches currently in stable-queue which might be from al.kochet(a)gmail.com are
queue-4.4/net-arc_emac-fix-arc_emac_rx-error-paths.patch
This is a note to let you know that I've just added the patch titled
net: gianfar_ptp: move set_fipers() to spinlock protecting area
to the 4.4-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-gianfar_ptp-move-set_fipers-to-spinlock-protecting-area.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Yangbo Lu <yangbo.lu(a)nxp.com>
Date: Tue, 9 Jan 2018 11:02:33 +0800
Subject: net: gianfar_ptp: move set_fipers() to spinlock protecting area
From: Yangbo Lu <yangbo.lu(a)nxp.com>
[ Upstream commit 11d827a993a969c3c6ec56758ff63a44ba19b466 ]
set_fipers() calling should be protected by spinlock in
case that any interrupt breaks related registers setting
and the function we expect. This patch is to move set_fipers()
to spinlock protecting area in ptp_gianfar_adjtime().
Signed-off-by: Yangbo Lu <yangbo.lu(a)nxp.com>
Acked-by: Richard Cochran <richardcochran(a)gmail.com>
Reviewed-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/freescale/gianfar_ptp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/net/ethernet/freescale/gianfar_ptp.c
+++ b/drivers/net/ethernet/freescale/gianfar_ptp.c
@@ -314,11 +314,10 @@ static int ptp_gianfar_adjtime(struct pt
now = tmr_cnt_read(etsects);
now += delta;
tmr_cnt_write(etsects, now);
+ set_fipers(etsects);
spin_unlock_irqrestore(&etsects->lock, flags);
- set_fipers(etsects);
-
return 0;
}
Patches currently in stable-queue which might be from yangbo.lu(a)nxp.com are
queue-4.4/net-gianfar_ptp-move-set_fipers-to-spinlock-protecting-area.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM
to the 4.4-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:
mtd-nand-gpmi-fix-failure-when-a-erased-page-has-a-bitflip-at-bbm.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Sascha Hauer <s.hauer(a)pengutronix.de>
Date: Tue, 5 Dec 2017 11:51:40 +0100
Subject: mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM
From: Sascha Hauer <s.hauer(a)pengutronix.de>
[ Upstream commit fdf2e821052958a114618a95ab18a300d0b080cb ]
When erased subpages are read then the BCH decoder returns STATUS_ERASED
if they are all empty, or STATUS_UNCORRECTABLE if there are bitflips.
When there are bitflips, we have to set these bits again to show the
upper layers a completely erased page. When a bitflip happens in the
exact byte where the bad block marker is, then this byte is swapped
with another byte in block_mark_swapping(). The correction code then
detects a bitflip in another subpage and no longer corrects the bitflip
where it really happens.
Correct this behaviour by calling block_mark_swapping() after the
bitflips have been corrected.
In our case UBIFS failed with this bug because it expects erased
pages to be really empty:
UBIFS error (pid 187): ubifs_scan: corrupt empty space at LEB 36:118735
UBIFS error (pid 187): ubifs_scanned_corruption: corruption at LEB 36:118735
UBIFS error (pid 187): ubifs_scanned_corruption: first 8192 bytes from LEB 36:118735
UBIFS error (pid 187): ubifs_scan: LEB 36 scanning failed
UBIFS error (pid 187): do_commit: commit failed, error -117
Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de>
Reviewed-by: Richard Weinberger <richard(a)nod.at>
Acked-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1029,9 +1029,6 @@ static int gpmi_ecc_read_page(struct mtd
return ret;
}
- /* handle the block mark swapping */
- block_mark_swapping(this, payload_virt, auxiliary_virt);
-
/* Loop over status bytes, accumulating ECC status. */
status = auxiliary_virt + nfc_geo->auxiliary_status_offset;
@@ -1047,6 +1044,9 @@ static int gpmi_ecc_read_page(struct mtd
max_bitflips = max_t(unsigned int, max_bitflips, *status);
}
+ /* handle the block mark swapping */
+ block_mark_swapping(this, buf, auxiliary_virt);
+
if (oob_required) {
/*
* It's time to deliver the OOB bytes. See gpmi_ecc_read_oob()
Patches currently in stable-queue which might be from s.hauer(a)pengutronix.de are
queue-4.4/mtd-nand-gpmi-fix-failure-when-a-erased-page-has-a-bitflip-at-bbm.patch
This is a note to let you know that I've just added the patch titled
mac80211: mesh: drop frames appearing to be from us
to the 4.4-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:
mac80211-mesh-drop-frames-appearing-to-be-from-us.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Thu, 4 Jan 2018 15:51:53 +0100
Subject: mac80211: mesh: drop frames appearing to be from us
From: Johannes Berg <johannes.berg(a)intel.com>
[ Upstream commit 736a80bbfda709fb3631f5f62056f250a38e5804 ]
If there are multiple mesh stations with the same MAC address,
they will both get confused and start throwing warnings.
Obviously in this case nothing can actually work anyway, so just
drop frames that look like they're from ourselves early on.
Reported-by: Gui Iribarren <gui(a)altermundi.net>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/rx.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3367,6 +3367,8 @@ static bool ieee80211_accept_frame(struc
}
return true;
case NL80211_IFTYPE_MESH_POINT:
+ if (ether_addr_equal(sdata->vif.addr, hdr->addr2))
+ return false;
if (multicast)
return true;
return ether_addr_equal(sdata->vif.addr, hdr->addr1);
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.4/mac80211-mesh-drop-frames-appearing-to-be-from-us.patch
This is a note to let you know that I've just added the patch titled
mdio-sun4i: Fix a memory leak
to the 4.4-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:
mdio-sun4i-fix-a-memory-leak.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sat, 6 Jan 2018 09:00:09 +0100
Subject: mdio-sun4i: Fix a memory leak
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 56c0290202ab94a2f2780c449395d4ae8495fab4 ]
If the probing of the regulator is deferred, the memory allocated by
'mdiobus_alloc_size()' will be leaking.
It should be freed before the next call to 'sun4i_mdio_probe()' which will
reallocate it.
Fixes: 4bdcb1dd9feb ("net: Add MDIO bus driver for the Allwinner EMAC")
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/phy/mdio-sun4i.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/phy/mdio-sun4i.c
+++ b/drivers/net/phy/mdio-sun4i.c
@@ -128,8 +128,10 @@ static int sun4i_mdio_probe(struct platf
data->regulator = devm_regulator_get(&pdev->dev, "phy");
if (IS_ERR(data->regulator)) {
- if (PTR_ERR(data->regulator) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
+ if (PTR_ERR(data->regulator) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto err_out_free_mdiobus;
+ }
dev_info(&pdev->dev, "no regulator found\n");
} else {
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.4/mdio-sun4i-fix-a-memory-leak.patch
This is a note to let you know that I've just added the patch titled
lib/mpi: Fix umul_ppmm() for MIPS64r6
to the 4.4-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:
lib-mpi-fix-umul_ppmm-for-mips64r6.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: James Hogan <jhogan(a)kernel.org>
Date: Tue, 5 Dec 2017 23:31:35 +0000
Subject: lib/mpi: Fix umul_ppmm() for MIPS64r6
From: James Hogan <jhogan(a)kernel.org>
[ Upstream commit bbc25bee37d2b32cf3a1fab9195b6da3a185614a ]
Current MIPS64r6 toolchains aren't able to generate efficient
DMULU/DMUHU based code for the C implementation of umul_ppmm(), which
performs an unsigned 64 x 64 bit multiply and returns the upper and
lower 64-bit halves of the 128-bit result. Instead it widens the 64-bit
inputs to 128-bits and emits a __multi3 intrinsic call to perform a 128
x 128 multiply. This is both inefficient, and it results in a link error
since we don't include __multi3 in MIPS linux.
For example commit 90a53e4432b1 ("cfg80211: implement regdb signature
checking") merged in v4.15-rc1 recently broke the 64r6_defconfig and
64r6el_defconfig builds by indirectly selecting MPILIB. The same build
errors can be reproduced on older kernels by enabling e.g. CRYPTO_RSA:
lib/mpi/generic_mpih-mul1.o: In function `mpihelp_mul_1':
lib/mpi/generic_mpih-mul1.c:50: undefined reference to `__multi3'
lib/mpi/generic_mpih-mul2.o: In function `mpihelp_addmul_1':
lib/mpi/generic_mpih-mul2.c:49: undefined reference to `__multi3'
lib/mpi/generic_mpih-mul3.o: In function `mpihelp_submul_1':
lib/mpi/generic_mpih-mul3.c:49: undefined reference to `__multi3'
lib/mpi/mpih-div.o In function `mpihelp_divrem':
lib/mpi/mpih-div.c:205: undefined reference to `__multi3'
lib/mpi/mpih-div.c:142: undefined reference to `__multi3'
Therefore add an efficient MIPS64r6 implementation of umul_ppmm() using
inline assembly and the DMULU/DMUHU instructions, to prevent __multi3
calls being emitted.
Fixes: 7fd08ca58ae6 ("MIPS: Add build support for the MIPS R6 ISA")
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Herbert Xu <herbert(a)gondor.apana.org.au>
Cc: "David S. Miller" <davem(a)davemloft.net>
Cc: linux-mips(a)linux-mips.org
Cc: linux-crypto(a)vger.kernel.org
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/mpi/longlong.h | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
--- a/lib/mpi/longlong.h
+++ b/lib/mpi/longlong.h
@@ -671,7 +671,23 @@ do { \
************** MIPS/64 **************
***************************************/
#if (defined(__mips) && __mips >= 3) && W_TYPE_SIZE == 64
-#if (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4)
+#if defined(__mips_isa_rev) && __mips_isa_rev >= 6
+/*
+ * GCC ends up emitting a __multi3 intrinsic call for MIPS64r6 with the plain C
+ * code below, so we special case MIPS64r6 until the compiler can do better.
+ */
+#define umul_ppmm(w1, w0, u, v) \
+do { \
+ __asm__ ("dmulu %0,%1,%2" \
+ : "=d" ((UDItype)(w0)) \
+ : "d" ((UDItype)(u)), \
+ "d" ((UDItype)(v))); \
+ __asm__ ("dmuhu %0,%1,%2" \
+ : "=d" ((UDItype)(w1)) \
+ : "d" ((UDItype)(u)), \
+ "d" ((UDItype)(v))); \
+} while (0)
+#elif (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4)
#define umul_ppmm(w1, w0, u, v) \
do { \
typedef unsigned int __ll_UTItype __attribute__((mode(TI))); \
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-4.4/lib-mpi-fix-umul_ppmm-for-mips64r6.patch
This is a note to let you know that I've just added the patch titled
ipv6: icmp6: Allow icmp messages to be looped back
to the 4.4-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-icmp6-allow-icmp-messages-to-be-looped-back.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Brendan McGrath <redmcg(a)redmandi.dyndns.org>
Date: Wed, 13 Dec 2017 22:14:57 +1100
Subject: ipv6: icmp6: Allow icmp messages to be looped back
From: Brendan McGrath <redmcg(a)redmandi.dyndns.org>
[ Upstream commit 588753f1eb18978512b1c9b85fddb457d46f9033 ]
One example of when an ICMPv6 packet is required to be looped back is
when a host acts as both a Multicast Listener and a Multicast Router.
A Multicast Router will listen on address ff02::16 for MLDv2 messages.
Currently, MLDv2 messages originating from a Multicast Listener running
on the same host as the Multicast Router are not being delivered to the
Multicast Router. This is due to dst.input being assigned the default
value of dst_discard.
This results in the packet being looped back but discarded before being
delivered to the Multicast Router.
This patch sets dst.input to ip6_input to ensure a looped back packet
is delivered to the Multicast Router.
Signed-off-by: Brendan McGrath <redmcg(a)redmandi.dyndns.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/route.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1614,6 +1614,7 @@ struct dst_entry *icmp6_dst_alloc(struct
}
rt->dst.flags |= DST_HOST;
+ rt->dst.input = ip6_input;
rt->dst.output = ip6_output;
atomic_set(&rt->dst.__refcnt, 1);
rt->rt6i_gateway = fl6->daddr;
Patches currently in stable-queue which might be from redmcg(a)redmandi.dyndns.org are
queue-4.4/ipv6-icmp6-allow-icmp-messages-to-be-looped-back.patch
This is a note to let you know that I've just added the patch titled
led: core: Fix brightness setting when setting delay_off=0
to the 4.4-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:
led-core-fix-brightness-setting-when-setting-delay_off-0.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Matthieu CASTET <matthieu.castet(a)parrot.com>
Date: Tue, 12 Dec 2017 11:10:44 +0100
Subject: led: core: Fix brightness setting when setting delay_off=0
From: Matthieu CASTET <matthieu.castet(a)parrot.com>
[ Upstream commit 2b83ff96f51d0b039c4561b9f95c824d7bddb85c ]
With the current code, the following sequence won't work :
echo timer > trigger
echo 0 > delay_off
* at this point we call
** led_delay_off_store
** led_blink_set
---
drivers/leds/led-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -149,7 +149,7 @@ void led_blink_set(struct led_classdev *
unsigned long *delay_on,
unsigned long *delay_off)
{
- del_timer_sync(&led_cdev->blink_timer);
+ led_stop_software_blink(led_cdev);
led_cdev->flags &= ~LED_BLINK_ONESHOT;
led_cdev->flags &= ~LED_BLINK_ONESHOT_STOP;
Patches currently in stable-queue which might be from matthieu.castet(a)parrot.com are
queue-4.4/led-core-fix-brightness-setting-when-setting-delay_off-0.patch
This is a note to let you know that I've just added the patch titled
IB/mlx4: Fix mlx4_ib_alloc_mr error flow
to the 4.4-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:
ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Sun, 31 Dec 2017 15:33:14 +0200
Subject: IB/mlx4: Fix mlx4_ib_alloc_mr error flow
From: Leon Romanovsky <leonro(a)mellanox.com>
[ Upstream commit 5a371cf87e145b86efd32007e46146e78c1eff6d ]
ibmr.device is being set only after ib_alloc_mr() is successfully complete.
Therefore, in case imlx4_mr_enable() returns with error, the error flow
unwinder calls to mlx4_free_priv_pages(), which uses ibmr.device.
Such usage causes to NULL dereference oops and to fix it, the IB device
should be set in the mr struct earlier stage (e.g. prior to calling
mlx4_free_priv_pages()).
Fixes: 1b2cd0fc673c ("IB/mlx4: Support the new memory registration API")
Signed-off-by: Nitzan Carmi <nitzanc(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx4/mr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/hw/mlx4/mr.c
+++ b/drivers/infiniband/hw/mlx4/mr.c
@@ -424,7 +424,6 @@ struct ib_mr *mlx4_ib_alloc_mr(struct ib
goto err_free_mr;
mr->max_pages = max_num_sg;
-
err = mlx4_mr_enable(dev->dev, &mr->mmr);
if (err)
goto err_free_pl;
@@ -435,6 +434,7 @@ struct ib_mr *mlx4_ib_alloc_mr(struct ib
return &mr->ibmr;
err_free_pl:
+ mr->ibmr.device = pd->device;
mlx4_free_priv_pages(mr);
err_free_mr:
(void) mlx4_mr_free(dev->dev, &mr->mmr);
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.4/ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch
This is a note to let you know that I've just added the patch titled
IB/ipoib: Fix race condition in neigh creation
to the 4.4-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:
ib-ipoib-fix-race-condition-in-neigh-creation.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Erez Shitrit <erezsh(a)mellanox.com>
Date: Sun, 31 Dec 2017 15:33:15 +0200
Subject: IB/ipoib: Fix race condition in neigh creation
From: Erez Shitrit <erezsh(a)mellanox.com>
[ Upstream commit 16ba3defb8bd01a9464ba4820a487f5b196b455b ]
When using enhanced mode for IPoIB, two threads may execute xmit in
parallel to two different TX queues while the target is the same.
In this case, both of them will add the same neighbor to the path's
neigh link list and we might see the following message:
list_add double add: new=ffff88024767a348, prev=ffff88024767a348...
WARNING: lib/list_debug.c:31__list_add_valid+0x4e/0x70
ipoib_start_xmit+0x477/0x680 [ib_ipoib]
dev_hard_start_xmit+0xb9/0x3e0
sch_direct_xmit+0xf9/0x250
__qdisc_run+0x176/0x5d0
__dev_queue_xmit+0x1f5/0xb10
__dev_queue_xmit+0x55/0xb10
Analysis:
Two SKB are scheduled to be transmitted from two cores.
In ipoib_start_xmit, both gets NULL when calling ipoib_neigh_get.
Two calls to neigh_add_path are made. One thread takes the spin-lock
and calls ipoib_neigh_alloc which creates the neigh structure,
then (after the __path_find) the neigh is added to the path's neigh
link list. When the second thread enters the critical section it also
calls ipoib_neigh_alloc but in this case it gets the already allocated
ipoib_neigh structure, which is already linked to the path's neigh
link list and adds it again to the list. Which beside of triggering
the list, it creates a loop in the linked list. This loop leads to
endless loop inside path_rec_completion.
Solution:
Check list_empty(&neigh->list) before adding to the list.
Add a similar fix in "ipoib_multicast.c::ipoib_mcast_send"
Fixes: b63b70d87741 ('IPoIB: Use a private hash table for path lookup in xmit path')
Signed-off-by: Erez Shitrit <erezsh(a)mellanox.com>
Reviewed-by: Alex Vesker <valex(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 25 ++++++++++++++++++-------
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 5 ++++-
2 files changed, 22 insertions(+), 8 deletions(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -844,8 +844,8 @@ static int path_rec_start(struct net_dev
return 0;
}
-static void neigh_add_path(struct sk_buff *skb, u8 *daddr,
- struct net_device *dev)
+static struct ipoib_neigh *neigh_add_path(struct sk_buff *skb, u8 *daddr,
+ struct net_device *dev)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_path *path;
@@ -858,7 +858,15 @@ static void neigh_add_path(struct sk_buf
spin_unlock_irqrestore(&priv->lock, flags);
++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
- return;
+ return NULL;
+ }
+
+ /* To avoid race condition, make sure that the
+ * neigh will be added only once.
+ */
+ if (unlikely(!list_empty(&neigh->list))) {
+ spin_unlock_irqrestore(&priv->lock, flags);
+ return neigh;
}
path = __path_find(dev, daddr + 4);
@@ -896,7 +904,7 @@ static void neigh_add_path(struct sk_buf
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_send(dev, skb, path->ah, IPOIB_QPN(daddr));
ipoib_neigh_put(neigh);
- return;
+ return NULL;
}
} else {
neigh->ah = NULL;
@@ -913,7 +921,7 @@ static void neigh_add_path(struct sk_buf
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_neigh_put(neigh);
- return;
+ return NULL;
err_path:
ipoib_neigh_free(neigh);
@@ -923,6 +931,8 @@ err_drop:
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_neigh_put(neigh);
+
+ return NULL;
}
static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev,
@@ -1028,8 +1038,9 @@ static int ipoib_start_xmit(struct sk_bu
case htons(ETH_P_TIPC):
neigh = ipoib_neigh_get(dev, phdr->hwaddr);
if (unlikely(!neigh)) {
- neigh_add_path(skb, phdr->hwaddr, dev);
- return NETDEV_TX_OK;
+ neigh = neigh_add_path(skb, phdr->hwaddr, dev);
+ if (likely(!neigh))
+ return NETDEV_TX_OK;
}
break;
case htons(ETH_P_ARP):
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -775,7 +775,10 @@ void ipoib_mcast_send(struct net_device
spin_lock_irqsave(&priv->lock, flags);
if (!neigh) {
neigh = ipoib_neigh_alloc(daddr, dev);
- if (neigh) {
+ /* Make sure that the neigh will be added only
+ * once to mcast list.
+ */
+ if (neigh && list_empty(&neigh->list)) {
kref_get(&mcast->ah->ref);
neigh->ah = mcast->ah;
list_add_tail(&neigh->list, &mcast->neigh_list);
Patches currently in stable-queue which might be from erezsh(a)mellanox.com are
queue-4.4/ib-ipoib-fix-race-condition-in-neigh-creation.patch
This is a note to let you know that I've just added the patch titled
drm/ttm: check the return value of kzalloc
to the 4.4-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:
drm-ttm-check-the-return-value-of-kzalloc.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Xiongwei Song <sxwjean(a)gmail.com>
Date: Tue, 2 Jan 2018 21:24:55 +0800
Subject: drm/ttm: check the return value of kzalloc
From: Xiongwei Song <sxwjean(a)gmail.com>
[ Upstream commit 19d859a7205bc59ffc38303eb25ae394f61d21dc ]
In the function ttm_page_alloc_init, kzalloc call is made for variable
_manager, we need to check its return value, it may return NULL.
Signed-off-by: Xiongwei Song <sxwjean(a)gmail.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -818,6 +818,8 @@ int ttm_page_alloc_init(struct ttm_mem_g
pr_info("Initializing pool allocator\n");
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
+ if (!_manager)
+ return -ENOMEM;
ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");
Patches currently in stable-queue which might be from sxwjean(a)gmail.com are
queue-4.4/drm-ttm-check-the-return-value-of-kzalloc.patch
This is a note to let you know that I've just added the patch titled
drm/nouveau/pci: do a msi rearm on init
to the 4.4-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:
drm-nouveau-pci-do-a-msi-rearm-on-init.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Karol Herbst <kherbst(a)redhat.com>
Date: Fri, 24 Nov 2017 03:56:26 +0100
Subject: drm/nouveau/pci: do a msi rearm on init
From: Karol Herbst <kherbst(a)redhat.com>
[ Upstream commit a121027d2747168df0aac0c3da35509eea39f61c ]
On my GP107 when I load nouveau after unloading it, for some reason the
GPU stopped sending or the CPU stopped receiving interrupts if MSI was
enabled.
Doing a rearm once before getting any interrupts fixes this.
Signed-off-by: Karol Herbst <kherbst(a)redhat.com>
Reviewed-by: Thierry Reding <treding(a)nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
@@ -127,6 +127,13 @@ nvkm_pci_init(struct nvkm_subdev *subdev
return ret;
pci->irq = pdev->irq;
+
+ /* Ensure MSI interrupts are armed, for the case where there are
+ * already interrupts pending (for whatever reason) at load time.
+ */
+ if (pci->msi)
+ pci->func->msi_rearm(pci);
+
return ret;
}
Patches currently in stable-queue which might be from kherbst(a)redhat.com are
queue-4.4/drm-nouveau-pci-do-a-msi-rearm-on-init.patch
This is a note to let you know that I've just added the patch titled
can: flex_can: Correct the checking for frame length in flexcan_start_xmit()
to the 4.4-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:
can-flex_can-correct-the-checking-for-frame-length-in-flexcan_start_xmit.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Luu An Phu <phu.luuan(a)nxp.com>
Date: Tue, 2 Jan 2018 10:44:18 +0700
Subject: can: flex_can: Correct the checking for frame length in flexcan_start_xmit()
From: Luu An Phu <phu.luuan(a)nxp.com>
[ Upstream commit 13454c14550065fcc1705d6bd4ee6d40e057099f ]
The flexcan_start_xmit() function compares the frame length with data
register length to write frame content into data[0] and data[1]
register. Data register length is 4 bytes and frame maximum length is 8
bytes.
Fix the check that compares frame length with 3. Because the register
length is 4.
Signed-off-by: Luu An Phu <phu.luuan(a)nxp.com>
Reviewed-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/flexcan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -493,7 +493,7 @@ static int flexcan_start_xmit(struct sk_
data = be32_to_cpup((__be32 *)&cf->data[0]);
flexcan_write(data, ®s->mb[FLEXCAN_TX_BUF_ID].data[0]);
}
- if (cf->can_dlc > 3) {
+ if (cf->can_dlc > 4) {
data = be32_to_cpup((__be32 *)&cf->data[4]);
flexcan_write(data, ®s->mb[FLEXCAN_TX_BUF_ID].data[1]);
}
Patches currently in stable-queue which might be from phu.luuan(a)nxp.com are
queue-4.4/can-flex_can-correct-the-checking-for-frame-length-in-flexcan_start_xmit.patch
This is a note to let you know that I've just added the patch titled
bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine.
to the 4.4-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:
bnxt_en-fix-the-invalid-vf-id-check-in-bnxt_vf_ndo_prep-routine.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com>
Date: Thu, 4 Jan 2018 18:46:55 -0500
Subject: bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine.
From: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com>
[ Upstream commit 78f300049335ae81a5cc6b4b232481dc5e1f9d41 ]
In bnxt_vf_ndo_prep (which is called by bnxt_get_vf_config ndo), there is a
check for "Invalid VF id". Currently, the check is done against max_vfs.
However, the user doesn't always create max_vfs. So, the check should be
against the created number of VFs. The number of bnxt_vf_info structures
that are allocated in bnxt_alloc_vf_resources routine is the "number of
requested VFs". So, if an "invalid VF id" falls between the requested
number of VFs and the max_vfs, the driver will be dereferencing an invalid
pointer.
Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Venkat Devvuru <venkatkumar.duvvuru(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
@@ -29,7 +29,7 @@ static int bnxt_vf_ndo_prep(struct bnxt
netdev_err(bp->dev, "vf ndo called though sriov is disabled\n");
return -EINVAL;
}
- if (vf_id >= bp->pf.max_vfs) {
+ if (vf_id >= bp->pf.active_vfs) {
netdev_err(bp->dev, "Invalid VF id %d\n", vf_id);
return -EINVAL;
}
Patches currently in stable-queue which might be from venkatkumar.duvvuru(a)broadcom.com are
queue-4.4/bnxt_en-fix-the-invalid-vf-id-check-in-bnxt_vf_ndo_prep-routine.patch
This is a note to let you know that I've just added the patch titled
bnx2x: Improve reliability in case of nested PCI errors
to the 4.4-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:
bnx2x-improve-reliability-in-case-of-nested-pci-errors.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com>
Date: Fri, 22 Dec 2017 13:01:39 -0200
Subject: bnx2x: Improve reliability in case of nested PCI errors
From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com>
[ Upstream commit f7084059a9cb9e56a186e1677b1dcffd76c2cd24 ]
While in recovery process of PCI error (called EEH on PowerPC arch),
another PCI transaction could be corrupted causing a situation of
nested PCI errors. Also, this scenario could be reproduced with
error injection mechanisms (for debug purposes).
We observe that in case of nested PCI errors, bnx2x might attempt to
initialize its shmem and cause a kernel crash due to bad addresses
read from MCP. Multiple different stack traces were observed depending
on the point the second PCI error happens.
This patch avoids the crashes by:
* failing PCI recovery in case of nested errors (since multiple
PCI errors in a row are not expected to lead to a functional
adapter anyway), and by,
* preventing access to adapter FW when MCP is failed (we mark it as
failed when shmem cannot get initialized properly).
Reported-by: Abdul Haleem <abdhalee(a)linux.vnet.ibm.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com>
Acked-by: Shahed Shaikh <Shahed.Shaikh(a)cavium.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 4 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 +++++++++++++-
2 files changed, 15 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -3052,7 +3052,7 @@ int bnx2x_nic_unload(struct bnx2x *bp, i
del_timer_sync(&bp->timer);
- if (IS_PF(bp)) {
+ if (IS_PF(bp) && !BP_NOMCP(bp)) {
/* Set ALWAYS_ALIVE bit in shmem */
bp->fw_drv_pulse_wr_seq |= DRV_PULSE_ALWAYS_ALIVE;
bnx2x_drv_pulse(bp);
@@ -3134,7 +3134,7 @@ int bnx2x_nic_unload(struct bnx2x *bp, i
bp->cnic_loaded = false;
/* Clear driver version indication in shmem */
- if (IS_PF(bp))
+ if (IS_PF(bp) && !BP_NOMCP(bp))
bnx2x_update_mng_version(bp);
/* Check if there are pending parity attentions. If there are - set
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -9570,6 +9570,15 @@ static int bnx2x_init_shmem(struct bnx2x
do {
bp->common.shmem_base = REG_RD(bp, MISC_REG_SHARED_MEM_ADDR);
+
+ /* If we read all 0xFFs, means we are in PCI error state and
+ * should bail out to avoid crashes on adapter's FW reads.
+ */
+ if (bp->common.shmem_base == 0xFFFFFFFF) {
+ bp->flags |= NO_MCP_FLAG;
+ return -ENODEV;
+ }
+
if (bp->common.shmem_base) {
val = SHMEM_RD(bp, validity_map[BP_PORT(bp)]);
if (val & SHR_MEM_VALIDITY_MB)
@@ -14214,7 +14223,10 @@ static pci_ers_result_t bnx2x_io_slot_re
BNX2X_ERR("IO slot reset --> driver unload\n");
/* MCP should have been reset; Need to wait for validity */
- bnx2x_init_shmem(bp);
+ if (bnx2x_init_shmem(bp)) {
+ rtnl_unlock();
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
if (IS_PF(bp) && SHMEM2_HAS(bp, drv_capabilities_flag)) {
u32 v;
Patches currently in stable-queue which might be from gpiccoli(a)linux.vnet.ibm.com are
queue-4.4/bnx2x-improve-reliability-in-case-of-nested-pci-errors.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: ls1021a: fix incorrect clock references
to the 4.4-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:
arm-dts-ls1021a-fix-incorrect-clock-references.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 21 Dec 2017 22:35:19 +0100
Subject: ARM: dts: ls1021a: fix incorrect clock references
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 506e8a912661c97b41adc8a286b875d01323ec45 ]
dtc warns about two 'clocks' properties that have an extraneous '1'
at the end:
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a:clocks[1])
Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2190000/sgtl5000@a
arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2190000/sgtl5000@a:clocks[1])
The clocks that get referenced here are fixed-rate, so they do not
take any argument, and dtc interprets the next cell as a phandle, which
is invalid.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/ls1021a-qds.dts | 2 +-
arch/arm/boot/dts/ls1021a-twr.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -215,7 +215,7 @@
reg = <0x2a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
};
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -167,7 +167,7 @@
reg = <0x0a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/arm-dts-ls1021a-fix-incorrect-clock-references.patch
This is a note to let you know that I've just added the patch titled
ARM: 8731/1: Fix csum_partial_copy_from_user() stack mismatch
to the 4.4-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:
arm-8731-1-fix-csum_partial_copy_from_user-stack-mismatch.patch
and it can be found in the queue-4.4 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 Wed Feb 28 16:19:30 CET 2018
From: Chunyan Zhang <zhang.lyra(a)gmail.com>
Date: Fri, 1 Dec 2017 03:51:04 +0100
Subject: ARM: 8731/1: Fix csum_partial_copy_from_user() stack mismatch
From: Chunyan Zhang <zhang.lyra(a)gmail.com>
[ Upstream commit 36b0cb84ee858f02c256d26f0cb4229c78e3399e ]
An additional 'ip' will be pushed to the stack, for restoring the
DACR later, if CONFIG_CPU_SW_DOMAIN_PAN defined.
However, the fixup still get the err_ptr by add #8*4 to sp, which
results in the fact that the code area pointed by the LR will be
overwritten, or the kernel will crash if CONFIG_DEBUG_RODATA is enabled.
This patch fixes the stack mismatch.
Fixes: a5e090acbf54 ("ARM: software-based priviledged-no-access support")
Signed-off-by: Lvqiang Huang <Lvqiang.Huang(a)spreadtrum.com>
Signed-off-by: Chunyan Zhang <zhang.lyra(a)gmail.com>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/lib/csumpartialcopyuser.S | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/arm/lib/csumpartialcopyuser.S
+++ b/arch/arm/lib/csumpartialcopyuser.S
@@ -85,7 +85,11 @@
.pushsection .text.fixup,"ax"
.align 4
9001: mov r4, #-EFAULT
+#ifdef CONFIG_CPU_SW_DOMAIN_PAN
+ ldr r5, [sp, #9*4] @ *err_ptr
+#else
ldr r5, [sp, #8*4] @ *err_ptr
+#endif
str r4, [r5]
ldmia sp, {r1, r2} @ retrieve dst, len
add r2, r2, r1
Patches currently in stable-queue which might be from zhang.lyra(a)gmail.com are
queue-4.4/arm-8731-1-fix-csum_partial_copy_from_user-stack-mismatch.patch
This is a note to let you know that I've just added the patch titled
xfs: quota: check result of register_shrinker()
to the 3.18-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:
xfs-quota-check-result-of-register_shrinker.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Date: Thu, 21 Dec 2017 13:18:26 -0800
Subject: xfs: quota: check result of register_shrinker()
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[ Upstream commit 3a3882ff26fbdbaf5f7e13f6a0bccfbf7121041d ]
xfs_qm_init_quotainfo() does not check result of register_shrinker()
which was tagged as __must_check recently, reported by sparse.
Signed-off-by: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[darrick: move xfs_qm_destroy_quotainos nearer xfs_qm_init_quotainos]
Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/xfs/xfs_qm.c | 45 +++++++++++++++++++++++++++++----------------
1 file changed, 29 insertions(+), 16 deletions(-)
--- a/fs/xfs/xfs_qm.c
+++ b/fs/xfs/xfs_qm.c
@@ -49,7 +49,7 @@
STATIC int xfs_qm_init_quotainos(xfs_mount_t *);
STATIC int xfs_qm_init_quotainfo(xfs_mount_t *);
-
+STATIC void xfs_qm_destroy_quotainos(xfs_quotainfo_t *qi);
STATIC void xfs_qm_dqfree_one(struct xfs_dquot *dqp);
/*
* We use the batch lookup interface to iterate over the dquots as it
@@ -662,9 +662,17 @@ xfs_qm_init_quotainfo(
qinf->qi_shrinker.scan_objects = xfs_qm_shrink_scan;
qinf->qi_shrinker.seeks = DEFAULT_SEEKS;
qinf->qi_shrinker.flags = SHRINKER_NUMA_AWARE;
- register_shrinker(&qinf->qi_shrinker);
+
+ error = register_shrinker(&qinf->qi_shrinker);
+ if (error)
+ goto out_free_inos;
+
return 0;
+out_free_inos:
+ mutex_destroy(&qinf->qi_quotaofflock);
+ mutex_destroy(&qinf->qi_tree_lock);
+ xfs_qm_destroy_quotainos(qinf);
out_free_lru:
list_lru_destroy(&qinf->qi_lru);
out_free_qinf:
@@ -673,7 +681,6 @@ out_free_qinf:
return error;
}
-
/*
* Gets called when unmounting a filesystem or when all quotas get
* turned off.
@@ -690,19 +697,7 @@ xfs_qm_destroy_quotainfo(
unregister_shrinker(&qi->qi_shrinker);
list_lru_destroy(&qi->qi_lru);
-
- if (qi->qi_uquotaip) {
- IRELE(qi->qi_uquotaip);
- qi->qi_uquotaip = NULL; /* paranoia */
- }
- if (qi->qi_gquotaip) {
- IRELE(qi->qi_gquotaip);
- qi->qi_gquotaip = NULL;
- }
- if (qi->qi_pquotaip) {
- IRELE(qi->qi_pquotaip);
- qi->qi_pquotaip = NULL;
- }
+ xfs_qm_destroy_quotainos(qi);
mutex_destroy(&qi->qi_tree_lock);
mutex_destroy(&qi->qi_quotaofflock);
kmem_free(qi);
@@ -1574,6 +1569,24 @@ error_rele:
}
STATIC void
+xfs_qm_destroy_quotainos(
+ xfs_quotainfo_t *qi)
+{
+ if (qi->qi_uquotaip) {
+ IRELE(qi->qi_uquotaip);
+ qi->qi_uquotaip = NULL; /* paranoia */
+ }
+ if (qi->qi_gquotaip) {
+ IRELE(qi->qi_gquotaip);
+ qi->qi_gquotaip = NULL;
+ }
+ if (qi->qi_pquotaip) {
+ IRELE(qi->qi_pquotaip);
+ qi->qi_pquotaip = NULL;
+ }
+}
+
+STATIC void
xfs_qm_dqfree_one(
struct xfs_dquot *dqp)
{
Patches currently in stable-queue which might be from akaraliou.dev(a)gmail.com are
queue-3.18/xfs-quota-fix-missed-destroy-of-qi_tree_lock.patch
queue-3.18/xfs-quota-check-result-of-register_shrinker.patch
This is a note to let you know that I've just added the patch titled
xfs: quota: fix missed destroy of qi_tree_lock
to the 3.18-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:
xfs-quota-fix-missed-destroy-of-qi_tree_lock.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Date: Thu, 21 Dec 2017 13:18:26 -0800
Subject: xfs: quota: fix missed destroy of qi_tree_lock
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[ Upstream commit 2196881566225f3c3428d1a5f847a992944daa5b ]
xfs_qm_destroy_quotainfo() does not destroy quotainfo->qi_tree_lock
while destroys quotainfo->qi_quotaofflock.
Signed-off-by: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/xfs/xfs_qm.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/xfs/xfs_qm.c
+++ b/fs/xfs/xfs_qm.c
@@ -703,6 +703,7 @@ xfs_qm_destroy_quotainfo(
IRELE(qi->qi_pquotaip);
qi->qi_pquotaip = NULL;
}
+ mutex_destroy(&qi->qi_tree_lock);
mutex_destroy(&qi->qi_quotaofflock);
kmem_free(qi);
mp->m_quotainfo = NULL;
Patches currently in stable-queue which might be from akaraliou.dev(a)gmail.com are
queue-3.18/xfs-quota-fix-missed-destroy-of-qi_tree_lock.patch
queue-3.18/xfs-quota-check-result-of-register_shrinker.patch
This is a note to let you know that I've just added the patch titled
xen-netfront: enable device after manual module load
to the 3.18-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:
xen-netfront-enable-device-after-manual-module-load.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Eduardo Otubo <otubo(a)redhat.com>
Date: Fri, 5 Jan 2018 09:42:16 +0100
Subject: xen-netfront: enable device after manual module load
From: Eduardo Otubo <otubo(a)redhat.com>
[ Upstream commit b707fda2df4070785d0fa8a278aa13944c5f51f8 ]
When loading the module after unloading it, the network interface would
not be enabled and thus wouldn't have a backend counterpart and unable
to be used by the guest.
The guest would face errors like:
[root@guest ~]# ethtool -i eth0
Cannot get driver information: No such device
[root@guest ~]# ifconfig eth0
eth0: error fetching interface information: Device not found
This patch initializes the state of the netfront device whenever it is
loaded manually, this state would communicate the netback to create its
device and establish the connection between them.
Signed-off-by: Eduardo Otubo <otubo(a)redhat.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/xen-netfront.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1358,6 +1358,7 @@ static struct net_device *xennet_create_
netif_carrier_off(netdev);
+ xenbus_switch_state(dev, XenbusStateInitialising);
return netdev;
exit:
Patches currently in stable-queue which might be from otubo(a)redhat.com are
queue-3.18/xen-netfront-enable-device-after-manual-module-load.patch
This is a note to let you know that I've just added the patch titled
xen/gntdev: Fix partial gntdev_mmap() cleanup
to the 3.18-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:
xen-gntdev-fix-partial-gntdev_mmap-cleanup.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Date: Tue, 9 Jan 2018 12:10:22 +0000
Subject: xen/gntdev: Fix partial gntdev_mmap() cleanup
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
[ Upstream commit cf2acf66ad43abb39735568f55e1f85f9844e990 ]
When cleaning up after a partially successful gntdev_mmap(), unmap the
successfully mapped grant pages otherwise Xen will kill the domain if
in debug mode (Attempt to implicitly unmap a granted PTE) or Linux will
kill the process and emit "BUG: Bad page map in process" if Xen is in
release mode.
This is only needed when use_ptemod is true because gntdev_put_map()
will unmap grant pages itself when use_ptemod is false.
Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/xen/gntdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -817,8 +817,10 @@ unlock_out:
out_unlock_put:
mutex_unlock(&priv->lock);
out_put_map:
- if (use_ptemod)
+ if (use_ptemod) {
map->vma = NULL;
+ unmap_grant_pages(map, 0, map->count);
+ }
gntdev_put_map(priv, map);
return err;
}
Patches currently in stable-queue which might be from ross.lagerwall(a)citrix.com are
queue-3.18/xen-gntdev-fix-off-by-one-error-when-unmapping-with-holes.patch
queue-3.18/xen-gntdev-fix-partial-gntdev_mmap-cleanup.patch
This is a note to let you know that I've just added the patch titled
tg3: Enable PHY reset in MTU change path for 5720
to the 3.18-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:
tg3-enable-phy-reset-in-mtu-change-path-for-5720.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Date: Fri, 22 Dec 2017 16:05:29 +0530
Subject: tg3: Enable PHY reset in MTU change path for 5720
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
[ Upstream commit e60ee41aaf898584205a6af5c996860d0fe6a836 ]
A customer noticed RX path hang when MTU is changed on the fly while
running heavy traffic with NCSI enabled for 5717 and 5719. Since 5720
belongs to same ASIC family, we observed same issue and same fix
could solve this problem for 5720.
Signed-off-by: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/tg3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -14214,7 +14214,8 @@ static int tg3_change_mtu(struct net_dev
*/
if (tg3_asic_rev(tp) == ASIC_REV_57766 ||
tg3_asic_rev(tp) == ASIC_REV_5717 ||
- tg3_asic_rev(tp) == ASIC_REV_5719)
+ tg3_asic_rev(tp) == ASIC_REV_5719 ||
+ tg3_asic_rev(tp) == ASIC_REV_5720)
reset_phy = true;
err = tg3_restart_hw(tp, reset_phy);
Patches currently in stable-queue which might be from siva.kallam(a)broadcom.com are
queue-3.18/tg3-enable-phy-reset-in-mtu-change-path-for-5720.patch
queue-3.18/tg3-add-workaround-to-restrict-5762-mrrs-to-2048.patch
This is a note to let you know that I've just added the patch titled
xen/gntdev: Fix off-by-one error when unmapping with holes
to the 3.18-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:
xen-gntdev-fix-off-by-one-error-when-unmapping-with-holes.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Date: Tue, 9 Jan 2018 12:10:21 +0000
Subject: xen/gntdev: Fix off-by-one error when unmapping with holes
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
[ Upstream commit 951a010233625b77cde3430b4b8785a9a22968d1 ]
If the requested range has a hole, the calculation of the number of
pages to unmap is off by one. Fix it.
Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/xen/gntdev.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -348,10 +348,8 @@ static int unmap_grant_pages(struct gran
}
range = 0;
while (range < pages) {
- if (map->unmap_ops[offset+range].handle == -1) {
- range--;
+ if (map->unmap_ops[offset+range].handle == -1)
break;
- }
range++;
}
err = __unmap_grant_pages(map, offset, range);
Patches currently in stable-queue which might be from ross.lagerwall(a)citrix.com are
queue-3.18/xen-gntdev-fix-off-by-one-error-when-unmapping-with-holes.patch
queue-3.18/xen-gntdev-fix-partial-gntdev_mmap-cleanup.patch
This is a note to let you know that I've just added the patch titled
spi: atmel: fixed spin_lock usage inside atmel_spi_remove
to the 3.18-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:
spi-atmel-fixed-spin_lock-usage-inside-atmel_spi_remove.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Radu Pirea <radu.pirea(a)microchip.com>
Date: Fri, 15 Dec 2017 17:40:17 +0200
Subject: spi: atmel: fixed spin_lock usage inside atmel_spi_remove
From: Radu Pirea <radu.pirea(a)microchip.com>
[ Upstream commit 66e900a3d225575c8b48b59ae1fe74bb6e5a65cc ]
The only part of atmel_spi_remove which needs to be atomic is hardware
reset.
atmel_spi_stop_dma calls dma_terminate_all and this needs interrupts
enabled.
atmel_spi_release_dma calls dma_release_channel and dma_release_channel
locks a mutex inside of spin_lock.
So the call of these functions can't be inside a spin_lock.
Reported-by: Jia-Ju Bai <baijiaju1990(a)gmail.com>
Signed-off-by: Radu Pirea <radu.pirea(a)microchip.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/spi/spi-atmel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1416,12 +1416,12 @@ static int atmel_spi_remove(struct platf
struct atmel_spi *as = spi_master_get_devdata(master);
/* reset the hardware and block queue progress */
- spin_lock_irq(&as->lock);
if (as->use_dma) {
atmel_spi_stop_dma(as);
atmel_spi_release_dma(as);
}
+ spin_lock_irq(&as->lock);
spi_writel(as, CR, SPI_BIT(SWRST));
spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
spi_readl(as, SR);
Patches currently in stable-queue which might be from radu.pirea(a)microchip.com are
queue-3.18/spi-atmel-fixed-spin_lock-usage-inside-atmel_spi_remove.patch
This is a note to let you know that I've just added the patch titled
tg3: Add workaround to restrict 5762 MRRS to 2048
to the 3.18-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:
tg3-add-workaround-to-restrict-5762-mrrs-to-2048.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Date: Fri, 22 Dec 2017 16:05:28 +0530
Subject: tg3: Add workaround to restrict 5762 MRRS to 2048
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
[ Upstream commit 4419bb1cedcda0272e1dc410345c5a1d1da0e367 ]
One of AMD based server with 5762 hangs with jumbo frame traffic.
This AMD platform has southbridge limitation which is restricting MRRS
to 4000. As a work around, driver to restricts the MRRS to 2048 for
this particular 5762 NX1 card.
Signed-off-by: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/tg3.c | 10 ++++++++++
drivers/net/ethernet/broadcom/tg3.h | 4 ++++
2 files changed, 14 insertions(+)
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -10028,6 +10028,16 @@ static int tg3_reset_hw(struct tg3 *tp,
tw32(GRC_MODE, tp->grc_mode | val);
+ /* On one of the AMD platform, MRRS is restricted to 4000 because of
+ * south bridge limitation. As a workaround, Driver is setting MRRS
+ * to 2048 instead of default 4096.
+ */
+ if (tp->pdev->subsystem_vendor == PCI_VENDOR_ID_DELL &&
+ tp->pdev->subsystem_device == TG3PCI_SUBDEVICE_ID_DELL_5762) {
+ val = tr32(TG3PCI_DEV_STATUS_CTRL) & ~MAX_READ_REQ_MASK;
+ tw32(TG3PCI_DEV_STATUS_CTRL, val | MAX_READ_REQ_SIZE_2048);
+ }
+
/* Setup the timer prescalar register. Clock is always 66Mhz. */
val = tr32(GRC_MISC_CFG);
val &= ~0xff;
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -95,6 +95,7 @@
#define TG3PCI_SUBDEVICE_ID_DELL_JAGUAR 0x0106
#define TG3PCI_SUBDEVICE_ID_DELL_MERLOT 0x0109
#define TG3PCI_SUBDEVICE_ID_DELL_SLIM_MERLOT 0x010a
+#define TG3PCI_SUBDEVICE_ID_DELL_5762 0x07f0
#define TG3PCI_SUBVENDOR_ID_COMPAQ PCI_VENDOR_ID_COMPAQ
#define TG3PCI_SUBDEVICE_ID_COMPAQ_BANSHEE 0x007c
#define TG3PCI_SUBDEVICE_ID_COMPAQ_BANSHEE_2 0x009a
@@ -280,6 +281,9 @@
#define TG3PCI_STD_RING_PROD_IDX 0x00000098 /* 64-bit */
#define TG3PCI_RCV_RET_RING_CON_IDX 0x000000a0 /* 64-bit */
/* 0xa8 --> 0xb8 unused */
+#define TG3PCI_DEV_STATUS_CTRL 0x000000b4
+#define MAX_READ_REQ_SIZE_2048 0x00004000
+#define MAX_READ_REQ_MASK 0x00007000
#define TG3PCI_DUAL_MAC_CTRL 0x000000b8
#define DUAL_MAC_CTRL_CH_MASK 0x00000003
#define DUAL_MAC_CTRL_ID 0x00000004
Patches currently in stable-queue which might be from siva.kallam(a)broadcom.com are
queue-3.18/tg3-enable-phy-reset-in-mtu-change-path-for-5720.patch
queue-3.18/tg3-add-workaround-to-restrict-5762-mrrs-to-2048.patch
This is a note to let you know that I've just added the patch titled
sget(): handle failures of register_shrinker()
to the 3.18-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:
sget-handle-failures-of-register_shrinker.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Al Viro <viro(a)zeniv.linux.org.uk>
Date: Mon, 18 Dec 2017 15:05:07 -0500
Subject: sget(): handle failures of register_shrinker()
From: Al Viro <viro(a)zeniv.linux.org.uk>
[ Upstream commit 9ee332d99e4d5a97548943b81c54668450ce641b ]
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/super.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/super.c
+++ b/fs/super.c
@@ -476,7 +476,11 @@ retry:
hlist_add_head(&s->s_instances, &type->fs_supers);
spin_unlock(&sb_lock);
get_filesystem(type);
- register_shrinker(&s->s_shrink);
+ err = register_shrinker(&s->s_shrink);
+ if (err) {
+ deactivate_locked_super(s);
+ s = ERR_PTR(err);
+ }
return s;
}
Patches currently in stable-queue which might be from viro(a)zeniv.linux.org.uk are
queue-3.18/sget-handle-failures-of-register_shrinker.patch
This is a note to let you know that I've just added the patch titled
SolutionEngine771x: fix Ether platform data
to the 3.18-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:
solutionengine771x-fix-ether-platform-data.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Date: Sat, 6 Jan 2018 21:53:26 +0300
Subject: SolutionEngine771x: fix Ether platform data
From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
[ Upstream commit 195e2addbce09e5afbc766efc1e6567c9ce840d3 ]
The 'sh_eth' driver's probe() method would fail on the SolutionEngine7710
board and crash on SolutionEngine7712 board as the platform code is
hopelessly behind the driver's platform data -- it passes the PHY address
instead of 'struct sh_eth_plat_data *'; pass the latter to the driver in
order to fix the bug...
Fixes: 71557a37adb5 ("[netdrvr] sh_eth: Add SH7619 support")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/sh/boards/mach-se/770x/setup.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/arch/sh/boards/mach-se/770x/setup.c
+++ b/arch/sh/boards/mach-se/770x/setup.c
@@ -8,6 +8,7 @@
*/
#include <linux/init.h>
#include <linux/platform_device.h>
+#include <linux/sh_eth.h>
#include <mach-se/mach/se.h>
#include <mach-se/mach/mrshpc.h>
#include <asm/machvec.h>
@@ -114,6 +115,11 @@ static struct platform_device heartbeat_
#if defined(CONFIG_CPU_SUBTYPE_SH7710) ||\
defined(CONFIG_CPU_SUBTYPE_SH7712)
/* SH771X Ethernet driver */
+static struct sh_eth_plat_data sh_eth_plat = {
+ .phy = PHY_ID,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+};
+
static struct resource sh_eth0_resources[] = {
[0] = {
.start = SH_ETH0_BASE,
@@ -131,7 +137,7 @@ static struct platform_device sh_eth0_de
.name = "sh771x-ether",
.id = 0,
.dev = {
- .platform_data = PHY_ID,
+ .platform_data = &sh_eth_plat,
},
.num_resources = ARRAY_SIZE(sh_eth0_resources),
.resource = sh_eth0_resources,
@@ -154,7 +160,7 @@ static struct platform_device sh_eth1_de
.name = "sh771x-ether",
.id = 1,
.dev = {
- .platform_data = PHY_ID,
+ .platform_data = &sh_eth_plat,
},
.num_resources = ARRAY_SIZE(sh_eth1_resources),
.resource = sh_eth1_resources,
Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are
queue-3.18/solutionengine771x-fix-ether-platform-data.patch
This is a note to let you know that I've just added the patch titled
scsi: storvsc: Fix scsi_cmd error assignments in storvsc_handle_error
to the 3.18-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:
scsi-storvsc-fix-scsi_cmd-error-assignments-in-storvsc_handle_error.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Cathy Avery <cavery(a)redhat.com>
Date: Tue, 19 Dec 2017 13:32:48 -0500
Subject: scsi: storvsc: Fix scsi_cmd error assignments in storvsc_handle_error
From: Cathy Avery <cavery(a)redhat.com>
[ Upstream commit d1b8b2391c24751e44f618fcf86fb55d9a9247fd ]
When an I/O is returned with an srb_status of SRB_STATUS_INVALID_LUN
which has zero good_bytes it must be assigned an error. Otherwise the
I/O will be continuously requeued and will cause a deadlock in the case
where disks are being hot added and removed. sd_probe_async will wait
forever for its I/O to complete while holding scsi_sd_probe_domain.
Also returning the default error of DID_TARGET_FAILURE causes multipath
to not retry the I/O resulting in applications receiving I/O errors
before a failover can occur.
Signed-off-by: Cathy Avery <cavery(a)redhat.com>
Signed-off-by: Long Li <longli(a)microsoft.com>
Reviewed-by: Stephen Hemminger <stephen(a)networkplumber.org>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/storvsc_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1029,10 +1029,11 @@ static void storvsc_handle_error(struct
case TEST_UNIT_READY:
break;
default:
- set_host_byte(scmnd, DID_TARGET_FAILURE);
+ set_host_byte(scmnd, DID_ERROR);
}
break;
case SRB_STATUS_INVALID_LUN:
+ set_host_byte(scmnd, DID_NO_CONNECT);
do_work = true;
process_err_fn = storvsc_remove_lun;
break;
Patches currently in stable-queue which might be from cavery(a)redhat.com are
queue-3.18/scsi-storvsc-fix-scsi_cmd-error-assignments-in-storvsc_handle_error.patch
This is a note to let you know that I've just added the patch titled
sctp: make use of pre-calculated len
to the 3.18-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:
sctp-make-use-of-pre-calculated-len.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Date: Mon, 8 Jan 2018 19:02:29 -0200
Subject: sctp: make use of pre-calculated len
From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
[ Upstream commit c76f97c99ae6d26d14c7f0e50e074382bfbc9f98 ]
Some sockopt handling functions were calculating the length of the
buffer to be written to userspace and then calculating it again when
actually writing the buffer, which could lead to some write not using
an up-to-date length.
This patch updates such places to just make use of the len variable.
Also, replace some sizeof(type) to sizeof(var).
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/socket.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4458,7 +4458,7 @@ static int sctp_getsockopt_autoclose(str
len = sizeof(int);
if (put_user(len, optlen))
return -EFAULT;
- if (copy_to_user(optval, &sctp_sk(sk)->autoclose, sizeof(int)))
+ if (copy_to_user(optval, &sctp_sk(sk)->autoclose, len))
return -EFAULT;
return 0;
}
@@ -5035,6 +5035,9 @@ copy_getaddrs:
err = -EFAULT;
goto out;
}
+ /* XXX: We should have accounted for sizeof(struct sctp_getaddrs) too,
+ * but we can't change it anymore.
+ */
if (put_user(bytes_copied, optlen))
err = -EFAULT;
out:
@@ -5471,7 +5474,7 @@ static int sctp_getsockopt_maxseg(struct
params.assoc_id = 0;
} else if (len >= sizeof(struct sctp_assoc_value)) {
len = sizeof(struct sctp_assoc_value);
- if (copy_from_user(¶ms, optval, sizeof(params)))
+ if (copy_from_user(¶ms, optval, len))
return -EFAULT;
} else
return -EINVAL;
@@ -5635,7 +5638,9 @@ static int sctp_getsockopt_active_key(st
if (len < sizeof(struct sctp_authkeyid))
return -EINVAL;
- if (copy_from_user(&val, optval, sizeof(struct sctp_authkeyid)))
+
+ len = sizeof(struct sctp_authkeyid);
+ if (copy_from_user(&val, optval, len))
return -EFAULT;
asoc = sctp_id2assoc(sk, val.scact_assoc_id);
@@ -5647,7 +5652,6 @@ static int sctp_getsockopt_active_key(st
else
val.scact_keynumber = ep->active_key_id;
- len = sizeof(struct sctp_authkeyid);
if (put_user(len, optlen))
return -EFAULT;
if (copy_to_user(optval, &val, len))
@@ -5673,7 +5677,7 @@ static int sctp_getsockopt_peer_auth_chu
if (len < sizeof(struct sctp_authchunks))
return -EINVAL;
- if (copy_from_user(&val, optval, sizeof(struct sctp_authchunks)))
+ if (copy_from_user(&val, optval, sizeof(val)))
return -EFAULT;
to = p->gauth_chunks;
@@ -5718,7 +5722,7 @@ static int sctp_getsockopt_local_auth_ch
if (len < sizeof(struct sctp_authchunks))
return -EINVAL;
- if (copy_from_user(&val, optval, sizeof(struct sctp_authchunks)))
+ if (copy_from_user(&val, optval, sizeof(val)))
return -EFAULT;
to = p->gauth_chunks;
Patches currently in stable-queue which might be from marcelo.leitner(a)gmail.com are
queue-3.18/sctp-make-use-of-pre-calculated-len.patch
This is a note to let you know that I've just added the patch titled
s390/dasd: fix wrongly assigned configuration data
to the 3.18-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:
s390-dasd-fix-wrongly-assigned-configuration-data.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Stefan Haberland <sth(a)linux.vnet.ibm.com>
Date: Wed, 6 Dec 2017 10:30:39 +0100
Subject: s390/dasd: fix wrongly assigned configuration data
From: Stefan Haberland <sth(a)linux.vnet.ibm.com>
[ Upstream commit 8a9bd4f8ebc6800bfc0596e28631ff6809a2f615 ]
We store per path and per device configuration data to identify the
path or device correctly. The per path configuration data might get
mixed up if the original request gets into error recovery and is
started with a random path mask.
This would lead to a wrong identification of a path in case of a CUIR
event for example.
Fix by copying the path mask from the original request to the error
recovery request in case it is a path verification request.
Signed-off-by: Stefan Haberland <sth(a)linux.vnet.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner(a)linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/block/dasd_3990_erp.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/s390/block/dasd_3990_erp.c
+++ b/drivers/s390/block/dasd_3990_erp.c
@@ -2743,6 +2743,16 @@ dasd_3990_erp_action(struct dasd_ccw_req
erp = dasd_3990_erp_handle_match_erp(cqr, erp);
}
+
+ /*
+ * For path verification work we need to stick with the path that was
+ * originally chosen so that the per path configuration data is
+ * assigned correctly.
+ */
+ if (test_bit(DASD_CQR_VERIFY_PATH, &erp->flags) && cqr->lpm) {
+ erp->lpm = cqr->lpm;
+ }
+
if (device->features & DASD_FEATURE_ERPLOG) {
/* print current erp_chain */
dev_err(&device->cdev->dev,
Patches currently in stable-queue which might be from sth(a)linux.vnet.ibm.com are
queue-3.18/s390-dasd-fix-wrongly-assigned-configuration-data.patch
This is a note to let you know that I've just added the patch titled
net: arc_emac: fix arc_emac_rx() error paths
to the 3.18-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-arc_emac-fix-arc_emac_rx-error-paths.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Alexander Kochetkov <al.kochet(a)gmail.com>
Date: Fri, 15 Dec 2017 20:20:06 +0300
Subject: net: arc_emac: fix arc_emac_rx() error paths
From: Alexander Kochetkov <al.kochet(a)gmail.com>
[ Upstream commit e688822d035b494071ecbadcccbd6f3325fb0f59 ]
arc_emac_rx() has some issues found by code review.
In case netdev_alloc_skb_ip_align() or dma_map_single() failure
rx fifo entry will not be returned to EMAC.
In case dma_map_single() failure previously allocated skb became
lost to driver. At the same time address of newly allocated skb
will not be provided to EMAC.
Signed-off-by: Alexander Kochetkov <al.kochet(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/arc/emac_main.c | 53 ++++++++++++++++++++---------------
1 file changed, 31 insertions(+), 22 deletions(-)
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -250,39 +250,48 @@ static int arc_emac_rx(struct net_device
continue;
}
- pktlen = info & LEN_MASK;
- stats->rx_packets++;
- stats->rx_bytes += pktlen;
- skb = rx_buff->skb;
- skb_put(skb, pktlen);
- skb->dev = ndev;
- skb->protocol = eth_type_trans(skb, ndev);
-
- dma_unmap_single(&ndev->dev, dma_unmap_addr(rx_buff, addr),
- dma_unmap_len(rx_buff, len), DMA_FROM_DEVICE);
-
- /* Prepare the BD for next cycle */
- rx_buff->skb = netdev_alloc_skb_ip_align(ndev,
- EMAC_BUFFER_SIZE);
- if (unlikely(!rx_buff->skb)) {
+ /* Prepare the BD for next cycle. netif_receive_skb()
+ * only if new skb was allocated and mapped to avoid holes
+ * in the RX fifo.
+ */
+ skb = netdev_alloc_skb_ip_align(ndev, EMAC_BUFFER_SIZE);
+ if (unlikely(!skb)) {
+ if (net_ratelimit())
+ netdev_err(ndev, "cannot allocate skb\n");
+ /* Return ownership to EMAC */
+ rxbd->info = cpu_to_le32(FOR_EMAC | EMAC_BUFFER_SIZE);
stats->rx_errors++;
- /* Because receive_skb is below, increment rx_dropped */
stats->rx_dropped++;
continue;
}
- /* receive_skb only if new skb was allocated to avoid holes */
- netif_receive_skb(skb);
-
- addr = dma_map_single(&ndev->dev, (void *)rx_buff->skb->data,
+ addr = dma_map_single(&ndev->dev, (void *)skb->data,
EMAC_BUFFER_SIZE, DMA_FROM_DEVICE);
if (dma_mapping_error(&ndev->dev, addr)) {
if (net_ratelimit())
- netdev_err(ndev, "cannot dma map\n");
- dev_kfree_skb(rx_buff->skb);
+ netdev_err(ndev, "cannot map dma buffer\n");
+ dev_kfree_skb(skb);
+ /* Return ownership to EMAC */
+ rxbd->info = cpu_to_le32(FOR_EMAC | EMAC_BUFFER_SIZE);
stats->rx_errors++;
+ stats->rx_dropped++;
continue;
}
+
+ /* unmap previosly mapped skb */
+ dma_unmap_single(&ndev->dev, dma_unmap_addr(rx_buff, addr),
+ dma_unmap_len(rx_buff, len), DMA_FROM_DEVICE);
+
+ pktlen = info & LEN_MASK;
+ stats->rx_packets++;
+ stats->rx_bytes += pktlen;
+ skb_put(rx_buff->skb, pktlen);
+ rx_buff->skb->dev = ndev;
+ rx_buff->skb->protocol = eth_type_trans(rx_buff->skb, ndev);
+
+ netif_receive_skb(rx_buff->skb);
+
+ rx_buff->skb = skb;
dma_unmap_addr_set(rx_buff, addr, addr);
dma_unmap_len_set(rx_buff, len, EMAC_BUFFER_SIZE);
Patches currently in stable-queue which might be from al.kochet(a)gmail.com are
queue-3.18/net-arc_emac-fix-arc_emac_rx-error-paths.patch
This is a note to let you know that I've just added the patch titled
net: gianfar_ptp: move set_fipers() to spinlock protecting area
to the 3.18-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-gianfar_ptp-move-set_fipers-to-spinlock-protecting-area.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Yangbo Lu <yangbo.lu(a)nxp.com>
Date: Tue, 9 Jan 2018 11:02:33 +0800
Subject: net: gianfar_ptp: move set_fipers() to spinlock protecting area
From: Yangbo Lu <yangbo.lu(a)nxp.com>
[ Upstream commit 11d827a993a969c3c6ec56758ff63a44ba19b466 ]
set_fipers() calling should be protected by spinlock in
case that any interrupt breaks related registers setting
and the function we expect. This patch is to move set_fipers()
to spinlock protecting area in ptp_gianfar_adjtime().
Signed-off-by: Yangbo Lu <yangbo.lu(a)nxp.com>
Acked-by: Richard Cochran <richardcochran(a)gmail.com>
Reviewed-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/freescale/gianfar_ptp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/net/ethernet/freescale/gianfar_ptp.c
+++ b/drivers/net/ethernet/freescale/gianfar_ptp.c
@@ -314,11 +314,10 @@ static int ptp_gianfar_adjtime(struct pt
now = tmr_cnt_read(etsects);
now += delta;
tmr_cnt_write(etsects, now);
+ set_fipers(etsects);
spin_unlock_irqrestore(&etsects->lock, flags);
- set_fipers(etsects);
-
return 0;
}
Patches currently in stable-queue which might be from yangbo.lu(a)nxp.com are
queue-3.18/net-gianfar_ptp-move-set_fipers-to-spinlock-protecting-area.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM
to the 3.18-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:
mtd-nand-gpmi-fix-failure-when-a-erased-page-has-a-bitflip-at-bbm.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Sascha Hauer <s.hauer(a)pengutronix.de>
Date: Tue, 5 Dec 2017 11:51:40 +0100
Subject: mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM
From: Sascha Hauer <s.hauer(a)pengutronix.de>
[ Upstream commit fdf2e821052958a114618a95ab18a300d0b080cb ]
When erased subpages are read then the BCH decoder returns STATUS_ERASED
if they are all empty, or STATUS_UNCORRECTABLE if there are bitflips.
When there are bitflips, we have to set these bits again to show the
upper layers a completely erased page. When a bitflip happens in the
exact byte where the bad block marker is, then this byte is swapped
with another byte in block_mark_swapping(). The correction code then
detects a bitflip in another subpage and no longer corrects the bitflip
where it really happens.
Correct this behaviour by calling block_mark_swapping() after the
bitflips have been corrected.
In our case UBIFS failed with this bug because it expects erased
pages to be really empty:
UBIFS error (pid 187): ubifs_scan: corrupt empty space at LEB 36:118735
UBIFS error (pid 187): ubifs_scanned_corruption: corruption at LEB 36:118735
UBIFS error (pid 187): ubifs_scanned_corruption: first 8192 bytes from LEB 36:118735
UBIFS error (pid 187): ubifs_scan: LEB 36 scanning failed
UBIFS error (pid 187): do_commit: commit failed, error -117
Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de>
Reviewed-by: Richard Weinberger <richard(a)nod.at>
Acked-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1025,9 +1025,6 @@ static int gpmi_ecc_read_page(struct mtd
return ret;
}
- /* handle the block mark swapping */
- block_mark_swapping(this, payload_virt, auxiliary_virt);
-
/* Loop over status bytes, accumulating ECC status. */
status = auxiliary_virt + nfc_geo->auxiliary_status_offset;
@@ -1043,6 +1040,9 @@ static int gpmi_ecc_read_page(struct mtd
max_bitflips = max_t(unsigned int, max_bitflips, *status);
}
+ /* handle the block mark swapping */
+ block_mark_swapping(this, buf, auxiliary_virt);
+
if (oob_required) {
/*
* It's time to deliver the OOB bytes. See gpmi_ecc_read_oob()
Patches currently in stable-queue which might be from s.hauer(a)pengutronix.de are
queue-3.18/mtd-nand-gpmi-fix-failure-when-a-erased-page-has-a-bitflip-at-bbm.patch
This is a note to let you know that I've just added the patch titled
led: core: Fix brightness setting when setting delay_off=0
to the 3.18-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:
led-core-fix-brightness-setting-when-setting-delay_off-0.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Matthieu CASTET <matthieu.castet(a)parrot.com>
Date: Tue, 12 Dec 2017 11:10:44 +0100
Subject: led: core: Fix brightness setting when setting delay_off=0
From: Matthieu CASTET <matthieu.castet(a)parrot.com>
[ Upstream commit 2b83ff96f51d0b039c4561b9f95c824d7bddb85c ]
With the current code, the following sequence won't work :
echo timer > trigger
echo 0 > delay_off
* at this point we call
** led_delay_off_store
** led_blink_set
---
drivers/leds/led-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -76,7 +76,7 @@ void led_blink_set(struct led_classdev *
unsigned long *delay_on,
unsigned long *delay_off)
{
- del_timer_sync(&led_cdev->blink_timer);
+ led_stop_software_blink(led_cdev);
led_cdev->flags &= ~LED_BLINK_ONESHOT;
led_cdev->flags &= ~LED_BLINK_ONESHOT_STOP;
Patches currently in stable-queue which might be from matthieu.castet(a)parrot.com are
queue-3.18/led-core-fix-brightness-setting-when-setting-delay_off-0.patch
This is a note to let you know that I've just added the patch titled
mdio-sun4i: Fix a memory leak
to the 3.18-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:
mdio-sun4i-fix-a-memory-leak.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sat, 6 Jan 2018 09:00:09 +0100
Subject: mdio-sun4i: Fix a memory leak
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 56c0290202ab94a2f2780c449395d4ae8495fab4 ]
If the probing of the regulator is deferred, the memory allocated by
'mdiobus_alloc_size()' will be leaking.
It should be freed before the next call to 'sun4i_mdio_probe()' which will
reallocate it.
Fixes: 4bdcb1dd9feb ("net: Add MDIO bus driver for the Allwinner EMAC")
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/phy/mdio-sun4i.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/phy/mdio-sun4i.c
+++ b/drivers/net/phy/mdio-sun4i.c
@@ -128,8 +128,10 @@ static int sun4i_mdio_probe(struct platf
data->regulator = devm_regulator_get(&pdev->dev, "phy");
if (IS_ERR(data->regulator)) {
- if (PTR_ERR(data->regulator) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
+ if (PTR_ERR(data->regulator) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto err_out_free_mdiobus;
+ }
dev_info(&pdev->dev, "no regulator found\n");
} else {
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-3.18/mdio-sun4i-fix-a-memory-leak.patch
This is a note to let you know that I've just added the patch titled
ipv6: icmp6: Allow icmp messages to be looped back
to the 3.18-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-icmp6-allow-icmp-messages-to-be-looped-back.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Brendan McGrath <redmcg(a)redmandi.dyndns.org>
Date: Wed, 13 Dec 2017 22:14:57 +1100
Subject: ipv6: icmp6: Allow icmp messages to be looped back
From: Brendan McGrath <redmcg(a)redmandi.dyndns.org>
[ Upstream commit 588753f1eb18978512b1c9b85fddb457d46f9033 ]
One example of when an ICMPv6 packet is required to be looped back is
when a host acts as both a Multicast Listener and a Multicast Router.
A Multicast Router will listen on address ff02::16 for MLDv2 messages.
Currently, MLDv2 messages originating from a Multicast Listener running
on the same host as the Multicast Router are not being delivered to the
Multicast Router. This is due to dst.input being assigned the default
value of dst_discard.
This results in the packet being looped back but discarded before being
delivered to the Multicast Router.
This patch sets dst.input to ip6_input to ensure a looped back packet
is delivered to the Multicast Router.
Signed-off-by: Brendan McGrath <redmcg(a)redmandi.dyndns.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/route.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1367,6 +1367,7 @@ struct dst_entry *icmp6_dst_alloc(struct
}
rt->dst.flags |= DST_HOST;
+ rt->dst.input = ip6_input;
rt->dst.output = ip6_output;
atomic_set(&rt->dst.__refcnt, 1);
rt->rt6i_gateway = fl6->daddr;
Patches currently in stable-queue which might be from redmcg(a)redmandi.dyndns.org are
queue-3.18/ipv6-icmp6-allow-icmp-messages-to-be-looped-back.patch
This is a note to let you know that I've just added the patch titled
bnx2x: Improve reliability in case of nested PCI errors
to the 3.18-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:
bnx2x-improve-reliability-in-case-of-nested-pci-errors.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com>
Date: Fri, 22 Dec 2017 13:01:39 -0200
Subject: bnx2x: Improve reliability in case of nested PCI errors
From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com>
[ Upstream commit f7084059a9cb9e56a186e1677b1dcffd76c2cd24 ]
While in recovery process of PCI error (called EEH on PowerPC arch),
another PCI transaction could be corrupted causing a situation of
nested PCI errors. Also, this scenario could be reproduced with
error injection mechanisms (for debug purposes).
We observe that in case of nested PCI errors, bnx2x might attempt to
initialize its shmem and cause a kernel crash due to bad addresses
read from MCP. Multiple different stack traces were observed depending
on the point the second PCI error happens.
This patch avoids the crashes by:
* failing PCI recovery in case of nested errors (since multiple
PCI errors in a row are not expected to lead to a functional
adapter anyway), and by,
* preventing access to adapter FW when MCP is failed (we mark it as
failed when shmem cannot get initialized properly).
Reported-by: Abdul Haleem <abdhalee(a)linux.vnet.ibm.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com>
Acked-by: Shahed Shaikh <Shahed.Shaikh(a)cavium.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 4 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 +++++++++++++-
2 files changed, 15 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -2994,7 +2994,7 @@ int bnx2x_nic_unload(struct bnx2x *bp, i
del_timer_sync(&bp->timer);
- if (IS_PF(bp)) {
+ if (IS_PF(bp) && !BP_NOMCP(bp)) {
/* Set ALWAYS_ALIVE bit in shmem */
bp->fw_drv_pulse_wr_seq |= DRV_PULSE_ALWAYS_ALIVE;
bnx2x_drv_pulse(bp);
@@ -3076,7 +3076,7 @@ int bnx2x_nic_unload(struct bnx2x *bp, i
bp->cnic_loaded = false;
/* Clear driver version indication in shmem */
- if (IS_PF(bp))
+ if (IS_PF(bp) && !BP_NOMCP(bp))
bnx2x_update_mng_version(bp);
/* Check if there are pending parity attentions. If there are - set
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -9472,6 +9472,15 @@ static int bnx2x_init_shmem(struct bnx2x
do {
bp->common.shmem_base = REG_RD(bp, MISC_REG_SHARED_MEM_ADDR);
+
+ /* If we read all 0xFFs, means we are in PCI error state and
+ * should bail out to avoid crashes on adapter's FW reads.
+ */
+ if (bp->common.shmem_base == 0xFFFFFFFF) {
+ bp->flags |= NO_MCP_FLAG;
+ return -ENODEV;
+ }
+
if (bp->common.shmem_base) {
val = SHMEM_RD(bp, validity_map[BP_PORT(bp)]);
if (val & SHR_MEM_VALIDITY_MB)
@@ -13743,7 +13752,10 @@ static pci_ers_result_t bnx2x_io_slot_re
BNX2X_ERR("IO slot reset --> driver unload\n");
/* MCP should have been reset; Need to wait for validity */
- bnx2x_init_shmem(bp);
+ if (bnx2x_init_shmem(bp)) {
+ rtnl_unlock();
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
if (IS_PF(bp) && SHMEM2_HAS(bp, drv_capabilities_flag)) {
u32 v;
Patches currently in stable-queue which might be from gpiccoli(a)linux.vnet.ibm.com are
queue-3.18/bnx2x-improve-reliability-in-case-of-nested-pci-errors.patch
This is a note to let you know that I've just added the patch titled
drm/ttm: check the return value of kzalloc
to the 3.18-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:
drm-ttm-check-the-return-value-of-kzalloc.patch
and it can be found in the queue-3.18 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 Wed Feb 28 16:16:23 CET 2018
From: Xiongwei Song <sxwjean(a)gmail.com>
Date: Tue, 2 Jan 2018 21:24:55 +0800
Subject: drm/ttm: check the return value of kzalloc
From: Xiongwei Song <sxwjean(a)gmail.com>
[ Upstream commit 19d859a7205bc59ffc38303eb25ae394f61d21dc ]
In the function ttm_page_alloc_init, kzalloc call is made for variable
_manager, we need to check its return value, it may return NULL.
Signed-off-by: Xiongwei Song <sxwjean(a)gmail.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -818,6 +818,8 @@ int ttm_page_alloc_init(struct ttm_mem_g
pr_info("Initializing pool allocator\n");
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
+ if (!_manager)
+ return -ENOMEM;
ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");
Patches currently in stable-queue which might be from sxwjean(a)gmail.com are
queue-3.18/drm-ttm-check-the-return-value-of-kzalloc.patch
This is a note to let you know that I've just added the patch titled
xfs: quota: check result of register_shrinker()
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:
xfs-quota-check-result-of-register_shrinker.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 Wed Feb 28 16:13:29 CET 2018
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Date: Thu, 21 Dec 2017 13:18:26 -0800
Subject: xfs: quota: check result of register_shrinker()
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[ Upstream commit 3a3882ff26fbdbaf5f7e13f6a0bccfbf7121041d ]
xfs_qm_init_quotainfo() does not check result of register_shrinker()
which was tagged as __must_check recently, reported by sparse.
Signed-off-by: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[darrick: move xfs_qm_destroy_quotainos nearer xfs_qm_init_quotainos]
Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/xfs/xfs_qm.c | 45 +++++++++++++++++++++++++++++----------------
1 file changed, 29 insertions(+), 16 deletions(-)
--- a/fs/xfs/xfs_qm.c
+++ b/fs/xfs/xfs_qm.c
@@ -47,7 +47,7 @@
STATIC int xfs_qm_init_quotainos(xfs_mount_t *);
STATIC int xfs_qm_init_quotainfo(xfs_mount_t *);
-
+STATIC void xfs_qm_destroy_quotainos(xfs_quotainfo_t *qi);
STATIC void xfs_qm_dqfree_one(struct xfs_dquot *dqp);
/*
* We use the batch lookup interface to iterate over the dquots as it
@@ -694,9 +694,17 @@ xfs_qm_init_quotainfo(
qinf->qi_shrinker.scan_objects = xfs_qm_shrink_scan;
qinf->qi_shrinker.seeks = DEFAULT_SEEKS;
qinf->qi_shrinker.flags = SHRINKER_NUMA_AWARE;
- register_shrinker(&qinf->qi_shrinker);
+
+ error = register_shrinker(&qinf->qi_shrinker);
+ if (error)
+ goto out_free_inos;
+
return 0;
+out_free_inos:
+ mutex_destroy(&qinf->qi_quotaofflock);
+ mutex_destroy(&qinf->qi_tree_lock);
+ xfs_qm_destroy_quotainos(qinf);
out_free_lru:
list_lru_destroy(&qinf->qi_lru);
out_free_qinf:
@@ -705,7 +713,6 @@ out_free_qinf:
return error;
}
-
/*
* Gets called when unmounting a filesystem or when all quotas get
* turned off.
@@ -722,19 +729,7 @@ xfs_qm_destroy_quotainfo(
unregister_shrinker(&qi->qi_shrinker);
list_lru_destroy(&qi->qi_lru);
-
- if (qi->qi_uquotaip) {
- IRELE(qi->qi_uquotaip);
- qi->qi_uquotaip = NULL; /* paranoia */
- }
- if (qi->qi_gquotaip) {
- IRELE(qi->qi_gquotaip);
- qi->qi_gquotaip = NULL;
- }
- if (qi->qi_pquotaip) {
- IRELE(qi->qi_pquotaip);
- qi->qi_pquotaip = NULL;
- }
+ xfs_qm_destroy_quotainos(qi);
mutex_destroy(&qi->qi_tree_lock);
mutex_destroy(&qi->qi_quotaofflock);
kmem_free(qi);
@@ -1621,6 +1616,24 @@ error_rele:
}
STATIC void
+xfs_qm_destroy_quotainos(
+ xfs_quotainfo_t *qi)
+{
+ if (qi->qi_uquotaip) {
+ IRELE(qi->qi_uquotaip);
+ qi->qi_uquotaip = NULL; /* paranoia */
+ }
+ if (qi->qi_gquotaip) {
+ IRELE(qi->qi_gquotaip);
+ qi->qi_gquotaip = NULL;
+ }
+ if (qi->qi_pquotaip) {
+ IRELE(qi->qi_pquotaip);
+ qi->qi_pquotaip = NULL;
+ }
+}
+
+STATIC void
xfs_qm_dqfree_one(
struct xfs_dquot *dqp)
{
Patches currently in stable-queue which might be from akaraliou.dev(a)gmail.com are
queue-4.9/xfs-quota-fix-missed-destroy-of-qi_tree_lock.patch
queue-4.9/xfs-quota-check-result-of-register_shrinker.patch
This is a note to let you know that I've just added the patch titled
xfs: quota: fix missed destroy of qi_tree_lock
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:
xfs-quota-fix-missed-destroy-of-qi_tree_lock.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 Wed Feb 28 16:13:29 CET 2018
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Date: Thu, 21 Dec 2017 13:18:26 -0800
Subject: xfs: quota: fix missed destroy of qi_tree_lock
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[ Upstream commit 2196881566225f3c3428d1a5f847a992944daa5b ]
xfs_qm_destroy_quotainfo() does not destroy quotainfo->qi_tree_lock
while destroys quotainfo->qi_quotaofflock.
Signed-off-by: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/xfs/xfs_qm.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/xfs/xfs_qm.c
+++ b/fs/xfs/xfs_qm.c
@@ -735,6 +735,7 @@ xfs_qm_destroy_quotainfo(
IRELE(qi->qi_pquotaip);
qi->qi_pquotaip = NULL;
}
+ mutex_destroy(&qi->qi_tree_lock);
mutex_destroy(&qi->qi_quotaofflock);
kmem_free(qi);
mp->m_quotainfo = NULL;
Patches currently in stable-queue which might be from akaraliou.dev(a)gmail.com are
queue-4.9/xfs-quota-fix-missed-destroy-of-qi_tree_lock.patch
queue-4.9/xfs-quota-check-result-of-register_shrinker.patch
This is a note to let you know that I've just added the patch titled
xen-netfront: enable device after manual module load
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:
xen-netfront-enable-device-after-manual-module-load.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 Wed Feb 28 16:13:29 CET 2018
From: Eduardo Otubo <otubo(a)redhat.com>
Date: Fri, 5 Jan 2018 09:42:16 +0100
Subject: xen-netfront: enable device after manual module load
From: Eduardo Otubo <otubo(a)redhat.com>
[ Upstream commit b707fda2df4070785d0fa8a278aa13944c5f51f8 ]
When loading the module after unloading it, the network interface would
not be enabled and thus wouldn't have a backend counterpart and unable
to be used by the guest.
The guest would face errors like:
[root@guest ~]# ethtool -i eth0
Cannot get driver information: No such device
[root@guest ~]# ifconfig eth0
eth0: error fetching interface information: Device not found
This patch initializes the state of the netfront device whenever it is
loaded manually, this state would communicate the netback to create its
device and establish the connection between them.
Signed-off-by: Eduardo Otubo <otubo(a)redhat.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/xen-netfront.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1345,6 +1345,7 @@ static struct net_device *xennet_create_
netif_carrier_off(netdev);
+ xenbus_switch_state(dev, XenbusStateInitialising);
return netdev;
exit:
Patches currently in stable-queue which might be from otubo(a)redhat.com are
queue-4.9/xen-netfront-enable-device-after-manual-module-load.patch
This is a note to let you know that I've just added the patch titled
xen/gntdev: Fix partial gntdev_mmap() cleanup
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:
xen-gntdev-fix-partial-gntdev_mmap-cleanup.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 Wed Feb 28 16:13:29 CET 2018
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Date: Tue, 9 Jan 2018 12:10:22 +0000
Subject: xen/gntdev: Fix partial gntdev_mmap() cleanup
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
[ Upstream commit cf2acf66ad43abb39735568f55e1f85f9844e990 ]
When cleaning up after a partially successful gntdev_mmap(), unmap the
successfully mapped grant pages otherwise Xen will kill the domain if
in debug mode (Attempt to implicitly unmap a granted PTE) or Linux will
kill the process and emit "BUG: Bad page map in process" if Xen is in
release mode.
This is only needed when use_ptemod is true because gntdev_put_map()
will unmap grant pages itself when use_ptemod is false.
Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/xen/gntdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -1077,8 +1077,10 @@ unlock_out:
out_unlock_put:
mutex_unlock(&priv->lock);
out_put_map:
- if (use_ptemod)
+ if (use_ptemod) {
map->vma = NULL;
+ unmap_grant_pages(map, 0, map->count);
+ }
gntdev_put_map(priv, map);
return err;
}
Patches currently in stable-queue which might be from ross.lagerwall(a)citrix.com are
queue-4.9/xen-gntdev-fix-off-by-one-error-when-unmapping-with-holes.patch
queue-4.9/xen-gntdev-fix-partial-gntdev_mmap-cleanup.patch
This is a note to let you know that I've just added the patch titled
xen/gntdev: Fix off-by-one error when unmapping with holes
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:
xen-gntdev-fix-off-by-one-error-when-unmapping-with-holes.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 Wed Feb 28 16:13:29 CET 2018
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Date: Tue, 9 Jan 2018 12:10:21 +0000
Subject: xen/gntdev: Fix off-by-one error when unmapping with holes
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
[ Upstream commit 951a010233625b77cde3430b4b8785a9a22968d1 ]
If the requested range has a hole, the calculation of the number of
pages to unmap is off by one. Fix it.
Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/xen/gntdev.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -378,10 +378,8 @@ static int unmap_grant_pages(struct gran
}
range = 0;
while (range < pages) {
- if (map->unmap_ops[offset+range].handle == -1) {
- range--;
+ if (map->unmap_ops[offset+range].handle == -1)
break;
- }
range++;
}
err = __unmap_grant_pages(map, offset, range);
Patches currently in stable-queue which might be from ross.lagerwall(a)citrix.com are
queue-4.9/xen-gntdev-fix-off-by-one-error-when-unmapping-with-holes.patch
queue-4.9/xen-gntdev-fix-partial-gntdev_mmap-cleanup.patch
This is a note to let you know that I've just added the patch titled
x86/asm: Allow again using asm.h when building for the 'bpf' clang target
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:
x86-asm-allow-again-using-asm.h-when-building-for-the-bpf-clang-target.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 Wed Feb 28 16:13:29 CET 2018
From: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Date: Mon, 4 Dec 2017 13:08:47 -0300
Subject: x86/asm: Allow again using asm.h when building for the 'bpf' clang target
From: Arnaldo Carvalho de Melo <acme(a)redhat.com>
[ Upstream commit ca26cffa4e4aaeb09bb9e308f95c7835cb149248 ]
Up to f5caf621ee35 ("x86/asm: Fix inline asm call constraints for Clang")
we were able to use x86 headers to build to the 'bpf' clang target, as
done by the BPF code in tools/perf/.
With that commit, we ended up with following failure for 'perf test LLVM', this
is because "clang ... -target bpf ..." fails since 4.0 does not have bpf inline
asm support and 6.0 does not recognize the register 'esp', fix it by guarding
that part with an #ifndef __BPF__, that is defined by clang when building to
the "bpf" target.
# perf test -v LLVM
37: LLVM search and compile :
37.1: Basic BPF llvm compile :
--- start ---
test child forked, pid 25526
Kernel build dir is set to /lib/modules/4.14.0+/build
set env: KBUILD_DIR=/lib/modules/4.14.0+/build
unset env: KBUILD_OPTS
include option is set to -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include -I/home/acme/git/linux/arch/x86/include -I./arch/x86/include/generated -I/home/acme/git/linux/include -I./include -I/home/acme/git/linux/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/home/acme/git/linux/include/uapi -I./include/generated/uapi -include /home/acme/git/linux/include/linux/kconfig.h
set env: NR_CPUS=4
set env: LINUX_VERSION_CODE=0x40e00
set env: CLANG_EXEC=/usr/local/bin/clang
set env: CLANG_OPTIONS=-xc
set env: KERNEL_INC_OPTIONS= -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include -I/home/acme/git/linux/arch/x86/include -I./arch/x86/include/generated -I/home/acme/git/linux/include -I./include -I/home/acme/git/linux/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/home/acme/git/linux/include/uapi -I./include/generated/uapi -include /home/acme/git/linux/include/linux/kconfig.h
set env: WORKING_DIR=/lib/modules/4.14.0+/build
set env: CLANG_SOURCE=-
llvm compiling command template: echo '/*
* bpf-script-example.c
* Test basic LLVM building
*/
#ifndef LINUX_VERSION_CODE
# error Need LINUX_VERSION_CODE
# error Example: for 4.2 kernel, put 'clang-opt="-DLINUX_VERSION_CODE=0x40200" into llvm section of ~/.perfconfig'
#endif
#define BPF_ANY 0
#define BPF_MAP_TYPE_ARRAY 2
#define BPF_FUNC_map_lookup_elem 1
#define BPF_FUNC_map_update_elem 2
static void *(*bpf_map_lookup_elem)(void *map, void *key) =
(void *) BPF_FUNC_map_lookup_elem;
static void *(*bpf_map_update_elem)(void *map, void *key, void *value, int flags) =
(void *) BPF_FUNC_map_update_elem;
struct bpf_map_def {
unsigned int type;
unsigned int key_size;
unsigned int value_size;
unsigned int max_entries;
};
#define SEC(NAME) __attribute__((section(NAME), used))
struct bpf_map_def SEC("maps") flip_table = {
.type = BPF_MAP_TYPE_ARRAY,
.key_size = sizeof(int),
.value_size = sizeof(int),
.max_entries = 1,
};
SEC("func=SyS_epoll_wait")
int bpf_func__SyS_epoll_wait(void *ctx)
{
int ind =0;
int *flag = bpf_map_lookup_elem(&flip_table, &ind);
int new_flag;
if (!flag)
return 0;
/* flip flag and store back */
new_flag = !*flag;
bpf_map_update_elem(&flip_table, &ind, &new_flag, BPF_ANY);
return new_flag;
}
char _license[] SEC("license") = "GPL";
int _version SEC("version") = LINUX_VERSION_CODE;
' | $CLANG_EXEC -D__KERNEL__ -D__NR_CPUS__=$NR_CPUS -DLINUX_VERSION_CODE=$LINUX_VERSION_CODE $CLANG_OPTIONS $KERNEL_INC_OPTIONS -Wno-unused-value -Wno-pointer-sign -working-directory $WORKING_DIR -c "$CLANG_SOURCE" -target bpf -O2 -o -
test child finished with 0
---- end ----
LLVM search and compile subtest 0: Ok
37.2: kbuild searching :
--- start ---
test child forked, pid 25950
Kernel build dir is set to /lib/modules/4.14.0+/build
set env: KBUILD_DIR=/lib/modules/4.14.0+/build
unset env: KBUILD_OPTS
include option is set to -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include -I/home/acme/git/linux/arch/x86/include -I./arch/x86/include/generated -I/home/acme/git/linux/include -I./include -I/home/acme/git/linux/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/home/acme/git/linux/include/uapi -I./include/generated/uapi -include /home/acme/git/linux/include/linux/kconfig.h
set env: NR_CPUS=4
set env: LINUX_VERSION_CODE=0x40e00
set env: CLANG_EXEC=/usr/local/bin/clang
set env: CLANG_OPTIONS=-xc
set env: KERNEL_INC_OPTIONS= -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include -I/home/acme/git/linux/arch/x86/include -I./arch/x86/include/generated -I/home/acme/git/linux/include -I./include -I/home/acme/git/linux/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/home/acme/git/linux/include/uapi -I./include/generated/uapi -include /home/acme/git/linux/include/linux/kconfig.h
set env: WORKING_DIR=/lib/modules/4.14.0+/build
set env: CLANG_SOURCE=-
llvm compiling command template: echo '/*
* bpf-script-test-kbuild.c
* Test include from kernel header
*/
#ifndef LINUX_VERSION_CODE
# error Need LINUX_VERSION_CODE
# error Example: for 4.2 kernel, put 'clang-opt="-DLINUX_VERSION_CODE=0x40200" into llvm section of ~/.perfconfig'
#endif
#define SEC(NAME) __attribute__((section(NAME), used))
#include <uapi/linux/fs.h>
#include <uapi/asm/ptrace.h>
SEC("func=vfs_llseek")
int bpf_func__vfs_llseek(void *ctx)
{
return 0;
}
char _license[] SEC("license") = "GPL";
int _version SEC("version") = LINUX_VERSION_CODE;
' | $CLANG_EXEC -D__KERNEL__ -D__NR_CPUS__=$NR_CPUS -DLINUX_VERSION_CODE=$LINUX_VERSION_CODE $CLANG_OPTIONS $KERNEL_INC_OPTIONS -Wno-unused-value -Wno-pointer-sign -working-directory $WORKING_DIR -c "$CLANG_SOURCE" -target bpf -O2 -o -
In file included from <stdin>:12:
In file included from /home/acme/git/linux/arch/x86/include/uapi/asm/ptrace.h:5:
In file included from /home/acme/git/linux/include/linux/compiler.h:242:
In file included from /home/acme/git/linux/arch/x86/include/asm/barrier.h:5:
In file included from /home/acme/git/linux/arch/x86/include/asm/alternative.h:10:
/home/acme/git/linux/arch/x86/include/asm/asm.h:145:50: error: unknown register name 'esp' in asm
register unsigned long current_stack_pointer asm(_ASM_SP);
^
/home/acme/git/linux/arch/x86/include/asm/asm.h:44:18: note: expanded from macro '_ASM_SP'
#define _ASM_SP __ASM_REG(sp)
^
/home/acme/git/linux/arch/x86/include/asm/asm.h:27:32: note: expanded from macro '__ASM_REG'
#define __ASM_REG(reg) __ASM_SEL_RAW(e##reg, r##reg)
^
/home/acme/git/linux/arch/x86/include/asm/asm.h:18:29: note: expanded from macro '__ASM_SEL_RAW'
# define __ASM_SEL_RAW(a,b) __ASM_FORM_RAW(a)
^
/home/acme/git/linux/arch/x86/include/asm/asm.h:11:32: note: expanded from macro '__ASM_FORM_RAW'
# define __ASM_FORM_RAW(x) #x
^
<scratch space>:4:1: note: expanded from here
"esp"
^
1 error generated.
ERROR: unable to compile -
Hint: Check error message shown above.
Hint: You can also pre-compile it into .o using:
clang -target bpf -O2 -c -
with proper -I and -D options.
Failed to compile test case: 'kbuild searching'
test child finished with -1
---- end ----
LLVM search and compile subtest 1: FAILED!
Cc: Adrian Hunter <adrian.hunter(a)intel.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Alexei Starovoitov <alexei.starovoitov(a)gmail.com>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: Daniel Borkmann <daniel(a)iogearbox.net>
Cc: David Ahern <dsahern(a)gmail.com>
Cc: Dmitriy Vyukov <dvyukov(a)google.com>
Cc: Jiri Olsa <jolsa(a)kernel.org>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Cc: Miguel Bernal Marin <miguel.bernal.marin(a)linux.intel.com>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Wang Nan <wangnan0(a)huawei.com>
Cc: Yonghong Song <yhs(a)fb.com>
Link: https://lkml.kernel.org/r/20171128175948.GL3298@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/asm.h | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -128,6 +128,7 @@
#endif
#ifndef __ASSEMBLY__
+#ifndef __BPF__
/*
* This output constraint should be used for any inline asm which has a "call"
* instruction. Otherwise the asm may be inserted before the frame pointer
@@ -137,5 +138,6 @@
register unsigned long current_stack_pointer asm(_ASM_SP);
#define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer)
#endif
+#endif
#endif /* _ASM_X86_ASM_H */
Patches currently in stable-queue which might be from acme(a)redhat.com are
queue-4.9/x86-asm-allow-again-using-asm.h-when-building-for-the-bpf-clang-target.patch
This is a note to let you know that I've just added the patch titled
uapi libc compat: add fallback for unsupported libcs
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:
uapi-libc-compat-add-fallback-for-unsupported-libcs.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 Wed Feb 28 16:13:29 CET 2018
From: Felix Janda <felix.janda(a)posteo.de>
Date: Mon, 1 Jan 2018 19:33:20 +0100
Subject: uapi libc compat: add fallback for unsupported libcs
From: Felix Janda <felix.janda(a)posteo.de>
[ Upstream commit c0bace798436bca0fdc221ff61143f1376a9c3de ]
libc-compat.h aims to prevent symbol collisions between uapi and libc
headers for each supported libc. This requires continuous coordination
between them.
The goal of this commit is to improve the situation for libcs (such as
musl) which are not yet supported and/or do not wish to be explicitly
supported, while not affecting supported libcs. More precisely, with
this commit, unsupported libcs can request the suppression of any
specific uapi definition by defining the correspondings _UAPI_DEF_*
macro as 0. This can fix symbol collisions for them, as long as the
libc headers are included before the uapi headers. Inclusion in the
other order is outside the scope of this commit.
All infrastructure in order to enable this fallback for unsupported
libcs is already in place, except that libc-compat.h unconditionally
defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
any previous definitions are ignored. In order to fix this, this commit
merely makes these definitions conditional.
This commit together with the musl libc commit
http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964f…
fixes for example the following compiler errors when <linux/in6.h> is
included after musl's <netinet/in.h>:
./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
The comments referencing glibc are still correct, but this file is not
only used for glibc any more.
Signed-off-by: Felix Janda <felix.janda(a)posteo.de>
Reviewed-by: Hauke Mehrtens <hauke(a)hauke-m.de>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/uapi/linux/libc-compat.h | 55 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 54 insertions(+), 1 deletion(-)
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -167,46 +167,99 @@
/* If we did not see any headers from any supported C libraries,
* or we are being included in the kernel, then define everything
- * that we need. */
+ * that we need. Check for previous __UAPI_* definitions to give
+ * unsupported C libraries a way to opt out of any kernel definition. */
#else /* !defined(__GLIBC__) */
/* Definitions for if.h */
+#ifndef __UAPI_DEF_IF_IFCONF
#define __UAPI_DEF_IF_IFCONF 1
+#endif
+#ifndef __UAPI_DEF_IF_IFMAP
#define __UAPI_DEF_IF_IFMAP 1
+#endif
+#ifndef __UAPI_DEF_IF_IFNAMSIZ
#define __UAPI_DEF_IF_IFNAMSIZ 1
+#endif
+#ifndef __UAPI_DEF_IF_IFREQ
#define __UAPI_DEF_IF_IFREQ 1
+#endif
/* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
+#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS
#define __UAPI_DEF_IF_NET_DEVICE_FLAGS 1
+#endif
/* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
+#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
#define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
+#endif
/* Definitions for in.h */
+#ifndef __UAPI_DEF_IN_ADDR
#define __UAPI_DEF_IN_ADDR 1
+#endif
+#ifndef __UAPI_DEF_IN_IPPROTO
#define __UAPI_DEF_IN_IPPROTO 1
+#endif
+#ifndef __UAPI_DEF_IN_PKTINFO
#define __UAPI_DEF_IN_PKTINFO 1
+#endif
+#ifndef __UAPI_DEF_IP_MREQ
#define __UAPI_DEF_IP_MREQ 1
+#endif
+#ifndef __UAPI_DEF_SOCKADDR_IN
#define __UAPI_DEF_SOCKADDR_IN 1
+#endif
+#ifndef __UAPI_DEF_IN_CLASS
#define __UAPI_DEF_IN_CLASS 1
+#endif
/* Definitions for in6.h */
+#ifndef __UAPI_DEF_IN6_ADDR
#define __UAPI_DEF_IN6_ADDR 1
+#endif
+#ifndef __UAPI_DEF_IN6_ADDR_ALT
#define __UAPI_DEF_IN6_ADDR_ALT 1
+#endif
+#ifndef __UAPI_DEF_SOCKADDR_IN6
#define __UAPI_DEF_SOCKADDR_IN6 1
+#endif
+#ifndef __UAPI_DEF_IPV6_MREQ
#define __UAPI_DEF_IPV6_MREQ 1
+#endif
+#ifndef __UAPI_DEF_IPPROTO_V6
#define __UAPI_DEF_IPPROTO_V6 1
+#endif
+#ifndef __UAPI_DEF_IPV6_OPTIONS
#define __UAPI_DEF_IPV6_OPTIONS 1
+#endif
+#ifndef __UAPI_DEF_IN6_PKTINFO
#define __UAPI_DEF_IN6_PKTINFO 1
+#endif
+#ifndef __UAPI_DEF_IP6_MTUINFO
#define __UAPI_DEF_IP6_MTUINFO 1
+#endif
/* Definitions for ipx.h */
+#ifndef __UAPI_DEF_SOCKADDR_IPX
#define __UAPI_DEF_SOCKADDR_IPX 1
+#endif
+#ifndef __UAPI_DEF_IPX_ROUTE_DEFINITION
#define __UAPI_DEF_IPX_ROUTE_DEFINITION 1
+#endif
+#ifndef __UAPI_DEF_IPX_INTERFACE_DEFINITION
#define __UAPI_DEF_IPX_INTERFACE_DEFINITION 1
+#endif
+#ifndef __UAPI_DEF_IPX_CONFIG_DATA
#define __UAPI_DEF_IPX_CONFIG_DATA 1
+#endif
+#ifndef __UAPI_DEF_IPX_ROUTE_DEF
#define __UAPI_DEF_IPX_ROUTE_DEF 1
+#endif
/* Definitions for xattr.h */
+#ifndef __UAPI_DEF_XATTR
#define __UAPI_DEF_XATTR 1
+#endif
#endif /* __GLIBC__ */
Patches currently in stable-queue which might be from felix.janda(a)posteo.de are
queue-4.9/uapi-libc-compat-add-fallback-for-unsupported-libcs.patch
This is a note to let you know that I've just added the patch titled
tipc: error path leak fixes in tipc_enable_bearer()
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:
tipc-error-path-leak-fixes-in-tipc_enable_bearer.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 Wed Feb 28 16:13:29 CET 2018
From: Tommi Rantala <tommi.t.rantala(a)nokia.com>
Date: Fri, 22 Dec 2017 09:35:16 +0200
Subject: tipc: error path leak fixes in tipc_enable_bearer()
From: Tommi Rantala <tommi.t.rantala(a)nokia.com>
[ Upstream commit 19142551b2be4a9e13838099fde1351386e5e007 ]
Fix memory leak in tipc_enable_bearer() if enable_media() fails, and
cleanup with bearer_disable() if tipc_mon_create() fails.
Acked-by: Ying Xue <ying.xue(a)windriver.com>
Acked-by: Jon Maloy <jon.maloy(a)ericsson.com>
Signed-off-by: Tommi Rantala <tommi.t.rantala(a)nokia.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/tipc/bearer.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/net/tipc/bearer.c
+++ b/net/tipc/bearer.c
@@ -322,6 +322,7 @@ restart:
if (res) {
pr_warn("Bearer <%s> rejected, enable failure (%d)\n",
name, -res);
+ kfree(b);
return -EINVAL;
}
@@ -345,8 +346,10 @@ restart:
if (skb)
tipc_bearer_xmit_skb(net, bearer_id, skb, &b->bcast_addr);
- if (tipc_mon_create(net, bearer_id))
+ if (tipc_mon_create(net, bearer_id)) {
+ bearer_disable(net, b);
return -ENOMEM;
+ }
pr_info("Enabled bearer <%s>, discovery domain %s, priority %u\n",
name,
Patches currently in stable-queue which might be from tommi.t.rantala(a)nokia.com are
queue-4.9/tipc-error-path-leak-fixes-in-tipc_enable_bearer.patch
queue-4.9/tipc-fix-tipc_mon_delete-oops-in-tipc_enable_bearer-error-path.patch
This is a note to let you know that I've just added the patch titled
tg3: Enable PHY reset in MTU change path for 5720
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:
tg3-enable-phy-reset-in-mtu-change-path-for-5720.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 Wed Feb 28 16:13:29 CET 2018
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Date: Fri, 22 Dec 2017 16:05:29 +0530
Subject: tg3: Enable PHY reset in MTU change path for 5720
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
[ Upstream commit e60ee41aaf898584205a6af5c996860d0fe6a836 ]
A customer noticed RX path hang when MTU is changed on the fly while
running heavy traffic with NCSI enabled for 5717 and 5719. Since 5720
belongs to same ASIC family, we observed same issue and same fix
could solve this problem for 5720.
Signed-off-by: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/tg3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -14238,7 +14238,8 @@ static int tg3_change_mtu(struct net_dev
*/
if (tg3_asic_rev(tp) == ASIC_REV_57766 ||
tg3_asic_rev(tp) == ASIC_REV_5717 ||
- tg3_asic_rev(tp) == ASIC_REV_5719)
+ tg3_asic_rev(tp) == ASIC_REV_5719 ||
+ tg3_asic_rev(tp) == ASIC_REV_5720)
reset_phy = true;
err = tg3_restart_hw(tp, reset_phy);
Patches currently in stable-queue which might be from siva.kallam(a)broadcom.com are
queue-4.9/tg3-enable-phy-reset-in-mtu-change-path-for-5720.patch
queue-4.9/tg3-add-workaround-to-restrict-5762-mrrs-to-2048.patch
This is a note to let you know that I've just added the patch titled
tg3: Add workaround to restrict 5762 MRRS to 2048
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:
tg3-add-workaround-to-restrict-5762-mrrs-to-2048.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 Wed Feb 28 16:13:29 CET 2018
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Date: Fri, 22 Dec 2017 16:05:28 +0530
Subject: tg3: Add workaround to restrict 5762 MRRS to 2048
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
[ Upstream commit 4419bb1cedcda0272e1dc410345c5a1d1da0e367 ]
One of AMD based server with 5762 hangs with jumbo frame traffic.
This AMD platform has southbridge limitation which is restricting MRRS
to 4000. As a work around, driver to restricts the MRRS to 2048 for
this particular 5762 NX1 card.
Signed-off-by: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/tg3.c | 10 ++++++++++
drivers/net/ethernet/broadcom/tg3.h | 4 ++++
2 files changed, 14 insertions(+)
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -10049,6 +10049,16 @@ static int tg3_reset_hw(struct tg3 *tp,
tw32(GRC_MODE, tp->grc_mode | val);
+ /* On one of the AMD platform, MRRS is restricted to 4000 because of
+ * south bridge limitation. As a workaround, Driver is setting MRRS
+ * to 2048 instead of default 4096.
+ */
+ if (tp->pdev->subsystem_vendor == PCI_VENDOR_ID_DELL &&
+ tp->pdev->subsystem_device == TG3PCI_SUBDEVICE_ID_DELL_5762) {
+ val = tr32(TG3PCI_DEV_STATUS_CTRL) & ~MAX_READ_REQ_MASK;
+ tw32(TG3PCI_DEV_STATUS_CTRL, val | MAX_READ_REQ_SIZE_2048);
+ }
+
/* Setup the timer prescalar register. Clock is always 66Mhz. */
val = tr32(GRC_MISC_CFG);
val &= ~0xff;
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -95,6 +95,7 @@
#define TG3PCI_SUBDEVICE_ID_DELL_JAGUAR 0x0106
#define TG3PCI_SUBDEVICE_ID_DELL_MERLOT 0x0109
#define TG3PCI_SUBDEVICE_ID_DELL_SLIM_MERLOT 0x010a
+#define TG3PCI_SUBDEVICE_ID_DELL_5762 0x07f0
#define TG3PCI_SUBVENDOR_ID_COMPAQ PCI_VENDOR_ID_COMPAQ
#define TG3PCI_SUBDEVICE_ID_COMPAQ_BANSHEE 0x007c
#define TG3PCI_SUBDEVICE_ID_COMPAQ_BANSHEE_2 0x009a
@@ -280,6 +281,9 @@
#define TG3PCI_STD_RING_PROD_IDX 0x00000098 /* 64-bit */
#define TG3PCI_RCV_RET_RING_CON_IDX 0x000000a0 /* 64-bit */
/* 0xa8 --> 0xb8 unused */
+#define TG3PCI_DEV_STATUS_CTRL 0x000000b4
+#define MAX_READ_REQ_SIZE_2048 0x00004000
+#define MAX_READ_REQ_MASK 0x00007000
#define TG3PCI_DUAL_MAC_CTRL 0x000000b8
#define DUAL_MAC_CTRL_CH_MASK 0x00000003
#define DUAL_MAC_CTRL_ID 0x00000004
Patches currently in stable-queue which might be from siva.kallam(a)broadcom.com are
queue-4.9/tg3-enable-phy-reset-in-mtu-change-path-for-5720.patch
queue-4.9/tg3-add-workaround-to-restrict-5762-mrrs-to-2048.patch
This is a note to let you know that I've just added the patch titled
spi: atmel: fixed spin_lock usage inside atmel_spi_remove
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:
spi-atmel-fixed-spin_lock-usage-inside-atmel_spi_remove.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 Wed Feb 28 16:13:29 CET 2018
From: Radu Pirea <radu.pirea(a)microchip.com>
Date: Fri, 15 Dec 2017 17:40:17 +0200
Subject: spi: atmel: fixed spin_lock usage inside atmel_spi_remove
From: Radu Pirea <radu.pirea(a)microchip.com>
[ Upstream commit 66e900a3d225575c8b48b59ae1fe74bb6e5a65cc ]
The only part of atmel_spi_remove which needs to be atomic is hardware
reset.
atmel_spi_stop_dma calls dma_terminate_all and this needs interrupts
enabled.
atmel_spi_release_dma calls dma_release_channel and dma_release_channel
locks a mutex inside of spin_lock.
So the call of these functions can't be inside a spin_lock.
Reported-by: Jia-Ju Bai <baijiaju1990(a)gmail.com>
Signed-off-by: Radu Pirea <radu.pirea(a)microchip.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/spi/spi-atmel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1669,12 +1669,12 @@ static int atmel_spi_remove(struct platf
pm_runtime_get_sync(&pdev->dev);
/* reset the hardware and block queue progress */
- spin_lock_irq(&as->lock);
if (as->use_dma) {
atmel_spi_stop_dma(as);
atmel_spi_release_dma(as);
}
+ spin_lock_irq(&as->lock);
spi_writel(as, CR, SPI_BIT(SWRST));
spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
spi_readl(as, SR);
Patches currently in stable-queue which might be from radu.pirea(a)microchip.com are
queue-4.9/spi-atmel-fixed-spin_lock-usage-inside-atmel_spi_remove.patch
This is a note to let you know that I've just added the patch titled
SolutionEngine771x: fix Ether platform data
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:
solutionengine771x-fix-ether-platform-data.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 Wed Feb 28 16:13:29 CET 2018
From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Date: Sat, 6 Jan 2018 21:53:26 +0300
Subject: SolutionEngine771x: fix Ether platform data
From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
[ Upstream commit 195e2addbce09e5afbc766efc1e6567c9ce840d3 ]
The 'sh_eth' driver's probe() method would fail on the SolutionEngine7710
board and crash on SolutionEngine7712 board as the platform code is
hopelessly behind the driver's platform data -- it passes the PHY address
instead of 'struct sh_eth_plat_data *'; pass the latter to the driver in
order to fix the bug...
Fixes: 71557a37adb5 ("[netdrvr] sh_eth: Add SH7619 support")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/sh/boards/mach-se/770x/setup.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/arch/sh/boards/mach-se/770x/setup.c
+++ b/arch/sh/boards/mach-se/770x/setup.c
@@ -8,6 +8,7 @@
*/
#include <linux/init.h>
#include <linux/platform_device.h>
+#include <linux/sh_eth.h>
#include <mach-se/mach/se.h>
#include <mach-se/mach/mrshpc.h>
#include <asm/machvec.h>
@@ -114,6 +115,11 @@ static struct platform_device heartbeat_
#if defined(CONFIG_CPU_SUBTYPE_SH7710) ||\
defined(CONFIG_CPU_SUBTYPE_SH7712)
/* SH771X Ethernet driver */
+static struct sh_eth_plat_data sh_eth_plat = {
+ .phy = PHY_ID,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+};
+
static struct resource sh_eth0_resources[] = {
[0] = {
.start = SH_ETH0_BASE,
@@ -131,7 +137,7 @@ static struct platform_device sh_eth0_de
.name = "sh771x-ether",
.id = 0,
.dev = {
- .platform_data = PHY_ID,
+ .platform_data = &sh_eth_plat,
},
.num_resources = ARRAY_SIZE(sh_eth0_resources),
.resource = sh_eth0_resources,
@@ -154,7 +160,7 @@ static struct platform_device sh_eth1_de
.name = "sh771x-ether",
.id = 1,
.dev = {
- .platform_data = PHY_ID,
+ .platform_data = &sh_eth_plat,
},
.num_resources = ARRAY_SIZE(sh_eth1_resources),
.resource = sh_eth1_resources,
Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are
queue-4.9/solutionengine771x-fix-ether-platform-data.patch
This is a note to let you know that I've just added the patch titled
sget(): handle failures of register_shrinker()
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:
sget-handle-failures-of-register_shrinker.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 Wed Feb 28 16:13:29 CET 2018
From: Al Viro <viro(a)zeniv.linux.org.uk>
Date: Mon, 18 Dec 2017 15:05:07 -0500
Subject: sget(): handle failures of register_shrinker()
From: Al Viro <viro(a)zeniv.linux.org.uk>
[ Upstream commit 9ee332d99e4d5a97548943b81c54668450ce641b ]
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/super.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/super.c
+++ b/fs/super.c
@@ -519,7 +519,11 @@ retry:
hlist_add_head(&s->s_instances, &type->fs_supers);
spin_unlock(&sb_lock);
get_filesystem(type);
- register_shrinker(&s->s_shrink);
+ err = register_shrinker(&s->s_shrink);
+ if (err) {
+ deactivate_locked_super(s);
+ s = ERR_PTR(err);
+ }
return s;
}
Patches currently in stable-queue which might be from viro(a)zeniv.linux.org.uk are
queue-4.9/sget-handle-failures-of-register_shrinker.patch
This is a note to let you know that I've just added the patch titled
sctp: make use of pre-calculated len
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:
sctp-make-use-of-pre-calculated-len.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 Wed Feb 28 16:13:29 CET 2018
From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Date: Mon, 8 Jan 2018 19:02:29 -0200
Subject: sctp: make use of pre-calculated len
From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
[ Upstream commit c76f97c99ae6d26d14c7f0e50e074382bfbc9f98 ]
Some sockopt handling functions were calculating the length of the
buffer to be written to userspace and then calculating it again when
actually writing the buffer, which could lead to some write not using
an up-to-date length.
This patch updates such places to just make use of the len variable.
Also, replace some sizeof(type) to sizeof(var).
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/socket.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4765,7 +4765,7 @@ static int sctp_getsockopt_autoclose(str
len = sizeof(int);
if (put_user(len, optlen))
return -EFAULT;
- if (copy_to_user(optval, &sctp_sk(sk)->autoclose, sizeof(int)))
+ if (copy_to_user(optval, &sctp_sk(sk)->autoclose, len))
return -EFAULT;
return 0;
}
@@ -5342,6 +5342,9 @@ copy_getaddrs:
err = -EFAULT;
goto out;
}
+ /* XXX: We should have accounted for sizeof(struct sctp_getaddrs) too,
+ * but we can't change it anymore.
+ */
if (put_user(bytes_copied, optlen))
err = -EFAULT;
out:
@@ -5778,7 +5781,7 @@ static int sctp_getsockopt_maxseg(struct
params.assoc_id = 0;
} else if (len >= sizeof(struct sctp_assoc_value)) {
len = sizeof(struct sctp_assoc_value);
- if (copy_from_user(¶ms, optval, sizeof(params)))
+ if (copy_from_user(¶ms, optval, len))
return -EFAULT;
} else
return -EINVAL;
@@ -5947,7 +5950,9 @@ static int sctp_getsockopt_active_key(st
if (len < sizeof(struct sctp_authkeyid))
return -EINVAL;
- if (copy_from_user(&val, optval, sizeof(struct sctp_authkeyid)))
+
+ len = sizeof(struct sctp_authkeyid);
+ if (copy_from_user(&val, optval, len))
return -EFAULT;
asoc = sctp_id2assoc(sk, val.scact_assoc_id);
@@ -5959,7 +5964,6 @@ static int sctp_getsockopt_active_key(st
else
val.scact_keynumber = ep->active_key_id;
- len = sizeof(struct sctp_authkeyid);
if (put_user(len, optlen))
return -EFAULT;
if (copy_to_user(optval, &val, len))
@@ -5985,7 +5989,7 @@ static int sctp_getsockopt_peer_auth_chu
if (len < sizeof(struct sctp_authchunks))
return -EINVAL;
- if (copy_from_user(&val, optval, sizeof(struct sctp_authchunks)))
+ if (copy_from_user(&val, optval, sizeof(val)))
return -EFAULT;
to = p->gauth_chunks;
@@ -6030,7 +6034,7 @@ static int sctp_getsockopt_local_auth_ch
if (len < sizeof(struct sctp_authchunks))
return -EINVAL;
- if (copy_from_user(&val, optval, sizeof(struct sctp_authchunks)))
+ if (copy_from_user(&val, optval, sizeof(val)))
return -EFAULT;
to = p->gauth_chunks;
Patches currently in stable-queue which might be from marcelo.leitner(a)gmail.com are
queue-4.9/sctp-make-use-of-pre-calculated-len.patch
This is a note to let you know that I've just added the patch titled
scsi: storvsc: Fix scsi_cmd error assignments in storvsc_handle_error
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:
scsi-storvsc-fix-scsi_cmd-error-assignments-in-storvsc_handle_error.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 Wed Feb 28 16:13:29 CET 2018
From: Cathy Avery <cavery(a)redhat.com>
Date: Tue, 19 Dec 2017 13:32:48 -0500
Subject: scsi: storvsc: Fix scsi_cmd error assignments in storvsc_handle_error
From: Cathy Avery <cavery(a)redhat.com>
[ Upstream commit d1b8b2391c24751e44f618fcf86fb55d9a9247fd ]
When an I/O is returned with an srb_status of SRB_STATUS_INVALID_LUN
which has zero good_bytes it must be assigned an error. Otherwise the
I/O will be continuously requeued and will cause a deadlock in the case
where disks are being hot added and removed. sd_probe_async will wait
forever for its I/O to complete while holding scsi_sd_probe_domain.
Also returning the default error of DID_TARGET_FAILURE causes multipath
to not retry the I/O resulting in applications receiving I/O errors
before a failover can occur.
Signed-off-by: Cathy Avery <cavery(a)redhat.com>
Signed-off-by: Long Li <longli(a)microsoft.com>
Reviewed-by: Stephen Hemminger <stephen(a)networkplumber.org>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/storvsc_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -915,10 +915,11 @@ static void storvsc_handle_error(struct
case TEST_UNIT_READY:
break;
default:
- set_host_byte(scmnd, DID_TARGET_FAILURE);
+ set_host_byte(scmnd, DID_ERROR);
}
break;
case SRB_STATUS_INVALID_LUN:
+ set_host_byte(scmnd, DID_NO_CONNECT);
do_work = true;
process_err_fn = storvsc_remove_lun;
break;
Patches currently in stable-queue which might be from cavery(a)redhat.com are
queue-4.9/scsi-storvsc-fix-scsi_cmd-error-assignments-in-storvsc_handle_error.patch
This is a note to let you know that I've just added the patch titled
s390/dasd: fix wrongly assigned configuration data
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:
s390-dasd-fix-wrongly-assigned-configuration-data.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 Wed Feb 28 16:13:29 CET 2018
From: Stefan Haberland <sth(a)linux.vnet.ibm.com>
Date: Wed, 6 Dec 2017 10:30:39 +0100
Subject: s390/dasd: fix wrongly assigned configuration data
From: Stefan Haberland <sth(a)linux.vnet.ibm.com>
[ Upstream commit 8a9bd4f8ebc6800bfc0596e28631ff6809a2f615 ]
We store per path and per device configuration data to identify the
path or device correctly. The per path configuration data might get
mixed up if the original request gets into error recovery and is
started with a random path mask.
This would lead to a wrong identification of a path in case of a CUIR
event for example.
Fix by copying the path mask from the original request to the error
recovery request in case it is a path verification request.
Signed-off-by: Stefan Haberland <sth(a)linux.vnet.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner(a)linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/block/dasd_3990_erp.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/s390/block/dasd_3990_erp.c
+++ b/drivers/s390/block/dasd_3990_erp.c
@@ -2755,6 +2755,16 @@ dasd_3990_erp_action(struct dasd_ccw_req
erp = dasd_3990_erp_handle_match_erp(cqr, erp);
}
+
+ /*
+ * For path verification work we need to stick with the path that was
+ * originally chosen so that the per path configuration data is
+ * assigned correctly.
+ */
+ if (test_bit(DASD_CQR_VERIFY_PATH, &erp->flags) && cqr->lpm) {
+ erp->lpm = cqr->lpm;
+ }
+
if (device->features & DASD_FEATURE_ERPLOG) {
/* print current erp_chain */
dev_err(&device->cdev->dev,
Patches currently in stable-queue which might be from sth(a)linux.vnet.ibm.com are
queue-4.9/s390-dasd-fix-wrongly-assigned-configuration-data.patch
This is a note to let you know that I've just added the patch titled
nvme: check hw sectors before setting chunk sectors
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:
nvme-check-hw-sectors-before-setting-chunk-sectors.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 Wed Feb 28 16:13:29 CET 2018
From: Keith Busch <keith.busch(a)intel.com>
Date: Thu, 14 Dec 2017 11:20:14 -0700
Subject: nvme: check hw sectors before setting chunk sectors
From: Keith Busch <keith.busch(a)intel.com>
[ Upstream commit 249159c5f15812140fa216f9997d799ac0023a1f ]
Some devices with IDs matching the "stripe" quirk don't actually have
this quirk, and don't have an MDTS value. When MDTS is not set, the
driver sets the max sectors to UINT_MAX, which is not a power of 2,
hitting a BUG_ON from blk_queue_chunk_sectors. This patch skips setting
chunk sectors for such devices.
Signed-off-by: Keith Busch <keith.busch(a)intel.com>
Reviewed-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nvme/host/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1204,7 +1204,8 @@ static void nvme_set_queue_limits(struct
blk_queue_max_hw_sectors(q, ctrl->max_hw_sectors);
blk_queue_max_segments(q, min_t(u32, max_segments, USHRT_MAX));
}
- if (ctrl->quirks & NVME_QUIRK_STRIPE_SIZE)
+ if ((ctrl->quirks & NVME_QUIRK_STRIPE_SIZE) &&
+ is_power_of_2(ctrl->max_hw_sectors))
blk_queue_chunk_sectors(q, ctrl->max_hw_sectors);
blk_queue_virt_boundary(q, ctrl->page_size - 1);
if (ctrl->vwc & NVME_CTRL_VWC_PRESENT)
Patches currently in stable-queue which might be from keith.busch(a)intel.com are
queue-4.9/nvme-check-hw-sectors-before-setting-chunk-sectors.patch
This is a note to let you know that I've just added the patch titled
nl80211: Check for the required netlink attribute presence
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:
nl80211-check-for-the-required-netlink-attribute-presence.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 Wed Feb 28 16:13:29 CET 2018
From: Hao Chen <flank3rsky(a)gmail.com>
Date: Wed, 3 Jan 2018 11:00:31 +0800
Subject: nl80211: Check for the required netlink attribute presence
From: Hao Chen <flank3rsky(a)gmail.com>
[ Upstream commit 3ea15452ee85754f70f3b9fa1f23165ef2e77ba7 ]
nl80211_nan_add_func() does not check if the required attribute
NL80211_NAN_FUNC_FOLLOW_UP_DEST is present when processing
NL80211_CMD_ADD_NAN_FUNCTION request. This request can be issued
by users with CAP_NET_ADMIN privilege and may result in NULL dereference
and a system crash. Add a check for the required attribute presence.
Signed-off-by: Hao Chen <flank3rsky(a)gmail.com>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/wireless/nl80211.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -10777,7 +10777,8 @@ static int nl80211_nan_add_func(struct s
break;
case NL80211_NAN_FUNC_FOLLOW_UP:
if (!tb[NL80211_NAN_FUNC_FOLLOW_UP_ID] ||
- !tb[NL80211_NAN_FUNC_FOLLOW_UP_REQ_ID]) {
+ !tb[NL80211_NAN_FUNC_FOLLOW_UP_REQ_ID] ||
+ !tb[NL80211_NAN_FUNC_FOLLOW_UP_DEST]) {
err = -EINVAL;
goto out;
}
Patches currently in stable-queue which might be from flank3rsky(a)gmail.com are
queue-4.9/nl80211-check-for-the-required-netlink-attribute-presence.patch
This is a note to let you know that I've just added the patch titled
net: usb: qmi_wwan: add Telit ME910 PID 0x1101 support
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-usb-qmi_wwan-add-telit-me910-pid-0x1101-support.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 Wed Feb 28 16:13:29 CET 2018
From: Daniele Palmas <dnlplm(a)gmail.com>
Date: Thu, 14 Dec 2017 16:56:14 +0100
Subject: net: usb: qmi_wwan: add Telit ME910 PID 0x1101 support
From: Daniele Palmas <dnlplm(a)gmail.com>
[ Upstream commit c647c0d62c82eb3ddf78a0d8b3d58819d9f552aa ]
This patch adds support for Telit ME910 PID 0x1101.
Signed-off-by: Daniele Palmas <dnlplm(a)gmail.com>
Acked-by: Bjørn Mork <bjorn(a)mork.no>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -914,6 +914,7 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x2357, 0x9000, 4)}, /* TP-LINK MA260 */
{QMI_QUIRK_SET_DTR(0x1bc7, 0x1040, 2)}, /* Telit LE922A */
{QMI_FIXED_INTF(0x1bc7, 0x1100, 3)}, /* Telit ME910 */
+ {QMI_FIXED_INTF(0x1bc7, 0x1101, 3)}, /* Telit ME910 dual modem */
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)}, /* Telit LE920 */
{QMI_FIXED_INTF(0x1bc7, 0x1201, 2)}, /* Telit LE920 */
{QMI_FIXED_INTF(0x1c9e, 0x9b01, 3)}, /* XS Stick W100-2 from 4G Systems */
Patches currently in stable-queue which might be from dnlplm(a)gmail.com are
queue-4.9/net-usb-qmi_wwan-add-telit-me910-pid-0x1101-support.patch
This is a note to let you know that I've just added the patch titled
NET: usb: qmi_wwan: add support for YUGA CLM920-NC5 PID 0x9625
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-usb-qmi_wwan-add-support-for-yuga-clm920-nc5-pid-0x9625.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 Wed Feb 28 16:13:29 CET 2018
From: "SZ Lin (林上智)" <sz.lin(a)moxa.com>
Date: Fri, 29 Dec 2017 17:02:17 +0800
Subject: NET: usb: qmi_wwan: add support for YUGA CLM920-NC5 PID 0x9625
From: "SZ Lin (林上智)" <sz.lin(a)moxa.com>
[ Upstream commit bd30ffc414e55194ed6149fad69a145550cb7c18 ]
This patch adds support for PID 0x9625 of YUGA CLM920-NC5.
YUGA CLM920-NC5 needs to enable QMI_WWAN_QUIRK_DTR before QMI operation.
qmicli -d /dev/cdc-wdm0 -p --dms-get-revision
[/dev/cdc-wdm0] Device revision retrieved:
Revision: 'CLM920_NC5-V1 1 [Oct 23 2016 19:00:00]'
Signed-off-by: SZ Lin (林上智) <sz.lin(a)moxa.com>
Acked-by: Bjørn Mork <bjorn(a)mork.no>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -805,6 +805,7 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x05c6, 0x9084, 4)},
{QMI_FIXED_INTF(0x05c6, 0x920d, 0)},
{QMI_FIXED_INTF(0x05c6, 0x920d, 5)},
+ {QMI_QUIRK_SET_DTR(0x05c6, 0x9625, 4)}, /* YUGA CLM920-NC5 */
{QMI_FIXED_INTF(0x0846, 0x68a2, 8)},
{QMI_FIXED_INTF(0x12d1, 0x140c, 1)}, /* Huawei E173 */
{QMI_FIXED_INTF(0x12d1, 0x14ac, 1)}, /* Huawei E1820 */
Patches currently in stable-queue which might be from sz.lin(a)moxa.com are
queue-4.9/net-usb-qmi_wwan-add-support-for-yuga-clm920-nc5-pid-0x9625.patch
This is a note to let you know that I've just added the patch titled
net: stmmac: Fix TX timestamp calculation
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-stmmac-fix-tx-timestamp-calculation.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 Wed Feb 28 16:13:29 CET 2018
From: Fredrik Hallenberg <megahallon(a)gmail.com>
Date: Mon, 18 Dec 2017 23:33:59 +0100
Subject: net: stmmac: Fix TX timestamp calculation
From: Fredrik Hallenberg <megahallon(a)gmail.com>
[ Upstream commit 200922c93f008e03ddc804c6dacdf26ca1ba86d7 ]
When using GMAC4 the value written in PTP_SSIR should be shifted however
the shifted value is also used in subsequent calculations which results
in a bad timestamp value.
Signed-off-by: Fredrik Hallenberg <megahallon(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -38,6 +38,7 @@ static u32 stmmac_config_sub_second_incr
{
u32 value = readl(ioaddr + PTP_TCR);
unsigned long data;
+ u32 reg_value;
/* For GMAC3.x, 4.x versions, convert the ptp_clock to nano second
* formula = (1/ptp_clock) * 1000000000
@@ -54,10 +55,11 @@ static u32 stmmac_config_sub_second_incr
data &= PTP_SSIR_SSINC_MASK;
+ reg_value = data;
if (gmac4)
- data = data << GMAC4_PTP_SSIR_SSINC_SHIFT;
+ reg_value <<= GMAC4_PTP_SSIR_SSINC_SHIFT;
- writel(data, ioaddr + PTP_SSIR);
+ writel(reg_value, ioaddr + PTP_SSIR);
return data;
}
Patches currently in stable-queue which might be from megahallon(a)gmail.com are
queue-4.9/net-stmmac-fix-tx-timestamp-calculation.patch
This is a note to let you know that I've just added the patch titled
net: phy: xgene: disable clk on error paths
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-phy-xgene-disable-clk-on-error-paths.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 Wed Feb 28 16:13:29 CET 2018
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Date: Sat, 16 Dec 2017 00:52:39 +0300
Subject: net: phy: xgene: disable clk on error paths
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
[ Upstream commit ab14436065c8066c265540312742390d6d07ddd2 ]
There are several error paths in xgene_mdio_probe(),
where clk is left undisabled. The patch fixes them.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/phy/mdio-xgene.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
--- a/drivers/net/phy/mdio-xgene.c
+++ b/drivers/net/phy/mdio-xgene.c
@@ -197,8 +197,11 @@ static int xgene_mdio_reset(struct xgene
}
ret = xgene_enet_ecc_init(pdata);
- if (ret)
+ if (ret) {
+ if (pdata->dev->of_node)
+ clk_disable_unprepare(pdata->clk);
return ret;
+ }
xgene_gmac_reset(pdata);
return 0;
@@ -364,8 +367,10 @@ static int xgene_mdio_probe(struct platf
return ret;
mdio_bus = mdiobus_alloc();
- if (!mdio_bus)
- return -ENOMEM;
+ if (!mdio_bus) {
+ ret = -ENOMEM;
+ goto out_clk;
+ }
mdio_bus->name = "APM X-Gene MDIO bus";
@@ -394,7 +399,7 @@ static int xgene_mdio_probe(struct platf
mdio_bus->phy_mask = ~0;
ret = mdiobus_register(mdio_bus);
if (ret)
- goto out;
+ goto out_mdiobus;
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_HANDLE(dev), 1,
acpi_register_phy, NULL, mdio_bus, NULL);
@@ -402,16 +407,20 @@ static int xgene_mdio_probe(struct platf
}
if (ret)
- goto out;
+ goto out_mdiobus;
pdata->mdio_bus = mdio_bus;
xgene_mdio_status = true;
return 0;
-out:
+out_mdiobus:
mdiobus_free(mdio_bus);
+out_clk:
+ if (dev->of_node)
+ clk_disable_unprepare(pdata->clk);
+
return ret;
}
Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are
queue-4.9/net-phy-xgene-disable-clk-on-error-paths.patch
This is a note to let you know that I've just added the patch titled
net: mediatek: setup proper state for disabled GMAC on the default
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-mediatek-setup-proper-state-for-disabled-gmac-on-the-default.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 Wed Feb 28 16:13:29 CET 2018
From: Sean Wang <sean.wang(a)mediatek.com>
Date: Mon, 18 Dec 2017 17:00:17 +0800
Subject: net: mediatek: setup proper state for disabled GMAC on the default
From: Sean Wang <sean.wang(a)mediatek.com>
[ Upstream commit 7352e252b5bf40d59342494a70354a2d436fd0cd ]
The current solution would setup fixed and force link of 1Gbps to the both
GMAC on the default. However, The GMAC should always be put to link down
state when the GMAC is disabled on certain target boards. Otherwise,
the driver possibly receives unexpected data from the floating hardware
connection through the unused GMAC. Although the driver had been added
certain protection in RX path to get rid of such kind of unexpected data
sent to the upper stack.
Signed-off-by: Sean Wang <sean.wang(a)mediatek.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1842,11 +1842,12 @@ static int mtk_hw_init(struct mtk_eth *e
/* set GE2 TUNE */
regmap_write(eth->pctl, GPIO_BIAS_CTRL, 0x0);
- /* GE1, Force 1000M/FD, FC ON */
- mtk_w32(eth, MAC_MCR_FIXED_LINK, MTK_MAC_MCR(0));
-
- /* GE2, Force 1000M/FD, FC ON */
- mtk_w32(eth, MAC_MCR_FIXED_LINK, MTK_MAC_MCR(1));
+ /* Set linkdown as the default for each GMAC. Its own MCR would be set
+ * up with the more appropriate value when mtk_phy_link_adjust call is
+ * being invoked.
+ */
+ for (i = 0; i < MTK_MAC_COUNT; i++)
+ mtk_w32(eth, 0, MTK_MAC_MCR(i));
/* Enable RX VLan Offloading */
mtk_w32(eth, 1, MTK_CDMP_EG_CTRL);
Patches currently in stable-queue which might be from sean.wang(a)mediatek.com are
queue-4.9/net-mediatek-setup-proper-state-for-disabled-gmac-on-the-default.patch
This is a note to let you know that I've just added the patch titled
net: gianfar_ptp: move set_fipers() to spinlock protecting area
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-gianfar_ptp-move-set_fipers-to-spinlock-protecting-area.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 Wed Feb 28 16:13:29 CET 2018
From: Yangbo Lu <yangbo.lu(a)nxp.com>
Date: Tue, 9 Jan 2018 11:02:33 +0800
Subject: net: gianfar_ptp: move set_fipers() to spinlock protecting area
From: Yangbo Lu <yangbo.lu(a)nxp.com>
[ Upstream commit 11d827a993a969c3c6ec56758ff63a44ba19b466 ]
set_fipers() calling should be protected by spinlock in
case that any interrupt breaks related registers setting
and the function we expect. This patch is to move set_fipers()
to spinlock protecting area in ptp_gianfar_adjtime().
Signed-off-by: Yangbo Lu <yangbo.lu(a)nxp.com>
Acked-by: Richard Cochran <richardcochran(a)gmail.com>
Reviewed-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/freescale/gianfar_ptp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/net/ethernet/freescale/gianfar_ptp.c
+++ b/drivers/net/ethernet/freescale/gianfar_ptp.c
@@ -314,11 +314,10 @@ static int ptp_gianfar_adjtime(struct pt
now = tmr_cnt_read(etsects);
now += delta;
tmr_cnt_write(etsects, now);
+ set_fipers(etsects);
spin_unlock_irqrestore(&etsects->lock, flags);
- set_fipers(etsects);
-
return 0;
}
Patches currently in stable-queue which might be from yangbo.lu(a)nxp.com are
queue-4.9/net-gianfar_ptp-move-set_fipers-to-spinlock-protecting-area.patch
This is a note to let you know that I've just added the patch titled
net: arc_emac: fix arc_emac_rx() error paths
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-arc_emac-fix-arc_emac_rx-error-paths.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 Wed Feb 28 16:13:29 CET 2018
From: Alexander Kochetkov <al.kochet(a)gmail.com>
Date: Fri, 15 Dec 2017 20:20:06 +0300
Subject: net: arc_emac: fix arc_emac_rx() error paths
From: Alexander Kochetkov <al.kochet(a)gmail.com>
[ Upstream commit e688822d035b494071ecbadcccbd6f3325fb0f59 ]
arc_emac_rx() has some issues found by code review.
In case netdev_alloc_skb_ip_align() or dma_map_single() failure
rx fifo entry will not be returned to EMAC.
In case dma_map_single() failure previously allocated skb became
lost to driver. At the same time address of newly allocated skb
will not be provided to EMAC.
Signed-off-by: Alexander Kochetkov <al.kochet(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/arc/emac_main.c | 53 ++++++++++++++++++++---------------
1 file changed, 31 insertions(+), 22 deletions(-)
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -210,39 +210,48 @@ static int arc_emac_rx(struct net_device
continue;
}
- pktlen = info & LEN_MASK;
- stats->rx_packets++;
- stats->rx_bytes += pktlen;
- skb = rx_buff->skb;
- skb_put(skb, pktlen);
- skb->dev = ndev;
- skb->protocol = eth_type_trans(skb, ndev);
-
- dma_unmap_single(&ndev->dev, dma_unmap_addr(rx_buff, addr),
- dma_unmap_len(rx_buff, len), DMA_FROM_DEVICE);
-
- /* Prepare the BD for next cycle */
- rx_buff->skb = netdev_alloc_skb_ip_align(ndev,
- EMAC_BUFFER_SIZE);
- if (unlikely(!rx_buff->skb)) {
+ /* Prepare the BD for next cycle. netif_receive_skb()
+ * only if new skb was allocated and mapped to avoid holes
+ * in the RX fifo.
+ */
+ skb = netdev_alloc_skb_ip_align(ndev, EMAC_BUFFER_SIZE);
+ if (unlikely(!skb)) {
+ if (net_ratelimit())
+ netdev_err(ndev, "cannot allocate skb\n");
+ /* Return ownership to EMAC */
+ rxbd->info = cpu_to_le32(FOR_EMAC | EMAC_BUFFER_SIZE);
stats->rx_errors++;
- /* Because receive_skb is below, increment rx_dropped */
stats->rx_dropped++;
continue;
}
- /* receive_skb only if new skb was allocated to avoid holes */
- netif_receive_skb(skb);
-
- addr = dma_map_single(&ndev->dev, (void *)rx_buff->skb->data,
+ addr = dma_map_single(&ndev->dev, (void *)skb->data,
EMAC_BUFFER_SIZE, DMA_FROM_DEVICE);
if (dma_mapping_error(&ndev->dev, addr)) {
if (net_ratelimit())
- netdev_err(ndev, "cannot dma map\n");
- dev_kfree_skb(rx_buff->skb);
+ netdev_err(ndev, "cannot map dma buffer\n");
+ dev_kfree_skb(skb);
+ /* Return ownership to EMAC */
+ rxbd->info = cpu_to_le32(FOR_EMAC | EMAC_BUFFER_SIZE);
stats->rx_errors++;
+ stats->rx_dropped++;
continue;
}
+
+ /* unmap previosly mapped skb */
+ dma_unmap_single(&ndev->dev, dma_unmap_addr(rx_buff, addr),
+ dma_unmap_len(rx_buff, len), DMA_FROM_DEVICE);
+
+ pktlen = info & LEN_MASK;
+ stats->rx_packets++;
+ stats->rx_bytes += pktlen;
+ skb_put(rx_buff->skb, pktlen);
+ rx_buff->skb->dev = ndev;
+ rx_buff->skb->protocol = eth_type_trans(rx_buff->skb, ndev);
+
+ netif_receive_skb(rx_buff->skb);
+
+ rx_buff->skb = skb;
dma_unmap_addr_set(rx_buff, addr, addr);
dma_unmap_len_set(rx_buff, len, EMAC_BUFFER_SIZE);
Patches currently in stable-queue which might be from al.kochet(a)gmail.com are
queue-4.9/net-arc_emac-fix-arc_emac_rx-error-paths.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM
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:
mtd-nand-gpmi-fix-failure-when-a-erased-page-has-a-bitflip-at-bbm.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 Wed Feb 28 16:13:29 CET 2018
From: Sascha Hauer <s.hauer(a)pengutronix.de>
Date: Tue, 5 Dec 2017 11:51:40 +0100
Subject: mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM
From: Sascha Hauer <s.hauer(a)pengutronix.de>
[ Upstream commit fdf2e821052958a114618a95ab18a300d0b080cb ]
When erased subpages are read then the BCH decoder returns STATUS_ERASED
if they are all empty, or STATUS_UNCORRECTABLE if there are bitflips.
When there are bitflips, we have to set these bits again to show the
upper layers a completely erased page. When a bitflip happens in the
exact byte where the bad block marker is, then this byte is swapped
with another byte in block_mark_swapping(). The correction code then
detects a bitflip in another subpage and no longer corrects the bitflip
where it really happens.
Correct this behaviour by calling block_mark_swapping() after the
bitflips have been corrected.
In our case UBIFS failed with this bug because it expects erased
pages to be really empty:
UBIFS error (pid 187): ubifs_scan: corrupt empty space at LEB 36:118735
UBIFS error (pid 187): ubifs_scanned_corruption: corruption at LEB 36:118735
UBIFS error (pid 187): ubifs_scanned_corruption: first 8192 bytes from LEB 36:118735
UBIFS error (pid 187): ubifs_scan: LEB 36 scanning failed
UBIFS error (pid 187): do_commit: commit failed, error -117
Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de>
Reviewed-by: Richard Weinberger <richard(a)nod.at>
Acked-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1059,9 +1059,6 @@ static int gpmi_ecc_read_page(struct mtd
return ret;
}
- /* handle the block mark swapping */
- block_mark_swapping(this, payload_virt, auxiliary_virt);
-
/* Loop over status bytes, accumulating ECC status. */
status = auxiliary_virt + nfc_geo->auxiliary_status_offset;
@@ -1150,6 +1147,9 @@ static int gpmi_ecc_read_page(struct mtd
max_bitflips = max_t(unsigned int, max_bitflips, *status);
}
+ /* handle the block mark swapping */
+ block_mark_swapping(this, buf, auxiliary_virt);
+
if (oob_required) {
/*
* It's time to deliver the OOB bytes. See gpmi_ecc_read_oob()
Patches currently in stable-queue which might be from s.hauer(a)pengutronix.de are
queue-4.9/mtd-nand-gpmi-fix-failure-when-a-erased-page-has-a-bitflip-at-bbm.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: brcmnand: Zero bitflip is not an error
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:
mtd-nand-brcmnand-zero-bitflip-is-not-an-error.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 Wed Feb 28 16:13:29 CET 2018
From: Albert Hsieh <wen.hsieh(a)broadcom.com>
Date: Mon, 20 Nov 2017 11:26:26 +0800
Subject: mtd: nand: brcmnand: Zero bitflip is not an error
From: Albert Hsieh <wen.hsieh(a)broadcom.com>
[ Upstream commit e44b9a9c135727f3410e029910275f40681dc8bc ]
A negative return value of brcmstb_nand_verify_erased_page() indicates a
real bitflip error of an erased page, and other return values (>= 0) show
the corrected bitflip number. Zero return value means no bitflip, but the
current driver code treats it as an error, and eventually leads to
falsely reported ECC error.
Fixes: 02b88eea9f9c ("mtd: brcmnand: Add check for erased page bitflip")
Signed-off-by: Albert Hsieh <wen.hsieh(a)broadcom.com>
Acked-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/brcmnand/brcmnand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1763,7 +1763,7 @@ try_dmaread:
err = brcmstb_nand_verify_erased_page(mtd, chip, buf,
addr);
/* erased page bitflips corrected */
- if (err > 0)
+ if (err >= 0)
return err;
}
Patches currently in stable-queue which might be from wen.hsieh(a)broadcom.com are
queue-4.9/mtd-nand-brcmnand-zero-bitflip-is-not-an-error.patch
This is a note to let you know that I've just added the patch titled
mdio-sun4i: Fix a memory leak
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:
mdio-sun4i-fix-a-memory-leak.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 Wed Feb 28 16:13:29 CET 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sat, 6 Jan 2018 09:00:09 +0100
Subject: mdio-sun4i: Fix a memory leak
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 56c0290202ab94a2f2780c449395d4ae8495fab4 ]
If the probing of the regulator is deferred, the memory allocated by
'mdiobus_alloc_size()' will be leaking.
It should be freed before the next call to 'sun4i_mdio_probe()' which will
reallocate it.
Fixes: 4bdcb1dd9feb ("net: Add MDIO bus driver for the Allwinner EMAC")
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/phy/mdio-sun4i.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/phy/mdio-sun4i.c
+++ b/drivers/net/phy/mdio-sun4i.c
@@ -118,8 +118,10 @@ static int sun4i_mdio_probe(struct platf
data->regulator = devm_regulator_get(&pdev->dev, "phy");
if (IS_ERR(data->regulator)) {
- if (PTR_ERR(data->regulator) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
+ if (PTR_ERR(data->regulator) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto err_out_free_mdiobus;
+ }
dev_info(&pdev->dev, "no regulator found\n");
data->regulator = NULL;
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.9/mdio-sun4i-fix-a-memory-leak.patch
This is a note to let you know that I've just added the patch titled
macvlan: Fix one possible double free
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-fix-one-possible-double-free.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 Wed Feb 28 16:13:29 CET 2018
From: Gao Feng <gfree.wind(a)vip.163.com>
Date: Tue, 26 Dec 2017 21:44:32 +0800
Subject: macvlan: Fix one possible double free
From: Gao Feng <gfree.wind(a)vip.163.com>
[ Upstream commit d02fd6e7d2933ede6478a15f9e4ce8a93845824e ]
Because the macvlan_uninit would free the macvlan port, so there is one
double free case in macvlan_common_newlink. When the macvlan port is just
created, then register_netdevice or netdev_upper_dev_link failed and they
would invoke macvlan_uninit. Then it would reach the macvlan_port_destroy
which triggers the double free.
Signed-off-by: Gao Feng <gfree.wind(a)vip.163.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/macvlan.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -1377,9 +1377,14 @@ int macvlan_common_newlink(struct net *s
return 0;
unregister_netdev:
+ /* macvlan_uninit would free the macvlan port */
unregister_netdevice(dev);
+ return err;
destroy_macvlan_port:
- if (create)
+ /* the macvlan port may be freed by macvlan_uninit when fail to register.
+ * so we destroy the macvlan port only when it's valid.
+ */
+ if (create && macvlan_port_get_rtnl(dev))
macvlan_port_destroy(port->dev);
return err;
}
Patches currently in stable-queue which might be from gfree.wind(a)vip.163.com are
queue-4.9/macvlan-fix-one-possible-double-free.patch
This is a note to let you know that I've just added the patch titled
mac80211_hwsim: Fix a possible sleep-in-atomic bug in hwsim_get_radio_nl
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:
mac80211_hwsim-fix-a-possible-sleep-in-atomic-bug-in-hwsim_get_radio_nl.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 Wed Feb 28 16:13:29 CET 2018
From: Jia-Ju Bai <baijiaju1990(a)163.com>
Date: Tue, 12 Dec 2017 17:26:36 +0800
Subject: mac80211_hwsim: Fix a possible sleep-in-atomic bug in hwsim_get_radio_nl
From: Jia-Ju Bai <baijiaju1990(a)163.com>
[ Upstream commit 162bd5e5fd921785077b5862d8f2ffabe2fe11e5 ]
The driver may sleep under a spinlock.
The function call path is:
hwsim_get_radio_nl (acquire the spinlock)
nlmsg_new(GFP_KERNEL) --> may sleep
To fix it, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool(DSAC) and checked by my code review.
Signed-off-by: Jia-Ju Bai <baijiaju1990(a)163.com>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/mac80211_hwsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3154,7 +3154,7 @@ static int hwsim_get_radio_nl(struct sk_
if (!net_eq(wiphy_net(data->hw->wiphy), genl_info_net(info)))
continue;
- skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
if (!skb) {
res = -ENOMEM;
goto out_err;
Patches currently in stable-queue which might be from baijiaju1990(a)163.com are
queue-4.9/mac80211_hwsim-fix-a-possible-sleep-in-atomic-bug-in-hwsim_get_radio_nl.patch
This is a note to let you know that I've just added the patch titled
mac80211: mesh: drop frames appearing to be from us
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:
mac80211-mesh-drop-frames-appearing-to-be-from-us.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 Wed Feb 28 16:13:29 CET 2018
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Thu, 4 Jan 2018 15:51:53 +0100
Subject: mac80211: mesh: drop frames appearing to be from us
From: Johannes Berg <johannes.berg(a)intel.com>
[ Upstream commit 736a80bbfda709fb3631f5f62056f250a38e5804 ]
If there are multiple mesh stations with the same MAC address,
they will both get confused and start throwing warnings.
Obviously in this case nothing can actually work anyway, so just
drop frames that look like they're from ourselves early on.
Reported-by: Gui Iribarren <gui(a)altermundi.net>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/rx.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3611,6 +3611,8 @@ static bool ieee80211_accept_frame(struc
}
return true;
case NL80211_IFTYPE_MESH_POINT:
+ if (ether_addr_equal(sdata->vif.addr, hdr->addr2))
+ return false;
if (multicast)
return true;
return ether_addr_equal(sdata->vif.addr, hdr->addr1);
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.9/mac80211_hwsim-fix-a-possible-sleep-in-atomic-bug-in-hwsim_get_radio_nl.patch
queue-4.9/nl80211-check-for-the-required-netlink-attribute-presence.patch
queue-4.9/mac80211-mesh-drop-frames-appearing-to-be-from-us.patch
This is a note to let you know that I've just added the patch titled
lib/mpi: Fix umul_ppmm() for MIPS64r6
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:
lib-mpi-fix-umul_ppmm-for-mips64r6.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 Wed Feb 28 16:13:29 CET 2018
From: James Hogan <jhogan(a)kernel.org>
Date: Tue, 5 Dec 2017 23:31:35 +0000
Subject: lib/mpi: Fix umul_ppmm() for MIPS64r6
From: James Hogan <jhogan(a)kernel.org>
[ Upstream commit bbc25bee37d2b32cf3a1fab9195b6da3a185614a ]
Current MIPS64r6 toolchains aren't able to generate efficient
DMULU/DMUHU based code for the C implementation of umul_ppmm(), which
performs an unsigned 64 x 64 bit multiply and returns the upper and
lower 64-bit halves of the 128-bit result. Instead it widens the 64-bit
inputs to 128-bits and emits a __multi3 intrinsic call to perform a 128
x 128 multiply. This is both inefficient, and it results in a link error
since we don't include __multi3 in MIPS linux.
For example commit 90a53e4432b1 ("cfg80211: implement regdb signature
checking") merged in v4.15-rc1 recently broke the 64r6_defconfig and
64r6el_defconfig builds by indirectly selecting MPILIB. The same build
errors can be reproduced on older kernels by enabling e.g. CRYPTO_RSA:
lib/mpi/generic_mpih-mul1.o: In function `mpihelp_mul_1':
lib/mpi/generic_mpih-mul1.c:50: undefined reference to `__multi3'
lib/mpi/generic_mpih-mul2.o: In function `mpihelp_addmul_1':
lib/mpi/generic_mpih-mul2.c:49: undefined reference to `__multi3'
lib/mpi/generic_mpih-mul3.o: In function `mpihelp_submul_1':
lib/mpi/generic_mpih-mul3.c:49: undefined reference to `__multi3'
lib/mpi/mpih-div.o In function `mpihelp_divrem':
lib/mpi/mpih-div.c:205: undefined reference to `__multi3'
lib/mpi/mpih-div.c:142: undefined reference to `__multi3'
Therefore add an efficient MIPS64r6 implementation of umul_ppmm() using
inline assembly and the DMULU/DMUHU instructions, to prevent __multi3
calls being emitted.
Fixes: 7fd08ca58ae6 ("MIPS: Add build support for the MIPS R6 ISA")
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Herbert Xu <herbert(a)gondor.apana.org.au>
Cc: "David S. Miller" <davem(a)davemloft.net>
Cc: linux-mips(a)linux-mips.org
Cc: linux-crypto(a)vger.kernel.org
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/mpi/longlong.h | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
--- a/lib/mpi/longlong.h
+++ b/lib/mpi/longlong.h
@@ -671,7 +671,23 @@ do { \
************** MIPS/64 **************
***************************************/
#if (defined(__mips) && __mips >= 3) && W_TYPE_SIZE == 64
-#if (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4)
+#if defined(__mips_isa_rev) && __mips_isa_rev >= 6
+/*
+ * GCC ends up emitting a __multi3 intrinsic call for MIPS64r6 with the plain C
+ * code below, so we special case MIPS64r6 until the compiler can do better.
+ */
+#define umul_ppmm(w1, w0, u, v) \
+do { \
+ __asm__ ("dmulu %0,%1,%2" \
+ : "=d" ((UDItype)(w0)) \
+ : "d" ((UDItype)(u)), \
+ "d" ((UDItype)(v))); \
+ __asm__ ("dmuhu %0,%1,%2" \
+ : "=d" ((UDItype)(w1)) \
+ : "d" ((UDItype)(u)), \
+ "d" ((UDItype)(v))); \
+} while (0)
+#elif (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4)
#define umul_ppmm(w1, w0, u, v) \
do { \
typedef unsigned int __ll_UTItype __attribute__((mode(TI))); \
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-4.9/lib-mpi-fix-umul_ppmm-for-mips64r6.patch
This is a note to let you know that I've just added the patch titled
ipv6: icmp6: Allow icmp messages to be looped back
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-icmp6-allow-icmp-messages-to-be-looped-back.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 Wed Feb 28 16:13:29 CET 2018
From: Brendan McGrath <redmcg(a)redmandi.dyndns.org>
Date: Wed, 13 Dec 2017 22:14:57 +1100
Subject: ipv6: icmp6: Allow icmp messages to be looped back
From: Brendan McGrath <redmcg(a)redmandi.dyndns.org>
[ Upstream commit 588753f1eb18978512b1c9b85fddb457d46f9033 ]
One example of when an ICMPv6 packet is required to be looped back is
when a host acts as both a Multicast Listener and a Multicast Router.
A Multicast Router will listen on address ff02::16 for MLDv2 messages.
Currently, MLDv2 messages originating from a Multicast Listener running
on the same host as the Multicast Router are not being delivered to the
Multicast Router. This is due to dst.input being assigned the default
value of dst_discard.
This results in the packet being looped back but discarded before being
delivered to the Multicast Router.
This patch sets dst.input to ip6_input to ensure a looped back packet
is delivered to the Multicast Router.
Signed-off-by: Brendan McGrath <redmcg(a)redmandi.dyndns.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/route.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1651,6 +1651,7 @@ struct dst_entry *icmp6_dst_alloc(struct
}
rt->dst.flags |= DST_HOST;
+ rt->dst.input = ip6_input;
rt->dst.output = ip6_output;
atomic_set(&rt->dst.__refcnt, 1);
rt->rt6i_gateway = fl6->daddr;
Patches currently in stable-queue which might be from redmcg(a)redmandi.dyndns.org are
queue-4.9/ipv6-icmp6-allow-icmp-messages-to-be-looped-back.patch
This is a note to let you know that I've just added the patch titled
led: core: Fix brightness setting when setting delay_off=0
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:
led-core-fix-brightness-setting-when-setting-delay_off-0.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 Wed Feb 28 16:13:29 CET 2018
From: Matthieu CASTET <matthieu.castet(a)parrot.com>
Date: Tue, 12 Dec 2017 11:10:44 +0100
Subject: led: core: Fix brightness setting when setting delay_off=0
From: Matthieu CASTET <matthieu.castet(a)parrot.com>
[ Upstream commit 2b83ff96f51d0b039c4561b9f95c824d7bddb85c ]
With the current code, the following sequence won't work :
echo timer > trigger
echo 0 > delay_off
* at this point we call
** led_delay_off_store
** led_blink_set
---
drivers/leds/led-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -186,7 +186,7 @@ void led_blink_set(struct led_classdev *
unsigned long *delay_on,
unsigned long *delay_off)
{
- del_timer_sync(&led_cdev->blink_timer);
+ led_stop_software_blink(led_cdev);
led_cdev->flags &= ~LED_BLINK_ONESHOT;
led_cdev->flags &= ~LED_BLINK_ONESHOT_STOP;
Patches currently in stable-queue which might be from matthieu.castet(a)parrot.com are
queue-4.9/led-core-fix-brightness-setting-when-setting-delay_off-0.patch
This is a note to let you know that I've just added the patch titled
ip6_tunnel: get the min mtu properly in ip6_tnl_xmit
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-get-the-min-mtu-properly-in-ip6_tnl_xmit.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 Wed Feb 28 16:13:29 CET 2018
From: Xin Long <lucien.xin(a)gmail.com>
Date: Mon, 18 Dec 2017 14:26:21 +0800
Subject: ip6_tunnel: get the min mtu properly in ip6_tnl_xmit
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit c9fefa08190fc879fb2e681035d7774e0a8c5170 ]
Now it's using IPV6_MIN_MTU as the min mtu in ip6_tnl_xmit, but
IPV6_MIN_MTU actually only works when the inner packet is ipv6.
With IPV6_MIN_MTU for ipv4 packets, the new pmtu for inner dst
couldn't be set less than 1280. It would cause tx_err and the
packet to be dropped when the outer dst pmtu is close to 1280.
Jianlin found it by running ipv4 traffic with the topo:
(client) gre6 <---> eth1 (route) eth2 <---> gre6 (server)
After changing eth2 mtu to 1300, the performance became very
low, or the connection was even broken. The issue also affects
ip4ip6 and ip6ip6 tunnels.
So if the inner packet is ipv4, 576 should be considered as the
min mtu.
Note that for ip4ip6 and ip6ip6 tunnels, the inner packet can
only be ipv4 or ipv6, but for gre6 tunnel, it may also be ARP.
This patch using 576 as the min mtu for non-ipv6 packet works
for all those cases.
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_tunnel.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1127,8 +1127,13 @@ route_lookup:
max_headroom += 8;
mtu -= 8;
}
- if (mtu < IPV6_MIN_MTU)
- mtu = IPV6_MIN_MTU;
+ if (skb->protocol == htons(ETH_P_IPV6)) {
+ if (mtu < IPV6_MIN_MTU)
+ mtu = IPV6_MIN_MTU;
+ } else if (mtu < 576) {
+ mtu = 576;
+ }
+
if (skb_dst(skb) && !t->parms.collect_md)
skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu);
if (skb->len - t->tun_hlen - eth_hlen > mtu && !skb_is_gso(skb)) {
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.9/ip6_tunnel-get-the-min-mtu-properly-in-ip6_tnl_xmit.patch
This is a note to let you know that I've just added the patch titled
IB/mlx5: Fix mlx5_ib_alloc_mr error flow
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:
ib-mlx5-fix-mlx5_ib_alloc_mr-error-flow.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 Wed Feb 28 16:13:29 CET 2018
From: Nitzan Carmi <nitzanc(a)mellanox.com>
Date: Tue, 26 Dec 2017 11:20:20 +0200
Subject: IB/mlx5: Fix mlx5_ib_alloc_mr error flow
From: Nitzan Carmi <nitzanc(a)mellanox.com>
[ Upstream commit 45e6ae7ef21b907dacb18da62d5787d74a31d860 ]
ibmr.device is being set only after ib_alloc_mr() is
(successfully) complete. Therefore, in case mlx5_core_create_mkey()
return with error, the error flow calls mlx5_free_priv_descs()
which uses ibmr.device (which doesn't exist yet), causing
a NULL dereference oops.
To fix this, the IB device should be set in the mr struct earlier
stage (e.g. prior to calling mlx5_core_create_mkey()).
Fixes: 8a187ee52b04 ("IB/mlx5: Support the new memory registration API")
Signed-off-by: Max Gurtovoy <maxg(a)mellanox.com>
Signed-off-by: Nitzan Carmi <nitzanc(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx5/mr.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1648,6 +1648,7 @@ struct ib_mr *mlx5_ib_alloc_mr(struct ib
MLX5_SET(mkc, mkc, access_mode, mr->access_mode);
MLX5_SET(mkc, mkc, umr_en, 1);
+ mr->ibmr.device = pd->device;
err = mlx5_core_create_mkey(dev->mdev, &mr->mmkey, in, inlen);
if (err)
goto err_destroy_psv;
Patches currently in stable-queue which might be from nitzanc(a)mellanox.com are
queue-4.9/ib-mlx5-fix-mlx5_ib_alloc_mr-error-flow.patch
queue-4.9/ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch
This is a note to let you know that I've just added the patch titled
IB/mlx4: Fix mlx4_ib_alloc_mr error flow
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:
ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.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 Wed Feb 28 16:13:29 CET 2018
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Sun, 31 Dec 2017 15:33:14 +0200
Subject: IB/mlx4: Fix mlx4_ib_alloc_mr error flow
From: Leon Romanovsky <leonro(a)mellanox.com>
[ Upstream commit 5a371cf87e145b86efd32007e46146e78c1eff6d ]
ibmr.device is being set only after ib_alloc_mr() is successfully complete.
Therefore, in case imlx4_mr_enable() returns with error, the error flow
unwinder calls to mlx4_free_priv_pages(), which uses ibmr.device.
Such usage causes to NULL dereference oops and to fix it, the IB device
should be set in the mr struct earlier stage (e.g. prior to calling
mlx4_free_priv_pages()).
Fixes: 1b2cd0fc673c ("IB/mlx4: Support the new memory registration API")
Signed-off-by: Nitzan Carmi <nitzanc(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx4/mr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/hw/mlx4/mr.c
+++ b/drivers/infiniband/hw/mlx4/mr.c
@@ -406,7 +406,6 @@ struct ib_mr *mlx4_ib_alloc_mr(struct ib
goto err_free_mr;
mr->max_pages = max_num_sg;
-
err = mlx4_mr_enable(dev->dev, &mr->mmr);
if (err)
goto err_free_pl;
@@ -417,6 +416,7 @@ struct ib_mr *mlx4_ib_alloc_mr(struct ib
return &mr->ibmr;
err_free_pl:
+ mr->ibmr.device = pd->device;
mlx4_free_priv_pages(mr);
err_free_mr:
(void) mlx4_mr_free(dev->dev, &mr->mmr);
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.9/ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch
This is a note to let you know that I've just added the patch titled
IB/ipoib: Fix race condition in neigh creation
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:
ib-ipoib-fix-race-condition-in-neigh-creation.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 Wed Feb 28 16:13:29 CET 2018
From: Erez Shitrit <erezsh(a)mellanox.com>
Date: Sun, 31 Dec 2017 15:33:15 +0200
Subject: IB/ipoib: Fix race condition in neigh creation
From: Erez Shitrit <erezsh(a)mellanox.com>
[ Upstream commit 16ba3defb8bd01a9464ba4820a487f5b196b455b ]
When using enhanced mode for IPoIB, two threads may execute xmit in
parallel to two different TX queues while the target is the same.
In this case, both of them will add the same neighbor to the path's
neigh link list and we might see the following message:
list_add double add: new=ffff88024767a348, prev=ffff88024767a348...
WARNING: lib/list_debug.c:31__list_add_valid+0x4e/0x70
ipoib_start_xmit+0x477/0x680 [ib_ipoib]
dev_hard_start_xmit+0xb9/0x3e0
sch_direct_xmit+0xf9/0x250
__qdisc_run+0x176/0x5d0
__dev_queue_xmit+0x1f5/0xb10
__dev_queue_xmit+0x55/0xb10
Analysis:
Two SKB are scheduled to be transmitted from two cores.
In ipoib_start_xmit, both gets NULL when calling ipoib_neigh_get.
Two calls to neigh_add_path are made. One thread takes the spin-lock
and calls ipoib_neigh_alloc which creates the neigh structure,
then (after the __path_find) the neigh is added to the path's neigh
link list. When the second thread enters the critical section it also
calls ipoib_neigh_alloc but in this case it gets the already allocated
ipoib_neigh structure, which is already linked to the path's neigh
link list and adds it again to the list. Which beside of triggering
the list, it creates a loop in the linked list. This loop leads to
endless loop inside path_rec_completion.
Solution:
Check list_empty(&neigh->list) before adding to the list.
Add a similar fix in "ipoib_multicast.c::ipoib_mcast_send"
Fixes: b63b70d87741 ('IPoIB: Use a private hash table for path lookup in xmit path')
Signed-off-by: Erez Shitrit <erezsh(a)mellanox.com>
Reviewed-by: Alex Vesker <valex(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 25 ++++++++++++++++++-------
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 5 ++++-
2 files changed, 22 insertions(+), 8 deletions(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -919,8 +919,8 @@ static int path_rec_start(struct net_dev
return 0;
}
-static void neigh_add_path(struct sk_buff *skb, u8 *daddr,
- struct net_device *dev)
+static struct ipoib_neigh *neigh_add_path(struct sk_buff *skb, u8 *daddr,
+ struct net_device *dev)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_path *path;
@@ -933,7 +933,15 @@ static void neigh_add_path(struct sk_buf
spin_unlock_irqrestore(&priv->lock, flags);
++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
- return;
+ return NULL;
+ }
+
+ /* To avoid race condition, make sure that the
+ * neigh will be added only once.
+ */
+ if (unlikely(!list_empty(&neigh->list))) {
+ spin_unlock_irqrestore(&priv->lock, flags);
+ return neigh;
}
path = __path_find(dev, daddr + 4);
@@ -971,7 +979,7 @@ static void neigh_add_path(struct sk_buf
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_send(dev, skb, path->ah, IPOIB_QPN(daddr));
ipoib_neigh_put(neigh);
- return;
+ return NULL;
}
} else {
neigh->ah = NULL;
@@ -988,7 +996,7 @@ static void neigh_add_path(struct sk_buf
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_neigh_put(neigh);
- return;
+ return NULL;
err_path:
ipoib_neigh_free(neigh);
@@ -998,6 +1006,8 @@ err_drop:
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_neigh_put(neigh);
+
+ return NULL;
}
static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev,
@@ -1103,8 +1113,9 @@ static int ipoib_start_xmit(struct sk_bu
case htons(ETH_P_TIPC):
neigh = ipoib_neigh_get(dev, phdr->hwaddr);
if (unlikely(!neigh)) {
- neigh_add_path(skb, phdr->hwaddr, dev);
- return NETDEV_TX_OK;
+ neigh = neigh_add_path(skb, phdr->hwaddr, dev);
+ if (likely(!neigh))
+ return NETDEV_TX_OK;
}
break;
case htons(ETH_P_ARP):
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -818,7 +818,10 @@ void ipoib_mcast_send(struct net_device
spin_lock_irqsave(&priv->lock, flags);
if (!neigh) {
neigh = ipoib_neigh_alloc(daddr, dev);
- if (neigh) {
+ /* Make sure that the neigh will be added only
+ * once to mcast list.
+ */
+ if (neigh && list_empty(&neigh->list)) {
kref_get(&mcast->ah->ref);
neigh->ah = mcast->ah;
list_add_tail(&neigh->list, &mcast->neigh_list);
Patches currently in stable-queue which might be from erezsh(a)mellanox.com are
queue-4.9/ib-ipoib-fix-race-condition-in-neigh-creation.patch
This is a note to let you know that I've just added the patch titled
i40e/i40evf: Account for frags split over multiple descriptors in check linearize
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:
i40e-i40evf-account-for-frags-split-over-multiple-descriptors-in-check-linearize.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 Wed Feb 28 16:13:29 CET 2018
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
Date: Fri, 8 Dec 2017 10:55:04 -0800
Subject: i40e/i40evf: Account for frags split over multiple descriptors in check linearize
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
[ Upstream commit 248de22e638f10bd5bfc7624a357f940f66ba137 ]
The original code for __i40e_chk_linearize didn't take into account the
fact that if a fragment is 16K in size or larger it has to be split over 2
descriptors and the smaller of those 2 descriptors will be on the trailing
edge of the transmit. As a result we can get into situations where we didn't
catch requests that could result in a Tx hang.
This patch takes care of that by subtracting the length of all but the
trailing edge of the stale fragment before we test for sum. By doing this
we can guarantee that we have all cases covered, including the case of a
fragment that spans multiple descriptors. We don't need to worry about
checking the inner portions of this since 12K is the maximum aligned DMA
size and that is larger than any MSS will ever be since the MTU limit for
jumbos is something on the order of 9K.
Signed-off-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 26 +++++++++++++++++++++++---
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 26 +++++++++++++++++++++++---
2 files changed, 46 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2670,10 +2670,30 @@ bool __i40e_chk_linearize(struct sk_buff
/* Walk through fragments adding latest fragment, testing it, and
* then removing stale fragments from the sum.
*/
- stale = &skb_shinfo(skb)->frags[0];
- for (;;) {
+ for (stale = &skb_shinfo(skb)->frags[0];; stale++) {
+ int stale_size = skb_frag_size(stale);
+
sum += skb_frag_size(frag++);
+ /* The stale fragment may present us with a smaller
+ * descriptor than the actual fragment size. To account
+ * for that we need to remove all the data on the front and
+ * figure out what the remainder would be in the last
+ * descriptor associated with the fragment.
+ */
+ if (stale_size > I40E_MAX_DATA_PER_TXD) {
+ int align_pad = -(stale->page_offset) &
+ (I40E_MAX_READ_REQ_SIZE - 1);
+
+ sum -= align_pad;
+ stale_size -= align_pad;
+
+ do {
+ sum -= I40E_MAX_DATA_PER_TXD_ALIGNED;
+ stale_size -= I40E_MAX_DATA_PER_TXD_ALIGNED;
+ } while (stale_size > I40E_MAX_DATA_PER_TXD);
+ }
+
/* if sum is negative we failed to make sufficient progress */
if (sum < 0)
return true;
@@ -2681,7 +2701,7 @@ bool __i40e_chk_linearize(struct sk_buff
if (!nr_frags--)
break;
- sum -= skb_frag_size(stale++);
+ sum -= stale_size;
}
return false;
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
@@ -1872,10 +1872,30 @@ bool __i40evf_chk_linearize(struct sk_bu
/* Walk through fragments adding latest fragment, testing it, and
* then removing stale fragments from the sum.
*/
- stale = &skb_shinfo(skb)->frags[0];
- for (;;) {
+ for (stale = &skb_shinfo(skb)->frags[0];; stale++) {
+ int stale_size = skb_frag_size(stale);
+
sum += skb_frag_size(frag++);
+ /* The stale fragment may present us with a smaller
+ * descriptor than the actual fragment size. To account
+ * for that we need to remove all the data on the front and
+ * figure out what the remainder would be in the last
+ * descriptor associated with the fragment.
+ */
+ if (stale_size > I40E_MAX_DATA_PER_TXD) {
+ int align_pad = -(stale->page_offset) &
+ (I40E_MAX_READ_REQ_SIZE - 1);
+
+ sum -= align_pad;
+ stale_size -= align_pad;
+
+ do {
+ sum -= I40E_MAX_DATA_PER_TXD_ALIGNED;
+ stale_size -= I40E_MAX_DATA_PER_TXD_ALIGNED;
+ } while (stale_size > I40E_MAX_DATA_PER_TXD);
+ }
+
/* if sum is negative we failed to make sufficient progress */
if (sum < 0)
return true;
@@ -1883,7 +1903,7 @@ bool __i40evf_chk_linearize(struct sk_bu
if (!nr_frags--)
break;
- sum -= skb_frag_size(stale++);
+ sum -= stale_size;
}
return false;
Patches currently in stable-queue which might be from alexander.h.duyck(a)intel.com are
queue-4.9/i40e-i40evf-account-for-frags-split-over-multiple-descriptors-in-check-linearize.patch
This is a note to let you know that I've just added the patch titled
genirq: Guard handle_bad_irq log messages
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:
genirq-guard-handle_bad_irq-log-messages.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 Wed Feb 28 16:13:29 CET 2018
From: Guenter Roeck <linux(a)roeck-us.net>
Date: Sat, 2 Dec 2017 09:13:04 -0800
Subject: genirq: Guard handle_bad_irq log messages
From: Guenter Roeck <linux(a)roeck-us.net>
[ Upstream commit 11bca0a83f83f6093d816295668e74ef24595944 ]
An interrupt storm on a bad interrupt will cause the kernel
log to be clogged.
[ 60.089234] ->handle_irq(): ffffffffbe2f803f,
[ 60.090455] 0xffffffffbf2af380
[ 60.090510] handle_bad_irq+0x0/0x2e5
[ 60.090522] ->irq_data.chip(): ffffffffbf2af380,
[ 60.090553] IRQ_NOPROBE set
[ 60.090584] ->handle_irq(): ffffffffbe2f803f,
[ 60.090590] handle_bad_irq+0x0/0x2e5
[ 60.090596] ->irq_data.chip(): ffffffffbf2af380,
[ 60.090602] 0xffffffffbf2af380
[ 60.090608] ->action(): (null)
[ 60.090779] handle_bad_irq+0x0/0x2e5
This was seen when running an upstream kernel on Acer Chromebook R11. The
system was unstable as result.
Guard the log message with __printk_ratelimit to reduce the impact. This
won't prevent the interrupt storm from happening, but at least the system
remains stable.
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Dmitry Torokhov <dtor(a)chromium.org>
Cc: Joe Perches <joe(a)perches.com>
Cc: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=197953
Link: https://lkml.kernel.org/r/1512234784-21038-1-git-send-email-linux@roeck-us.…
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/irq/debug.h | 5 +++++
1 file changed, 5 insertions(+)
--- a/kernel/irq/debug.h
+++ b/kernel/irq/debug.h
@@ -11,6 +11,11 @@
static inline void print_irq_desc(unsigned int irq, struct irq_desc *desc)
{
+ static DEFINE_RATELIMIT_STATE(ratelimit, 5 * HZ, 5);
+
+ if (!__ratelimit(&ratelimit))
+ return;
+
printk("irq %d, desc: %p, depth: %d, count: %d, unhandled: %d\n",
irq, desc, desc->depth, desc->irq_count, desc->irqs_unhandled);
printk("->handle_irq(): %p, ", desc->handle_irq);
Patches currently in stable-queue which might be from linux(a)roeck-us.net are
queue-4.9/genirq-guard-handle_bad_irq-log-messages.patch
This is a note to let you know that I've just added the patch titled
drm/ttm: check the return value of kzalloc
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:
drm-ttm-check-the-return-value-of-kzalloc.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 Wed Feb 28 16:13:29 CET 2018
From: Xiongwei Song <sxwjean(a)gmail.com>
Date: Tue, 2 Jan 2018 21:24:55 +0800
Subject: drm/ttm: check the return value of kzalloc
From: Xiongwei Song <sxwjean(a)gmail.com>
[ Upstream commit 19d859a7205bc59ffc38303eb25ae394f61d21dc ]
In the function ttm_page_alloc_init, kzalloc call is made for variable
_manager, we need to check its return value, it may return NULL.
Signed-off-by: Xiongwei Song <sxwjean(a)gmail.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -818,6 +818,8 @@ int ttm_page_alloc_init(struct ttm_mem_g
pr_info("Initializing pool allocator\n");
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
+ if (!_manager)
+ return -ENOMEM;
ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");
Patches currently in stable-queue which might be from sxwjean(a)gmail.com are
queue-4.9/drm-ttm-check-the-return-value-of-kzalloc.patch
This is a note to let you know that I've just added the patch titled
drm/nouveau/pci: do a msi rearm on init
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:
drm-nouveau-pci-do-a-msi-rearm-on-init.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 Wed Feb 28 16:13:29 CET 2018
From: Karol Herbst <kherbst(a)redhat.com>
Date: Fri, 24 Nov 2017 03:56:26 +0100
Subject: drm/nouveau/pci: do a msi rearm on init
From: Karol Herbst <kherbst(a)redhat.com>
[ Upstream commit a121027d2747168df0aac0c3da35509eea39f61c ]
On my GP107 when I load nouveau after unloading it, for some reason the
GPU stopped sending or the CPU stopped receiving interrupts if MSI was
enabled.
Doing a rearm once before getting any interrupts fixes this.
Signed-off-by: Karol Herbst <kherbst(a)redhat.com>
Reviewed-by: Thierry Reding <treding(a)nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
@@ -136,6 +136,13 @@ nvkm_pci_init(struct nvkm_subdev *subdev
return ret;
pci->irq = pdev->irq;
+
+ /* Ensure MSI interrupts are armed, for the case where there are
+ * already interrupts pending (for whatever reason) at load time.
+ */
+ if (pci->msi)
+ pci->func->msi_rearm(pci);
+
return ret;
}
Patches currently in stable-queue which might be from kherbst(a)redhat.com are
queue-4.9/drm-nouveau-pci-do-a-msi-rearm-on-init.patch
This is a note to let you know that I've just added the patch titled
dmaengine: fsl-edma: disable clks on all error paths
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:
dmaengine-fsl-edma-disable-clks-on-all-error-paths.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 Wed Feb 28 16:13:29 CET 2018
From: Andreas Platschek <andreas.platschek(a)opentech.at>
Date: Thu, 14 Dec 2017 12:50:51 +0100
Subject: dmaengine: fsl-edma: disable clks on all error paths
From: Andreas Platschek <andreas.platschek(a)opentech.at>
[ Upstream commit 2610acf46b9ed528ec2cacd717bc9d354e452b73 ]
Previously enabled clks are only disabled if clk_prepare_enable() fails.
However, there are other error paths were the previously enabled
clocks are not disabled.
To fix the problem, fsl_disable_clocks() now takes the number of clocks
that shall be disabled + unprepared. For existing calls were all clocks
were already successfully prepared + enabled, DMAMUX_NR is passed to
disable + unprepare all clocks.
In error paths were only some clocks were successfully prepared +
enabled the loop counter is passed, in order to disable + unprepare
all successfully prepared + enabled clocks.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Andreas Platschek <andreas.platschek(a)opentech.at>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/fsl-edma.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
--- a/drivers/dma/fsl-edma.c
+++ b/drivers/dma/fsl-edma.c
@@ -863,11 +863,11 @@ static void fsl_edma_irq_exit(
}
}
-static void fsl_disable_clocks(struct fsl_edma_engine *fsl_edma)
+static void fsl_disable_clocks(struct fsl_edma_engine *fsl_edma, int nr_clocks)
{
int i;
- for (i = 0; i < DMAMUX_NR; i++)
+ for (i = 0; i < nr_clocks; i++)
clk_disable_unprepare(fsl_edma->muxclk[i]);
}
@@ -904,25 +904,25 @@ static int fsl_edma_probe(struct platfor
res = platform_get_resource(pdev, IORESOURCE_MEM, 1 + i);
fsl_edma->muxbase[i] = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(fsl_edma->muxbase[i]))
+ if (IS_ERR(fsl_edma->muxbase[i])) {
+ /* on error: disable all previously enabled clks */
+ fsl_disable_clocks(fsl_edma, i);
return PTR_ERR(fsl_edma->muxbase[i]);
+ }
sprintf(clkname, "dmamux%d", i);
fsl_edma->muxclk[i] = devm_clk_get(&pdev->dev, clkname);
if (IS_ERR(fsl_edma->muxclk[i])) {
dev_err(&pdev->dev, "Missing DMAMUX block clock.\n");
+ /* on error: disable all previously enabled clks */
+ fsl_disable_clocks(fsl_edma, i);
return PTR_ERR(fsl_edma->muxclk[i]);
}
ret = clk_prepare_enable(fsl_edma->muxclk[i]);
- if (ret) {
- /* disable only clks which were enabled on error */
- for (; i >= 0; i--)
- clk_disable_unprepare(fsl_edma->muxclk[i]);
-
- dev_err(&pdev->dev, "DMAMUX clk block failed.\n");
- return ret;
- }
+ if (ret)
+ /* on error: disable all previously enabled clks */
+ fsl_disable_clocks(fsl_edma, i);
}
@@ -976,7 +976,7 @@ static int fsl_edma_probe(struct platfor
if (ret) {
dev_err(&pdev->dev,
"Can't register Freescale eDMA engine. (%d)\n", ret);
- fsl_disable_clocks(fsl_edma);
+ fsl_disable_clocks(fsl_edma, DMAMUX_NR);
return ret;
}
@@ -985,7 +985,7 @@ static int fsl_edma_probe(struct platfor
dev_err(&pdev->dev,
"Can't register Freescale eDMA of_dma. (%d)\n", ret);
dma_async_device_unregister(&fsl_edma->dma_dev);
- fsl_disable_clocks(fsl_edma);
+ fsl_disable_clocks(fsl_edma, DMAMUX_NR);
return ret;
}
@@ -1015,7 +1015,7 @@ static int fsl_edma_remove(struct platfo
fsl_edma_cleanup_vchan(&fsl_edma->dma_dev);
of_dma_controller_free(np);
dma_async_device_unregister(&fsl_edma->dma_dev);
- fsl_disable_clocks(fsl_edma);
+ fsl_disable_clocks(fsl_edma, DMAMUX_NR);
return 0;
}
Patches currently in stable-queue which might be from andreas.platschek(a)opentech.at are
queue-4.9/dmaengine-fsl-edma-disable-clks-on-all-error-paths.patch
This is a note to let you know that I've just added the patch titled
can: flex_can: Correct the checking for frame length in flexcan_start_xmit()
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:
can-flex_can-correct-the-checking-for-frame-length-in-flexcan_start_xmit.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 Wed Feb 28 16:13:29 CET 2018
From: Luu An Phu <phu.luuan(a)nxp.com>
Date: Tue, 2 Jan 2018 10:44:18 +0700
Subject: can: flex_can: Correct the checking for frame length in flexcan_start_xmit()
From: Luu An Phu <phu.luuan(a)nxp.com>
[ Upstream commit 13454c14550065fcc1705d6bd4ee6d40e057099f ]
The flexcan_start_xmit() function compares the frame length with data
register length to write frame content into data[0] and data[1]
register. Data register length is 4 bytes and frame maximum length is 8
bytes.
Fix the check that compares frame length with 3. Because the register
length is 4.
Signed-off-by: Luu An Phu <phu.luuan(a)nxp.com>
Reviewed-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/flexcan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -493,7 +493,7 @@ static int flexcan_start_xmit(struct sk_
data = be32_to_cpup((__be32 *)&cf->data[0]);
flexcan_write(data, ®s->mb[FLEXCAN_TX_BUF_ID].data[0]);
}
- if (cf->can_dlc > 3) {
+ if (cf->can_dlc > 4) {
data = be32_to_cpup((__be32 *)&cf->data[4]);
flexcan_write(data, ®s->mb[FLEXCAN_TX_BUF_ID].data[1]);
}
Patches currently in stable-queue which might be from phu.luuan(a)nxp.com are
queue-4.9/can-flex_can-correct-the-checking-for-frame-length-in-flexcan_start_xmit.patch
This is a note to let you know that I've just added the patch titled
bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine.
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:
bnxt_en-fix-the-invalid-vf-id-check-in-bnxt_vf_ndo_prep-routine.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 Wed Feb 28 16:13:29 CET 2018
From: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com>
Date: Thu, 4 Jan 2018 18:46:55 -0500
Subject: bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine.
From: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com>
[ Upstream commit 78f300049335ae81a5cc6b4b232481dc5e1f9d41 ]
In bnxt_vf_ndo_prep (which is called by bnxt_get_vf_config ndo), there is a
check for "Invalid VF id". Currently, the check is done against max_vfs.
However, the user doesn't always create max_vfs. So, the check should be
against the created number of VFs. The number of bnxt_vf_info structures
that are allocated in bnxt_alloc_vf_resources routine is the "number of
requested VFs". So, if an "invalid VF id" falls between the requested
number of VFs and the max_vfs, the driver will be dereferencing an invalid
pointer.
Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Venkat Devvuru <venkatkumar.duvvuru(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
@@ -68,7 +68,7 @@ static int bnxt_vf_ndo_prep(struct bnxt
netdev_err(bp->dev, "vf ndo called though sriov is disabled\n");
return -EINVAL;
}
- if (vf_id >= bp->pf.max_vfs) {
+ if (vf_id >= bp->pf.active_vfs) {
netdev_err(bp->dev, "Invalid VF id %d\n", vf_id);
return -EINVAL;
}
Patches currently in stable-queue which might be from venkatkumar.duvvuru(a)broadcom.com are
queue-4.9/bnxt_en-fix-the-invalid-vf-id-check-in-bnxt_vf_ndo_prep-routine.patch
This is a note to let you know that I've just added the patch titled
bnx2x: Improve reliability in case of nested PCI errors
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:
bnx2x-improve-reliability-in-case-of-nested-pci-errors.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 Wed Feb 28 16:13:29 CET 2018
From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com>
Date: Fri, 22 Dec 2017 13:01:39 -0200
Subject: bnx2x: Improve reliability in case of nested PCI errors
From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com>
[ Upstream commit f7084059a9cb9e56a186e1677b1dcffd76c2cd24 ]
While in recovery process of PCI error (called EEH on PowerPC arch),
another PCI transaction could be corrupted causing a situation of
nested PCI errors. Also, this scenario could be reproduced with
error injection mechanisms (for debug purposes).
We observe that in case of nested PCI errors, bnx2x might attempt to
initialize its shmem and cause a kernel crash due to bad addresses
read from MCP. Multiple different stack traces were observed depending
on the point the second PCI error happens.
This patch avoids the crashes by:
* failing PCI recovery in case of nested errors (since multiple
PCI errors in a row are not expected to lead to a functional
adapter anyway), and by,
* preventing access to adapter FW when MCP is failed (we mark it as
failed when shmem cannot get initialized properly).
Reported-by: Abdul Haleem <abdhalee(a)linux.vnet.ibm.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com>
Acked-by: Shahed Shaikh <Shahed.Shaikh(a)cavium.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 4 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 +++++++++++++-
2 files changed, 15 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -3034,7 +3034,7 @@ int bnx2x_nic_unload(struct bnx2x *bp, i
del_timer_sync(&bp->timer);
- if (IS_PF(bp)) {
+ if (IS_PF(bp) && !BP_NOMCP(bp)) {
/* Set ALWAYS_ALIVE bit in shmem */
bp->fw_drv_pulse_wr_seq |= DRV_PULSE_ALWAYS_ALIVE;
bnx2x_drv_pulse(bp);
@@ -3120,7 +3120,7 @@ int bnx2x_nic_unload(struct bnx2x *bp, i
bp->cnic_loaded = false;
/* Clear driver version indication in shmem */
- if (IS_PF(bp))
+ if (IS_PF(bp) && !BP_NOMCP(bp))
bnx2x_update_mng_version(bp);
/* Check if there are pending parity attentions. If there are - set
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -9578,6 +9578,15 @@ static int bnx2x_init_shmem(struct bnx2x
do {
bp->common.shmem_base = REG_RD(bp, MISC_REG_SHARED_MEM_ADDR);
+
+ /* If we read all 0xFFs, means we are in PCI error state and
+ * should bail out to avoid crashes on adapter's FW reads.
+ */
+ if (bp->common.shmem_base == 0xFFFFFFFF) {
+ bp->flags |= NO_MCP_FLAG;
+ return -ENODEV;
+ }
+
if (bp->common.shmem_base) {
val = SHMEM_RD(bp, validity_map[BP_PORT(bp)]);
if (val & SHR_MEM_VALIDITY_MB)
@@ -14312,7 +14321,10 @@ static pci_ers_result_t bnx2x_io_slot_re
BNX2X_ERR("IO slot reset --> driver unload\n");
/* MCP should have been reset; Need to wait for validity */
- bnx2x_init_shmem(bp);
+ if (bnx2x_init_shmem(bp)) {
+ rtnl_unlock();
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
if (IS_PF(bp) && SHMEM2_HAS(bp, drv_capabilities_flag)) {
u32 v;
Patches currently in stable-queue which might be from gpiccoli(a)linux.vnet.ibm.com are
queue-4.9/bnx2x-improve-reliability-in-case-of-nested-pci-errors.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: ls1021a: fix incorrect clock references
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:
arm-dts-ls1021a-fix-incorrect-clock-references.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 Wed Feb 28 16:13:29 CET 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 21 Dec 2017 22:35:19 +0100
Subject: ARM: dts: ls1021a: fix incorrect clock references
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 506e8a912661c97b41adc8a286b875d01323ec45 ]
dtc warns about two 'clocks' properties that have an extraneous '1'
at the end:
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a:clocks[1])
Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2190000/sgtl5000@a
arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2190000/sgtl5000@a:clocks[1])
The clocks that get referenced here are fixed-rate, so they do not
take any argument, and dtc interprets the next cell as a phandle, which
is invalid.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/ls1021a-qds.dts | 2 +-
arch/arm/boot/dts/ls1021a-twr.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -215,7 +215,7 @@
reg = <0x2a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
};
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -187,7 +187,7 @@
reg = <0x0a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/x86-asm-allow-again-using-asm.h-when-building-for-the-bpf-clang-target.patch
queue-4.9/arm-dts-ls1021a-fix-incorrect-clock-references.patch
This is a note to let you know that I've just added the patch titled
ASoC: nau8825: fix issue that pop noise when start capture
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:
asoc-nau8825-fix-issue-that-pop-noise-when-start-capture.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 Wed Feb 28 16:13:29 CET 2018
From: Abhijeet Kumar <abhijeet.kumar(a)intel.com>
Date: Tue, 12 Dec 2017 00:40:25 +0530
Subject: ASoC: nau8825: fix issue that pop noise when start capture
From: Abhijeet Kumar <abhijeet.kumar(a)intel.com>
[ Upstream commit d070f7c703ef26e3db613f24206823f916272fc6 ]
In skylake platform, we hear a loud pop noise(0 dB) at start of
audio capture power up sequence. This patch removes the pop noise
from the recording by adding a delay before enabling ADC.
Signed-off-by: Abhijeet Kumar <abhijeet.kumar(a)intel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/nau8825.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/soc/codecs/nau8825.c
+++ b/sound/soc/codecs/nau8825.c
@@ -882,6 +882,7 @@ static int nau8825_adc_event(struct snd_
switch (event) {
case SND_SOC_DAPM_POST_PMU:
+ msleep(125);
regmap_update_bits(nau8825->regmap, NAU8825_REG_ENA_CTRL,
NAU8825_ENABLE_ADC, NAU8825_ENABLE_ADC);
break;
Patches currently in stable-queue which might be from abhijeet.kumar(a)intel.com are
queue-4.9/asoc-nau8825-fix-issue-that-pop-noise-when-start-capture.patch
This is a note to let you know that I've just added the patch titled
ARM: 8731/1: Fix csum_partial_copy_from_user() stack mismatch
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:
arm-8731-1-fix-csum_partial_copy_from_user-stack-mismatch.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 Wed Feb 28 16:13:29 CET 2018
From: Chunyan Zhang <zhang.lyra(a)gmail.com>
Date: Fri, 1 Dec 2017 03:51:04 +0100
Subject: ARM: 8731/1: Fix csum_partial_copy_from_user() stack mismatch
From: Chunyan Zhang <zhang.lyra(a)gmail.com>
[ Upstream commit 36b0cb84ee858f02c256d26f0cb4229c78e3399e ]
An additional 'ip' will be pushed to the stack, for restoring the
DACR later, if CONFIG_CPU_SW_DOMAIN_PAN defined.
However, the fixup still get the err_ptr by add #8*4 to sp, which
results in the fact that the code area pointed by the LR will be
overwritten, or the kernel will crash if CONFIG_DEBUG_RODATA is enabled.
This patch fixes the stack mismatch.
Fixes: a5e090acbf54 ("ARM: software-based priviledged-no-access support")
Signed-off-by: Lvqiang Huang <Lvqiang.Huang(a)spreadtrum.com>
Signed-off-by: Chunyan Zhang <zhang.lyra(a)gmail.com>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/lib/csumpartialcopyuser.S | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/arm/lib/csumpartialcopyuser.S
+++ b/arch/arm/lib/csumpartialcopyuser.S
@@ -85,7 +85,11 @@
.pushsection .text.fixup,"ax"
.align 4
9001: mov r4, #-EFAULT
+#ifdef CONFIG_CPU_SW_DOMAIN_PAN
+ ldr r5, [sp, #9*4] @ *err_ptr
+#else
ldr r5, [sp, #8*4] @ *err_ptr
+#endif
str r4, [r5]
ldmia sp, {r1, r2} @ retrieve dst, len
add r2, r2, r1
Patches currently in stable-queue which might be from zhang.lyra(a)gmail.com are
queue-4.9/arm-8731-1-fix-csum_partial_copy_from_user-stack-mismatch.patch
This is a note to let you know that I've just added the patch titled
f2fs: fix a bug caused by NULL extent tree
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:
f2fs-fix-a-bug-caused-by-null-extent-tree.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 dad48e73127ba10279ea33e6dbc8d3905c4d31c0 Mon Sep 17 00:00:00 2001
From: Yunlei He <heyunlei(a)huawei.com>
Date: Fri, 19 May 2017 15:06:12 +0800
Subject: f2fs: fix a bug caused by NULL extent tree
From: Yunlei He <heyunlei(a)huawei.com>
commit dad48e73127ba10279ea33e6dbc8d3905c4d31c0 upstream.
Thread A: Thread B:
-f2fs_remount
-sbi->mount_opt.opt = 0;
<--- -f2fs_iget
-do_read_inode
-f2fs_init_extent_tree
-F2FS_I(inode)->extent_tree is NULL
-default_options && parse_options
-remount return
<--- -f2fs_map_blocks
-f2fs_lookup_extent_tree
-f2fs_bug_on(sbi, !et);
The same problem with f2fs_new_inode.
Signed-off-by: Yunlei He <heyunlei(a)huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org>
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/f2fs/extent_cache.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -177,7 +177,7 @@ static void __drop_largest_extent(struct
}
/* return true, if inode page is changed */
-bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
+static bool __f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct extent_tree *et;
@@ -215,6 +215,16 @@ out:
return false;
}
+bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
+{
+ bool ret = __f2fs_init_extent_tree(inode, i_ext);
+
+ if (!F2FS_I(inode)->extent_tree)
+ set_inode_flag(inode, FI_NO_EXTENT);
+
+ return ret;
+}
+
static bool f2fs_lookup_extent_tree(struct inode *inode, pgoff_t pgofs,
struct extent_info *ei)
{
Patches currently in stable-queue which might be from heyunlei(a)huawei.com are
queue-4.9/f2fs-fix-a-bug-caused-by-null-extent-tree.patch
This is a note to let you know that I've just added the patch titled
f2fs: fix a bug caused by NULL extent tree
to the 4.4-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:
f2fs-fix-a-bug-caused-by-null-extent-tree.patch
and it can be found in the queue-4.4 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 dad48e73127ba10279ea33e6dbc8d3905c4d31c0 Mon Sep 17 00:00:00 2001
From: Yunlei He <heyunlei(a)huawei.com>
Date: Fri, 19 May 2017 15:06:12 +0800
Subject: f2fs: fix a bug caused by NULL extent tree
From: Yunlei He <heyunlei(a)huawei.com>
commit dad48e73127ba10279ea33e6dbc8d3905c4d31c0 upstream.
Thread A: Thread B:
-f2fs_remount
-sbi->mount_opt.opt = 0;
<--- -f2fs_iget
-do_read_inode
-f2fs_init_extent_tree
-F2FS_I(inode)->extent_tree is NULL
-default_options && parse_options
-remount return
<--- -f2fs_map_blocks
-f2fs_lookup_extent_tree
-f2fs_bug_on(sbi, !et);
The same problem with f2fs_new_inode.
Signed-off-by: Yunlei He <heyunlei(a)huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org>
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/f2fs/extent_cache.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -172,7 +172,7 @@ void f2fs_drop_largest_extent(struct ino
__drop_largest_extent(inode, fofs, 1);
}
-void f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
+static void __f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct extent_tree *et;
@@ -204,6 +204,14 @@ out:
write_unlock(&et->lock);
}
+void f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
+{
+ __f2fs_init_extent_tree(inode, i_ext);
+
+ if (!F2FS_I(inode)->extent_tree)
+ set_inode_flag(F2FS_I(inode), FI_NO_EXTENT);
+}
+
static bool f2fs_lookup_extent_tree(struct inode *inode, pgoff_t pgofs,
struct extent_info *ei)
{
Patches currently in stable-queue which might be from heyunlei(a)huawei.com are
queue-4.4/f2fs-fix-a-bug-caused-by-null-extent-tree.patch
This is a note to let you know that I've just added the patch titled
i2c: designware: must wait for enable
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:
i2c-designware-must-wait-for-enable.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 fba4adbbf670577e605f9ad306629db6031cd48b Mon Sep 17 00:00:00 2001
From: Ben Gardner <gardner.ben(a)gmail.com>
Date: Wed, 14 Feb 2018 09:29:52 -0600
Subject: i2c: designware: must wait for enable
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ben Gardner <gardner.ben(a)gmail.com>
commit fba4adbbf670577e605f9ad306629db6031cd48b upstream.
One I2C bus on my Atom E3845 board has been broken since 4.9.
It has two devices, both declared by ACPI and with built-in drivers.
There are two back-to-back transactions originating from the kernel, one
targeting each device. The first transaction works, the second one locks
up the I2C controller. The controller never recovers.
These kernel logs show up whenever an I2C transaction is attempted after
this failure.
i2c-designware-pci 0000:00:18.3: timeout in disabling adapter
i2c-designware-pci 0000:00:18.3: timeout waiting for bus ready
Waiting for the I2C controller status to indicate that it is enabled
before programming it fixes the issue.
I have tested this patch on 4.14 and 4.15.
Fixes: commit 2702ea7dbec5 ("i2c: designware: wait for disable/enable only if necessary")
Cc: linux-stable <stable(a)vger.kernel.org> #4.13+
Signed-off-by: Ben Gardner <gardner.ben(a)gmail.com>
Acked-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza(a)intel.com>
Signed-off-by: Wolfram Sang <wsa(a)the-dreams.de>
Signed-off-by: Ben Gardner <gardner.ben(a)gmail.com>
[Jarkko: Backported to v4.9..v4.12 before i2c-designware-core.c was renamed to i2c-designware-master.c]
Signed-off-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/i2c/busses/i2c-designware-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -507,7 +507,7 @@ static void i2c_dw_xfer_init(struct dw_i
i2c_dw_disable_int(dev);
/* Enable the adapter */
- __i2c_dw_enable(dev, true);
+ __i2c_dw_enable_and_wait(dev, true);
/* Clear and enable interrupts */
dw_readl(dev, DW_IC_CLR_INTR);
Patches currently in stable-queue which might be from gardner.ben(a)gmail.com are
queue-4.9/i2c-designware-must-wait-for-enable.patch
Requesting backport of:
174134ac760275457bb0d1560a0dbe6cf8a12ad6
ipmi_si: Fix error handling of platform device
to 4.15 only. Without it, an oops can occur in certain
situations.
Thanks,
-corey
This is a note to let you know that I've just added the patch titled
ipmi_si: Fix error handling of platform device
to the 4.15-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:
ipmi_si-fix-error-handling-of-platform-device.patch
and it can be found in the queue-4.15 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 174134ac760275457bb0d1560a0dbe6cf8a12ad6 Mon Sep 17 00:00:00 2001
From: Corey Minyard <cminyard(a)mvista.com>
Date: Mon, 27 Nov 2017 08:18:33 -0600
Subject: ipmi_si: Fix error handling of platform device
From: Corey Minyard <cminyard(a)mvista.com>
commit 174134ac760275457bb0d1560a0dbe6cf8a12ad6 upstream.
Cleanup of platform devices created by the IPMI driver was not
being done correctly and could result in a memory leak. So
create a local boolean to know how to clean up those platform
devices.
Reported-by: David Binderman <dcb314(a)hotmail.com>
Signed-off-by: Corey Minyard <cminyard(a)mvista.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/char/ipmi/ipmi_si_intf.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2045,6 +2045,7 @@ static int try_smi_init(struct smi_info
int rv = 0;
int i;
char *init_name = NULL;
+ bool platform_device_registered = false;
pr_info(PFX "Trying %s-specified %s state machine at %s address 0x%lx, slave address 0x%x, irq %d\n",
ipmi_addr_src_to_str(new_smi->io.addr_source),
@@ -2173,6 +2174,7 @@ static int try_smi_init(struct smi_info
rv);
goto out_err;
}
+ platform_device_registered = true;
}
dev_set_drvdata(new_smi->io.dev, new_smi);
@@ -2279,10 +2281,11 @@ out_err:
}
if (new_smi->pdev) {
- platform_device_unregister(new_smi->pdev);
+ if (platform_device_registered)
+ platform_device_unregister(new_smi->pdev);
+ else
+ platform_device_put(new_smi->pdev);
new_smi->pdev = NULL;
- } else if (new_smi->pdev) {
- platform_device_put(new_smi->pdev);
}
kfree(init_name);
Patches currently in stable-queue which might be from cminyard(a)mvista.com are
queue-4.15/ipmi_si-fix-error-handling-of-platform-device.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 9f2068f35729948bde84d87a40d135015911345d Mon Sep 17 00:00:00 2001
From: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Date: Tue, 13 Feb 2018 15:04:46 +0100
Subject: serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
Add PCI ids for two variants of Brainboxes UC-260 quad port
PCI serial cards.
Suggested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_pci.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index d580625acc79..a93f77ab3da0 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -4702,6 +4702,17 @@ static const struct pci_device_id serial_pci_tbl[] = {
{ PCI_VENDOR_ID_INTASHIELD, PCI_DEVICE_ID_INTASHIELD_IS400,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, /* 135a.0dc0 */
pbn_b2_4_115200 },
+ /*
+ * BrainBoxes UC-260
+ */
+ { PCI_VENDOR_ID_INTASHIELD, 0x0D21,
+ PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+ pbn_b2_4_115200 },
+ { PCI_VENDOR_ID_INTASHIELD, 0x0E34,
+ PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+ pbn_b2_4_115200 },
/*
* Perle PCI-RAS cards
*/
--
2.16.2
This is a note to let you know that I've just added the patch titled
serial: sh-sci: prevent lockup on full TTY buffers
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 7842055bfce4bf0170d0f61df8b2add8399697be Mon Sep 17 00:00:00 2001
From: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
Date: Thu, 15 Feb 2018 13:02:27 +0100
Subject: serial: sh-sci: prevent lockup on full TTY buffers
When the TTY buffers fill up to the configured maximum, a system lockup
occurs:
[ 598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 598.825796] 0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1
[ 598.832577] (detected by 3, t=62517 jiffies, g=296, c=295, q=126)
[ 598.838755] Task dump for CPU 0:
[ 598.841977] swapper/0 R running task 0 0 0 0x00000022
[ 598.849023] Call trace:
[ 598.851476] __switch_to+0x98/0xb0
[ 598.854870] (null)
This can be prevented by doing a dummy read of the RX data register.
This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0;
reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms
as well.
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Cc: stable <stable(a)vger.kernel.org>
Tested-by: Nguyen Viet Dung <dung.nguyen.aj(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 7257c078e155..44adf9db38f8 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -885,6 +885,8 @@ static void sci_receive_chars(struct uart_port *port)
/* Tell the rest of the system the news. New characters! */
tty_flip_buffer_push(tport);
} else {
+ /* TTY buffers full; read from RX reg to prevent lockup */
+ serial_port_in(port, SCxRDR);
serial_port_in(port, SCxSR); /* dummy read */
sci_clear_SCxSR(port, SCxSR_RDxF_CLEAR(port));
}
--
2.16.2
This is a note to let you know that I've just added the patch titled
serial: core: mark port as initialized in autoconfig
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 714569064adee3c114a2a6490735b94abe269068 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Date: Sat, 3 Feb 2018 12:27:23 +0100
Subject: serial: core: mark port as initialized in autoconfig
This is a followup on 44117a1d1732 ("serial: core: mark port as
initialized after successful IRQ change").
Nikola has been using autoconfig via setserial and reported a crash
similar to what I fixed in the earlier mentioned commit. Here I do the
same fixup for the autoconfig. I wasn't sure that this is the right
approach. Nikola confirmed that it fixes his crash.
Fixes: b3b576461864 ("tty: serial_core: convert uart_open to use tty_port_open")
Link: http://lkml.kernel.org/r/20180131072000.GD1853@localhost.localdomain
Reported-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Tested-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Tested-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Acked-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/serial_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index c8dde56b532b..35b9201db3b4 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1144,6 +1144,8 @@ static int uart_do_autoconfig(struct tty_struct *tty,struct uart_state *state)
uport->ops->config_port(uport, flags);
ret = uart_startup(tty, state, 1);
+ if (ret == 0)
+ tty_port_set_initialized(port, true);
if (ret > 0)
ret = 0;
}
--
2.16.2
This is a note to let you know that I've just added the patch titled
tty/serial: atmel: add new version check for usart
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 Mon Sep 17 00:00:00 2001
From: Jonas Danielsson <jonas(a)orbital-systems.com>
Date: Mon, 29 Jan 2018 12:39:15 +0100
Subject: tty/serial: atmel: add new version check for usart
On our at91sam9260 based board the usart0 and usart1 ports report
their versions (ATMEL_US_VERSION) as 0x10302. This version is not
included in the current checks in the driver.
Signed-off-by: Jonas Danielsson <jonas(a)orbital-systems.com>
Acked-by: Richard Genoud <richard.genoud(a)gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/atmel_serial.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index df46a9e88c34..e287fe8f10fc 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1734,6 +1734,7 @@ static void atmel_get_ip_name(struct uart_port *port)
switch (version) {
case 0x302:
case 0x10213:
+ case 0x10302:
dev_dbg(port->dev, "This version is usart\n");
atmel_port->has_frac_baudrate = true;
atmel_port->has_hw_timer = true;
--
2.16.2
It will get the wrong virtual address because port->mapbase is not added
the correct reg-offset yet. We have to update it before earlycon_map()
is called
Signed-off-by: Greentime Hu <greentime(a)andestech.com>
Acked-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Peter Hurley <peter(a)hurleysoftware.com>
Cc: stable(a)vger.kernel.org
Fixes: 088da2a17619 ("of: earlycon: Initialize port fields from DT
properties")
---
drivers/tty/serial/earlycon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 870e84fb6e39..a24278380fec 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -245,11 +245,12 @@ int __init of_setup_earlycon(const struct earlycon_id *match,
}
port->mapbase = addr;
port->uartclk = BASE_BAUD * 16;
- port->membase = earlycon_map(port->mapbase, SZ_4K);
val = of_get_flat_dt_prop(node, "reg-offset", NULL);
if (val)
port->mapbase += be32_to_cpu(*val);
+ port->membase = earlycon_map(port->mapbase, SZ_4K);
+
val = of_get_flat_dt_prop(node, "reg-shift", NULL);
if (val)
port->regshift = be32_to_cpu(*val);
--
2.16.1
This is a note to let you know that I've just added the patch titled
hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
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:
hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.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 48d0c9becc7f3c66874c100c126459a9da0fdced Mon Sep 17 00:00:00 2001
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Date: Thu, 21 Dec 2017 11:41:35 +0100
Subject: hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
commit 48d0c9becc7f3c66874c100c126459a9da0fdced upstream.
The POSIX specification defines that relative CLOCK_REALTIME timers are not
affected by clock modifications. Those timers have to use CLOCK_MONOTONIC
to ensure POSIX compliance.
The introduction of the additional HRTIMER_MODE_PINNED mode broke this
requirement for pinned timers.
There is no user space visible impact because user space timers are not
using pinned mode, but for consistency reasons this needs to be fixed.
Check whether the mode has the HRTIMER_MODE_REL bit set instead of
comparing with HRTIMER_MODE_ABS.
Signed-off-by: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: John Stultz <john.stultz(a)linaro.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: keescook(a)chromium.org
Fixes: 597d0275736d ("timers: Framework for identifying pinned timers")
Link: http://lkml.kernel.org/r/20171221104205.7269-7-anna-maria@linutronix.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/hrtimer.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1134,7 +1134,12 @@ static void __hrtimer_init(struct hrtime
cpu_base = raw_cpu_ptr(&hrtimer_bases);
- if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS)
+ /*
+ * POSIX magic: Relative CLOCK_REALTIME timers are not affected by
+ * clock modifications, so they needs to become CLOCK_MONOTONIC to
+ * ensure POSIX compliance.
+ */
+ if (clock_id == CLOCK_REALTIME && mode & HRTIMER_MODE_REL)
clock_id = CLOCK_MONOTONIC;
base = hrtimer_clockid_to_base(clock_id);
Patches currently in stable-queue which might be from anna-maria(a)linutronix.de are
queue-4.9/hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
This is a note to let you know that I've just added the patch titled
hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
to the 4.4-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:
hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
and it can be found in the queue-4.4 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 48d0c9becc7f3c66874c100c126459a9da0fdced Mon Sep 17 00:00:00 2001
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Date: Thu, 21 Dec 2017 11:41:35 +0100
Subject: hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
commit 48d0c9becc7f3c66874c100c126459a9da0fdced upstream.
The POSIX specification defines that relative CLOCK_REALTIME timers are not
affected by clock modifications. Those timers have to use CLOCK_MONOTONIC
to ensure POSIX compliance.
The introduction of the additional HRTIMER_MODE_PINNED mode broke this
requirement for pinned timers.
There is no user space visible impact because user space timers are not
using pinned mode, but for consistency reasons this needs to be fixed.
Check whether the mode has the HRTIMER_MODE_REL bit set instead of
comparing with HRTIMER_MODE_ABS.
Signed-off-by: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: John Stultz <john.stultz(a)linaro.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: keescook(a)chromium.org
Fixes: 597d0275736d ("timers: Framework for identifying pinned timers")
Link: http://lkml.kernel.org/r/20171221104205.7269-7-anna-maria@linutronix.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/hrtimer.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1139,7 +1139,12 @@ static void __hrtimer_init(struct hrtime
cpu_base = raw_cpu_ptr(&hrtimer_bases);
- if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS)
+ /*
+ * POSIX magic: Relative CLOCK_REALTIME timers are not affected by
+ * clock modifications, so they needs to become CLOCK_MONOTONIC to
+ * ensure POSIX compliance.
+ */
+ if (clock_id == CLOCK_REALTIME && mode & HRTIMER_MODE_REL)
clock_id = CLOCK_MONOTONIC;
base = hrtimer_clockid_to_base(clock_id);
Patches currently in stable-queue which might be from anna-maria(a)linutronix.de are
queue-4.4/hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
This is a note to let you know that I've just added the patch titled
hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
to the 4.15-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:
hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
and it can be found in the queue-4.15 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 48d0c9becc7f3c66874c100c126459a9da0fdced Mon Sep 17 00:00:00 2001
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Date: Thu, 21 Dec 2017 11:41:35 +0100
Subject: hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
commit 48d0c9becc7f3c66874c100c126459a9da0fdced upstream.
The POSIX specification defines that relative CLOCK_REALTIME timers are not
affected by clock modifications. Those timers have to use CLOCK_MONOTONIC
to ensure POSIX compliance.
The introduction of the additional HRTIMER_MODE_PINNED mode broke this
requirement for pinned timers.
There is no user space visible impact because user space timers are not
using pinned mode, but for consistency reasons this needs to be fixed.
Check whether the mode has the HRTIMER_MODE_REL bit set instead of
comparing with HRTIMER_MODE_ABS.
Signed-off-by: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: John Stultz <john.stultz(a)linaro.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: keescook(a)chromium.org
Fixes: 597d0275736d ("timers: Framework for identifying pinned timers")
Link: http://lkml.kernel.org/r/20171221104205.7269-7-anna-maria@linutronix.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/hrtimer.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1104,7 +1104,12 @@ static void __hrtimer_init(struct hrtime
cpu_base = raw_cpu_ptr(&hrtimer_bases);
- if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS)
+ /*
+ * POSIX magic: Relative CLOCK_REALTIME timers are not affected by
+ * clock modifications, so they needs to become CLOCK_MONOTONIC to
+ * ensure POSIX compliance.
+ */
+ if (clock_id == CLOCK_REALTIME && mode & HRTIMER_MODE_REL)
clock_id = CLOCK_MONOTONIC;
base = hrtimer_clockid_to_base(clock_id);
Patches currently in stable-queue which might be from anna-maria(a)linutronix.de are
queue-4.15/hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
This is the start of the stable review cycle for the 4.4.119 release.
There are 22 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Feb 28 20:15:48 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.119-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.4.119-rc1
Eric Biggers <ebiggers(a)google.com>
binder: add missing binder_unlock()
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
Jack Pham <jackp(a)codeaurora.org>
usb: gadget: f_fs: Process all descriptors during bind
Karsten Koop <kkoop(a)ld-didactic.de>
usb: ldusb: add PIDs for new CASSY devices supported by this driver
Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
usb: dwc3: gadget: Set maxpacket size for ep0 IN
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
Jack Stocker <jackstocker.93(a)gmail.com>
Add delay-init quirk for Corsair K70 RGB keyboards
Michael Weiser <michael.weiser(a)gmx.de>
arm64: Disable unhandled signal log messages by default
AMAN DEEP <aman.deep(a)samsung.com>
usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
Shanker Donthineni <shankerd(a)codeaurora.org>
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
Arnd Bergmann <arnd(a)arndb.de>
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
Lars-Peter Clausen <lars(a)metafoo.de>
iio: adis_lib: Initialize trigger before requesting interrupt
Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
iio: buffer: check if a buffer has been set up when poll is called
Arnd Bergmann <arnd(a)arndb.de>
cfg80211: fix cfg80211_beacon_dup
Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
Max Filippov <jcmvbkbc(a)gmail.com>
xtensa: fix high memory/reserved memory collision
Paolo Abeni <pabeni(a)redhat.com>
ip_tunnel: fix preempt warning in ip tunnel creation/updating
Paolo Abeni <pabeni(a)redhat.com>
ip_tunnel: replace dst_cache with generic implementation
Johan Hovold <johan(a)kernel.org>
PCI: keystone: Fix interrupt-controller-node lookup
Michael Ellerman <mpe(a)ellerman.id.au>
powerpc/64s: Fix RFI flush dependency on HARDLOCKUP_DETECTOR
Paolo Abeni <pabeni(a)redhat.com>
netfilter: drop outermost socket lock in getsockopt()
-------------
Diffstat:
Makefile | 4 +-
arch/arm64/kernel/traps.c | 2 +-
arch/powerpc/kernel/setup_64.c | 2 +-
arch/x86/oprofile/nmi_int.c | 2 +-
arch/xtensa/mm/init.c | 70 ++++++++++++++++++++++++---
drivers/android/binder.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 -
drivers/gpu/drm/drm_edid.c | 3 ++
drivers/hid/hid-core.c | 3 ++
drivers/hid/hid-ids.h | 3 ++
drivers/iio/imu/adis_trigger.c | 7 +--
drivers/iio/industrialio-buffer.c | 2 +-
drivers/irqchip/irq-gic-v3.c | 2 +-
drivers/pci/host/pci-keystone.c | 9 +++-
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
drivers/usb/core/quirks.c | 3 ++
drivers/usb/dwc3/gadget.c | 2 +
drivers/usb/gadget/function/f_fs.c | 6 +--
drivers/usb/host/ohci-q.c | 17 ++++---
drivers/usb/misc/ldusb.c | 6 +++
drivers/usb/renesas_usbhs/fifo.c | 5 ++
include/net/ip_tunnels.h | 9 +---
net/ipv4/Kconfig | 1 +
net/ipv4/ip_sockglue.c | 7 +--
net/ipv4/ip_tunnel.c | 78 +++++-------------------------
net/ipv6/ipv6_sockglue.c | 10 +---
net/ipv6/sit.c | 17 ++++---
net/mac80211/cfg.c | 2 +-
28 files changed, 151 insertions(+), 129 deletions(-)
This is a note to let you know that I've just added the patch titled
hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
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:
hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.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 48d0c9becc7f3c66874c100c126459a9da0fdced Mon Sep 17 00:00:00 2001
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Date: Thu, 21 Dec 2017 11:41:35 +0100
Subject: hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
commit 48d0c9becc7f3c66874c100c126459a9da0fdced upstream.
The POSIX specification defines that relative CLOCK_REALTIME timers are not
affected by clock modifications. Those timers have to use CLOCK_MONOTONIC
to ensure POSIX compliance.
The introduction of the additional HRTIMER_MODE_PINNED mode broke this
requirement for pinned timers.
There is no user space visible impact because user space timers are not
using pinned mode, but for consistency reasons this needs to be fixed.
Check whether the mode has the HRTIMER_MODE_REL bit set instead of
comparing with HRTIMER_MODE_ABS.
Signed-off-by: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: John Stultz <john.stultz(a)linaro.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: keescook(a)chromium.org
Fixes: 597d0275736d ("timers: Framework for identifying pinned timers")
Link: http://lkml.kernel.org/r/20171221104205.7269-7-anna-maria@linutronix.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/hrtimer.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1106,7 +1106,12 @@ static void __hrtimer_init(struct hrtime
cpu_base = raw_cpu_ptr(&hrtimer_bases);
- if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS)
+ /*
+ * POSIX magic: Relative CLOCK_REALTIME timers are not affected by
+ * clock modifications, so they needs to become CLOCK_MONOTONIC to
+ * ensure POSIX compliance.
+ */
+ if (clock_id == CLOCK_REALTIME && mode & HRTIMER_MODE_REL)
clock_id = CLOCK_MONOTONIC;
base = hrtimer_clockid_to_base(clock_id);
Patches currently in stable-queue which might be from anna-maria(a)linutronix.de are
queue-4.14/hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
This is a note to let you know that I've just added the patch titled
hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
to the 3.18-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:
hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
and it can be found in the queue-3.18 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 48d0c9becc7f3c66874c100c126459a9da0fdced Mon Sep 17 00:00:00 2001
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Date: Thu, 21 Dec 2017 11:41:35 +0100
Subject: hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
commit 48d0c9becc7f3c66874c100c126459a9da0fdced upstream.
The POSIX specification defines that relative CLOCK_REALTIME timers are not
affected by clock modifications. Those timers have to use CLOCK_MONOTONIC
to ensure POSIX compliance.
The introduction of the additional HRTIMER_MODE_PINNED mode broke this
requirement for pinned timers.
There is no user space visible impact because user space timers are not
using pinned mode, but for consistency reasons this needs to be fixed.
Check whether the mode has the HRTIMER_MODE_REL bit set instead of
comparing with HRTIMER_MODE_ABS.
Signed-off-by: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: John Stultz <john.stultz(a)linaro.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: keescook(a)chromium.org
Fixes: 597d0275736d ("timers: Framework for identifying pinned timers")
Link: http://lkml.kernel.org/r/20171221104205.7269-7-anna-maria@linutronix.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/hrtimer.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1149,7 +1149,12 @@ static void __hrtimer_init(struct hrtime
cpu_base = raw_cpu_ptr(&hrtimer_bases);
- if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS)
+ /*
+ * POSIX magic: Relative CLOCK_REALTIME timers are not affected by
+ * clock modifications, so they needs to become CLOCK_MONOTONIC to
+ * ensure POSIX compliance.
+ */
+ if (clock_id == CLOCK_REALTIME && mode & HRTIMER_MODE_REL)
clock_id = CLOCK_MONOTONIC;
base = hrtimer_clockid_to_base(clock_id);
Patches currently in stable-queue which might be from anna-maria(a)linutronix.de are
queue-3.18/hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
Hi Josh,
I recently did some randconfig testing with a plain 4.14-stable kernel
and gcc-7.3.0, and came across three distinct objtool warnings:
drivers/misc/lkdtm_bugs.o: warning: objtool:
lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool:
x509_note_pkey_algo()+0xa4: sibling call from callable instruction
with modified stack frame
drivers/infiniband/hw/bnxt_re/qplib_fp.o: warning: objtool:
bnxt_qplib_poll_cq()+0x106: sibling call from callable instruction
with modified stack frame
It's likely that this is the complete set at the moment, I saw each
one multiple times,
but did not see any others. I'll reply with the respective object
files for your reference,
in case these are so far unknown to you. There are only a handful of randconfig
warnings we see overall in the kernel these days (at least on x86 and arm64), so
even if they are false-positive, it would be great to get rid of the
output so we can
do randconfig testing on 4.14.y and treat any output from 'make -s' as
a regression.
I did not check
With gcc-8, things are looking very differently, and we still get an
endless supply of
similar warnings.
Arnd
The patch
spi: atmel: init FIFOs before spi enable
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 9581329eff9db72ab4fbb46a594fd7fdda3c51b0 Mon Sep 17 00:00:00 2001
From: Eugen Hristev <eugen.hristev(a)microchip.com>
Date: Tue, 27 Feb 2018 12:25:07 +0200
Subject: [PATCH] spi: atmel: init FIFOs before spi enable
The datasheet recommends initializing FIFOs before
SPI enable. If we do not do it like this, there may be
a strange behavior. We noticed that DMA does not work properly
with FIFOs if we do not clear them beforehand or enable them
before SPIEN.
Signed-off-by: Eugen Hristev <eugen.hristev(a)microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
drivers/spi/spi-atmel.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 4a11fc0d4136..b7936f815373 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1512,6 +1512,11 @@ static void atmel_spi_init(struct atmel_spi *as)
{
spi_writel(as, CR, SPI_BIT(SWRST));
spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
+
+ /* It is recommended to enable FIFOs first thing after reset */
+ if (as->fifo_size)
+ spi_writel(as, CR, SPI_BIT(FIFOEN));
+
if (as->caps.has_wdrbt) {
spi_writel(as, MR, SPI_BIT(WDRBT) | SPI_BIT(MODFDIS)
| SPI_BIT(MSTR));
@@ -1522,9 +1527,6 @@ static void atmel_spi_init(struct atmel_spi *as)
if (as->use_pdc)
spi_writel(as, PTCR, SPI_BIT(RXTDIS) | SPI_BIT(TXTDIS));
spi_writel(as, CR, SPI_BIT(SPIEN));
-
- if (as->fifo_size)
- spi_writel(as, CR, SPI_BIT(FIFOEN));
}
static int atmel_spi_probe(struct platform_device *pdev)
--
2.16.1
The patch
ASoC: wm_adsp: For TLV controls only register TLV get/set
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From d7789f5bcdb298c4a302db471b1b20f74a20de95 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald <rf(a)opensource.cirrus.com>
Date: Wed, 28 Feb 2018 10:31:10 +0000
Subject: [PATCH] ASoC: wm_adsp: For TLV controls only register TLV get/set
Normal 512-byte get/set of a TLV isn't supported but we were
registering the normal get/set anyway and relying on omitting
the SNDRV_CTL_ELEM_ACCESS_[READ|WRITE] flags to prevent them
being called.
Trouble is if this gets broken in the core ALSA code - as it has
been since at least 4.14 - the standard get/set can be called
unexpectedly and corrupt memory.
There's no point providing functions that won't be called and
it's a trivial change. The benefit is that if the ALSA core gets
broken again we get a big fat immediate NULL dereference instead
of a memory corruption timebomb.
Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
sound/soc/codecs/wm_adsp.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c
index 66e32f5d2917..989d093abda7 100644
--- a/sound/soc/codecs/wm_adsp.c
+++ b/sound/soc/codecs/wm_adsp.c
@@ -1204,12 +1204,14 @@ static int wmfw_add_ctl(struct wm_adsp *dsp, struct wm_coeff_ctl *ctl)
kcontrol->put = wm_coeff_put_acked;
break;
default:
- kcontrol->get = wm_coeff_get;
- kcontrol->put = wm_coeff_put;
-
- ctl->bytes_ext.max = ctl->len;
- ctl->bytes_ext.get = wm_coeff_tlv_get;
- ctl->bytes_ext.put = wm_coeff_tlv_put;
+ if (kcontrol->access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK) {
+ ctl->bytes_ext.max = ctl->len;
+ ctl->bytes_ext.get = wm_coeff_tlv_get;
+ ctl->bytes_ext.put = wm_coeff_tlv_put;
+ } else {
+ kcontrol->get = wm_coeff_get;
+ kcontrol->put = wm_coeff_put;
+ }
break;
}
--
2.16.1
On Fri, Feb 23, 2018 at 06:29:02PM +0000, Ard Biesheuvel wrote:
> Stable backport commit 173358a49173 ("arm64: kpti: Add ->enable callback
> to remap swapper using nG mappings") of upstream commit f992b4dfd58b did
> not survive the backporting process unscathed, and ends up writing garbage
> into the TTBR1_EL1 register, rather than pointing it to the zero page to
> disable translations. Fix that.
>
> Cc: <stable(a)vger.kernel.org> #v4.14
> Reported-by: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
> ---
> arch/arm64/mm/proc.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Any reason why you didn't cc: the stable list, as this is a patch that
is not needed in mainline, right?
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 08572f95bd8a..2b473ddeb7a3 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -155,7 +155,7 @@ ENDPROC(cpu_do_switch_mm)
>
> .macro __idmap_cpu_set_reserved_ttbr1, tmp1, tmp2
> adrp \tmp1, empty_zero_page
> - msr ttbr1_el1, \tmp2
> + msr ttbr1_el1, \tmp1
I don't understand why this isn't also needed in Linus's tree. What
commit there prevents this from being required?
thanks,
greg k-h
This is a note to let you know that I've just added the patch titled
vsprintf: avoid misleading "(null)" for %px
to the 4.15-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:
vsprintf-avoid-misleading-null-for-px.patch
and it can be found in the queue-4.15 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 3a129cc2151425e5aeb69aeb25fbc994ec738137 Mon Sep 17 00:00:00 2001
From: Adam Borowski <kilobyte(a)angband.pl>
Date: Sun, 4 Feb 2018 18:45:21 +0100
Subject: vsprintf: avoid misleading "(null)" for %px
From: Adam Borowski <kilobyte(a)angband.pl>
commit 3a129cc2151425e5aeb69aeb25fbc994ec738137 upstream.
Like %pK already does, print "00000000" instead.
This confused people -- the convention is that "(null)" means you tried to
dereference a null pointer as opposed to printing the address.
Link: http://lkml.kernel.org/r/20180204174521.21383-1-kilobyte@angband.pl
To: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
To: Steven Rostedt <rostedt(a)goodmis.org>
To: linux-kernel(a)vger.kernel.org
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Joe Perches <joe(a)perches.com>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: "Roberts, William C" <william.c.roberts(a)intel.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: David Laight <David.Laight(a)ACULAB.COM>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Geert Uytterhoeven <geert(a)linux-m68k.org>
Signed-off-by: Adam Borowski <kilobyte(a)angband.pl>
Signed-off-by: Petr Mladek <pmladek(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/vsprintf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1849,7 +1849,7 @@ char *pointer(const char *fmt, char *buf
{
const int default_width = 2 * sizeof(void *);
- if (!ptr && *fmt != 'K') {
+ if (!ptr && *fmt != 'K' && *fmt != 'x') {
/*
* Print (null) with the same width as a pointer so it makes
* tabular output look nice.
Patches currently in stable-queue which might be from kilobyte(a)angband.pl are
queue-4.15/vsprintf-avoid-misleading-null-for-px.patch
Hi,
Please include 3a129cc21514 ("vsprintf: avoid misleading "(null)" for
%px") in the 4.15 stable tree. That patch should have had these
fields:
Fixes: 668533dc0764 ("kallsyms: take advantage of the new '%px' format")
Cc: stable(a)vger.kernel.org
But I didn't notice when it went by originally. (Thanks to Steve for
pointing this out as being missed for 4.15.) :)
Thanks!
-Kees
--
Kees Cook
Pixel Security
This is a note to let you know that I've just added the patch titled
ipv6: Skip XFRM lookup if dst_entry in socket cache is valid
to the 3.18-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-skip-xfrm-lookup-if-dst_entry-in-socket-cache-is-valid.patch
and it can be found in the queue-3.18 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 00bc0ef5880dc7b82f9c320dead4afaad48e47be Mon Sep 17 00:00:00 2001
From: Jakub Sitnicki <jkbs(a)redhat.com>
Date: Wed, 8 Jun 2016 15:13:34 +0200
Subject: ipv6: Skip XFRM lookup if dst_entry in socket cache is valid
From: Jakub Sitnicki <jkbs(a)redhat.com>
commit 00bc0ef5880dc7b82f9c320dead4afaad48e47be upstream.
At present we perform an xfrm_lookup() for each UDPv6 message we
send. The lookup involves querying the flow cache (flow_cache_lookup)
and, in case of a cache miss, creating an XFRM bundle.
If we miss the flow cache, we can end up creating a new bundle and
deriving the path MTU (xfrm_init_pmtu) from on an already transformed
dst_entry, which we pass from the socket cache (sk->sk_dst_cache) down
to xfrm_lookup(). This can happen only if we're caching the dst_entry
in the socket, that is when we're using a connected UDP socket.
To put it another way, the path MTU shrinks each time we miss the flow
cache, which later on leads to incorrectly fragmented payload. It can
be observed with ESPv6 in transport mode:
1) Set up a transformation and lower the MTU to trigger fragmentation
# ip xfrm policy add dir out src ::1 dst ::1 \
tmpl src ::1 dst ::1 proto esp spi 1
# ip xfrm state add src ::1 dst ::1 \
proto esp spi 1 enc 'aes' 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
# ip link set dev lo mtu 1500
2) Monitor the packet flow and set up an UDP sink
# tcpdump -ni lo -ttt &
# socat udp6-listen:12345,fork /dev/null &
3) Send a datagram that needs fragmentation with a connected socket
# perl -e 'print "@" x 1470 | socat - udp6:[::1]:12345
2016/06/07 18:52:52 socat[724] E read(3, 0x555bb3d5ba00, 8192): Protocol error
00:00:00.000000 IP6 ::1 > ::1: frag (0|1448) ESP(spi=0x00000001,seq=0x2), length 1448
00:00:00.000014 IP6 ::1 > ::1: frag (1448|32)
00:00:00.000050 IP6 ::1 > ::1: ESP(spi=0x00000001,seq=0x3), length 1272
(^ ICMPv6 Parameter Problem)
00:00:00.000022 IP6 ::1 > ::1: ESP(spi=0x00000001,seq=0x5), length 136
4) Compare it to a non-connected socket
# perl -e 'print "@" x 1500' | socat - udp6-sendto:[::1]:12345
00:00:40.535488 IP6 ::1 > ::1: frag (0|1448) ESP(spi=0x00000001,seq=0x6), length 1448
00:00:00.000010 IP6 ::1 > ::1: frag (1448|64)
What happens in step (3) is:
1) when connecting the socket in __ip6_datagram_connect(), we
perform an XFRM lookup, miss the flow cache, create an XFRM
bundle, and cache the destination,
2) afterwards, when sending the datagram, we perform an XFRM lookup,
again, miss the flow cache (due to mismatch of flowi6_iif and
flowi6_oif, which is an issue of its own), and recreate an XFRM
bundle based on the cached (and already transformed) destination.
To prevent the recreation of an XFRM bundle, avoid an XFRM lookup
altogether whenever we already have a destination entry cached in the
socket. This prevents the path MTU shrinkage and brings us on par with
UDPv4.
The fix also benefits connected PINGv6 sockets, another user of
ip6_sk_dst_lookup_flow(), who also suffer messages being transformed
twice.
Joint work with Hannes Frederic Sowa.
Reported-by: Jan Tluka <jtluka(a)redhat.com>
Signed-off-by: Jakub Sitnicki <jkbs(a)redhat.com>
Acked-by: Hannes Frederic Sowa <hannes(a)stressinduktion.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Benedict Wong <benedictwong(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_output.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1038,17 +1038,12 @@ struct dst_entry *ip6_sk_dst_lookup_flow
const struct in6_addr *final_dst)
{
struct dst_entry *dst = sk_dst_check(sk, inet6_sk(sk)->dst_cookie);
- int err;
dst = ip6_sk_dst_check(sk, dst, fl6);
+ if (!dst)
+ dst = ip6_dst_lookup_flow(sk, fl6, final_dst);
- err = ip6_dst_lookup_tail(sk, &dst, fl6);
- if (err)
- return ERR_PTR(err);
- if (final_dst)
- fl6->daddr = *final_dst;
-
- return xfrm_lookup_route(sock_net(sk), dst, flowi6_to_flowi(fl6), sk, 0);
+ return dst;
}
EXPORT_SYMBOL_GPL(ip6_sk_dst_lookup_flow);
Patches currently in stable-queue which might be from jkbs(a)redhat.com are
queue-3.18/ipv6-skip-xfrm-lookup-if-dst_entry-in-socket-cache-is-valid.patch
This is the start of the stable review cycle for the 4.14.23 release.
There are 54 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Feb 28 20:21:22 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.23-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.14.23-rc1
Chris Wilson <chris(a)chris-wilson.co.uk>
drm/i915/breadcrumbs: Ignore unsubmitted signalers
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
drm/amdgpu: add new device to use atpx quirk
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: add atpx quirk handling (v2)
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: only check mmBIF_IOV_FUNC_IDENTIFIER on tonga/fiji
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: Add dpm quirk for Jet PRO (v2)
Huang Rui <ray.huang(a)amd.com>
drm/amdgpu: disable MMHUB power gating on raven
Chris Wilson <chris(a)chris-wilson.co.uk>
drm: Handle unexpected holes in color-eviction
Daniel Vetter <daniel.vetter(a)ffwll.ch>
drm/cirrus: Load lut in crtc_commit
Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
Jack Pham <jackp(a)codeaurora.org>
usb: gadget: f_fs: Use config_ep_by_speed()
Jack Pham <jackp(a)codeaurora.org>
usb: gadget: f_fs: Process all descriptors during bind
Bin Liu <b-liu(a)ti.com>
Revert "usb: musb: host: don't start next rx urb if current one failed"
Karsten Koop <kkoop(a)ld-didactic.de>
usb: ldusb: add PIDs for new CASSY devices supported by this driver
Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
usb: dwc3: ep0: Reset TRB counter for ep0 IN
Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
usb: dwc3: gadget: Set maxpacket size for ep0 IN
Peter Chen <hzpeterchen(a)gmail.com>
usb: host: ehci: use correct device pointer for dma ops
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
Jack Stocker <jackstocker.93(a)gmail.com>
Add delay-init quirk for Corsair K70 RGB keyboards
Will Deacon <will.deacon(a)arm.com>
arm64: cpufeature: Fix CTR_EL0 field definitions
Michael Weiser <michael.weiser(a)gmx.de>
arm64: Disable unhandled signal log messages by default
Michael Weiser <michael.weiser(a)gmx.de>
arm64: Remove unimplemented syscall log message
AMAN DEEP <aman.deep(a)samsung.com>
usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
Shigeru Yoshida <shigeru.yoshida(a)windriver.com>
ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
Casey Leedom <leedom(a)chelsio.com>
PCI/cxgb4: Extend T3 PCI quirk to T4+ devices
Matt Redfearn <matt.redfearn(a)mips.com>
irqchip/mips-gic: Avoid spuriously handling masked interrupts
Shanker Donthineni <shankerd(a)codeaurora.org>
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
Huang Ying <huang.ying.caritas(a)gmail.com>
mm, swap, frontswap: fix THP swap if frontswap enabled
Arnd Bergmann <arnd(a)arndb.de>
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
Arnd Bergmann <arnd(a)arndb.de>
Kbuild: always define endianess in kconfig.h
Lars-Peter Clausen <lars(a)metafoo.de>
iio: adis_lib: Initialize trigger before requesting interrupt
Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
iio: buffer: check if a buffer has been set up when poll is called
Andreas Klinger <ak(a)it-klinger.de>
iio: srf08: fix link error "devm_iio_triggered_buffer_setup" undefined
Fabrice Gasnier <fabrice.gasnier(a)st.com>
iio: adc: stm32: fix stm32h7_adc_enable error handling
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Sanitize user entered port numbers prior to access it
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Fix circular locking dependency
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Fix bad unlock balance in ib_uverbs_close_xrcd
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Protect from command mask overflow
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Protect from races between lookup and destroy of uobjects
Hans de Goede <hdegoede(a)redhat.com>
extcon: int3496: process id-pin first so that we start with the right status
Eric Biggers <ebiggers(a)google.com>
PKCS#7: fix certificate blacklisting
Eric Biggers <ebiggers(a)google.com>
PKCS#7: fix certificate chain verification
Eric Biggers <ebiggers(a)google.com>
X.509: fix NULL dereference when restricting key with unsupported_sig
Eric Biggers <ebiggers(a)google.com>
X.509: fix BUG_ON() when hash algorithm is unsupported
Eric Anholt <eric(a)anholt.net>
i2c: bcm2835: Set up the rising/falling edge delays
Ben Gardner <gardner.ben(a)gmail.com>
i2c: designware: must wait for enable
Arnd Bergmann <arnd(a)arndb.de>
cfg80211: fix cfg80211_beacon_dup
James Hogan <jhogan(a)kernel.org>
MIPS: Drop spurious __unused in struct compat_flock
Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
Max Filippov <jcmvbkbc(a)gmail.com>
xtensa: fix high memory/reserved memory collision
Kees Cook <keescook(a)chromium.org>
MIPS: boot: Define __ASSEMBLY__ for its.S build
Kees Cook <keescook(a)chromium.org>
kconfig.h: Include compiler types to avoid missed struct attributes
Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
arm64: mm: don't write garbage into TTBR1_EL1 register
Paolo Abeni <pabeni(a)redhat.com>
netfilter: drop outermost socket lock in getsockopt()
-------------
Diffstat:
Makefile | 4 +-
arch/arm64/kernel/cpufeature.c | 6 +-
arch/arm64/kernel/traps.c | 10 +---
arch/arm64/mm/proc.S | 2 +-
arch/mips/boot/Makefile | 1 +
arch/mips/include/asm/compat.h | 1 -
arch/x86/oprofile/nmi_int.c | 2 +-
arch/xtensa/mm/init.c | 70 +++++++++++++++++++++---
crypto/asymmetric_keys/pkcs7_verify.c | 12 ++--
crypto/asymmetric_keys/public_key.c | 4 +-
crypto/asymmetric_keys/restrict.c | 21 ++++---
drivers/extcon/extcon-intel-int3496.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 58 +++++++++++++++++---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 -
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 5 ++
drivers/gpu/drm/amd/amdgpu/soc15.c | 4 +-
drivers/gpu/drm/amd/amdgpu/vi.c | 21 ++++---
drivers/gpu/drm/cirrus/cirrus_mode.c | 40 ++++++++------
drivers/gpu/drm/drm_edid.c | 3 +
drivers/gpu/drm/drm_mm.c | 21 ++++++-
drivers/gpu/drm/i915/intel_breadcrumbs.c | 29 ++++------
drivers/hid/hid-core.c | 3 +
drivers/hid/hid-ids.h | 3 +
drivers/i2c/busses/i2c-bcm2835.c | 21 ++++++-
drivers/i2c/busses/i2c-designware-master.c | 2 +-
drivers/iio/adc/stm32-adc.c | 7 ++-
drivers/iio/imu/adis_trigger.c | 7 ++-
drivers/iio/industrialio-buffer.c | 2 +-
drivers/iio/proximity/Kconfig | 2 +
drivers/infiniband/core/rdma_core.c | 10 +++-
drivers/infiniband/core/uverbs_cmd.c | 16 ++++--
drivers/infiniband/core/uverbs_main.c | 27 ++++++---
drivers/irqchip/irq-gic-v3.c | 2 +-
drivers/irqchip/irq-mips-gic.c | 2 -
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 10 ----
drivers/pci/quirks.c | 39 +++++++------
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
drivers/usb/core/quirks.c | 3 +
drivers/usb/dwc3/ep0.c | 7 ++-
drivers/usb/dwc3/gadget.c | 2 +
drivers/usb/gadget/function/f_fs.c | 44 +++------------
drivers/usb/host/ehci-hub.c | 4 +-
drivers/usb/host/ohci-hcd.c | 10 +++-
drivers/usb/host/ohci-hub.c | 4 +-
drivers/usb/host/ohci-q.c | 17 +++---
drivers/usb/misc/ldusb.c | 6 ++
drivers/usb/musb/musb_host.c | 8 +--
drivers/usb/renesas_usbhs/fifo.c | 5 ++
drivers/xen/tmem.c | 4 ++
include/linux/kconfig.h | 9 +++
mm/zswap.c | 6 ++
net/ipv4/ip_sockglue.c | 7 +--
net/ipv6/ipv6_sockglue.c | 10 +---
net/mac80211/cfg.c | 2 +-
54 files changed, 403 insertions(+), 219 deletions(-)
On 2/27/18 7:57 AM, Mark Brown wrote:
> On Tue, Feb 27, 2018 at 07:13:17AM -0800, Pierre-Louis Bossart wrote:
>> On 2/27/18 2:38 AM, Mark Brown wrote:
>>> On Mon, Feb 26, 2018 at 06:30:15PM -0800, Pierre-Louis Bossart wrote:
>
>>>> This issue was found during the development of SOF (Sound Open Firmware)
>>>> where we get the reverse of the intended behavior when using the same
>>>> conventions in topology files as in machine drivers.
>
>>> Is this perhaps something that the earlier firmware is handling inside
>>> the firmware?
>
>> For SKL+ the SSP settings come from binary blobs read from ACPI/NHLT tables
>> so I am wondering if this inversion is compensated for in the tools used to
>> generate the blobs.
>
> Ugh, I'm confused here. Is this a case of SoF differing from the
> regular firmware somehow - presumably the stuff coming from the NHLT
> table is the same for both firmwares?
no we are not using the NHLT info for now but using the one provided in
topology files. the SOF firmware does not rely on blobs but programs the
registers based on masks and settings passed. This difference is
precisely how we exposed a difference in behavior.
Hi All,
This backport patchset fixed the spectre issue, it's original branch:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti
A few dependency or fixingpatches are also picked up, if they are necessary
or no functional changes.
arm64: cpu_errata: Allow an erratum to be match for all revisions of a core
arm64: cpufeature: __this_cpu_has_cap() shouldn't stop early
arm64: syscallno is secretly an int, make it official
arm64: uaccess: consistently check object sizes
arm64: Factor out TTBR0_EL1 post-update workaround into a specific asm macro
arm64: Factor out PAN enabling/disabling into separate uaccess_* macros
arm64: move TASK_* definitions to <asm/processor.h>
arm64: alternatives: apply boot time fixups via the linear mapping
mm: Introduce lm_alias
The patchset also on repository:
git://git.linaro.org/kernel/linux-linaro-stable.git lts-4.9-spectrevv2
The kernelci.org and lkft testing show no regressions.
Any comments are appreciated!
Regards
Alex
---
Ard Biesheuvel <ard.biesheuvel(a)linaro.org> (1):
arm64: alternatives: apply boot time fixups via the linear mapping
Catalin Marinas <catalin.marinas(a)arm.com> (2):
arm64: Factor out PAN enabling/disabling into separate uaccess_* macros
arm64: Factor out TTBR0_EL1 post-update workaround into a specific asm macro
Dave Martin <Dave.Martin(a)arm.com> (1):
arm64: syscallno is secretly an int, make it official
James Morse <james.morse(a)arm.com> (1):
arm64: cpufeature: __this_cpu_has_cap() shouldn't stop early
Laura Abbott <labbott(a)redhat.com> (1):
mm: Introduce lm_alias
Marc Zyngier <marc.zyngier(a)arm.com> (26):
arm64: cpu_errata: Allow an erratum to be match for all revisions of a core
arm64: Move post_ttbr_update_workaround to C code
arm64: Move BP hardening to check_and_switch_context
arm64: KVM: Use per-CPU vector when BP hardening is enabled
arm64: KVM: Increment PC after handling an SMC trap
arm/arm64: KVM: Consolidate the PSCI include files
arm/arm64: KVM: Add PSCI_VERSION helper
arm/arm64: KVM: Add smccc accessors to PSCI code
arm/arm64: KVM: Implement PSCI 1.0 support
arm/arm64: KVM: Advertise SMCCC v1.1
arm64: KVM: Make PSCI_VERSION a fast path
arm/arm64: KVM: Turn kvm_psci_version into a static inline
arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening support
arm64: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling
firmware/psci: Expose PSCI conduit
firmware/psci: Expose SMCCC version through psci_ops
arm/arm64: smccc: Make function identifiers an unsigned quantity
arm/arm64: smccc: Implement SMCCC v1.1 inline primitive
arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support
arm64: Kill PSCI_GET_VERSION as a variant-2 workaround
arm: Add BTB invalidation on switch_mm for Cortex-A9, A12 and A17
arm: Invalidate BTB on prefetch abort outside of user mapping on Cortex A8, A9, A12 and A17
arm: KVM: Invalidate BTB on guest exit for Cortex-A12/A17
arm: Add icache invalidation on switch_mm for Cortex-A15
arm: Invalidate icache on prefetch abort outside of user mapping on Cortex-A15
arm: KVM: Invalidate icache on guest exit for Cortex-A15
Mark Rutland <mark.rutland(a)arm.com> (1):
arm64: uaccess: consistently check object sizes
Robin Murphy <robin.murphy(a)arm.com> (3):
arm64: Implement array_index_mask_nospec()
arm64: Make USER_DS an inclusive limit
arm64: Use pointer masking to limit uaccess speculation
Suzuki K Poulose <suzuki.poulose(a)arm.com> (1):
arm64: Run enable method for errata work arounds on late CPUs
Will Deacon <will.deacon(a)arm.com> (14):
arm64: barrier: Add CSDB macros to control data-value prediction
arm64: entry: Ensure branch through syscall table is bounded under speculation
arm64: uaccess: Prevent speculative use of the current addr_limit
arm64: uaccess: Don't bother eliding access_ok checks in __{get, put}_user
arm64: uaccess: Mask __user pointers for __arch_{clear, copy_*}_user
arm64: futex: Mask __user pointers prior to dereference
drivers/firmware: Expose psci_get_version through psci_ops structure
arm64: cpufeature: Pass capability structure to ->enable callback
arm64: Add skeleton to harden the branch predictor against aliasing attacks
arm64: entry: Apply BP hardening for high-priority synchronous exceptions
arm64: entry: Apply BP hardening for suspicious interrupts from EL0
arm64: cputype: Add missing MIDR values for Cortex-A72 and Cortex-A75
arm64: Implement branch predictor hardening for affected Cortex-A CPUs
arm64: Add README describing the branch
Yury Norov <ynorov(a)caviumnetworks.com> (1):
arm64: move TASK_* definitions to <asm/processor.h>
proc_sys_link_fill_cache() does not take currently unregistering
sysctl tables into account, which might result into a page fault in
sysctl_follow_link() - add a check to fix it.
This bug has been present since v3.4.
Fixes: 0e47c99d7fe25 ("sysctl: Replace root_list with links between sysctl_table_sets")
Cc: stable(a)vger.kernel.org
Acked-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
---
v2: removed empty line between between sysctl_head_grab and IS_ERR
v3: extend commit message, add tags and cc stable
---
fs/proc/proc_sysctl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index c5cbbdff3c3d..82ac5f682b73 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -707,7 +707,10 @@ static bool proc_sys_link_fill_cache(struct file *file,
struct ctl_table *table)
{
bool ret = true;
+
head = sysctl_head_grab(head);
+ if (IS_ERR(head))
+ return false;
if (S_ISLNK(table->mode)) {
/* It is not an error if we can not follow the link ignore it */
--
2.14.1
The following series implements...
Changes since v3 [1]:
* Kill IS_DAX() in favor of explicit IS_FSDAX() and IS_DEVDAX() helpers.
Jan noted, "having IS_DAX() and IS_FSDAX() doing almost the same, just
not exactly the same, is IMHO a recipe for confusion", and I agree. A
nice side effect of this elimination is a cleanup to remove occasions of
"#ifdef CONFIG_FS_DAX" in C files, it is all moved to header files
now. (Jan)
---
The vfio interface, like RDMA, wants to setup long term (indefinite)
pins of the pages backing an address range so that a guest or userspace
driver can perform DMA to the with physical address. Given that this
pinning may lead to filesystem operations deadlocking in the
filesystem-dax case, the pinning request needs to be rejected.
The longer term fix for vfio, RDMA, and any other long term pin user, is
to provide a 'pin with lease' mechanism. Similar to the leases that are
hold for pNFS RDMA layouts, this userspace lease gives the kernel a way
to notify userspace that the block layout of the file is changing and
the kernel is revoking access to pinned pages.
Related to this change is the discovery that vma_is_fsdax() was causing
device-dax inode detection to fail. That lead to series of fixes and
cleanups to make sure that S_DAX is defined correctly in the
CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case.
---
Dan Williams (12):
dax: fix vma_is_fsdax() helper
dax: introduce IS_DEVDAX() and IS_FSDAX()
ext2, dax: finish implementing dax_sem helpers
ext2, dax: define ext2_dax_*() infrastructure in all cases
ext4, dax: define ext4_dax_*() infrastructure in all cases
ext2, dax: replace IS_DAX() with IS_FSDAX()
ext4, dax: replace IS_DAX() with IS_FSDAX()
xfs, dax: replace IS_DAX() with IS_FSDAX()
mm, dax: replace IS_DAX() with IS_DEVDAX() or IS_FSDAX()
fs, dax: kill IS_DAX()
dax: fix S_DAX definition
vfio: disable filesystem-dax page pinning
drivers/vfio/vfio_iommu_type1.c | 18 ++++++++++++++--
fs/ext2/ext2.h | 6 +++++
fs/ext2/file.c | 19 +++++------------
fs/ext2/inode.c | 10 ++++-----
fs/ext4/file.c | 18 +++++-----------
fs/ext4/inode.c | 4 ++--
fs/ext4/ioctl.c | 2 +-
fs/ext4/super.c | 2 +-
fs/iomap.c | 2 +-
fs/xfs/xfs_file.c | 14 ++++++-------
fs/xfs/xfs_ioctl.c | 4 ++--
fs/xfs/xfs_iomap.c | 6 +++--
fs/xfs/xfs_reflink.c | 2 +-
include/linux/dax.h | 12 ++++++++---
include/linux/fs.h | 43 ++++++++++++++++++++++++++++-----------
mm/fadvise.c | 3 ++-
mm/filemap.c | 4 ++--
mm/huge_memory.c | 4 +++-
mm/madvise.c | 3 ++-
19 files changed, 102 insertions(+), 74 deletions(-)
This is the start of the stable review cycle for the 4.15.7 release.
There are 64 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Feb 28 20:21:30 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.7-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.15.7-rc1
Chris Wilson <chris(a)chris-wilson.co.uk>
drm/i915/breadcrumbs: Ignore unsubmitted signalers
Will Deacon <will.deacon(a)arm.com>
arm64: __show_regs: Only resolve kernel symbols when running at EL1
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
drm/amdgpu: add new device to use atpx quirk
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: add atpx quirk handling (v2)
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: only check mmBIF_IOV_FUNC_IDENTIFIER on tonga/fiji
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: Add dpm quirk for Jet PRO (v2)
Christian König <christian.koenig(a)amd.com>
drm/amdgpu: fix VA hole handling on Vega10 v3
Huang Rui <ray.huang(a)amd.com>
drm/amdgpu: disable MMHUB power gating on raven
Chris Wilson <chris(a)chris-wilson.co.uk>
drm: Handle unexpected holes in color-eviction
Leo (Sunpeng) Li <sunpeng.li(a)amd.com>
drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits
Daniel Vetter <daniel.vetter(a)ffwll.ch>
drm/cirrus: Load lut in crtc_commit
Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
Jack Pham <jackp(a)codeaurora.org>
usb: gadget: f_fs: Use config_ep_by_speed()
Jack Pham <jackp(a)codeaurora.org>
usb: gadget: f_fs: Process all descriptors during bind
Bin Liu <b-liu(a)ti.com>
Revert "usb: musb: host: don't start next rx urb if current one failed"
Karsten Koop <kkoop(a)ld-didactic.de>
usb: ldusb: add PIDs for new CASSY devices supported by this driver
Fabio Estevam <fabio.estevam(a)nxp.com>
usb: phy: mxs: Fix NULL pointer dereference on i.MX23/28
Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
usb: dwc3: ep0: Reset TRB counter for ep0 IN
Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
usb: dwc3: gadget: Set maxpacket size for ep0 IN
Peter Chen <hzpeterchen(a)gmail.com>
usb: host: ehci: use correct device pointer for dma ops
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
Jack Stocker <jackstocker.93(a)gmail.com>
Add delay-init quirk for Corsair K70 RGB keyboards
Will Deacon <will.deacon(a)arm.com>
arm64: cpufeature: Fix CTR_EL0 field definitions
Michael Weiser <michael.weiser(a)gmx.de>
arm64: Disable unhandled signal log messages by default
Michael Weiser <michael.weiser(a)gmx.de>
arm64: Remove unimplemented syscall log message
AMAN DEEP <aman.deep(a)samsung.com>
usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
Shigeru Yoshida <shigeru.yoshida(a)windriver.com>
ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
Mika Westerberg <mika.westerberg(a)linux.intel.com>
net: thunderbolt: Run disconnect flow asynchronously when logout is received
Mika Westerberg <mika.westerberg(a)linux.intel.com>
net: thunderbolt: Tear down connection properly on suspend
Casey Leedom <leedom(a)chelsio.com>
PCI/cxgb4: Extend T3 PCI quirk to T4+ devices
Matt Redfearn <matt.redfearn(a)mips.com>
irqchip/mips-gic: Avoid spuriously handling masked interrupts
Shanker Donthineni <shankerd(a)codeaurora.org>
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
Hauke Mehrtens <hauke(a)hauke-m.de>
uapi/if_ether.h: move __UAPI_DEF_ETHHDR libc define
Juergen Gross <jgross(a)suse.com>
mm: don't defer struct page initialization for Xen pv guests
Huang Ying <huang.ying.caritas(a)gmail.com>
mm, swap, frontswap: fix THP swap if frontswap enabled
Arnd Bergmann <arnd(a)arndb.de>
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
Thomas Gleixner <tglx(a)linutronix.de>
x86/apic/vector: Handle vector release on CPU unplug correctly
Arnd Bergmann <arnd(a)arndb.de>
Kbuild: always define endianess in kconfig.h
Lars-Peter Clausen <lars(a)metafoo.de>
iio: adis_lib: Initialize trigger before requesting interrupt
Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
iio: buffer: check if a buffer has been set up when poll is called
Andreas Klinger <ak(a)it-klinger.de>
iio: srf08: fix link error "devm_iio_triggered_buffer_setup" undefined
Fabrice Gasnier <fabrice.gasnier(a)st.com>
iio: adc: stm32: fix stm32h7_adc_enable error handling
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Sanitize user entered port numbers prior to access it
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Fix circular locking dependency
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Fix bad unlock balance in ib_uverbs_close_xrcd
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Protect from command mask overflow
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Protect from races between lookup and destroy of uobjects
Thomas Gleixner <tglx(a)linutronix.de>
genirq/matrix: Handle CPU offlining proper
Hans de Goede <hdegoede(a)redhat.com>
extcon: int3496: process id-pin first so that we start with the right status
Eric Biggers <ebiggers(a)google.com>
PKCS#7: fix certificate blacklisting
Eric Biggers <ebiggers(a)google.com>
PKCS#7: fix certificate chain verification
Eric Biggers <ebiggers(a)google.com>
X.509: fix NULL dereference when restricting key with unsupported_sig
Eric Biggers <ebiggers(a)google.com>
X.509: fix BUG_ON() when hash algorithm is unsupported
Eric Anholt <eric(a)anholt.net>
i2c: bcm2835: Set up the rising/falling edge delays
Ben Gardner <gardner.ben(a)gmail.com>
i2c: designware: must wait for enable
Arnd Bergmann <arnd(a)arndb.de>
cfg80211: fix cfg80211_beacon_dup
James Hogan <jhogan(a)kernel.org>
MIPS: Drop spurious __unused in struct compat_flock
Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
Max Filippov <jcmvbkbc(a)gmail.com>
xtensa: fix high memory/reserved memory collision
Kees Cook <keescook(a)chromium.org>
MIPS: boot: Define __ASSEMBLY__ for its.S build
Kees Cook <keescook(a)chromium.org>
kconfig.h: Include compiler types to avoid missed struct attributes
Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
arm64: mm: don't write garbage into TTBR1_EL1 register
Paolo Abeni <pabeni(a)redhat.com>
netfilter: drop outermost socket lock in getsockopt()
-------------
Diffstat:
Makefile | 4 +-
arch/arm64/kernel/cpufeature.c | 6 +-
arch/arm64/kernel/process.c | 11 +++-
arch/arm64/kernel/traps.c | 10 +---
arch/arm64/mm/proc.S | 2 +-
arch/mips/boot/Makefile | 1 +
arch/mips/include/asm/compat.h | 1 -
arch/x86/kernel/apic/vector.c | 25 ++++++++-
arch/x86/oprofile/nmi_int.c | 2 +-
arch/xtensa/mm/init.c | 70 +++++++++++++++++++++---
crypto/asymmetric_keys/pkcs7_verify.c | 12 ++--
crypto/asymmetric_keys/public_key.c | 4 +-
crypto/asymmetric_keys/restrict.c | 21 ++++---
drivers/extcon/extcon-intel-int3496.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 58 +++++++++++++++++---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 10 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 11 ++++
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 13 +++++
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 5 ++
drivers/gpu/drm/amd/amdgpu/soc15.c | 4 +-
drivers/gpu/drm/amd/amdgpu/vi.c | 21 ++++---
drivers/gpu/drm/cirrus/cirrus_mode.c | 40 ++++++++------
drivers/gpu/drm/drm_atomic_helper.c | 15 +++++
drivers/gpu/drm/drm_edid.c | 3 +
drivers/gpu/drm/drm_mm.c | 21 ++++++-
drivers/gpu/drm/i915/intel_breadcrumbs.c | 29 ++++------
drivers/hid/hid-core.c | 3 +
drivers/hid/hid-ids.h | 3 +
drivers/i2c/busses/i2c-bcm2835.c | 21 ++++++-
drivers/i2c/busses/i2c-designware-master.c | 2 +-
drivers/iio/adc/stm32-adc.c | 7 ++-
drivers/iio/imu/adis_trigger.c | 7 ++-
drivers/iio/industrialio-buffer.c | 2 +-
drivers/iio/proximity/Kconfig | 2 +
drivers/infiniband/core/rdma_core.c | 10 +++-
drivers/infiniband/core/uverbs_cmd.c | 16 ++++--
drivers/infiniband/core/uverbs_main.c | 27 ++++++---
drivers/irqchip/irq-gic-v3.c | 2 +-
drivers/irqchip/irq-mips-gic.c | 2 -
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 10 ----
drivers/net/thunderbolt.c | 19 +++++--
drivers/pci/quirks.c | 39 +++++++------
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
drivers/usb/core/quirks.c | 3 +
drivers/usb/dwc3/ep0.c | 7 ++-
drivers/usb/dwc3/gadget.c | 2 +
drivers/usb/gadget/function/f_fs.c | 44 +++------------
drivers/usb/host/ehci-hub.c | 4 +-
drivers/usb/host/ohci-hcd.c | 10 +++-
drivers/usb/host/ohci-hub.c | 4 +-
drivers/usb/host/ohci-q.c | 17 +++---
drivers/usb/misc/ldusb.c | 6 ++
drivers/usb/musb/musb_host.c | 8 +--
drivers/usb/phy/phy-mxs-usb.c | 3 +
drivers/usb/renesas_usbhs/fifo.c | 5 ++
drivers/xen/tmem.c | 4 ++
include/drm/drm_atomic.h | 9 +++
include/linux/kconfig.h | 9 +++
include/uapi/linux/if_ether.h | 6 +-
include/uapi/linux/libc-compat.h | 6 --
kernel/irq/matrix.c | 23 +++++---
mm/page_alloc.c | 4 ++
mm/zswap.c | 6 ++
net/ipv4/ip_sockglue.c | 7 +--
net/ipv6/ipv6_sockglue.c | 10 +---
net/mac80211/cfg.c | 2 +-
68 files changed, 530 insertions(+), 251 deletions(-)
This is a note to let you know that I've just added the patch titled
microblaze: fix endian handling
to the 4.15-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:
microblaze-fix-endian-handling.patch
and it can be found in the queue-4.15 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 71e7673dadfdae0605d4c1f66ecb4b045c79fe0f Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 2 Jan 2018 12:47:19 +0100
Subject: microblaze: fix endian handling
From: Arnd Bergmann <arnd(a)arndb.de>
commit 71e7673dadfdae0605d4c1f66ecb4b045c79fe0f upstream.
Building an allmodconfig kernel fails horribly because of
endian mismatch. It turns out that the -mlittle-endian
switch was not honored at all as we were using the wrong
Kconfig symbol and failing to apply CPUFLAGS to the CFLAGS.
Finally, the linker flags did not get set right.
This addresses all three of those issues, which now lets
me build both big-endian and little-endian kernels for
testing.
Fixes: 428dbf156cc5 ("arch: change default endian for microblaze")
Fixes: 206d3642d8ee ("arch/microblaze: add choice for endianness and update Makefile")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Michal Simek <michal.simek(a)xilinx.com>
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/microblaze/Makefile | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
--- a/arch/microblaze/Makefile
+++ b/arch/microblaze/Makefile
@@ -36,16 +36,21 @@ endif
CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div
CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift
CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR) += -mxl-pattern-compare
-CPUFLAGS-$(CONFIG_BIG_ENDIAN) += -mbig-endian
-CPUFLAGS-$(CONFIG_LITTLE_ENDIAN) += -mlittle-endian
+
+ifdef CONFIG_CPU_BIG_ENDIAN
+KBUILD_CFLAGS += -mbig-endian
+KBUILD_AFLAGS += -mbig-endian
+LD += -EB
+else
+KBUILD_CFLAGS += -mlittle-endian
+KBUILD_AFLAGS += -mlittle-endian
+LD += -EL
+endif
CPUFLAGS-1 += $(call cc-option,-mcpu=v$(CPU_VER))
# r31 holds current when in kernel mode
-KBUILD_CFLAGS += -ffixed-r31 $(CPUFLAGS-1) $(CPUFLAGS-2)
-
-LDFLAGS :=
-LDFLAGS_vmlinux :=
+KBUILD_CFLAGS += -ffixed-r31 $(CPUFLAGS-y) $(CPUFLAGS-1) $(CPUFLAGS-2)
head-y := arch/microblaze/kernel/head.o
libs-y += arch/microblaze/lib/
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.15/microblaze-fix-endian-handling.patch
queue-4.15/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.15/cfg80211-fix-cfg80211_beacon_dup.patch
queue-4.15/kbuild-always-define-endianess-in-kconfig.h.patch
This is a note to let you know that I've just added the patch titled
microblaze: fix endian 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:
microblaze-fix-endian-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 71e7673dadfdae0605d4c1f66ecb4b045c79fe0f Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 2 Jan 2018 12:47:19 +0100
Subject: microblaze: fix endian handling
From: Arnd Bergmann <arnd(a)arndb.de>
commit 71e7673dadfdae0605d4c1f66ecb4b045c79fe0f upstream.
Building an allmodconfig kernel fails horribly because of
endian mismatch. It turns out that the -mlittle-endian
switch was not honored at all as we were using the wrong
Kconfig symbol and failing to apply CPUFLAGS to the CFLAGS.
Finally, the linker flags did not get set right.
This addresses all three of those issues, which now lets
me build both big-endian and little-endian kernels for
testing.
Fixes: 428dbf156cc5 ("arch: change default endian for microblaze")
Fixes: 206d3642d8ee ("arch/microblaze: add choice for endianness and update Makefile")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Michal Simek <michal.simek(a)xilinx.com>
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/microblaze/Makefile | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
--- a/arch/microblaze/Makefile
+++ b/arch/microblaze/Makefile
@@ -36,16 +36,21 @@ endif
CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div
CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift
CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR) += -mxl-pattern-compare
-CPUFLAGS-$(CONFIG_BIG_ENDIAN) += -mbig-endian
-CPUFLAGS-$(CONFIG_LITTLE_ENDIAN) += -mlittle-endian
+
+ifdef CONFIG_CPU_BIG_ENDIAN
+KBUILD_CFLAGS += -mbig-endian
+KBUILD_AFLAGS += -mbig-endian
+LD += -EB
+else
+KBUILD_CFLAGS += -mlittle-endian
+KBUILD_AFLAGS += -mlittle-endian
+LD += -EL
+endif
CPUFLAGS-1 += $(call cc-option,-mcpu=v$(CPU_VER))
# r31 holds current when in kernel mode
-KBUILD_CFLAGS += -ffixed-r31 $(CPUFLAGS-1) $(CPUFLAGS-2)
-
-LDFLAGS :=
-LDFLAGS_vmlinux :=
+KBUILD_CFLAGS += -ffixed-r31 $(CPUFLAGS-y) $(CPUFLAGS-1) $(CPUFLAGS-2)
head-y := arch/microblaze/kernel/head.o
libs-y += arch/microblaze/lib/
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/microblaze-fix-endian-handling.patch
queue-4.14/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.14/cfg80211-fix-cfg80211_beacon_dup.patch
queue-4.14/kbuild-always-define-endianess-in-kconfig.h.patch
This is a note to let you know that I've just added the patch titled
m32r: fix endianness constraints
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:
m32r-fix-endianness-constraints.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 c95f121142a41c951fd62683a5574f2a7b37c573 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
Date: Wed, 15 Nov 2017 17:31:18 -0800
Subject: m32r: fix endianness constraints
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
commit c95f121142a41c951fd62683a5574f2a7b37c573 upstream.
The m32r Kconfig provides both CPU_BIG_ENDIAN and CPU_LITTLE_ENDIAN
configuration options. As they are user-selectable and independent,
this allows invalid configurations:
- All m32r defconfigs build a big endian kernel, but CPU_BIG_ENDIAN is
not set, causing compiler warnings like:
include/linux/byteorder/big_endian.h:7:2: warning: #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN [-Wcpp]
#warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN
^
- Since commit 5bdfca6435b82944 ("m32r: define CPU_BIG_ENDIAN"),
building an allmodconfig or allyesconfig enables both
CONFIG_CPU_BIG_ENDIAN and CONFIG_CPU_LITTLE_ENDIAN.
While this did get rid of the warning above, both options are
obviously mutually exclusive.
Fix this by making only CPU_LITTLE_ENDIAN configurable by the user, as
before, and by making sure exactly one of CPU_BIG_ENDIAN and
CPU_LITTLE_ENDIAN is always enabled.
Link: http://lkml.kernel.org/r/1509361505-18150-1-git-send-email-geert@linux-m68k…
Fixes: 5bdfca6435b82944 ("m32r: define CPU_BIG_ENDIAN")
Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Cc: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/m32r/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/m32r/Kconfig
+++ b/arch/m32r/Kconfig
@@ -196,8 +196,8 @@ config TIMER_DIVIDE
default "128"
config CPU_BIG_ENDIAN
- bool "Generate big endian code"
- default n
+ bool
+ default !CPU_LITTLE_ENDIAN
config CPU_LITTLE_ENDIAN
bool "Generate little endian code"
Patches currently in stable-queue which might be from geert(a)linux-m68k.org are
queue-4.14/m32r-fix-endianness-constraints.patch