This is a note to let you know that I've just added the patch titled
nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>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:
nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-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 Thu Feb 1 13:45:42 CET 2018
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Fri, 3 Nov 2017 08:00:12 -0400
Subject: nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0)
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
[ Upstream commit fb500a7cfee7f2f447d2bbf30cb59629feab6ac1 ]
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfsd/nfs4state.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -63,6 +63,9 @@ static const stateid_t zero_stateid = {
static const stateid_t currentstateid = {
.si_generation = 1,
};
+static const stateid_t close_stateid = {
+ .si_generation = 0xffffffffU,
+};
static u64 current_sessionid = 1;
@@ -5411,6 +5414,11 @@ nfsd4_close(struct svc_rqst *rqstp, stru
nfsd4_close_open_stateid(stp);
mutex_unlock(&stp->st_mutex);
+ /* See RFC5661 sectionm 18.2.4 */
+ if (stp->st_stid.sc_client->cl_minorversion)
+ memcpy(&close->cl_stateid, &close_stateid,
+ sizeof(close->cl_stateid));
+
/* put reference from nfs4_preprocess_seqid_op */
nfs4_put_stid(&stp->st_stid);
out:
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.14/nfsd-ensure-we-check-stateid-validity-in-the-seqid-operation-checks.patch
queue-4.14/sunrpc-allow-connect-to-return-ehostunreach.patch
queue-4.14/nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch
This is a note to let you know that I've just added the patch titled
nfsd: check for use of the closed special stateid
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:
nfsd-check-for-use-of-the-closed-special-stateid.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 Thu Feb 1 13:45:42 CET 2018
From: Andrew Elble <aweits(a)rit.edu>
Date: Thu, 9 Nov 2017 13:41:10 -0500
Subject: nfsd: check for use of the closed special stateid
From: Andrew Elble <aweits(a)rit.edu>
[ Upstream commit ae254dac721d44c0bfebe2795df87459e2e88219 ]
Prevent the use of the closed (invalid) special stateid by clients.
Signed-off-by: Andrew Elble <aweits(a)rit.edu>
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfsd/nfs4state.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -72,6 +72,7 @@ static u64 current_sessionid = 1;
#define ZERO_STATEID(stateid) (!memcmp((stateid), &zero_stateid, sizeof(stateid_t)))
#define ONE_STATEID(stateid) (!memcmp((stateid), &one_stateid, sizeof(stateid_t)))
#define CURRENT_STATEID(stateid) (!memcmp((stateid), ¤tstateid, sizeof(stateid_t)))
+#define CLOSE_STATEID(stateid) (!memcmp((stateid), &close_stateid, sizeof(stateid_t)))
/* forward declarations */
static bool check_for_locks(struct nfs4_file *fp, struct nfs4_lockowner *lowner);
@@ -4869,7 +4870,8 @@ static __be32 nfsd4_validate_stateid(str
struct nfs4_stid *s;
__be32 status = nfserr_bad_stateid;
- if (ZERO_STATEID(stateid) || ONE_STATEID(stateid))
+ if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) ||
+ CLOSE_STATEID(stateid))
return status;
/* Client debugging aid. */
if (!same_clid(&stateid->si_opaque.so_clid, &cl->cl_clientid)) {
@@ -4927,7 +4929,8 @@ nfsd4_lookup_stateid(struct nfsd4_compou
else if (typemask & NFS4_DELEG_STID)
typemask |= NFS4_REVOKED_DELEG_STID;
- if (ZERO_STATEID(stateid) || ONE_STATEID(stateid))
+ if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) ||
+ CLOSE_STATEID(stateid))
return nfserr_bad_stateid;
status = lookup_clientid(&stateid->si_opaque.so_clid, cstate, nn);
if (status == nfserr_stale_clientid) {
Patches currently in stable-queue which might be from aweits(a)rit.edu are
queue-4.14/nfsd-check-for-use-of-the-closed-special-stateid.patch
This is a note to let you know that I've just added the patch titled
net: phy: marvell10g: fix the PHY id 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:
net-phy-marvell10g-fix-the-phy-id-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 Thu Feb 1 13:45:42 CET 2018
From: Antoine Tenart <antoine.tenart(a)free-electrons.com>
Date: Tue, 28 Nov 2017 14:26:30 +0100
Subject: net: phy: marvell10g: fix the PHY id mask
From: Antoine Tenart <antoine.tenart(a)free-electrons.com>
[ Upstream commit 952b6b3b07877419386e719ff20917170e1ce684 ]
The Marvell 10G PHY driver supports different hardware revisions, which
have their bits 3..0 differing. To get the correct revision number these
bits should be ignored. This patch fixes this by using the already
defined MARVELL_PHY_ID_MASK (0xfffffff0) instead of the custom
0xffffffff mask.
Fixes: 20b2af32ff3f ("net: phy: add Marvell Alaska X 88X3310 10Gigabit PHY support")
Suggested-by: Yan Markman <ymarkman(a)marvell.com>
Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com>
Reviewed-by: Andrew Lunn <andrew(a)lunn.ch>
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/marvell10g.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -16,6 +16,7 @@
* link takes priority and the other port is completely locked out.
*/
#include <linux/phy.h>
+#include <linux/marvell_phy.h>
enum {
MV_PCS_BASE_T = 0x0000,
@@ -338,7 +339,7 @@ static int mv3310_read_status(struct phy
static struct phy_driver mv3310_drivers[] = {
{
.phy_id = 0x002b09aa,
- .phy_id_mask = 0xffffffff,
+ .phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "mv88x3310",
.features = SUPPORTED_10baseT_Full |
SUPPORTED_100baseT_Full |
@@ -360,7 +361,7 @@ static struct phy_driver mv3310_drivers[
module_phy_driver(mv3310_drivers);
static struct mdio_device_id __maybe_unused mv3310_tbl[] = {
- { 0x002b09aa, 0xffffffff },
+ { 0x002b09aa, MARVELL_PHY_ID_MASK },
{ },
};
MODULE_DEVICE_TABLE(mdio, mv3310_tbl);
Patches currently in stable-queue which might be from antoine.tenart(a)free-electrons.com are
queue-4.14/net-phy-marvell10g-fix-the-phy-id-mask.patch
queue-4.14/net-mvpp2-fix-the-txq_init-error-path.patch
queue-4.14/crypto-inside-secure-avoid-unmapping-dma-memory-that-was-not-mapped.patch
queue-4.14/crypto-inside-secure-fix-hash-when-length-is-a-multiple-of-a-block.patch
This is a note to let you know that I've just added the patch titled
net: mvpp2: fix the txq_init error 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:
net-mvpp2-fix-the-txq_init-error-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 Thu Feb 1 13:45:42 CET 2018
From: Antoine Tenart <antoine.tenart(a)free-electrons.com>
Date: Tue, 28 Nov 2017 14:19:48 +0100
Subject: net: mvpp2: fix the txq_init error path
From: Antoine Tenart <antoine.tenart(a)free-electrons.com>
[ Upstream commit ba2d8d887d962c2f790e6dc01b2fd25b4608720b ]
When an allocation in the txq_init path fails, the allocated buffers
end-up being freed twice: in the txq_init error path, and in txq_deinit.
This lead to issues as txq_deinit would work on already freed memory
regions:
kernel BUG at mm/slub.c:3915!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
This patch fixes this by removing the txq_init own error path, as the
txq_deinit function is always called on errors. This was introduced by
TSO as way more buffers are allocated.
Fixes: 186cd4d4e414 ("net: mvpp2: software tso support")
Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.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/marvell/mvpp2.c | 20 ++------------------
1 file changed, 2 insertions(+), 18 deletions(-)
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5597,7 +5597,7 @@ static int mvpp2_txq_init(struct mvpp2_p
sizeof(*txq_pcpu->buffs),
GFP_KERNEL);
if (!txq_pcpu->buffs)
- goto cleanup;
+ return -ENOMEM;
txq_pcpu->count = 0;
txq_pcpu->reserved_num = 0;
@@ -5610,26 +5610,10 @@ static int mvpp2_txq_init(struct mvpp2_p
&txq_pcpu->tso_headers_dma,
GFP_KERNEL);
if (!txq_pcpu->tso_headers)
- goto cleanup;
+ return -ENOMEM;
}
return 0;
-cleanup:
- for_each_present_cpu(cpu) {
- txq_pcpu = per_cpu_ptr(txq->pcpu, cpu);
- kfree(txq_pcpu->buffs);
-
- dma_free_coherent(port->dev->dev.parent,
- txq_pcpu->size * TSO_HEADER_SIZE,
- txq_pcpu->tso_headers,
- txq_pcpu->tso_headers_dma);
- }
-
- dma_free_coherent(port->dev->dev.parent,
- txq->size * MVPP2_DESC_ALIGNED_SIZE,
- txq->descs, txq->descs_dma);
-
- return -ENOMEM;
}
/* Free allocated TXQ resources */
Patches currently in stable-queue which might be from antoine.tenart(a)free-electrons.com are
queue-4.14/net-phy-marvell10g-fix-the-phy-id-mask.patch
queue-4.14/net-mvpp2-fix-the-txq_init-error-path.patch
queue-4.14/crypto-inside-secure-avoid-unmapping-dma-memory-that-was-not-mapped.patch
queue-4.14/crypto-inside-secure-fix-hash-when-length-is-a-multiple-of-a-block.patch
This is a note to let you know that I've just added the patch titled
net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit
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:
net-ethernet-xilinx-mark-xilinx_ll_temac-broken-on-64-bit.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 Thu Feb 1 13:45:42 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Wed, 29 Nov 2017 11:01:09 +0100
Subject: net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit 15bfe05c8d6386f1a90e9340d15336e85e32aad6 ]
On 64-bit (e.g. powerpc64/allmodconfig):
drivers/net/ethernet/xilinx/ll_temac_main.c: In function 'temac_start_xmit_done':
drivers/net/ethernet/xilinx/ll_temac_main.c:633:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
dev_kfree_skb_irq((struct sk_buff *)cur_p->app4);
^
cdmac_bd.app4 is u32, so it is too small to hold a kernel pointer.
Note that several other fields in struct cdmac_bd are also too small to
hold physical addresses on 64-bit platforms.
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
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/xilinx/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/xilinx/Kconfig
+++ b/drivers/net/ethernet/xilinx/Kconfig
@@ -34,6 +34,7 @@ config XILINX_AXI_EMAC
config XILINX_LL_TEMAC
tristate "Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver"
depends on (PPC || MICROBLAZE)
+ depends on !64BIT || BROKEN
select PHYLIB
---help---
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.14/net-ethernet-xilinx-mark-xilinx_ll_temac-broken-on-64-bit.patch
This is a note to let you know that I've just added the patch titled
media: usbtv: add a new usbid
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:
media-usbtv-add-a-new-usbid.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 Thu Feb 1 13:45:42 CET 2018
From: Icenowy Zheng <icenowy(a)aosc.io>
Date: Sun, 16 Apr 2017 02:51:16 -0400
Subject: media: usbtv: add a new usbid
From: Icenowy Zheng <icenowy(a)aosc.io>
[ Upstream commit 04226916d2360f56d57ad00bc48d2d1854d1e0b0 ]
A new usbid of UTV007 is found in a newly bought device.
The usbid is 1f71:3301.
The ID on the chip is:
UTV007
A89029.1
1520L18K1
Both video and audio is tested with the modified usbtv driver.
Signed-off-by: Icenowy Zheng <icenowy(a)aosc.io>
Acked-by: Lubomir Rintel <lkundrak(a)v3.sk>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/usb/usbtv/usbtv-core.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -144,6 +144,7 @@ static void usbtv_disconnect(struct usb_
static const struct usb_device_id usbtv_id_table[] = {
{ USB_DEVICE(0x1b71, 0x3002) },
+ { USB_DEVICE(0x1f71, 0x3301) },
{}
};
MODULE_DEVICE_TABLE(usb, usbtv_id_table);
Patches currently in stable-queue which might be from icenowy(a)aosc.io are
queue-4.14/media-usbtv-add-a-new-usbid.patch
This is a note to let you know that I've just added the patch titled
mac80211: use QoS NDP for AP probing
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-use-qos-ndp-for-ap-probing.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 Thu Feb 1 13:45:42 CET 2018
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Tue, 21 Nov 2017 14:46:08 +0100
Subject: mac80211: use QoS NDP for AP probing
From: Johannes Berg <johannes.berg(a)intel.com>
[ Upstream commit 7b6ddeaf27eca72795ceeae2f0f347db1b5f9a30 ]
When connected to a QoS/WMM AP, mac80211 should use a QoS NDP
for probing it, instead of a regular non-QoS one, fix this.
Change all the drivers to *not* allow QoS NDP for now, even
though it looks like most of them should be OK with that.
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/ath/ath9k/channel.c | 2 +-
drivers/net/wireless/st/cw1200/sta.c | 4 ++--
drivers/net/wireless/ti/wl1251/main.c | 2 +-
drivers/net/wireless/ti/wlcore/cmd.c | 5 +++--
include/net/mac80211.h | 8 +++++++-
net/mac80211/mlme.c | 2 +-
net/mac80211/tx.c | 29 +++++++++++++++++++++++++++--
7 files changed, 42 insertions(+), 10 deletions(-)
--- a/drivers/net/wireless/ath/ath9k/channel.c
+++ b/drivers/net/wireless/ath/ath9k/channel.c
@@ -1112,7 +1112,7 @@ ath_chanctx_send_vif_ps_frame(struct ath
if (!avp->assoc)
return false;
- skb = ieee80211_nullfunc_get(sc->hw, vif);
+ skb = ieee80211_nullfunc_get(sc->hw, vif, false);
if (!skb)
return false;
--- a/drivers/net/wireless/st/cw1200/sta.c
+++ b/drivers/net/wireless/st/cw1200/sta.c
@@ -198,7 +198,7 @@ void __cw1200_cqm_bssloss_sm(struct cw12
priv->bss_loss_state++;
- skb = ieee80211_nullfunc_get(priv->hw, priv->vif);
+ skb = ieee80211_nullfunc_get(priv->hw, priv->vif, false);
WARN_ON(!skb);
if (skb)
cw1200_tx(priv->hw, NULL, skb);
@@ -2266,7 +2266,7 @@ static int cw1200_upload_null(struct cw1
.rate = 0xFF,
};
- frame.skb = ieee80211_nullfunc_get(priv->hw, priv->vif);
+ frame.skb = ieee80211_nullfunc_get(priv->hw, priv->vif, false);
if (!frame.skb)
return -ENOMEM;
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -566,7 +566,7 @@ static int wl1251_build_null_data(struct
size = sizeof(struct wl12xx_null_data_template);
ptr = NULL;
} else {
- skb = ieee80211_nullfunc_get(wl->hw, wl->vif);
+ skb = ieee80211_nullfunc_get(wl->hw, wl->vif, false);
if (!skb)
goto out;
size = skb->len;
--- a/drivers/net/wireless/ti/wlcore/cmd.c
+++ b/drivers/net/wireless/ti/wlcore/cmd.c
@@ -1069,7 +1069,8 @@ int wl12xx_cmd_build_null_data(struct wl
ptr = NULL;
} else {
skb = ieee80211_nullfunc_get(wl->hw,
- wl12xx_wlvif_to_vif(wlvif));
+ wl12xx_wlvif_to_vif(wlvif),
+ false);
if (!skb)
goto out;
size = skb->len;
@@ -1096,7 +1097,7 @@ int wl12xx_cmd_build_klv_null_data(struc
struct sk_buff *skb = NULL;
int ret = -ENOMEM;
- skb = ieee80211_nullfunc_get(wl->hw, vif);
+ skb = ieee80211_nullfunc_get(wl->hw, vif, false);
if (!skb)
goto out;
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -4470,18 +4470,24 @@ struct sk_buff *ieee80211_pspoll_get(str
* ieee80211_nullfunc_get - retrieve a nullfunc template
* @hw: pointer obtained from ieee80211_alloc_hw().
* @vif: &struct ieee80211_vif pointer from the add_interface callback.
+ * @qos_ok: QoS NDP is acceptable to the caller, this should be set
+ * if at all possible
*
* Creates a Nullfunc template which can, for example, uploaded to
* hardware. The template must be updated after association so that correct
* BSSID and address is used.
*
+ * If @qos_ndp is set and the association is to an AP with QoS/WMM, the
+ * returned packet will be QoS NDP.
+ *
* Note: Caller (or hardware) is responsible for setting the
* &IEEE80211_FCTL_PM bit as well as Duration and Sequence Control fields.
*
* Return: The nullfunc template. %NULL on error.
*/
struct sk_buff *ieee80211_nullfunc_get(struct ieee80211_hw *hw,
- struct ieee80211_vif *vif);
+ struct ieee80211_vif *vif,
+ bool qos_ok);
/**
* ieee80211_probereq_get - retrieve a Probe Request template
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -908,7 +908,7 @@ void ieee80211_send_nullfunc(struct ieee
struct ieee80211_hdr_3addr *nullfunc;
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
- skb = ieee80211_nullfunc_get(&local->hw, &sdata->vif);
+ skb = ieee80211_nullfunc_get(&local->hw, &sdata->vif, true);
if (!skb)
return;
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -4404,13 +4404,15 @@ struct sk_buff *ieee80211_pspoll_get(str
EXPORT_SYMBOL(ieee80211_pspoll_get);
struct sk_buff *ieee80211_nullfunc_get(struct ieee80211_hw *hw,
- struct ieee80211_vif *vif)
+ struct ieee80211_vif *vif,
+ bool qos_ok)
{
struct ieee80211_hdr_3addr *nullfunc;
struct ieee80211_sub_if_data *sdata;
struct ieee80211_if_managed *ifmgd;
struct ieee80211_local *local;
struct sk_buff *skb;
+ bool qos = false;
if (WARN_ON(vif->type != NL80211_IFTYPE_STATION))
return NULL;
@@ -4419,7 +4421,17 @@ struct sk_buff *ieee80211_nullfunc_get(s
ifmgd = &sdata->u.mgd;
local = sdata->local;
- skb = dev_alloc_skb(local->hw.extra_tx_headroom + sizeof(*nullfunc));
+ if (qos_ok) {
+ struct sta_info *sta;
+
+ rcu_read_lock();
+ sta = sta_info_get(sdata, ifmgd->bssid);
+ qos = sta && sta->sta.wme;
+ rcu_read_unlock();
+ }
+
+ skb = dev_alloc_skb(local->hw.extra_tx_headroom +
+ sizeof(*nullfunc) + 2);
if (!skb)
return NULL;
@@ -4429,6 +4441,19 @@ struct sk_buff *ieee80211_nullfunc_get(s
nullfunc->frame_control = cpu_to_le16(IEEE80211_FTYPE_DATA |
IEEE80211_STYPE_NULLFUNC |
IEEE80211_FCTL_TODS);
+ if (qos) {
+ __le16 qos = cpu_to_le16(7);
+
+ BUILD_BUG_ON((IEEE80211_STYPE_QOS_NULLFUNC |
+ IEEE80211_STYPE_NULLFUNC) !=
+ IEEE80211_STYPE_QOS_NULLFUNC);
+ nullfunc->frame_control |=
+ cpu_to_le16(IEEE80211_STYPE_QOS_NULLFUNC);
+ skb->priority = 7;
+ skb_set_queue_mapping(skb, IEEE80211_AC_VO);
+ skb_put_data(skb, &qos, sizeof(qos));
+ }
+
memcpy(nullfunc->addr1, ifmgd->bssid, ETH_ALEN);
memcpy(nullfunc->addr2, vif->addr, ETH_ALEN);
memcpy(nullfunc->addr3, ifmgd->bssid, ETH_ALEN);
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.14/mac80211-fix-the-update-of-path-metric-for-rann-frame.patch
queue-4.14/mac80211-use-qos-ndp-for-ap-probing.patch
This is a note to let you know that I've just added the patch titled
lockd: fix "list_add double add" caused by legacy signal interface
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:
lockd-fix-list_add-double-add-caused-by-legacy-signal-interface.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 Thu Feb 1 13:45:42 CET 2018
From: Vasily Averin <vvs(a)virtuozzo.com>
Date: Mon, 13 Nov 2017 07:25:40 +0300
Subject: lockd: fix "list_add double add" caused by legacy signal interface
From: Vasily Averin <vvs(a)virtuozzo.com>
[ Upstream commit 81833de1a46edce9ca20cfe079872ac1c20ef359 ]
restart_grace() uses hardcoded init_net.
It can cause to "list_add double add" in following scenario:
1) nfsd and lockd was started in several net namespaces
2) nfsd in init_net was stopped (lockd was not stopped because
it have users from another net namespaces)
3) lockd got signal, called restart_grace() -> set_grace_period()
and enabled lock_manager in hardcoded init_net.
4) nfsd in init_net is started again,
its lockd_up() calls set_grace_period() and tries to add
lock_manager into init_net 2nd time.
Jeff Layton suggest:
"Make it safe to call locks_start_grace multiple times on the same
lock_manager. If it's already on the global grace_list, then don't try
to add it again. (But we don't intentionally add twice, so for now we
WARN about that case.)
With this change, we also need to ensure that the nfsd4 lock manager
initializes the list before we call locks_start_grace. While we're at
it, move the rest of the nfsd_net initialization into
nfs4_state_create_net. I see no reason to have it spread over two
functions like it is today."
Suggested patch was updated to generate warning in described situation.
Suggested-by: Jeff Layton <jlayton(a)redhat.com>
Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com>
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs_common/grace.c | 6 +++++-
fs/nfsd/nfs4state.c | 7 ++++---
2 files changed, 9 insertions(+), 4 deletions(-)
--- a/fs/nfs_common/grace.c
+++ b/fs/nfs_common/grace.c
@@ -30,7 +30,11 @@ locks_start_grace(struct net *net, struc
struct list_head *grace_list = net_generic(net, grace_net_id);
spin_lock(&grace_lock);
- list_add(&lm->list, grace_list);
+ if (list_empty(&lm->list))
+ list_add(&lm->list, grace_list);
+ else
+ WARN(1, "double list_add attempt detected in net %x %s\n",
+ net->ns.inum, (net == &init_net) ? "(init_net)" : "");
spin_unlock(&grace_lock);
}
EXPORT_SYMBOL_GPL(locks_start_grace);
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -7021,6 +7021,10 @@ static int nfs4_state_create_net(struct
INIT_LIST_HEAD(&nn->sessionid_hashtbl[i]);
nn->conf_name_tree = RB_ROOT;
nn->unconf_name_tree = RB_ROOT;
+ nn->boot_time = get_seconds();
+ nn->grace_ended = false;
+ nn->nfsd4_manager.block_opens = true;
+ INIT_LIST_HEAD(&nn->nfsd4_manager.list);
INIT_LIST_HEAD(&nn->client_lru);
INIT_LIST_HEAD(&nn->close_lru);
INIT_LIST_HEAD(&nn->del_recall_lru);
@@ -7078,9 +7082,6 @@ nfs4_state_start_net(struct net *net)
ret = nfs4_state_create_net(net);
if (ret)
return ret;
- nn->boot_time = get_seconds();
- nn->grace_ended = false;
- nn->nfsd4_manager.block_opens = true;
locks_start_grace(net, &nn->nfsd4_manager);
nfsd4_client_tracking_init(net);
printk(KERN_INFO "NFSD: starting %ld-second grace period (net %p)\n",
Patches currently in stable-queue which might be from vvs(a)virtuozzo.com are
queue-4.14/lockd-fix-list_add-double-add-caused-by-legacy-signal-interface.patch
queue-4.14/grace-replace-bug_on-by-warn_once-in-exit_net-hook.patch
queue-4.14/perf-core-fix-memory-leak-triggered-by-perf-namespace.patch
queue-4.14/race-of-lockd-inetaddr-notifiers-vs-nlmsvc_rqst-change.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: ioapic: Preserve read-only values in the redirection table
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:
kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.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 Thu Feb 1 13:45:42 CET 2018
From: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
Date: Sun, 5 Nov 2017 15:52:33 +0200
Subject: KVM: x86: ioapic: Preserve read-only values in the redirection table
From: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
[ Upstream commit b200dded0a6974a3b69599832b2203483920ab25 ]
According to 82093AA (IOAPIC) manual, Remote IRR and Delivery Status are
read-only. QEMU implements the bits as RO in commit 479c2a1cb7fb
("ioapic: keep RO bits for IOAPIC entry").
Signed-off-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
Reviewed-by: Liran Alon <liran.alon(a)oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Reviewed-by: Steve Rutherford <srutherford(a)google.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/ioapic.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/arch/x86/kvm/ioapic.c
+++ b/arch/x86/kvm/ioapic.c
@@ -276,6 +276,7 @@ static void ioapic_write_indirect(struct
{
unsigned index;
bool mask_before, mask_after;
+ int old_remote_irr, old_delivery_status;
union kvm_ioapic_redirect_entry *e;
switch (ioapic->ioregsel) {
@@ -298,6 +299,9 @@ static void ioapic_write_indirect(struct
return;
e = &ioapic->redirtbl[index];
mask_before = e->fields.mask;
+ /* Preserve read-only fields */
+ old_remote_irr = e->fields.remote_irr;
+ old_delivery_status = e->fields.delivery_status;
if (ioapic->ioregsel & 1) {
e->bits &= 0xffffffff;
e->bits |= (u64) val << 32;
@@ -305,6 +309,8 @@ static void ioapic_write_indirect(struct
e->bits &= ~0xffffffffULL;
e->bits |= (u32) val;
}
+ e->fields.remote_irr = old_remote_irr;
+ e->fields.delivery_status = old_delivery_status;
/*
* Some OSes (Linux, Xen) assume that Remote IRR bit will
Patches currently in stable-queue which might be from nikita.leshchenko(a)oracle.com are
queue-4.14/kvm-nvmx-fix-vmx_check_nested_events-return-value-in-case-an-event-was-reinjected-to-l2.patch
queue-4.14/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch
queue-4.14/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch
queue-4.14/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch
queue-4.14/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch
queue-4.14/kvm-nvmx-nsvm-don-t-intercept-ud-when-running-l2.patch
queue-4.14/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race
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:
kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.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 Thu Feb 1 13:45:42 CET 2018
From: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
Date: Sun, 5 Nov 2017 15:52:29 +0200
Subject: KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race
From: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
[ Upstream commit 0fc5a36dd6b345eb0d251a65c236e53bead3eef7 ]
KVM uses ioapic_handled_vectors to track vectors that need to notify the
IOAPIC on EOI. The problem is that IOAPIC can be reconfigured while an
interrupt with old configuration is pending or running and
ioapic_handled_vectors only remembers the newest configuration;
thus EOI from the old interrupt is not delievered to the IOAPIC.
A previous commit db2bdcbbbd32
("KVM: x86: fix edge EOI and IOAPIC reconfig race")
addressed this issue by adding pending edge-triggered interrupts to
ioapic_handled_vectors, fixing this race for edge-triggered interrupts.
The commit explicitly ignored level-triggered interrupts,
but this race applies to them as well:
1) IOAPIC sends a level triggered interrupt vector to VCPU0
2) VCPU0's handler deasserts the irq line and reconfigures the IOAPIC
to route the vector to VCPU1. The reconfiguration rewrites only the
upper 32 bits of the IOREDTBLn register. (Causes KVM to update
ioapic_handled_vectors for VCPU0 and it no longer includes the vector.)
3) VCPU0 sends EOI for the vector, but it's not delievered to the
IOAPIC because the ioapic_handled_vectors doesn't include the vector.
4) New interrupts are not delievered to VCPU1 because remote_irr bit
is set forever.
Therefore, the correct behavior is to add all pending and running
interrupts to ioapic_handled_vectors.
This commit introduces a slight performance hit similar to
commit db2bdcbbbd32 ("KVM: x86: fix edge EOI and IOAPIC reconfig race")
for the rare case that the vector is reused by a non-IOAPIC source on
VCPU0. We prefer to keep solution simple and not handle this case just
as the original commit does.
Fixes: db2bdcbbbd32 ("KVM: x86: fix edge EOI and IOAPIC reconfig race")
Signed-off-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
Reviewed-by: Liran Alon <liran.alon(a)oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/ioapic.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/x86/kvm/ioapic.c
+++ b/arch/x86/kvm/ioapic.c
@@ -257,8 +257,7 @@ void kvm_ioapic_scan_entry(struct kvm_vc
index == RTC_GSI) {
if (kvm_apic_match_dest(vcpu, NULL, 0,
e->fields.dest_id, e->fields.dest_mode) ||
- (e->fields.trig_mode == IOAPIC_EDGE_TRIG &&
- kvm_apic_pending_eoi(vcpu, e->fields.vector)))
+ kvm_apic_pending_eoi(vcpu, e->fields.vector))
__set_bit(e->fields.vector,
ioapic_handled_vectors);
}
Patches currently in stable-queue which might be from nikita.leshchenko(a)oracle.com are
queue-4.14/kvm-nvmx-fix-vmx_check_nested_events-return-value-in-case-an-event-was-reinjected-to-l2.patch
queue-4.14/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch
queue-4.14/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch
queue-4.14/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch
queue-4.14/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch
queue-4.14/kvm-nvmx-nsvm-don-t-intercept-ud-when-running-l2.patch
queue-4.14/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: ioapic: Clear Remote IRR when entry is switched to edge-triggered
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:
kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.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 Thu Feb 1 13:45:42 CET 2018
From: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
Date: Sun, 5 Nov 2017 15:52:32 +0200
Subject: KVM: x86: ioapic: Clear Remote IRR when entry is switched to edge-triggered
From: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
[ Upstream commit a8bfec2930525808c01f038825d1df3904638631 ]
Some OSes (Linux, Xen) use this behavior to clear the Remote IRR bit for
IOAPICs without an EOI register. They simulate the EOI message manually
by changing the trigger mode to edge and then back to level, with the
entry being masked during this.
QEMU implements this feature in commit ed1263c363c9
("ioapic: clear remote irr bit for edge-triggered interrupts")
As a side effect, this commit removes an incorrect behavior where Remote
IRR was cleared when the redirection table entry was rewritten. This is not
consistent with the manual and also opens an opportunity for a strange
behavior when a redirection table entry is modified from an interrupt
handler that handles the same entry: The modification will clear the
Remote IRR bit even though the interrupt handler is still running.
Signed-off-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
Reviewed-by: Liran Alon <liran.alon(a)oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Reviewed-by: Steve Rutherford <srutherford(a)google.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/ioapic.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/arch/x86/kvm/ioapic.c
+++ b/arch/x86/kvm/ioapic.c
@@ -304,8 +304,17 @@ static void ioapic_write_indirect(struct
} else {
e->bits &= ~0xffffffffULL;
e->bits |= (u32) val;
- e->fields.remote_irr = 0;
}
+
+ /*
+ * Some OSes (Linux, Xen) assume that Remote IRR bit will
+ * be cleared by IOAPIC hardware when the entry is configured
+ * as edge-triggered. This behavior is used to simulate an
+ * explicit EOI on IOAPICs that don't have the EOI register.
+ */
+ if (e->fields.trig_mode == IOAPIC_EDGE_TRIG)
+ e->fields.remote_irr = 0;
+
mask_after = e->fields.mask;
if (mask_before != mask_after)
kvm_fire_mask_notifiers(ioapic->kvm, KVM_IRQCHIP_IOAPIC, index, mask_after);
Patches currently in stable-queue which might be from nikita.leshchenko(a)oracle.com are
queue-4.14/kvm-nvmx-fix-vmx_check_nested_events-return-value-in-case-an-event-was-reinjected-to-l2.patch
queue-4.14/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch
queue-4.14/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch
queue-4.14/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch
queue-4.14/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch
queue-4.14/kvm-nvmx-nsvm-don-t-intercept-ud-when-running-l2.patch
queue-4.14/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch
This is a note to let you know that I've just added the patch titled
KVM: X86: Fix softlockup when get the current kvmclock
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:
kvm-x86-fix-softlockup-when-get-the-current-kvmclock.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 Thu Feb 1 13:45:42 CET 2018
From: Wanpeng Li <kernellwp(a)gmail.com>
Date: Mon, 20 Nov 2017 14:55:05 -0800
Subject: KVM: X86: Fix softlockup when get the current kvmclock
From: Wanpeng Li <kernellwp(a)gmail.com>
[ Upstream commit e70b57a6ce4e8b92a56a615ae79bdb2bd66035e7 ]
watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [qemu-system-x86:10185]
CPU: 6 PID: 10185 Comm: qemu-system-x86 Tainted: G OE 4.14.0-rc4+ #4
RIP: 0010:kvm_get_time_scale+0x4e/0xa0 [kvm]
Call Trace:
get_time_ref_counter+0x5a/0x80 [kvm]
kvm_hv_process_stimers+0x120/0x5f0 [kvm]
kvm_arch_vcpu_ioctl_run+0x4b4/0x1690 [kvm]
kvm_vcpu_ioctl+0x33a/0x620 [kvm]
do_vfs_ioctl+0xa1/0x5d0
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x1e/0xa9
This can be reproduced when running kvm-unit-tests/hyperv_stimer.flat and
cpu-hotplug stress simultaneously. __this_cpu_read(cpu_tsc_khz) returns 0
(set in kvmclock_cpu_down_prep()) when the pCPU is unhotplug which results
in kvm_get_time_scale() gets into an infinite loop.
This patch fixes it by treating the unhotplug pCPU as not using master clock.
Reviewed-by: Radim Krčmář <rkrcmar(a)redhat.com>
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/x86.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1795,10 +1795,13 @@ u64 get_kvmclock_ns(struct kvm *kvm)
/* both __this_cpu_read() and rdtsc() should be on the same cpu */
get_cpu();
- kvm_get_time_scale(NSEC_PER_SEC, __this_cpu_read(cpu_tsc_khz) * 1000LL,
- &hv_clock.tsc_shift,
- &hv_clock.tsc_to_system_mul);
- ret = __pvclock_read_cycles(&hv_clock, rdtsc());
+ if (__this_cpu_read(cpu_tsc_khz)) {
+ kvm_get_time_scale(NSEC_PER_SEC, __this_cpu_read(cpu_tsc_khz) * 1000LL,
+ &hv_clock.tsc_shift,
+ &hv_clock.tsc_to_system_mul);
+ ret = __pvclock_read_cycles(&hv_clock, rdtsc());
+ } else
+ ret = ktime_get_boot_ns() + ka->kvmclock_offset;
put_cpu();
Patches currently in stable-queue which might be from kernellwp(a)gmail.com are
queue-4.14/kvm-x86-fix-softlockup-when-get-the-current-kvmclock.patch
This is a note to let you know that I've just added the patch titled
KVM: X86: Fix operand/address-size during instruction decoding
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:
kvm-x86-fix-operand-address-size-during-instruction-decoding.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 Thu Feb 1 13:45:42 CET 2018
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
Date: Sun, 5 Nov 2017 16:54:47 -0800
Subject: KVM: X86: Fix operand/address-size during instruction decoding
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
[ Upstream commit 3853be2603191829b442b64dac6ae8ba0c027bf9 ]
Pedro reported:
During tests that we conducted on KVM, we noticed that executing a "PUSH %ES"
instruction under KVM produces different results on both memory and the SP
register depending on whether EPT support is enabled. With EPT the SP is
reduced by 4 bytes (and the written value is 0-padded) but without EPT support
it is only reduced by 2 bytes. The difference can be observed when the CS.DB
field is 1 (32-bit) but not when it's 0 (16-bit).
The internal segment descriptor cache exist even in real/vm8096 mode. The CS.D
also should be respected instead of just default operand/address-size/66H
prefix/67H prefix during instruction decoding. This patch fixes it by also
adjusting operand/address-size according to CS.D.
Reported-by: Pedro Fonseca <pfonseca(a)cs.washington.edu>
Tested-by: Pedro Fonseca <pfonseca(a)cs.washington.edu>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Cc: Nadav Amit <nadav.amit(a)gmail.com>
Cc: Pedro Fonseca <pfonseca(a)cs.washington.edu>
Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Reviewed-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/emulate.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -5009,6 +5009,8 @@ int x86_decode_insn(struct x86_emulate_c
bool op_prefix = false;
bool has_seg_override = false;
struct opcode opcode;
+ u16 dummy;
+ struct desc_struct desc;
ctxt->memop.type = OP_NONE;
ctxt->memopp = NULL;
@@ -5027,6 +5029,11 @@ int x86_decode_insn(struct x86_emulate_c
switch (mode) {
case X86EMUL_MODE_REAL:
case X86EMUL_MODE_VM86:
+ def_op_bytes = def_ad_bytes = 2;
+ ctxt->ops->get_segment(ctxt, &dummy, &desc, NULL, VCPU_SREG_CS);
+ if (desc.d)
+ def_op_bytes = def_ad_bytes = 4;
+ break;
case X86EMUL_MODE_PROT16:
def_op_bytes = def_ad_bytes = 2;
break;
Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are
queue-4.14/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch
queue-4.14/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch
queue-4.14/kvm-nvmx-fix-mmu-context-after-vmlaunch-vmresume-failure.patch
queue-4.14/kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch
queue-4.14/kvm-x86-fix-operand-address-size-during-instruction-decoding.patch
queue-4.14/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch
queue-4.14/kvm-nvmx-nsvm-don-t-intercept-ud-when-running-l2.patch
queue-4.14/kvm-x86-fix-softlockup-when-get-the-current-kvmclock.patch
queue-4.14/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure
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:
kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.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 Thu Feb 1 13:45:42 CET 2018
From: Liran Alon <liran.alon(a)oracle.com>
Date: Sun, 5 Nov 2017 16:56:33 +0200
Subject: KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure
From: Liran Alon <liran.alon(a)oracle.com>
[ Upstream commit 1f4dcb3b213235e642088709a1c54964d23365e9 ]
On this case, handle_emulation_failure() fills kvm_run with
internal-error information which it expects to be delivered
to user-mode for further processing.
However, the code reports a wrong return-value which makes KVM to never
return to user-mode on this scenario.
Fixes: 6d77dbfc88e3 ("KVM: inject #UD if instruction emulation fails and exit to
userspace")
Signed-off-by: Liran Alon <liran.alon(a)oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5416,7 +5416,7 @@ static int handle_emulation_failure(stru
vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
vcpu->run->internal.suberror = KVM_INTERNAL_ERROR_EMULATION;
vcpu->run->internal.ndata = 0;
- r = EMULATE_FAIL;
+ r = EMULATE_USER_EXIT;
}
kvm_queue_exception(vcpu, UD_VECTOR);
Patches currently in stable-queue which might be from liran.alon(a)oracle.com are
queue-4.14/kvm-nvmx-fix-vmx_check_nested_events-return-value-in-case-an-event-was-reinjected-to-l2.patch
queue-4.14/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch
queue-4.14/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch
queue-4.14/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch
queue-4.14/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch
queue-4.14/kvm-nvmx-nsvm-don-t-intercept-ud-when-running-l2.patch
queue-4.14/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: emulate #UD while in guest mode
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:
kvm-x86-emulate-ud-while-in-guest-mode.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 Thu Feb 1 13:45:42 CET 2018
From: Paolo Bonzini <pbonzini(a)redhat.com>
Date: Thu, 11 Jan 2018 16:55:24 +0100
Subject: KVM: x86: emulate #UD while in guest mode
From: Paolo Bonzini <pbonzini(a)redhat.com>
[ Upstream commit bd89525a823ce6edddcedbe9aed79faa1b9cf544 ]
This reverts commits ae1f57670703656cc9f293722c3b8b6782f8ab3f
and ac9b305caa0df6f5b75d294e4b86c1027648991e.
If the hardware doesn't support MOVBE, but L0 sets CPUID.01H:ECX.MOVBE
in L1's emulated CPUID information, then L1 is likely to pass that
CPUID bit through to L2. L2 will expect MOVBE to work, but if L1
doesn't intercept #UD, then any MOVBE instruction executed in L2 will
raise #UD, and the exception will be delivered in L2.
Commit ac9b305caa0df6f5b75d294e4b86c1027648991e is a better and more
complete version of ae1f57670703 ("KVM: nVMX: Do not emulate #UD while
in guest mode"); however, neither considers the above case.
Suggested-by: Jim Mattson <jmattson(a)redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini(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/kvm/svm.c | 9 +--------
arch/x86/kvm/vmx.c | 5 +----
2 files changed, 2 insertions(+), 12 deletions(-)
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -362,7 +362,6 @@ static void recalc_intercepts(struct vcp
{
struct vmcb_control_area *c, *h;
struct nested_state *g;
- u32 h_intercept_exceptions;
mark_dirty(svm->vmcb, VMCB_INTERCEPTS);
@@ -373,14 +372,9 @@ static void recalc_intercepts(struct vcp
h = &svm->nested.hsave->control;
g = &svm->nested;
- /* No need to intercept #UD if L1 doesn't intercept it */
- h_intercept_exceptions =
- h->intercept_exceptions & ~(1U << UD_VECTOR);
-
c->intercept_cr = h->intercept_cr | g->intercept_cr;
c->intercept_dr = h->intercept_dr | g->intercept_dr;
- c->intercept_exceptions =
- h_intercept_exceptions | g->intercept_exceptions;
+ c->intercept_exceptions = h->intercept_exceptions | g->intercept_exceptions;
c->intercept = h->intercept | g->intercept;
}
@@ -2195,7 +2189,6 @@ static int ud_interception(struct vcpu_s
{
int er;
- WARN_ON_ONCE(is_guest_mode(&svm->vcpu));
er = emulate_instruction(&svm->vcpu, EMULTYPE_TRAP_UD);
if (er == EMULATE_USER_EXIT)
return 0;
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1891,7 +1891,7 @@ static void update_exception_bitmap(stru
{
u32 eb;
- eb = (1u << PF_VECTOR) | (1u << MC_VECTOR) |
+ eb = (1u << PF_VECTOR) | (1u << UD_VECTOR) | (1u << MC_VECTOR) |
(1u << DB_VECTOR) | (1u << AC_VECTOR);
if ((vcpu->guest_debug &
(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
@@ -1909,8 +1909,6 @@ static void update_exception_bitmap(stru
*/
if (is_guest_mode(vcpu))
eb |= get_vmcs12(vcpu)->exception_bitmap;
- else
- eb |= 1u << UD_VECTOR;
vmcs_write32(EXCEPTION_BITMAP, eb);
}
@@ -5921,7 +5919,6 @@ static int handle_exception(struct kvm_v
return 1; /* already handled by vmx_vcpu_run() */
if (is_invalid_opcode(intr_info)) {
- WARN_ON_ONCE(is_guest_mode(vcpu));
er = emulate_instruction(vcpu, EMULTYPE_TRAP_UD);
if (er == EMULATE_USER_EXIT)
return 0;
Patches currently in stable-queue which might be from pbonzini(a)redhat.com are
queue-4.14/kvm-nvmx-fix-mmu-context-after-vmlaunch-vmresume-failure.patch
queue-4.14/kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch
queue-4.14/kvm-x86-emulate-ud-while-in-guest-mode.patch
queue-4.14/kvm-x86-fix-operand-address-size-during-instruction-decoding.patch
queue-4.14/kvm-nvmx-nsvm-don-t-intercept-ud-when-running-l2.patch
queue-4.14/kvm-let-kvm_set_signal_mask-work-as-advertised.patch
queue-4.14/kvm-x86-fix-softlockup-when-get-the-current-kvmclock.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: Don't re-execute instruction when not passing CR2 value
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:
kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.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 Thu Feb 1 13:45:42 CET 2018
From: Liran Alon <liran.alon(a)oracle.com>
Date: Sun, 5 Nov 2017 16:56:34 +0200
Subject: KVM: x86: Don't re-execute instruction when not passing CR2 value
From: Liran Alon <liran.alon(a)oracle.com>
[ Upstream commit 9b8ae63798cb97e785a667ff27e43fa6220cb734 ]
In case of instruction-decode failure or emulation failure,
x86_emulate_instruction() will call reexecute_instruction() which will
attempt to use the cr2 value passed to x86_emulate_instruction().
However, when x86_emulate_instruction() is called from
emulate_instruction(), cr2 is not passed (passed as 0) and therefore
it doesn't make sense to execute reexecute_instruction() logic at all.
Fixes: 51d8b66199e9 ("KVM: cleanup emulate_instruction")
Signed-off-by: Liran Alon <liran.alon(a)oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/kvm_host.h | 3 ++-
arch/x86/kvm/vmx.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1156,7 +1156,8 @@ int x86_emulate_instruction(struct kvm_v
static inline int emulate_instruction(struct kvm_vcpu *vcpu,
int emulation_type)
{
- return x86_emulate_instruction(vcpu, 0, emulation_type, NULL, 0);
+ return x86_emulate_instruction(vcpu, 0,
+ emulation_type | EMULTYPE_NO_REEXECUTE, NULL, 0);
}
void kvm_enable_efer_bits(u64);
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6607,7 +6607,7 @@ static int handle_invalid_guest_state(st
if (kvm_test_request(KVM_REQ_EVENT, vcpu))
return 1;
- err = emulate_instruction(vcpu, EMULTYPE_NO_REEXECUTE);
+ err = emulate_instruction(vcpu, 0);
if (err == EMULATE_USER_EXIT) {
++vcpu->stat.mmio_exits;
Patches currently in stable-queue which might be from liran.alon(a)oracle.com are
queue-4.14/kvm-nvmx-fix-vmx_check_nested_events-return-value-in-case-an-event-was-reinjected-to-l2.patch
queue-4.14/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch
queue-4.14/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch
queue-4.14/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch
queue-4.14/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch
queue-4.14/kvm-nvmx-nsvm-don-t-intercept-ud-when-running-l2.patch
queue-4.14/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch
This is a note to let you know that I've just added the patch titled
KVM: VMX: Fix rflags cache during vCPU reset
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:
kvm-vmx-fix-rflags-cache-during-vcpu-reset.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 Thu Feb 1 13:45:42 CET 2018
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
Date: Mon, 20 Nov 2017 14:52:21 -0800
Subject: KVM: VMX: Fix rflags cache during vCPU reset
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
[ Upstream commit c37c28730bb031cc8a44a130c2555c0f3efbe2d0 ]
Reported by syzkaller:
*** Guest State ***
CR0: actual=0x0000000080010031, shadow=0x0000000060000010, gh_mask=fffffffffffffff7
CR4: actual=0x0000000000002061, shadow=0x0000000000000000, gh_mask=ffffffffffffe8f1
CR3 = 0x000000002081e000
RSP = 0x000000000000fffa RIP = 0x0000000000000000
RFLAGS=0x00023000 DR7 = 0x00000000000000
^^^^^^^^^^
------------[ cut here ]------------
WARNING: CPU: 6 PID: 24431 at /home/kernel/linux/arch/x86/kvm//x86.c:7302 kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm]
CPU: 6 PID: 24431 Comm: reprotest Tainted: G W OE 4.14.0+ #26
RIP: 0010:kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm]
RSP: 0018:ffff880291d179e0 EFLAGS: 00010202
Call Trace:
kvm_vcpu_ioctl+0x479/0x880 [kvm]
do_vfs_ioctl+0x142/0x9a0
SyS_ioctl+0x74/0x80
entry_SYSCALL_64_fastpath+0x23/0x9a
The failed vmentry is triggered by the following beautified testcase:
#include <unistd.h>
#include <sys/syscall.h>
#include <string.h>
#include <stdint.h>
#include <linux/kvm.h>
#include <fcntl.h>
#include <sys/ioctl.h>
long r[5];
int main()
{
struct kvm_debugregs dr = { 0 };
r[2] = open("/dev/kvm", O_RDONLY);
r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7);
struct kvm_guest_debug debug = {
.control = 0xf0403,
.arch = {
.debugreg[6] = 0x2,
.debugreg[7] = 0x2
}
};
ioctl(r[4], KVM_SET_GUEST_DEBUG, &debug);
ioctl(r[4], KVM_RUN, 0);
}
which testcase tries to setup the processor specific debug
registers and configure vCPU for handling guest debug events through
KVM_SET_GUEST_DEBUG. The KVM_SET_GUEST_DEBUG ioctl will get and set
rflags in order to set TF bit if single step is needed. All regs' caches
are reset to avail and GUEST_RFLAGS vmcs field is reset to 0x2 during vCPU
reset. However, the cache of rflags is not reset during vCPU reset. The
function vmx_get_rflags() returns an unreset rflags cache value since
the cache is marked avail, it is 0 after boot. Vmentry fails if the
rflags reserved bit 1 is 0.
This patch fixes it by resetting both the GUEST_RFLAGS vmcs field and
its cache to 0x2 during vCPU reset.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Tested-by: Dmitry Vyukov <dvyukov(a)google.com>
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Cc: Nadav Amit <nadav.amit(a)gmail.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5608,7 +5608,7 @@ static void vmx_vcpu_reset(struct kvm_vc
vmcs_write64(GUEST_IA32_DEBUGCTL, 0);
}
- vmcs_writel(GUEST_RFLAGS, 0x02);
+ kvm_set_rflags(vcpu, X86_EFLAGS_FIXED);
kvm_rip_write(vcpu, 0xfff0);
vmcs_writel(GUEST_GDTR_BASE, 0);
Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are
queue-4.14/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch
queue-4.14/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch
queue-4.14/kvm-nvmx-fix-mmu-context-after-vmlaunch-vmresume-failure.patch
queue-4.14/kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch
queue-4.14/kvm-x86-fix-operand-address-size-during-instruction-decoding.patch
queue-4.14/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch
queue-4.14/kvm-nvmx-nsvm-don-t-intercept-ud-when-running-l2.patch
queue-4.14/kvm-x86-fix-softlockup-when-get-the-current-kvmclock.patch
queue-4.14/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch
This is a note to let you know that I've just added the patch titled
KVM: nVMX/nSVM: Don't intercept #UD when running L2
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:
kvm-nvmx-nsvm-don-t-intercept-ud-when-running-l2.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 Thu Feb 1 13:45:42 CET 2018
From: Liran Alon <liran.alon(a)oracle.com>
Date: Mon, 6 Nov 2017 16:15:10 +0200
Subject: KVM: nVMX/nSVM: Don't intercept #UD when running L2
From: Liran Alon <liran.alon(a)oracle.com>
[ Upstream commit ac9b305caa0df6f5b75d294e4b86c1027648991e ]
When running L2, #UD should be intercepted by L1 or just forwarded
directly to L2. It should not reach L0 x86 emulator.
Therefore, set intercept for #UD only based on L1 exception-bitmap.
Also add WARN_ON_ONCE() on L0 #UD intercept handlers to make sure
it is never reached while running L2.
This improves commit ae1f57670703 ("KVM: nVMX: Do not emulate #UD while
in guest mode") by removing an unnecessary exit from L2 to L0 on #UD
when L1 doesn't intercept it.
In addition, SVM L0 #UD intercept handler doesn't handle correctly the
case it is raised from L2. In this case, it should forward the #UD to
guest instead of x86 emulator. As done in VMX #UD intercept handler.
This commit fixes this issue as-well.
Signed-off-by: Liran Alon <liran.alon(a)oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Reviewed-by: Paolo Bonzini <pbonzini(a)redhat.com>
Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/svm.c | 9 ++++++++-
arch/x86/kvm/vmx.c | 9 ++++-----
2 files changed, 12 insertions(+), 6 deletions(-)
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -362,6 +362,7 @@ static void recalc_intercepts(struct vcp
{
struct vmcb_control_area *c, *h;
struct nested_state *g;
+ u32 h_intercept_exceptions;
mark_dirty(svm->vmcb, VMCB_INTERCEPTS);
@@ -372,9 +373,14 @@ static void recalc_intercepts(struct vcp
h = &svm->nested.hsave->control;
g = &svm->nested;
+ /* No need to intercept #UD if L1 doesn't intercept it */
+ h_intercept_exceptions =
+ h->intercept_exceptions & ~(1U << UD_VECTOR);
+
c->intercept_cr = h->intercept_cr | g->intercept_cr;
c->intercept_dr = h->intercept_dr | g->intercept_dr;
- c->intercept_exceptions = h->intercept_exceptions | g->intercept_exceptions;
+ c->intercept_exceptions =
+ h_intercept_exceptions | g->intercept_exceptions;
c->intercept = h->intercept | g->intercept;
}
@@ -2189,6 +2195,7 @@ static int ud_interception(struct vcpu_s
{
int er;
+ WARN_ON_ONCE(is_guest_mode(&svm->vcpu));
er = emulate_instruction(&svm->vcpu, EMULTYPE_TRAP_UD);
if (er == EMULATE_USER_EXIT)
return 0;
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1891,7 +1891,7 @@ static void update_exception_bitmap(stru
{
u32 eb;
- eb = (1u << PF_VECTOR) | (1u << UD_VECTOR) | (1u << MC_VECTOR) |
+ eb = (1u << PF_VECTOR) | (1u << MC_VECTOR) |
(1u << DB_VECTOR) | (1u << AC_VECTOR);
if ((vcpu->guest_debug &
(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
@@ -1909,6 +1909,8 @@ static void update_exception_bitmap(stru
*/
if (is_guest_mode(vcpu))
eb |= get_vmcs12(vcpu)->exception_bitmap;
+ else
+ eb |= 1u << UD_VECTOR;
vmcs_write32(EXCEPTION_BITMAP, eb);
}
@@ -5919,10 +5921,7 @@ static int handle_exception(struct kvm_v
return 1; /* already handled by vmx_vcpu_run() */
if (is_invalid_opcode(intr_info)) {
- if (is_guest_mode(vcpu)) {
- kvm_queue_exception(vcpu, UD_VECTOR);
- return 1;
- }
+ WARN_ON_ONCE(is_guest_mode(vcpu));
er = emulate_instruction(vcpu, EMULTYPE_TRAP_UD);
if (er == EMULATE_USER_EXIT)
return 0;
Patches currently in stable-queue which might be from liran.alon(a)oracle.com are
queue-4.14/kvm-nvmx-fix-vmx_check_nested_events-return-value-in-case-an-event-was-reinjected-to-l2.patch
queue-4.14/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch
queue-4.14/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch
queue-4.14/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch
queue-4.14/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch
queue-4.14/kvm-nvmx-nsvm-don-t-intercept-ud-when-running-l2.patch
queue-4.14/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch
This is a note to let you know that I've just added the patch titled
KVM: nVMX: Fix vmx_check_nested_events() return value in case an event was reinjected to L2
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:
kvm-nvmx-fix-vmx_check_nested_events-return-value-in-case-an-event-was-reinjected-to-l2.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 Thu Feb 1 13:45:42 CET 2018
From: Liran Alon <liran.alon(a)oracle.com>
Date: Sun, 5 Nov 2017 16:07:43 +0200
Subject: KVM: nVMX: Fix vmx_check_nested_events() return value in case an event was reinjected to L2
From: Liran Alon <liran.alon(a)oracle.com>
[ Upstream commit 917dc6068bc12a2dafffcf0e9d405ddb1b8780cb ]
vmx_check_nested_events() should return -EBUSY only in case there is a
pending L1 event which requires a VMExit from L2 to L1 but such a
VMExit is currently blocked. Such VMExits are blocked either
because nested_run_pending=1 or an event was reinjected to L2.
vmx_check_nested_events() should return 0 in case there are no
pending L1 events which requires a VMExit from L2 to L1 or if
a VMExit from L2 to L1 was done internally.
However, upstream commit which introduced blocking in case an event was
reinjected to L2 (commit acc9ab601327 ("KVM: nVMX: Fix pending events
injection")) contains a bug: It returns -EBUSY even if there are no
pending L1 events which requires VMExit from L2 to L1.
This commit fix this issue.
Fixes: acc9ab601327 ("KVM: nVMX: Fix pending events injection")
Signed-off-by: Liran Alon <liran.alon(a)oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -11114,13 +11114,12 @@ static int vmx_check_nested_events(struc
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
unsigned long exit_qual;
-
- if (kvm_event_needs_reinjection(vcpu))
- return -EBUSY;
+ bool block_nested_events =
+ vmx->nested.nested_run_pending || kvm_event_needs_reinjection(vcpu);
if (vcpu->arch.exception.pending &&
nested_vmx_check_exception(vcpu, &exit_qual)) {
- if (vmx->nested.nested_run_pending)
+ if (block_nested_events)
return -EBUSY;
nested_vmx_inject_exception_vmexit(vcpu, exit_qual);
vcpu->arch.exception.pending = false;
@@ -11129,14 +11128,14 @@ static int vmx_check_nested_events(struc
if (nested_cpu_has_preemption_timer(get_vmcs12(vcpu)) &&
vmx->nested.preemption_timer_expired) {
- if (vmx->nested.nested_run_pending)
+ if (block_nested_events)
return -EBUSY;
nested_vmx_vmexit(vcpu, EXIT_REASON_PREEMPTION_TIMER, 0, 0);
return 0;
}
if (vcpu->arch.nmi_pending && nested_exit_on_nmi(vcpu)) {
- if (vmx->nested.nested_run_pending)
+ if (block_nested_events)
return -EBUSY;
nested_vmx_vmexit(vcpu, EXIT_REASON_EXCEPTION_NMI,
NMI_VECTOR | INTR_TYPE_NMI_INTR |
@@ -11152,7 +11151,7 @@ static int vmx_check_nested_events(struc
if ((kvm_cpu_has_interrupt(vcpu) || external_intr) &&
nested_exit_on_intr(vcpu)) {
- if (vmx->nested.nested_run_pending)
+ if (block_nested_events)
return -EBUSY;
nested_vmx_vmexit(vcpu, EXIT_REASON_EXTERNAL_INTERRUPT, 0, 0);
return 0;
Patches currently in stable-queue which might be from liran.alon(a)oracle.com are
queue-4.14/kvm-nvmx-fix-vmx_check_nested_events-return-value-in-case-an-event-was-reinjected-to-l2.patch
queue-4.14/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch
queue-4.14/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch
queue-4.14/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch
queue-4.14/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch
queue-4.14/kvm-nvmx-nsvm-don-t-intercept-ud-when-running-l2.patch
queue-4.14/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch
This is a note to let you know that I've just added the patch titled
KVM: nVMX: Fix mmu context after VMLAUNCH/VMRESUME failure
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:
kvm-nvmx-fix-mmu-context-after-vmlaunch-vmresume-failure.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 Thu Feb 1 13:45:42 CET 2018
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
Date: Sun, 5 Nov 2017 16:54:49 -0800
Subject: KVM: nVMX: Fix mmu context after VMLAUNCH/VMRESUME failure
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
[ Upstream commit 5af4157388adad82c339e3742fb6b67840721347 ]
Commit 4f350c6dbcb (kvm: nVMX: Handle deferred early VMLAUNCH/VMRESUME failure
properly) can result in L1(run kvm-unit-tests/run_tests.sh vmx_controls in L1)
null pointer deference and also L0 calltrace when EPT=0 on both L0 and L1.
In L1:
BUG: unable to handle kernel paging request at ffffffffc015bf8f
IP: vmx_vcpu_run+0x202/0x510 [kvm_intel]
PGD 146e13067 P4D 146e13067 PUD 146e15067 PMD 3d2686067 PTE 3d4af9161
Oops: 0003 [#1] PREEMPT SMP
CPU: 2 PID: 1798 Comm: qemu-system-x86 Not tainted 4.14.0-rc4+ #6
RIP: 0010:vmx_vcpu_run+0x202/0x510 [kvm_intel]
Call Trace:
WARNING: kernel stack frame pointer at ffffb86f4988bc18 in qemu-system-x86:1798 has bad value 0000000000000002
In L0:
-----------[ cut here ]------------
WARNING: CPU: 6 PID: 4460 at /home/kernel/linux/arch/x86/kvm//vmx.c:9845 vmx_inject_page_fault_nested+0x130/0x140 [kvm_intel]
CPU: 6 PID: 4460 Comm: qemu-system-x86 Tainted: G OE 4.14.0-rc7+ #25
RIP: 0010:vmx_inject_page_fault_nested+0x130/0x140 [kvm_intel]
Call Trace:
paging64_page_fault+0x500/0xde0 [kvm]
? paging32_gva_to_gpa_nested+0x120/0x120 [kvm]
? nonpaging_page_fault+0x3b0/0x3b0 [kvm]
? __asan_storeN+0x12/0x20
? paging64_gva_to_gpa+0xb0/0x120 [kvm]
? paging64_walk_addr_generic+0x11a0/0x11a0 [kvm]
? lock_acquire+0x2c0/0x2c0
? vmx_read_guest_seg_ar+0x97/0x100 [kvm_intel]
? vmx_get_segment+0x2a6/0x310 [kvm_intel]
? sched_clock+0x1f/0x30
? check_chain_key+0x137/0x1e0
? __lock_acquire+0x83c/0x2420
? kvm_multiple_exception+0xf2/0x220 [kvm]
? debug_check_no_locks_freed+0x240/0x240
? debug_smp_processor_id+0x17/0x20
? __lock_is_held+0x9e/0x100
kvm_mmu_page_fault+0x90/0x180 [kvm]
kvm_handle_page_fault+0x15c/0x310 [kvm]
? __lock_is_held+0x9e/0x100
handle_exception+0x3c7/0x4d0 [kvm_intel]
vmx_handle_exit+0x103/0x1010 [kvm_intel]
? kvm_arch_vcpu_ioctl_run+0x1628/0x2e20 [kvm]
The commit avoids to load host state of vmcs12 as vmcs01's guest state
since vmcs12 is not modified (except for the VM-instruction error field)
if the checking of vmcs control area fails. However, the mmu context is
switched to nested mmu in prepare_vmcs02() and it will not be reloaded
since load_vmcs12_host_state() is skipped when nested VMLAUNCH/VMRESUME
fails. This patch fixes it by reloading mmu context when nested
VMLAUNCH/VMRESUME fails.
Reviewed-by: Jim Mattson <jmattson(a)google.com>
Reviewed-by: Krish Sadhukhan <krish.sadhukhan(a)oracle.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Cc: Jim Mattson <jmattson(a)google.com>
Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Reviewed-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 34 ++++++++++++++++++++++------------
1 file changed, 22 insertions(+), 12 deletions(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -11339,6 +11339,24 @@ static void prepare_vmcs12(struct kvm_vc
kvm_clear_interrupt_queue(vcpu);
}
+static void load_vmcs12_mmu_host_state(struct kvm_vcpu *vcpu,
+ struct vmcs12 *vmcs12)
+{
+ u32 entry_failure_code;
+
+ nested_ept_uninit_mmu_context(vcpu);
+
+ /*
+ * Only PDPTE load can fail as the value of cr3 was checked on entry and
+ * couldn't have changed.
+ */
+ if (nested_vmx_load_cr3(vcpu, vmcs12->host_cr3, false, &entry_failure_code))
+ nested_vmx_abort(vcpu, VMX_ABORT_LOAD_HOST_PDPTE_FAIL);
+
+ if (!enable_ept)
+ vcpu->arch.walk_mmu->inject_page_fault = kvm_inject_page_fault;
+}
+
/*
* A part of what we need to when the nested L2 guest exits and we want to
* run its L1 parent, is to reset L1's guest state to the host state specified
@@ -11352,7 +11370,6 @@ static void load_vmcs12_host_state(struc
struct vmcs12 *vmcs12)
{
struct kvm_segment seg;
- u32 entry_failure_code;
if (vmcs12->vm_exit_controls & VM_EXIT_LOAD_IA32_EFER)
vcpu->arch.efer = vmcs12->host_ia32_efer;
@@ -11379,17 +11396,7 @@ static void load_vmcs12_host_state(struc
vcpu->arch.cr4_guest_owned_bits = ~vmcs_readl(CR4_GUEST_HOST_MASK);
vmx_set_cr4(vcpu, vmcs12->host_cr4);
- nested_ept_uninit_mmu_context(vcpu);
-
- /*
- * Only PDPTE load can fail as the value of cr3 was checked on entry and
- * couldn't have changed.
- */
- if (nested_vmx_load_cr3(vcpu, vmcs12->host_cr3, false, &entry_failure_code))
- nested_vmx_abort(vcpu, VMX_ABORT_LOAD_HOST_PDPTE_FAIL);
-
- if (!enable_ept)
- vcpu->arch.walk_mmu->inject_page_fault = kvm_inject_page_fault;
+ load_vmcs12_mmu_host_state(vcpu, vmcs12);
if (enable_vpid) {
/*
@@ -11615,6 +11622,9 @@ static void nested_vmx_vmexit(struct kvm
* accordingly.
*/
nested_vmx_failValid(vcpu, VMXERR_ENTRY_INVALID_CONTROL_FIELD);
+
+ load_vmcs12_mmu_host_state(vcpu, vmcs12);
+
/*
* The emulated instruction was already skipped in
* nested_vmx_run, but the updated RIP was never
Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are
queue-4.14/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch
queue-4.14/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch
queue-4.14/kvm-nvmx-fix-mmu-context-after-vmlaunch-vmresume-failure.patch
queue-4.14/kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch
queue-4.14/kvm-x86-fix-operand-address-size-during-instruction-decoding.patch
queue-4.14/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch
queue-4.14/kvm-nvmx-nsvm-don-t-intercept-ud-when-running-l2.patch
queue-4.14/kvm-x86-fix-softlockup-when-get-the-current-kvmclock.patch
queue-4.14/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch
This is a note to let you know that I've just added the patch titled
KVM: Let KVM_SET_SIGNAL_MASK work as advertised
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:
kvm-let-kvm_set_signal_mask-work-as-advertised.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 Thu Feb 1 13:45:42 CET 2018
From: "Jan H. Schönherr" <jschoenh(a)amazon.de>
Date: Fri, 24 Nov 2017 22:39:01 +0100
Subject: KVM: Let KVM_SET_SIGNAL_MASK work as advertised
From: "Jan H. Schönherr" <jschoenh(a)amazon.de>
[ Upstream commit 20b7035c66bacc909ae3ffe92c1a1ea7db99fe4f ]
KVM API says for the signal mask you set via KVM_SET_SIGNAL_MASK, that
"any unblocked signal received [...] will cause KVM_RUN to return with
-EINTR" and that "the signal will only be delivered if not blocked by
the original signal mask".
This, however, is only true, when the calling task has a signal handler
registered for a signal. If not, signal evaluation is short-circuited for
SIG_IGN and SIG_DFL, and the signal is either ignored without KVM_RUN
returning or the whole process is terminated.
Make KVM_SET_SIGNAL_MASK behave as advertised by utilizing logic similar
to that in do_sigtimedwait() to avoid short-circuiting of signals.
Signed-off-by: Jan H. Schönherr <jschoenh(a)amazon.de>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kvm/mips.c | 7 ++-----
arch/powerpc/kvm/powerpc.c | 7 ++-----
arch/s390/kvm/kvm-s390.c | 7 ++-----
arch/x86/kvm/x86.c | 7 ++-----
include/linux/kvm_host.h | 3 +++
virt/kvm/arm/arm.c | 8 +++-----
virt/kvm/kvm_main.c | 23 +++++++++++++++++++++++
7 files changed, 37 insertions(+), 25 deletions(-)
--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -445,10 +445,8 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(
int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
{
int r = -EINTR;
- sigset_t sigsaved;
- if (vcpu->sigset_active)
- sigprocmask(SIG_SETMASK, &vcpu->sigset, &sigsaved);
+ kvm_sigset_activate(vcpu);
if (vcpu->mmio_needed) {
if (!vcpu->mmio_is_write)
@@ -480,8 +478,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
local_irq_enable();
out:
- if (vcpu->sigset_active)
- sigprocmask(SIG_SETMASK, &sigsaved, NULL);
+ kvm_sigset_deactivate(vcpu);
return r;
}
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -1407,7 +1407,6 @@ int kvm_vcpu_ioctl_set_one_reg(struct kv
int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
{
int r;
- sigset_t sigsaved;
if (vcpu->mmio_needed) {
vcpu->mmio_needed = 0;
@@ -1448,16 +1447,14 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
#endif
}
- if (vcpu->sigset_active)
- sigprocmask(SIG_SETMASK, &vcpu->sigset, &sigsaved);
+ kvm_sigset_activate(vcpu);
if (run->immediate_exit)
r = -EINTR;
else
r = kvmppc_vcpu_run(run, vcpu);
- if (vcpu->sigset_active)
- sigprocmask(SIG_SETMASK, &sigsaved, NULL);
+ kvm_sigset_deactivate(vcpu);
return r;
}
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -3378,7 +3378,6 @@ static void store_regs(struct kvm_vcpu *
int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
{
int rc;
- sigset_t sigsaved;
if (kvm_run->immediate_exit)
return -EINTR;
@@ -3388,8 +3387,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
return 0;
}
- if (vcpu->sigset_active)
- sigprocmask(SIG_SETMASK, &vcpu->sigset, &sigsaved);
+ kvm_sigset_activate(vcpu);
if (!kvm_s390_user_cpu_state_ctrl(vcpu->kvm)) {
kvm_s390_vcpu_start(vcpu);
@@ -3423,8 +3421,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
disable_cpu_timer_accounting(vcpu);
store_regs(vcpu, kvm_run);
- if (vcpu->sigset_active)
- sigprocmask(SIG_SETMASK, &sigsaved, NULL);
+ kvm_sigset_deactivate(vcpu);
vcpu->stat.exit_userspace++;
return rc;
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7245,12 +7245,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
{
struct fpu *fpu = ¤t->thread.fpu;
int r;
- sigset_t sigsaved;
fpu__initialize(fpu);
- if (vcpu->sigset_active)
- sigprocmask(SIG_SETMASK, &vcpu->sigset, &sigsaved);
+ kvm_sigset_activate(vcpu);
if (unlikely(vcpu->arch.mp_state == KVM_MP_STATE_UNINITIALIZED)) {
if (kvm_run->immediate_exit) {
@@ -7293,8 +7291,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
out:
post_kvm_run_save(vcpu);
- if (vcpu->sigset_active)
- sigprocmask(SIG_SETMASK, &sigsaved, NULL);
+ kvm_sigset_deactivate(vcpu);
return r;
}
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -714,6 +714,9 @@ int kvm_vcpu_write_guest(struct kvm_vcpu
unsigned long len);
void kvm_vcpu_mark_page_dirty(struct kvm_vcpu *vcpu, gfn_t gfn);
+void kvm_sigset_activate(struct kvm_vcpu *vcpu);
+void kvm_sigset_deactivate(struct kvm_vcpu *vcpu);
+
void kvm_vcpu_block(struct kvm_vcpu *vcpu);
void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu);
void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu);
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -612,7 +612,6 @@ static void check_vcpu_requests(struct k
int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
{
int ret;
- sigset_t sigsaved;
if (unlikely(!kvm_vcpu_initialized(vcpu)))
return -ENOEXEC;
@@ -630,8 +629,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
if (run->immediate_exit)
return -EINTR;
- if (vcpu->sigset_active)
- sigprocmask(SIG_SETMASK, &vcpu->sigset, &sigsaved);
+ kvm_sigset_activate(vcpu);
ret = 1;
run->exit_reason = KVM_EXIT_UNKNOWN;
@@ -753,8 +751,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
kvm_pmu_update_run(vcpu);
}
- if (vcpu->sigset_active)
- sigprocmask(SIG_SETMASK, &sigsaved, NULL);
+ kvm_sigset_deactivate(vcpu);
+
return ret;
}
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2073,6 +2073,29 @@ void kvm_vcpu_mark_page_dirty(struct kvm
}
EXPORT_SYMBOL_GPL(kvm_vcpu_mark_page_dirty);
+void kvm_sigset_activate(struct kvm_vcpu *vcpu)
+{
+ if (!vcpu->sigset_active)
+ return;
+
+ /*
+ * This does a lockless modification of ->real_blocked, which is fine
+ * because, only current can change ->real_blocked and all readers of
+ * ->real_blocked don't care as long ->real_blocked is always a subset
+ * of ->blocked.
+ */
+ sigprocmask(SIG_SETMASK, &vcpu->sigset, ¤t->real_blocked);
+}
+
+void kvm_sigset_deactivate(struct kvm_vcpu *vcpu)
+{
+ if (!vcpu->sigset_active)
+ return;
+
+ sigprocmask(SIG_SETMASK, ¤t->real_blocked, NULL);
+ sigemptyset(¤t->real_blocked);
+}
+
static void grow_halt_poll_ns(struct kvm_vcpu *vcpu)
{
unsigned int old, val, grow;
Patches currently in stable-queue which might be from jschoenh(a)amazon.de are
queue-4.14/kvm-let-kvm_set_signal_mask-work-as-advertised.patch
This is a note to let you know that I've just added the patch titled
kmemleak: add scheduling point to kmemleak_scan()
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:
kmemleak-add-scheduling-point-to-kmemleak_scan.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 Thu Feb 1 13:45:42 CET 2018
From: Yisheng Xie <xieyisheng1(a)huawei.com>
Date: Wed, 29 Nov 2017 16:11:08 -0800
Subject: kmemleak: add scheduling point to kmemleak_scan()
From: Yisheng Xie <xieyisheng1(a)huawei.com>
[ Upstream commit bde5f6bc68db51128f875a756e9082a6c6ff7b4c ]
kmemleak_scan() will scan struct page for each node and it can be really
large and resulting in a soft lockup. We have seen a soft lockup when
do scan while compile kernel:
watchdog: BUG: soft lockup - CPU#53 stuck for 22s! [bash:10287]
[...]
Call Trace:
kmemleak_scan+0x21a/0x4c0
kmemleak_write+0x312/0x350
full_proxy_write+0x5a/0xa0
__vfs_write+0x33/0x150
vfs_write+0xad/0x1a0
SyS_write+0x52/0xc0
do_syscall_64+0x61/0x1a0
entry_SYSCALL64_slow_path+0x25/0x25
Fix this by adding cond_resched every MAX_SCAN_SIZE.
Link: http://lkml.kernel.org/r/1511439788-20099-1-git-send-email-xieyisheng1@huaw…
Signed-off-by: Yisheng Xie <xieyisheng1(a)huawei.com>
Suggested-by: Catalin Marinas <catalin.marinas(a)arm.com>
Acked-by: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: Michal Hocko <mhocko(a)kernel.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/kmemleak.c | 2 ++
1 file changed, 2 insertions(+)
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1532,6 +1532,8 @@ static void kmemleak_scan(void)
if (page_count(page) == 0)
continue;
scan_block(page, page + 1, NULL);
+ if (!(pfn % (MAX_SCAN_SIZE / sizeof(*page))))
+ cond_resched();
}
}
put_online_mems();
Patches currently in stable-queue which might be from xieyisheng1(a)huawei.com are
queue-4.14/kmemleak-add-scheduling-point-to-kmemleak_scan.patch
This is a note to let you know that I've just added the patch titled
iwlwifi: mvm: fix the TX queue hang timeout for MONITOR vif type
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:
iwlwifi-mvm-fix-the-tx-queue-hang-timeout-for-monitor-vif-type.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 Thu Feb 1 13:45:42 CET 2018
From: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com>
Date: Wed, 15 Nov 2017 14:12:30 +0200
Subject: iwlwifi: mvm: fix the TX queue hang timeout for MONITOR vif type
From: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com>
[ Upstream commit d1b275ffec459c5ae12b5c7086c84175696e5a9f ]
The MONITOR type is missing in the interface type switch.
Add it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com>
Signed-off-by: Luca Coelho <luciano.coelho(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/intel/iwlwifi/mvm/utils.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/wireless/intel/iwlwifi/mvm/utils.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/utils.c
@@ -1181,6 +1181,8 @@ unsigned int iwl_mvm_get_wd_timeout(stru
return le32_to_cpu(txq_timer->p2p_go);
case NL80211_IFTYPE_P2P_DEVICE:
return le32_to_cpu(txq_timer->p2p_device);
+ case NL80211_IFTYPE_MONITOR:
+ return default_timeout;
default:
WARN_ON(1);
return mvm->cfg->base_params->wd_timeout;
Patches currently in stable-queue which might be from emmanuel.grumbach(a)intel.com are
queue-4.14/iwlwifi-mvm-fix-the-tx-queue-hang-timeout-for-monitor-vif-type.patch
This is a note to let you know that I've just added the patch titled
iwlwifi: fix access to prph when transport is stopped
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:
iwlwifi-fix-access-to-prph-when-transport-is-stopped.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 Thu Feb 1 13:45:42 CET 2018
From: Sara Sharon <sara.sharon(a)intel.com>
Date: Mon, 20 Nov 2017 13:25:05 +0200
Subject: iwlwifi: fix access to prph when transport is stopped
From: Sara Sharon <sara.sharon(a)intel.com>
[ Upstream commit 0232d2cd7aa8e1b810fe84fb4059a0bd1eabe2ba ]
When getting HW rfkill we get stop_device being called from
two paths.
One path is the IRQ calling stop device, and updating op
mode and stack.
As a result, cfg80211 is running rfkill sync work that shuts
down all devices (second path).
In the second path, we eventually get to iwl_mvm_stop_device
which calls iwl_fw_dump_conf_clear->iwl_fw_dbg_stop_recording,
that access periphery registers.
The device may be stopped at this point from the first path,
which will result with a failure to access those registers.
Simply checking for the trans status is insufficient, since
the race will still exist, only minimized.
Instead, move the stop from iwl_fw_dump_conf_clear (which is
getting called only from stop path) to the transport stop
device function, where the access is always safe.
This has the added value, of actually stopping dbgc before
stopping device even when the stop is initiated from the
transport.
Fixes: 1efc3843a4ee ("iwlwifi: stop dbgc recording before stopping DMA")
Signed-off-by: Sara Sharon <sara.sharon(a)intel.com>
Signed-off-by: Luca Coelho <luciano.coelho(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/intel/iwlwifi/fw/dbg.h | 2 --
drivers/net/wireless/intel/iwlwifi/pcie/trans-gen2.c | 6 ++++++
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 9 +++++++++
3 files changed, 15 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.h
@@ -209,8 +209,6 @@ static inline void iwl_fw_dbg_stop_recor
static inline void iwl_fw_dump_conf_clear(struct iwl_fw_runtime *fwrt)
{
- iwl_fw_dbg_stop_recording(fwrt);
-
fwrt->dump.conf = FW_DBG_INVALID;
}
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans-gen2.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans-gen2.c
@@ -49,6 +49,7 @@
*
*****************************************************************************/
#include "iwl-trans.h"
+#include "iwl-prph.h"
#include "iwl-context-info.h"
#include "internal.h"
@@ -156,6 +157,11 @@ void _iwl_trans_pcie_gen2_stop_device(st
trans_pcie->is_down = true;
+ /* Stop dbgc before stopping device */
+ iwl_write_prph(trans, DBGC_IN_SAMPLE, 0);
+ udelay(100);
+ iwl_write_prph(trans, DBGC_OUT_CTRL, 0);
+
/* tell the device to stop sending interrupts */
iwl_disable_interrupts(trans);
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -1138,6 +1138,15 @@ static void _iwl_trans_pcie_stop_device(
trans_pcie->is_down = true;
+ /* Stop dbgc before stopping device */
+ if (trans->cfg->device_family == IWL_DEVICE_FAMILY_7000) {
+ iwl_set_bits_prph(trans, MON_BUFF_SAMPLE_CTL, 0x100);
+ } else {
+ iwl_write_prph(trans, DBGC_IN_SAMPLE, 0);
+ udelay(100);
+ iwl_write_prph(trans, DBGC_OUT_CTRL, 0);
+ }
+
/* tell the device to stop sending interrupts */
iwl_disable_interrupts(trans);
Patches currently in stable-queue which might be from sara.sharon(a)intel.com are
queue-4.14/iwlwifi-fix-access-to-prph-when-transport-is-stopped.patch
This is a note to let you know that I've just added the patch titled
i2c: i2c-boardinfo: fix memory leaks on devinfo
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:
i2c-i2c-boardinfo-fix-memory-leaks-on-devinfo.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 Thu Feb 1 13:45:42 CET 2018
From: Colin Ian King <colin.king(a)canonical.com>
Date: Wed, 22 Nov 2017 17:52:24 +0000
Subject: i2c: i2c-boardinfo: fix memory leaks on devinfo
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 66a7c84d677e8e4a5a2ef4afdb9bd52e1399a866 ]
Currently when an error occurs devinfo is still allocated but is
unused when the error exit paths break out of the for-loop. Fix
this by kfree'ing devinfo to avoid the leak.
Detected by CoverityScan, CID#1416590 ("Resource Leak")
Fixes: 4124c4eba402 ("i2c: allow attaching IRQ resources to i2c_board_info")
Fixes: 0daaf99d8424 ("i2c: copy device properties when using i2c_register_board_info()")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Signed-off-by: Wolfram Sang <wsa(a)the-dreams.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/i2c/i2c-boardinfo.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/i2c/i2c-boardinfo.c
+++ b/drivers/i2c/i2c-boardinfo.c
@@ -86,6 +86,7 @@ int i2c_register_board_info(int busnum,
property_entries_dup(info->properties);
if (IS_ERR(devinfo->board_info.properties)) {
status = PTR_ERR(devinfo->board_info.properties);
+ kfree(devinfo);
break;
}
}
@@ -98,6 +99,7 @@ int i2c_register_board_info(int busnum,
GFP_KERNEL);
if (!devinfo->board_info.resources) {
status = -ENOMEM;
+ kfree(devinfo);
break;
}
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.14/i2c-i2c-boardinfo-fix-memory-leaks-on-devinfo.patch
queue-4.14/usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch
This is a note to let you know that I've just added the patch titled
hwmon: (pmbus) Use 64bit math for DIRECT format values
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:
hwmon-pmbus-use-64bit-math-for-direct-format-values.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 Thu Feb 1 13:45:42 CET 2018
From: Robert Lippert <roblip(a)gmail.com>
Date: Mon, 27 Nov 2017 15:51:55 -0800
Subject: hwmon: (pmbus) Use 64bit math for DIRECT format values
From: Robert Lippert <roblip(a)gmail.com>
[ Upstream commit bd467e4eababe4c04272c1e646f066db02734c79 ]
Power values in the 100s of watt range can easily blow past
32bit math limits when processing everything in microwatts.
Use 64bit math instead to avoid these issues on common 32bit ARM
BMC platforms.
Fixes: 442aba78728e ("hwmon: PMBus device driver")
Signed-off-by: Robert Lippert <rlippert(a)google.com>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hwmon/pmbus/pmbus_core.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -21,6 +21,7 @@
#include <linux/debugfs.h>
#include <linux/kernel.h>
+#include <linux/math64.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/err.h>
@@ -499,8 +500,8 @@ static long pmbus_reg2data_linear(struct
static long pmbus_reg2data_direct(struct pmbus_data *data,
struct pmbus_sensor *sensor)
{
- long val = (s16) sensor->data;
- long m, b, R;
+ s64 b, val = (s16)sensor->data;
+ s32 m, R;
m = data->info->m[sensor->class];
b = data->info->b[sensor->class];
@@ -528,11 +529,12 @@ static long pmbus_reg2data_direct(struct
R--;
}
while (R < 0) {
- val = DIV_ROUND_CLOSEST(val, 10);
+ val = div_s64(val + 5LL, 10L); /* round closest */
R++;
}
- return (val - b) / m;
+ val = div_s64(val - b, m);
+ return clamp_val(val, LONG_MIN, LONG_MAX);
}
/*
@@ -656,7 +658,8 @@ static u16 pmbus_data2reg_linear(struct
static u16 pmbus_data2reg_direct(struct pmbus_data *data,
struct pmbus_sensor *sensor, long val)
{
- long m, b, R;
+ s64 b, val64 = val;
+ s32 m, R;
m = data->info->m[sensor->class];
b = data->info->b[sensor->class];
@@ -673,18 +676,18 @@ static u16 pmbus_data2reg_direct(struct
R -= 3; /* Adjust R and b for data in milli-units */
b *= 1000;
}
- val = val * m + b;
+ val64 = val64 * m + b;
while (R > 0) {
- val *= 10;
+ val64 *= 10;
R--;
}
while (R < 0) {
- val = DIV_ROUND_CLOSEST(val, 10);
+ val64 = div_s64(val64 + 5LL, 10L); /* round closest */
R++;
}
- return val;
+ return (u16)clamp_val(val64, S16_MIN, S16_MAX);
}
static u16 pmbus_data2reg_vid(struct pmbus_data *data,
Patches currently in stable-queue which might be from roblip(a)gmail.com are
queue-4.14/hwmon-pmbus-use-64bit-math-for-direct-format-values.patch
This is a note to let you know that I've just added the patch titled
grace: replace BUG_ON by WARN_ONCE in exit_net hook
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:
grace-replace-bug_on-by-warn_once-in-exit_net-hook.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 Thu Feb 1 13:45:42 CET 2018
From: Vasily Averin <vvs(a)virtuozzo.com>
Date: Mon, 6 Nov 2017 16:22:48 +0300
Subject: grace: replace BUG_ON by WARN_ONCE in exit_net hook
From: Vasily Averin <vvs(a)virtuozzo.com>
[ Upstream commit b872285751c1af010e12d02bce7069e2061a58ca ]
Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com>
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs_common/grace.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/nfs_common/grace.c
+++ b/fs/nfs_common/grace.c
@@ -104,7 +104,9 @@ grace_exit_net(struct net *net)
{
struct list_head *grace_list = net_generic(net, grace_net_id);
- BUG_ON(!list_empty(grace_list));
+ WARN_ONCE(!list_empty(grace_list),
+ "net %x %s: grace_list is not empty\n",
+ net->ns.inum, __func__);
}
static struct pernet_operations grace_net_ops = {
Patches currently in stable-queue which might be from vvs(a)virtuozzo.com are
queue-4.14/lockd-fix-list_add-double-add-caused-by-legacy-signal-interface.patch
queue-4.14/grace-replace-bug_on-by-warn_once-in-exit_net-hook.patch
queue-4.14/perf-core-fix-memory-leak-triggered-by-perf-namespace.patch
queue-4.14/race-of-lockd-inetaddr-notifiers-vs-nlmsvc_rqst-change.patch
This is a note to let you know that I've just added the patch titled
drm/vc4: Move IRQ enable to PM 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:
drm-vc4-move-irq-enable-to-pm-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 Thu Feb 1 13:45:42 CET 2018
From: Stefan Schake <stschake(a)gmail.com>
Date: Fri, 29 Dec 2017 17:05:43 +0100
Subject: drm/vc4: Move IRQ enable to PM path
From: Stefan Schake <stschake(a)gmail.com>
[ Upstream commit ce9caf2f79a5aa170a4b6456a03db639eed9c988 ]
We were calling enable_irq on bind, where it was already enabled previously
by the IRQ helper. Additionally, dev->irq is not set correctly until after
postinstall and so was always zero here, triggering a warning in 4.15.
Fix both by moving the enable to the power management resume path, where we
know there was a previous disable invocation during suspend.
Fixes: 253696ccd613 ("drm/vc4: Account for interrupts in flight")
Signed-off-by: Stefan Schake <stschake(a)gmail.com>
Signed-off-by: Eric Anholt <eric(a)anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1514563543-32511-1-git-send-e…
Tested-by: Stefan Wahren <stefan.wahren(a)i2se.com>
Reviewed-by: Eric Anholt <eric(a)anholt.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/vc4/vc4_irq.c | 3 ---
drivers/gpu/drm/vc4/vc4_v3d.c | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -208,9 +208,6 @@ vc4_irq_postinstall(struct drm_device *d
{
struct vc4_dev *vc4 = to_vc4_dev(dev);
- /* Undo the effects of a previous vc4_irq_uninstall. */
- enable_irq(dev->irq);
-
/* Enable both the render done and out of memory interrupts. */
V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS);
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -327,6 +327,9 @@ static int vc4_v3d_runtime_resume(struct
return ret;
vc4_v3d_init_hw(vc4->dev);
+
+ /* We disabled the IRQ as part of vc4_irq_uninstall in suspend. */
+ enable_irq(vc4->dev->irq);
vc4_irq_postinstall(vc4->dev);
return 0;
Patches currently in stable-queue which might be from stschake(a)gmail.com are
queue-4.14/drm-vc4-move-irq-enable-to-pm-path.patch
queue-4.14/drm-vc4-account-for-interrupts-in-flight.patch
This is a note to let you know that I've just added the patch titled
drm/vc4: Account for interrupts in flight
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-vc4-account-for-interrupts-in-flight.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 Thu Feb 1 13:45:42 CET 2018
From: Stefan Schake <stschake(a)gmail.com>
Date: Fri, 10 Nov 2017 02:05:06 +0100
Subject: drm/vc4: Account for interrupts in flight
From: Stefan Schake <stschake(a)gmail.com>
[ Upstream commit 253696ccd613fbdaa5aba1de44c461a058e0a114 ]
Synchronously disable the IRQ to make the following cancel_work_sync
invocation effective.
An interrupt in flight could enqueue further overflow mem work. As we
free the binner BO immediately following vc4_irq_uninstall this caused
a NULL pointer dereference in the work callback vc4_overflow_mem_work.
Link: https://github.com/anholt/linux/issues/114
Signed-off-by: Stefan Schake <stschake(a)gmail.com>
Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
Signed-off-by: Eric Anholt <eric(a)anholt.net>
Reviewed-by: Eric Anholt <eric(a)anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1510275907-993-2-git-send-ema…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/vc4/vc4_irq.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -208,6 +208,9 @@ vc4_irq_postinstall(struct drm_device *d
{
struct vc4_dev *vc4 = to_vc4_dev(dev);
+ /* Undo the effects of a previous vc4_irq_uninstall. */
+ enable_irq(dev->irq);
+
/* Enable both the render done and out of memory interrupts. */
V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS);
@@ -225,6 +228,9 @@ vc4_irq_uninstall(struct drm_device *dev
/* Clear any pending interrupts we might have left. */
V3D_WRITE(V3D_INTCTL, V3D_DRIVER_IRQS);
+ /* Finish any interrupt handler still in flight. */
+ disable_irq(dev->irq);
+
cancel_work_sync(&vc4->overflow_mem_work);
}
Patches currently in stable-queue which might be from stschake(a)gmail.com are
queue-4.14/drm-vc4-move-irq-enable-to-pm-path.patch
queue-4.14/drm-vc4-account-for-interrupts-in-flight.patch
This is a note to let you know that I've just added the patch titled
drm/rockchip: dw-mipi-dsi: fix possible un-balanced runtime PM enable
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-rockchip-dw-mipi-dsi-fix-possible-un-balanced-runtime-pm-enable.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 Thu Feb 1 13:45:42 CET 2018
From: Mirza Krak <mirza.krak(a)endian.se>
Date: Wed, 15 Nov 2017 08:24:46 +0000
Subject: drm/rockchip: dw-mipi-dsi: fix possible un-balanced runtime PM enable
From: Mirza Krak <mirza.krak(a)endian.se>
[ Upstream commit 517f56839f581618d24f2e67a35738a5c6cbaecb ]
In the case where the bind gets deferred we would end up with a
un-balanced runtime PM enable call.
Fix this by simply moving the pm_runtime_enable call to the end of
the bind function when all paths have succeeded.
Signed-off-by: Mirza Krak <mirza.krak(a)endian.se>
Signed-off-by: Sandy Huang <hjc(a)rock-chips.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510734286-37434-1-git-send-e…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -1275,8 +1275,6 @@ static int dw_mipi_dsi_bind(struct devic
goto err_pllref;
}
- pm_runtime_enable(dev);
-
dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
dsi->dsi_host.dev = dev;
ret = mipi_dsi_host_register(&dsi->dsi_host);
@@ -1291,6 +1289,7 @@ static int dw_mipi_dsi_bind(struct devic
}
dev_set_drvdata(dev, dsi);
+ pm_runtime_enable(dev);
return 0;
err_mipi_dsi_host:
Patches currently in stable-queue which might be from mirza.krak(a)endian.se are
queue-4.14/drm-rockchip-dw-mipi-dsi-fix-possible-un-balanced-runtime-pm-enable.patch
This is a note to let you know that I've just added the patch titled
drm/omap: Fix error handling path in 'omap_dmm_probe()'
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-omap-fix-error-handling-path-in-omap_dmm_probe.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 Thu Feb 1 13:45:42 CET 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sun, 24 Sep 2017 08:01:03 +0200
Subject: drm/omap: Fix error handling path in 'omap_dmm_probe()'
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 8677b1ac2db021ab30bb1fa34f1e56ebe0051ec3 ]
If we don't find a matching device node, we must free the memory allocated
in 'omap_dmm' a few lines above.
Fixes: 7cb0d6c17b96 ("drm/omap: fix TILER on OMAP5")
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -638,7 +638,8 @@ static int omap_dmm_probe(struct platfor
match = of_match_node(dmm_of_match, dev->dev.of_node);
if (!match) {
dev_err(&dev->dev, "failed to find matching device node\n");
- return -ENODEV;
+ ret = -ENODEV;
+ goto fail;
}
omap_dmm->plat_data = match->data;
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.14/bnxt_en-fix-an-error-handling-path-in-bnxt_get_module_eeprom.patch
queue-4.14/drm-omap-fix-error-handling-path-in-omap_dmm_probe.patch
This is a note to let you know that I've just added the patch titled
drm/omap: displays: panel-dpi: add backlight dependency
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-omap-displays-panel-dpi-add-backlight-dependency.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 Thu Feb 1 13:45:42 CET 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 5 Oct 2017 14:06:41 +0200
Subject: drm/omap: displays: panel-dpi: add backlight dependency
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 499ec0ed5eb2f6a7fcaab2dd66ffc5993484bda9 ]
The new backlight code causes a link failure when backlight
support itself is disabled:
drivers/gpu/drm/omapdrm/displays/panel-dpi.o: In function `panel_dpi_probe_of':
panel-dpi.c:(.text+0x35c): undefined reference to `of_find_backlight_by_node'
This adds a Kconfig dependency like we have for the other OMAP
display targets.
Fixes: 39135a305a0f ("drm/omap: displays: panel-dpi: Support for handling backlight devices")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/omapdrm/displays/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/omapdrm/displays/Kconfig
+++ b/drivers/gpu/drm/omapdrm/displays/Kconfig
@@ -35,6 +35,7 @@ config DRM_OMAP_CONNECTOR_ANALOG_TV
config DRM_OMAP_PANEL_DPI
tristate "Generic DPI panel"
+ depends on BACKLIGHT_CLASS_DEVICE
help
Driver for generic DPI panels.
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/drm-omap-displays-panel-dpi-add-backlight-dependency.patch
queue-4.14/gpio-fix-kernel-stack-leak-to-userspace.patch
This is a note to let you know that I've just added the patch titled
drm/bridge: tc358767: fix timing calculations
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-bridge-tc358767-fix-timing-calculations.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 Thu Feb 1 13:45:42 CET 2018
From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
Date: Tue, 7 Nov 2017 19:56:22 +0300
Subject: drm/bridge: tc358767: fix timing calculations
From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
[ Upstream commit 66d1c3b94d5d59e4325e61a78d520f92c043d645 ]
Fields in HTIM01 and HTIM02 regs should be even.
Recomended thresh_dly value is max_tu_symbol.
Remove set of VPCTRL0.VSDELAY as it is related to DSI input
interface. Currently driver supports only DPI.
Acked-by: Philipp Zabel <p.zabel(a)pengutronix.de>
Signed-off-by: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-5-git-send-e…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/bridge/tc358767.c | 34 ++++++++++++++++++++--------------
1 file changed, 20 insertions(+), 14 deletions(-)
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -659,6 +659,14 @@ static int tc_set_video_mode(struct tc_d
int lower_margin = mode->vsync_start - mode->vdisplay;
int vsync_len = mode->vsync_end - mode->vsync_start;
+ /*
+ * Recommended maximum number of symbols transferred in a transfer unit:
+ * DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size,
+ * (output active video bandwidth in bytes))
+ * Must be less than tu_size.
+ */
+ max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
+
dev_dbg(tc->dev, "set mode %dx%d\n",
mode->hdisplay, mode->vdisplay);
dev_dbg(tc->dev, "H margin %d,%d sync %d\n",
@@ -668,13 +676,18 @@ static int tc_set_video_mode(struct tc_d
dev_dbg(tc->dev, "total: %dx%d\n", mode->htotal, mode->vtotal);
- /* LCD Ctl Frame Size */
- tc_write(VPCTRL0, (0x40 << 20) /* VSDELAY */ |
+ /*
+ * LCD Ctl Frame Size
+ * datasheet is not clear of vsdelay in case of DPI
+ * assume we do not need any delay when DPI is a source of
+ * sync signals
+ */
+ tc_write(VPCTRL0, (0 << 20) /* VSDELAY */ |
OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED);
- tc_write(HTIM01, (left_margin << 16) | /* H back porch */
- (hsync_len << 0)); /* Hsync */
- tc_write(HTIM02, (right_margin << 16) | /* H front porch */
- (mode->hdisplay << 0)); /* width */
+ tc_write(HTIM01, (ALIGN(left_margin, 2) << 16) | /* H back porch */
+ (ALIGN(hsync_len, 2) << 0)); /* Hsync */
+ tc_write(HTIM02, (ALIGN(right_margin, 2) << 16) | /* H front porch */
+ (ALIGN(mode->hdisplay, 2) << 0)); /* width */
tc_write(VTIM01, (upper_margin << 16) | /* V back porch */
(vsync_len << 0)); /* Vsync */
tc_write(VTIM02, (lower_margin << 16) | /* V front porch */
@@ -693,7 +706,7 @@ static int tc_set_video_mode(struct tc_d
/* DP Main Stream Attributes */
vid_sync_dly = hsync_len + left_margin + mode->hdisplay;
tc_write(DP0_VIDSYNCDELAY,
- (0x003e << 16) | /* thresh_dly */
+ (max_tu_symbol << 16) | /* thresh_dly */
(vid_sync_dly << 0));
tc_write(DP0_TOTALVAL, (mode->vtotal << 16) | (mode->htotal));
@@ -709,13 +722,6 @@ static int tc_set_video_mode(struct tc_d
tc_write(DPIPXLFMT, VS_POL_ACTIVE_LOW | HS_POL_ACTIVE_LOW |
DE_POL_ACTIVE_HIGH | SUB_CFG_TYPE_CONFIG1 | DPI_BPP_RGB888);
- /*
- * Recommended maximum number of symbols transferred in a transfer unit:
- * DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size,
- * (output active video bandwidth in bytes))
- * Must be less than tu_size.
- */
- max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
tc_write(DP0_MISC, (max_tu_symbol << 23) | (TU_SIZE_RECOMMENDED << 16) |
BPC_8);
Patches currently in stable-queue which might be from andrey.gusakov(a)cogentembedded.com are
queue-4.14/drm-bridge-tc358767-fix-timing-calculations.patch
queue-4.14/drm-bridge-tc358767-fix-auxdatan-registers-access.patch
queue-4.14/drm-bridge-tc358767-filter-out-too-high-modes.patch
queue-4.14/drm-bridge-tc358767-fix-1-lane-behavior.patch
queue-4.14/drm-bridge-tc358767-fix-dp0_misc-register-set.patch
queue-4.14/drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch
This is a note to let you know that I've just added the patch titled
drm/bridge: tc358767: fix DP0_MISC register set
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-bridge-tc358767-fix-dp0_misc-register-set.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 Thu Feb 1 13:45:42 CET 2018
From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
Date: Tue, 7 Nov 2017 19:56:21 +0300
Subject: drm/bridge: tc358767: fix DP0_MISC register set
From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
[ Upstream commit f3b8adbe1911f66fd3cab1aaa74f0f66b7ceda25 ]
Remove shift from TU_SIZE_RECOMMENDED define as it used to
calculate max_tu_symbols.
Acked-by: Philipp Zabel <p.zabel(a)pengutronix.de>
Signed-off-by: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-4-git-send-e…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/bridge/tc358767.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -97,7 +97,7 @@
#define DP0_ACTIVEVAL 0x0650
#define DP0_SYNCVAL 0x0654
#define DP0_MISC 0x0658
-#define TU_SIZE_RECOMMENDED (0x3f << 16) /* LSCLK cycles per TU */
+#define TU_SIZE_RECOMMENDED (63) /* LSCLK cycles per TU */
#define BPC_6 (0 << 5)
#define BPC_8 (1 << 5)
@@ -716,7 +716,8 @@ static int tc_set_video_mode(struct tc_d
* Must be less than tu_size.
*/
max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
- tc_write(DP0_MISC, (max_tu_symbol << 23) | TU_SIZE_RECOMMENDED | BPC_8);
+ tc_write(DP0_MISC, (max_tu_symbol << 23) | (TU_SIZE_RECOMMENDED << 16) |
+ BPC_8);
return 0;
err:
Patches currently in stable-queue which might be from andrey.gusakov(a)cogentembedded.com are
queue-4.14/drm-bridge-tc358767-fix-timing-calculations.patch
queue-4.14/drm-bridge-tc358767-fix-auxdatan-registers-access.patch
queue-4.14/drm-bridge-tc358767-filter-out-too-high-modes.patch
queue-4.14/drm-bridge-tc358767-fix-1-lane-behavior.patch
queue-4.14/drm-bridge-tc358767-fix-dp0_misc-register-set.patch
queue-4.14/drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch
This is a note to let you know that I've just added the patch titled
drm/bridge: tc358767: fix AUXDATAn registers access
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-bridge-tc358767-fix-auxdatan-registers-access.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 Thu Feb 1 13:45:42 CET 2018
From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
Date: Tue, 7 Nov 2017 19:56:23 +0300
Subject: drm/bridge: tc358767: fix AUXDATAn registers access
From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
[ Upstream commit 9217c1abbc145a77d65c476cf2004a3df02104c7 ]
First four bytes should go to DP0_AUXWDATA0. Due to bug if
len > 4 first four bytes was writen to DP0_AUXWDATA1 and all
data get shifted by 4 bytes. Fix it.
Acked-by: Philipp Zabel <p.zabel(a)pengutronix.de>
Signed-off-by: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-6-git-send-e…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/bridge/tc358767.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -318,7 +318,7 @@ static ssize_t tc_aux_transfer(struct dr
tmp = (tmp << 8) | buf[i];
i++;
if (((i % 4) == 0) || (i == size)) {
- tc_write(DP0_AUXWDATA(i >> 2), tmp);
+ tc_write(DP0_AUXWDATA((i - 1) >> 2), tmp);
tmp = 0;
}
}
Patches currently in stable-queue which might be from andrey.gusakov(a)cogentembedded.com are
queue-4.14/drm-bridge-tc358767-fix-timing-calculations.patch
queue-4.14/drm-bridge-tc358767-fix-auxdatan-registers-access.patch
queue-4.14/drm-bridge-tc358767-filter-out-too-high-modes.patch
queue-4.14/drm-bridge-tc358767-fix-1-lane-behavior.patch
queue-4.14/drm-bridge-tc358767-fix-dp0_misc-register-set.patch
queue-4.14/drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch
This is a note to let you know that I've just added the patch titled
drm/bridge: tc358767: fix 1-lane behavior
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-bridge-tc358767-fix-1-lane-behavior.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 Thu Feb 1 13:45:42 CET 2018
From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
Date: Tue, 7 Nov 2017 19:56:24 +0300
Subject: drm/bridge: tc358767: fix 1-lane behavior
From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
[ Upstream commit 4dbd6c03fbf88299c573d676838896c6e06aade2 ]
Use drm_dp_channel_eq_ok helper
Acked-by: Philipp Zabel <p.zabel(a)pengutronix.de>
Signed-off-by: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-7-git-send-e…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/bridge/tc358767.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -819,8 +819,6 @@ static int tc_main_link_setup(struct tc_
unsigned int rate;
u32 dp_phy_ctrl;
int timeout;
- bool aligned;
- bool ready;
u32 value;
int ret;
u8 tmp[8];
@@ -965,16 +963,15 @@ static int tc_main_link_setup(struct tc_
ret = drm_dp_dpcd_read_link_status(aux, tmp + 2);
if (ret < 0)
goto err_dpcd_read;
- ready = (tmp[2] == ((DP_CHANNEL_EQ_BITS << 4) | /* Lane1 */
- DP_CHANNEL_EQ_BITS)); /* Lane0 */
- aligned = tmp[4] & DP_INTERLANE_ALIGN_DONE;
- } while ((--timeout) && !(ready && aligned));
+ } while ((--timeout) &&
+ !(drm_dp_channel_eq_ok(tmp + 2, tc->link.base.num_lanes)));
if (timeout == 0) {
/* Read DPCD 0x200-0x201 */
ret = drm_dp_dpcd_read(aux, DP_SINK_COUNT, tmp, 2);
if (ret < 0)
goto err_dpcd_read;
+ dev_err(dev, "channel(s) EQ not ok\n");
dev_info(dev, "0x0200 SINK_COUNT: 0x%02x\n", tmp[0]);
dev_info(dev, "0x0201 DEVICE_SERVICE_IRQ_VECTOR: 0x%02x\n",
tmp[1]);
@@ -985,10 +982,6 @@ static int tc_main_link_setup(struct tc_
dev_info(dev, "0x0206 ADJUST_REQUEST_LANE0_1: 0x%02x\n",
tmp[6]);
- if (!ready)
- dev_err(dev, "Lane0/1 not ready\n");
- if (!aligned)
- dev_err(dev, "Lane0/1 not aligned\n");
return -EAGAIN;
}
Patches currently in stable-queue which might be from andrey.gusakov(a)cogentembedded.com are
queue-4.14/drm-bridge-tc358767-fix-timing-calculations.patch
queue-4.14/drm-bridge-tc358767-fix-auxdatan-registers-access.patch
queue-4.14/drm-bridge-tc358767-filter-out-too-high-modes.patch
queue-4.14/drm-bridge-tc358767-fix-1-lane-behavior.patch
queue-4.14/drm-bridge-tc358767-fix-dp0_misc-register-set.patch
queue-4.14/drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch
This is a note to let you know that I've just added the patch titled
drm/bridge: tc358767: filter out too high modes
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-bridge-tc358767-filter-out-too-high-modes.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 Thu Feb 1 13:45:42 CET 2018
From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
Date: Tue, 7 Nov 2017 19:56:20 +0300
Subject: drm/bridge: tc358767: filter out too high modes
From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
[ Upstream commit 99fc8e963a4c0203dba26a77cf737db6081bca14 ]
Pixel clock limitation for DPI is 154 MHz. Do not accept modes
with higher pixel clock rate.
Reviewed-by: Andrzej Hajda <a.hajda(a)samsung.com>
Signed-off-by: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-3-git-send-e…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/bridge/tc358767.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1103,7 +1103,10 @@ static bool tc_bridge_mode_fixup(struct
static int tc_connector_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
- /* Accept any mode */
+ /* DPI interface clock limitation: upto 154 MHz */
+ if (mode->clock > 154000)
+ return MODE_CLOCK_HIGH;
+
return MODE_OK;
}
Patches currently in stable-queue which might be from andrey.gusakov(a)cogentembedded.com are
queue-4.14/drm-bridge-tc358767-fix-timing-calculations.patch
queue-4.14/drm-bridge-tc358767-fix-auxdatan-registers-access.patch
queue-4.14/drm-bridge-tc358767-filter-out-too-high-modes.patch
queue-4.14/drm-bridge-tc358767-fix-1-lane-behavior.patch
queue-4.14/drm-bridge-tc358767-fix-dp0_misc-register-set.patch
queue-4.14/drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch
This is a note to let you know that I've just added the patch titled
drm/bridge: tc358767: do no fail on hi-res displays
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-bridge-tc358767-do-no-fail-on-hi-res-displays.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 Thu Feb 1 13:45:42 CET 2018
From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
Date: Tue, 7 Nov 2017 19:56:19 +0300
Subject: drm/bridge: tc358767: do no fail on hi-res displays
From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
[ Upstream commit cffd2b16c01c3431a7a7dd62e722af33490fc436 ]
Do not fail data rates higher than 2.7 and more than 2 lanes.
Try to fall back to 2.7Gbps and 2 lanes.
Acked-by: Philipp Zabel <p.zabel(a)pengutronix.de>
Reviewed-by: Andrzej Hajda <a.hajda(a)samsung.com>
Signed-off-by: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-2-git-send-e…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/bridge/tc358767.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -603,8 +603,15 @@ static int tc_get_display_props(struct t
ret = drm_dp_link_probe(&tc->aux, &tc->link.base);
if (ret < 0)
goto err_dpcd_read;
- if ((tc->link.base.rate != 162000) && (tc->link.base.rate != 270000))
- goto err_dpcd_inval;
+ if (tc->link.base.rate != 162000 && tc->link.base.rate != 270000) {
+ dev_dbg(tc->dev, "Falling to 2.7 Gbps rate\n");
+ tc->link.base.rate = 270000;
+ }
+
+ if (tc->link.base.num_lanes > 2) {
+ dev_dbg(tc->dev, "Falling to 2 lanes\n");
+ tc->link.base.num_lanes = 2;
+ }
ret = drm_dp_dpcd_readb(&tc->aux, DP_MAX_DOWNSPREAD, tmp);
if (ret < 0)
@@ -637,9 +644,6 @@ static int tc_get_display_props(struct t
err_dpcd_read:
dev_err(tc->dev, "failed to read DPCD: %d\n", ret);
return ret;
-err_dpcd_inval:
- dev_err(tc->dev, "invalid DPCD\n");
- return -EINVAL;
}
static int tc_set_video_mode(struct tc_data *tc, struct drm_display_mode *mode)
Patches currently in stable-queue which might be from andrey.gusakov(a)cogentembedded.com are
queue-4.14/drm-bridge-tc358767-fix-timing-calculations.patch
queue-4.14/drm-bridge-tc358767-fix-auxdatan-registers-access.patch
queue-4.14/drm-bridge-tc358767-filter-out-too-high-modes.patch
queue-4.14/drm-bridge-tc358767-fix-1-lane-behavior.patch
queue-4.14/drm-bridge-tc358767-fix-dp0_misc-register-set.patch
queue-4.14/drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch
This is a note to let you know that I've just added the patch titled
drm/bridge: Fix lvds-encoder since the panel_bridge rework.
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-bridge-fix-lvds-encoder-since-the-panel_bridge-rework.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 Thu Feb 1 13:45:42 CET 2018
From: Eric Anholt <eric(a)anholt.net>
Date: Tue, 14 Nov 2017 11:16:47 -0800
Subject: drm/bridge: Fix lvds-encoder since the panel_bridge rework.
From: Eric Anholt <eric(a)anholt.net>
[ Upstream commit dbb58bfd9ae6c885b2ca001a9a5ab8b881fb4ba9 ]
The panel_bridge bridge attaches to the panel's OF node, not the
lvds-encoder's node. Put in a little no-op bridge of our own so that
our consumers can still find a bridge where they expect.
This also fixes an unintended unregistration and leak of the
panel-bridge on module remove.
Signed-off-by: Eric Anholt <eric(a)anholt.net>
Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the lvds-encoder bri
dge.")
Tested-by: Lothar Waßmann <LW(a)KARO-electronics.de>
Signed-off-by: Archit Taneja <architt(a)codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114191647.22207-1-eric@a…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/bridge/lvds-encoder.c | 48 +++++++++++++++++++++++++++++-----
1 file changed, 41 insertions(+), 7 deletions(-)
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -13,13 +13,37 @@
#include <linux/of_graph.h>
+struct lvds_encoder {
+ struct drm_bridge bridge;
+ struct drm_bridge *panel_bridge;
+};
+
+static int lvds_encoder_attach(struct drm_bridge *bridge)
+{
+ struct lvds_encoder *lvds_encoder = container_of(bridge,
+ struct lvds_encoder,
+ bridge);
+
+ return drm_bridge_attach(bridge->encoder, lvds_encoder->panel_bridge,
+ bridge);
+}
+
+static struct drm_bridge_funcs funcs = {
+ .attach = lvds_encoder_attach,
+};
+
static int lvds_encoder_probe(struct platform_device *pdev)
{
struct device_node *port;
struct device_node *endpoint;
struct device_node *panel_node;
struct drm_panel *panel;
- struct drm_bridge *bridge;
+ struct lvds_encoder *lvds_encoder;
+
+ lvds_encoder = devm_kzalloc(&pdev->dev, sizeof(*lvds_encoder),
+ GFP_KERNEL);
+ if (!lvds_encoder)
+ return -ENOMEM;
/* Locate the panel DT node. */
port = of_graph_get_port_by_id(pdev->dev.of_node, 1);
@@ -49,20 +73,30 @@ static int lvds_encoder_probe(struct pla
return -EPROBE_DEFER;
}
- bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_LVDS);
- if (IS_ERR(bridge))
- return PTR_ERR(bridge);
+ lvds_encoder->panel_bridge =
+ devm_drm_panel_bridge_add(&pdev->dev,
+ panel, DRM_MODE_CONNECTOR_LVDS);
+ if (IS_ERR(lvds_encoder->panel_bridge))
+ return PTR_ERR(lvds_encoder->panel_bridge);
+
+ /* The panel_bridge bridge is attached to the panel's of_node,
+ * but we need a bridge attached to our of_node for our user
+ * to look up.
+ */
+ lvds_encoder->bridge.of_node = pdev->dev.of_node;
+ lvds_encoder->bridge.funcs = &funcs;
+ drm_bridge_add(&lvds_encoder->bridge);
- platform_set_drvdata(pdev, bridge);
+ platform_set_drvdata(pdev, lvds_encoder);
return 0;
}
static int lvds_encoder_remove(struct platform_device *pdev)
{
- struct drm_bridge *bridge = platform_get_drvdata(pdev);
+ struct lvds_encoder *lvds_encoder = platform_get_drvdata(pdev);
- drm_bridge_remove(bridge);
+ drm_bridge_remove(&lvds_encoder->bridge);
return 0;
}
Patches currently in stable-queue which might be from eric(a)anholt.net are
queue-4.14/drm-bridge-fix-lvds-encoder-since-the-panel_bridge-rework.patch
queue-4.14/drm-vc4-move-irq-enable-to-pm-path.patch
queue-4.14/drm-vc4-account-for-interrupts-in-flight.patch
This is a note to let you know that I've just added the patch titled
drm/amdkfd: Fix SDMA ring buffer size calculation
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-amdkfd-fix-sdma-ring-buffer-size-calculation.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 Thu Feb 1 13:45:42 CET 2018
From: shaoyunl <Shaoyun.Liu(a)amd.com>
Date: Wed, 1 Nov 2017 19:21:56 -0400
Subject: drm/amdkfd: Fix SDMA ring buffer size calculation
From: shaoyunl <Shaoyun.Liu(a)amd.com>
[ Upstream commit d12fb13f23199faa7e536acec1db49068e5a067d ]
ffs function return the position of the first bit set on 1 based.
(bit zero returns 1).
Signed-off-by: shaoyun liu <shaoyun.liu(a)amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling(a)amd.com>
Reviewed-by: Oded Gabbay <oded.gabbay(a)gmail.com>
Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c
@@ -205,8 +205,8 @@ static int update_mqd_sdma(struct mqd_ma
struct cik_sdma_rlc_registers *m;
m = get_sdma_mqd(mqd);
- m->sdma_rlc_rb_cntl = ffs(q->queue_size / sizeof(unsigned int)) <<
- SDMA0_RLC0_RB_CNTL__RB_SIZE__SHIFT |
+ m->sdma_rlc_rb_cntl = (ffs(q->queue_size / sizeof(unsigned int)) - 1)
+ << SDMA0_RLC0_RB_CNTL__RB_SIZE__SHIFT |
q->vmid << SDMA0_RLC0_RB_CNTL__RB_VMID__SHIFT |
1 << SDMA0_RLC0_RB_CNTL__RPTR_WRITEBACK_ENABLE__SHIFT |
6 << SDMA0_RLC0_RB_CNTL__RPTR_WRITEBACK_TIMER__SHIFT;
Patches currently in stable-queue which might be from Shaoyun.Liu(a)amd.com are
queue-4.14/drm-amdkfd-fix-sdma-ring-buffer-size-calculation.patch
This is a note to let you know that I've just added the patch titled
drm/amdkfd: Fix SDMA oversubsription 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:
drm-amdkfd-fix-sdma-oversubsription-handling.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Felix Kuehling <Felix.Kuehling(a)amd.com>
Date: Wed, 1 Nov 2017 19:21:57 -0400
Subject: drm/amdkfd: Fix SDMA oversubsription handling
From: Felix Kuehling <Felix.Kuehling(a)amd.com>
[ Upstream commit 8c946b8988acec785bcf67088b6bd0747f36d2d3 ]
SDMA only supports a fixed number of queues. HWS cannot handle
oversubscription.
Signed-off-by: shaoyun liu <shaoyun.liu(a)amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling(a)amd.com>
Reviewed-by: Oded Gabbay <oded.gabbay(a)gmail.com>
Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 18 +++++++++++++++++
1 file changed, 18 insertions(+)
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
@@ -184,6 +184,24 @@ int pqm_create_queue(struct process_queu
switch (type) {
case KFD_QUEUE_TYPE_SDMA:
+ if (dev->dqm->queue_count >=
+ CIK_SDMA_QUEUES_PER_ENGINE * CIK_SDMA_ENGINE_NUM) {
+ pr_err("Over-subscription is not allowed for SDMA.\n");
+ retval = -EPERM;
+ goto err_create_queue;
+ }
+
+ retval = create_cp_queue(pqm, dev, &q, properties, f, *qid);
+ if (retval != 0)
+ goto err_create_queue;
+ pqn->q = q;
+ pqn->kq = NULL;
+ retval = dev->dqm->ops.create_queue(dev->dqm, q, &pdd->qpd,
+ &q->properties.vmid);
+ pr_debug("DQM returned %d for create_queue\n", retval);
+ print_queue(q);
+ break;
+
case KFD_QUEUE_TYPE_COMPUTE:
/* check if there is over subscription */
if ((sched_policy == KFD_SCHED_POLICY_HWS_NO_OVERSUBSCRIPTION) &&
Patches currently in stable-queue which might be from Felix.Kuehling(a)amd.com are
queue-4.14/drm-amdkfd-fix-sdma-oversubsription-handling.patch
queue-4.14/drm-amdkfd-fix-sdma-ring-buffer-size-calculation.patch
queue-4.14/drm-amdgpu-fix-sdma-load-unload-sequence-on-hws-disabled-mode.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: don't try to move pinned BOs
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-amdgpu-don-t-try-to-move-pinned-bos.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 Thu Feb 1 13:45:42 CET 2018
From: "Christian König" <christian.koenig(a)amd.com>
Date: Fri, 24 Nov 2017 11:39:30 +0100
Subject: drm/amdgpu: don't try to move pinned BOs
From: "Christian König" <christian.koenig(a)amd.com>
[ Upstream commit 6edc6910ba4cd6eab309263539c8f09b8ad772bf ]
Never try to move pinned BOs during CS.
Signed-off-by: Christian König <christian.koenig(a)amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer(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/amd/amdgpu/amdgpu_cs.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -403,6 +403,10 @@ static bool amdgpu_cs_try_evict(struct a
if (candidate->robj == validated)
break;
+ /* We can't move pinned BOs here */
+ if (bo->pin_count)
+ continue;
+
other = amdgpu_mem_type_to_domain(bo->tbo.mem.mem_type);
/* Check if this BO is in one of the domains we need space for */
Patches currently in stable-queue which might be from christian.koenig(a)amd.com are
queue-4.14/drm-amdgpu-don-t-try-to-move-pinned-bos.patch
This is a note to let you know that I've just added the patch titled
cpupowerutils: bench - Fix cpu online 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:
cpupowerutils-bench-fix-cpu-online-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 Thu Feb 1 13:45:42 CET 2018
From: Abhishek Goel <huntbag(a)linux.vnet.ibm.com>
Date: Tue, 7 Nov 2017 15:17:55 +0530
Subject: cpupowerutils: bench - Fix cpu online check
From: Abhishek Goel <huntbag(a)linux.vnet.ibm.com>
[ Upstream commit 53d1cd6b125fb9d69303516a1179ebc3b72f797a ]
cpupower_is_cpu_online was incorrectly checking for 0. This patch fixes
this by checking for 1 when the cpu is online.
Signed-off-by: Abhishek Goel <huntbag(a)linux.vnet.ibm.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/power/cpupower/bench/system.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/power/cpupower/bench/system.c
+++ b/tools/power/cpupower/bench/system.c
@@ -61,7 +61,7 @@ int set_cpufreq_governor(char *governor,
dprintf("set %s as cpufreq governor\n", governor);
- if (cpupower_is_cpu_online(cpu) != 0) {
+ if (cpupower_is_cpu_online(cpu) != 1) {
perror("cpufreq_cpu_exists");
fprintf(stderr, "error: cpu %u does not exist\n", cpu);
return -1;
Patches currently in stable-queue which might be from huntbag(a)linux.vnet.ibm.com are
queue-4.14/cpupowerutils-bench-fix-cpu-online-check.patch
queue-4.14/cpupower-fix-cpupower-working-when-cpu0-is-offline.patch
This is a note to let you know that I've just added the patch titled
cpupower : Fix cpupower working when cpu0 is offline
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:
cpupower-fix-cpupower-working-when-cpu0-is-offline.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 Thu Feb 1 13:45:42 CET 2018
From: Abhishek Goel <huntbag(a)linux.vnet.ibm.com>
Date: Wed, 15 Nov 2017 14:10:02 +0530
Subject: cpupower : Fix cpupower working when cpu0 is offline
From: Abhishek Goel <huntbag(a)linux.vnet.ibm.com>
[ Upstream commit dbdc468f35ee827cab2753caa1c660bdb832243a ]
cpuidle_monitor used to assume that cpu0 is always online which is not
a valid assumption on POWER machines. This patch fixes this by getting
the cpu on which the current thread is running, instead of always using
cpu0 for monitoring which may not be online.
Signed-off-by: Abhishek Goel <huntbag(a)linux.vnet.ibm.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c
+++ b/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c
@@ -130,15 +130,18 @@ static struct cpuidle_monitor *cpuidle_r
{
int num;
char *tmp;
+ int this_cpu;
+
+ this_cpu = sched_getcpu();
/* Assume idle state count is the same for all CPUs */
- cpuidle_sysfs_monitor.hw_states_num = cpuidle_state_count(0);
+ cpuidle_sysfs_monitor.hw_states_num = cpuidle_state_count(this_cpu);
if (cpuidle_sysfs_monitor.hw_states_num <= 0)
return NULL;
for (num = 0; num < cpuidle_sysfs_monitor.hw_states_num; num++) {
- tmp = cpuidle_state_name(0, num);
+ tmp = cpuidle_state_name(this_cpu, num);
if (tmp == NULL)
continue;
@@ -146,7 +149,7 @@ static struct cpuidle_monitor *cpuidle_r
strncpy(cpuidle_cstates[num].name, tmp, CSTATE_NAME_LEN - 1);
free(tmp);
- tmp = cpuidle_state_desc(0, num);
+ tmp = cpuidle_state_desc(this_cpu, num);
if (tmp == NULL)
continue;
strncpy(cpuidle_cstates[num].desc, tmp, CSTATE_DESC_LEN - 1);
Patches currently in stable-queue which might be from huntbag(a)linux.vnet.ibm.com are
queue-4.14/cpupowerutils-bench-fix-cpu-online-check.patch
queue-4.14/cpupower-fix-cpupower-working-when-cpu0-is-offline.patch
This is a note to let you know that I've just added the patch titled
cpufreq: Add Loongson machine dependencies
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:
cpufreq-add-loongson-machine-dependencies.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 Thu Feb 1 13:45:42 CET 2018
From: James Hogan <jhogan(a)kernel.org>
Date: Wed, 15 Nov 2017 21:17:55 +0000
Subject: cpufreq: Add Loongson machine dependencies
From: James Hogan <jhogan(a)kernel.org>
[ Upstream commit 0d307935fefa6389eb726c6362351c162c949101 ]
The MIPS loongson cpufreq drivers don't build unless configured for the
correct machine type, due to dependency on machine specific architecture
headers and symbols in machine specific platform code.
More specifically loongson1-cpufreq.c uses RST_CPU_EN and RST_CPU,
neither of which is defined in asm/mach-loongson32/regs-clk.h unless
CONFIG_LOONGSON1_LS1B=y, and loongson2_cpufreq.c references
loongson2_clockmod_table[], which is only defined in
arch/mips/loongson64/lemote-2f/clock.c, i.e. when
CONFIG_LEMOTE_MACH2F=y.
Add these dependencies to Kconfig to avoid randconfig / allyesconfig
build failures (e.g. when based on BMIPS which also has a cpufreq
driver).
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/cpufreq/Kconfig | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -275,6 +275,7 @@ config BMIPS_CPUFREQ
config LOONGSON2_CPUFREQ
tristate "Loongson2 CPUFreq Driver"
+ depends on LEMOTE_MACH2F
help
This option adds a CPUFreq driver for loongson processors which
support software configurable cpu frequency.
@@ -287,6 +288,7 @@ config LOONGSON2_CPUFREQ
config LOONGSON1_CPUFREQ
tristate "Loongson1 CPUFreq Driver"
+ depends on LOONGSON1_LS1B
help
This option adds a CPUFreq driver for loongson1 processors which
support software configurable cpu frequency.
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-4.14/cpufreq-add-loongson-machine-dependencies.patch
This is a note to let you know that I've just added the patch titled
Btrfs: incremental send, fix wrong unlink path after renaming file
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-incremental-send-fix-wrong-unlink-path-after-renaming-file.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 Thu Feb 1 13:45:42 CET 2018
From: Filipe Manana <fdmanana(a)suse.com>
Date: Fri, 17 Nov 2017 01:54:00 +0000
Subject: Btrfs: incremental send, fix wrong unlink path after renaming file
From: Filipe Manana <fdmanana(a)suse.com>
[ Upstream commit ea37d5998b50a72b9045ba60a132eeb20e1c4230 ]
Under some circumstances, an incremental send operation can issue wrong
paths for unlink commands related to files that have multiple hard links
and some (or all) of those links were renamed between the parent and send
snapshots. Consider the following example:
Parent snapshot
. (ino 256)
|---- a/ (ino 257)
| |---- b/ (ino 259)
| | |---- c/ (ino 260)
| | |---- f2 (ino 261)
| |
| |---- f2l1 (ino 261)
|
|---- d/ (ino 262)
|---- f1l1_2 (ino 258)
|---- f2l2 (ino 261)
|---- f1_2 (ino 258)
Send snapshot
. (ino 256)
|---- a/ (ino 257)
| |---- f2l1/ (ino 263)
| |---- b2/ (ino 259)
| |---- c/ (ino 260)
| | |---- d3 (ino 262)
| | |---- f1l1_2 (ino 258)
| | |---- f2l2_2 (ino 261)
| | |---- f1_2 (ino 258)
| |
| |---- f2 (ino 261)
| |---- f1l2 (ino 258)
|
|---- d (ino 261)
When computing the incremental send stream the following steps happen:
1) When processing inode 261, a rename operation is issued that renames
inode 262, which currently as a path of "d", to an orphan name of
"o262-7-0". This is done because in the send snapshot, inode 261 has
of its hard links with a path of "d" as well.
2) Two link operations are issued that create the new hard links for
inode 261, whose names are "d" and "f2l2_2", at paths "/" and
"o262-7-0/" respectively.
3) Still while processing inode 261, unlink operations are issued to
remove the old hard links of inode 261, with names "f2l1" and "f2l2",
at paths "a/" and "d/". However path "d/" does not correspond anymore
to the directory inode 262 but corresponds instead to a hard link of
inode 261 (link command issued in the previous step). This makes the
receiver fail with a ENOTDIR error when attempting the unlink
operation.
The problem happens because before sending the unlink operation, we failed
to detect that inode 262 was one of ancestors for inode 261 in the parent
snapshot, and therefore we didn't recompute the path for inode 262 before
issuing the unlink operation for the link named "f2l2" of inode 262. The
detection failed because the function "is_ancestor()" only follows the
first hard link it finds for an inode instead of all of its hard links
(as it was originally created for being used with directories only, for
which only one hard link exists). So fix this by making "is_ancestor()"
follow all hard links of the input inode.
A test case for fstests follows soon.
Signed-off-by: Filipe Manana <fdmanana(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/send.c | 124 +++++++++++++++++++++++++++++++++++++++++++++++---------
1 file changed, 106 insertions(+), 18 deletions(-)
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -3527,7 +3527,40 @@ out:
}
/*
- * Check if ino ino1 is an ancestor of inode ino2 in the given root.
+ * Check if inode ino2, or any of its ancestors, is inode ino1.
+ * Return 1 if true, 0 if false and < 0 on error.
+ */
+static int check_ino_in_path(struct btrfs_root *root,
+ const u64 ino1,
+ const u64 ino1_gen,
+ const u64 ino2,
+ const u64 ino2_gen,
+ struct fs_path *fs_path)
+{
+ u64 ino = ino2;
+
+ if (ino1 == ino2)
+ return ino1_gen == ino2_gen;
+
+ while (ino > BTRFS_FIRST_FREE_OBJECTID) {
+ u64 parent;
+ u64 parent_gen;
+ int ret;
+
+ fs_path_reset(fs_path);
+ ret = get_first_ref(root, ino, &parent, &parent_gen, fs_path);
+ if (ret < 0)
+ return ret;
+ if (parent == ino1)
+ return parent_gen == ino1_gen;
+ ino = parent;
+ }
+ return 0;
+}
+
+/*
+ * Check if ino ino1 is an ancestor of inode ino2 in the given root for any
+ * possible path (in case ino2 is not a directory and has multiple hard links).
* Return 1 if true, 0 if false and < 0 on error.
*/
static int is_ancestor(struct btrfs_root *root,
@@ -3536,36 +3569,91 @@ static int is_ancestor(struct btrfs_root
const u64 ino2,
struct fs_path *fs_path)
{
- u64 ino = ino2;
- bool free_path = false;
+ bool free_fs_path = false;
int ret = 0;
+ struct btrfs_path *path = NULL;
+ struct btrfs_key key;
if (!fs_path) {
fs_path = fs_path_alloc();
if (!fs_path)
return -ENOMEM;
- free_path = true;
+ free_fs_path = true;
}
- while (ino > BTRFS_FIRST_FREE_OBJECTID) {
- u64 parent;
- u64 parent_gen;
+ path = alloc_path_for_send();
+ if (!path) {
+ ret = -ENOMEM;
+ goto out;
+ }
- fs_path_reset(fs_path);
- ret = get_first_ref(root, ino, &parent, &parent_gen, fs_path);
- if (ret < 0) {
- if (ret == -ENOENT && ino == ino2)
- ret = 0;
- goto out;
+ key.objectid = ino2;
+ key.type = BTRFS_INODE_REF_KEY;
+ key.offset = 0;
+
+ ret = btrfs_search_slot(NULL, root, &key, path, 0, 0);
+ if (ret < 0)
+ goto out;
+
+ while (true) {
+ struct extent_buffer *leaf = path->nodes[0];
+ int slot = path->slots[0];
+ u32 cur_offset = 0;
+ u32 item_size;
+
+ if (slot >= btrfs_header_nritems(leaf)) {
+ ret = btrfs_next_leaf(root, path);
+ if (ret < 0)
+ goto out;
+ if (ret > 0)
+ break;
+ continue;
}
- if (parent == ino1) {
- ret = parent_gen == ino1_gen ? 1 : 0;
- goto out;
+
+ btrfs_item_key_to_cpu(leaf, &key, slot);
+ if (key.objectid != ino2)
+ break;
+ if (key.type != BTRFS_INODE_REF_KEY &&
+ key.type != BTRFS_INODE_EXTREF_KEY)
+ break;
+
+ item_size = btrfs_item_size_nr(leaf, slot);
+ while (cur_offset < item_size) {
+ u64 parent;
+ u64 parent_gen;
+
+ if (key.type == BTRFS_INODE_EXTREF_KEY) {
+ unsigned long ptr;
+ struct btrfs_inode_extref *extref;
+
+ ptr = btrfs_item_ptr_offset(leaf, slot);
+ extref = (struct btrfs_inode_extref *)
+ (ptr + cur_offset);
+ parent = btrfs_inode_extref_parent(leaf,
+ extref);
+ cur_offset += sizeof(*extref);
+ cur_offset += btrfs_inode_extref_name_len(leaf,
+ extref);
+ } else {
+ parent = key.offset;
+ cur_offset = item_size;
+ }
+
+ ret = get_inode_info(root, parent, NULL, &parent_gen,
+ NULL, NULL, NULL, NULL);
+ if (ret < 0)
+ goto out;
+ ret = check_ino_in_path(root, ino1, ino1_gen,
+ parent, parent_gen, fs_path);
+ if (ret)
+ goto out;
}
- ino = parent;
+ path->slots[0]++;
}
+ ret = 0;
out:
- if (free_path)
+ btrfs_free_path(path);
+ if (free_fs_path)
fs_path_free(fs_path);
return ret;
}
Patches currently in stable-queue which might be from fdmanana(a)suse.com are
queue-4.14/btrfs-incremental-send-fix-wrong-unlink-path-after-renaming-file.patch
This is a note to let you know that I've just added the patch titled
btrfs: Fix transaction abort during failure in btrfs_rm_dev_item
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-transaction-abort-during-failure-in-btrfs_rm_dev_item.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 Thu Feb 1 13:45:42 CET 2018
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Mon, 23 Oct 2017 09:58:46 +0300
Subject: btrfs: Fix transaction abort during failure in btrfs_rm_dev_item
From: Nikolay Borisov <nborisov(a)suse.com>
[ Upstream commit 5e9f2ad5b2904a7e81df6d9a3dbef29478952eac ]
btrfs_rm_dev_item calls several function under an active transaction,
however it fails to abort it if an error happens. Fix this by adding
explicit btrfs_abort_transaction/btrfs_end_transaction calls.
Signed-off-by: Nikolay Borisov <nborisov(a)suse.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 | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1765,20 +1765,24 @@ static int btrfs_rm_dev_item(struct btrf
key.offset = device->devid;
ret = btrfs_search_slot(trans, root, &key, path, -1, 1);
- if (ret < 0)
- goto out;
-
- if (ret > 0) {
- ret = -ENOENT;
+ if (ret) {
+ if (ret > 0)
+ ret = -ENOENT;
+ btrfs_abort_transaction(trans, ret);
+ btrfs_end_transaction(trans);
goto out;
}
ret = btrfs_del_item(trans, root, path);
- if (ret)
- goto out;
+ if (ret) {
+ btrfs_abort_transaction(trans, ret);
+ btrfs_end_transaction(trans);
+ }
+
out:
btrfs_free_path(path);
- btrfs_commit_transaction(trans);
+ if (!ret)
+ ret = btrfs_commit_transaction(trans);
return ret;
}
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.14/btrfs-fix-transaction-abort-during-failure-in-btrfs_rm_dev_item.patch
This is a note to let you know that I've just added the patch titled
Btrfs: fix list_add corruption and soft lockups in fsync
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-list_add-corruption-and-soft-lockups-in-fsync.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 Thu Feb 1 13:45:42 CET 2018
From: Liu Bo <bo.li.liu(a)oracle.com>
Date: Tue, 21 Nov 2017 14:35:40 -0700
Subject: Btrfs: fix list_add corruption and soft lockups in fsync
From: Liu Bo <bo.li.liu(a)oracle.com>
[ Upstream commit ebb70442cdd4872260c2415929c456be3562da82 ]
Xfstests btrfs/146 revealed this corruption,
[ 58.138831] Buffer I/O error on dev dm-0, logical block 2621424, async page read
[ 58.151233] BTRFS error (device sdf): bdev /dev/mapper/error-test errs: wr 1, rd 0, flush 0, corrupt 0, gen 0
[ 58.152403] list_add corruption. prev->next should be next (ffff88005e6775d8), but was ffffc9000189be88. (prev=ffffc9000189be88).
[ 58.153518] ------------[ cut here ]------------
[ 58.153892] WARNING: CPU: 1 PID: 1287 at lib/list_debug.c:31 __list_add_valid+0x169/0x1f0
...
[ 58.157379] RIP: 0010:__list_add_valid+0x169/0x1f0
...
[ 58.161956] Call Trace:
[ 58.162264] btrfs_log_inode_parent+0x5bd/0xfb0 [btrfs]
[ 58.163583] btrfs_log_dentry_safe+0x60/0x80 [btrfs]
[ 58.164003] btrfs_sync_file+0x4c2/0x6f0 [btrfs]
[ 58.164393] vfs_fsync_range+0x5f/0xd0
[ 58.164898] do_fsync+0x5a/0x90
[ 58.165170] SyS_fsync+0x10/0x20
[ 58.165395] entry_SYSCALL_64_fastpath+0x1f/0xbe
...
It turns out that we could record btrfs_log_ctx:io_err in
log_one_extents when IO fails, but make log_one_extents() return '0'
instead of -EIO, so the IO error is not acknowledged by the callers,
i.e. btrfs_log_inode_parent(), which would remove btrfs_log_ctx:list
from list head 'root->log_ctxs'. Since btrfs_log_ctx is allocated
from stack memory, it'd get freed with a object alive on the
list. then a future list_add will throw the above warning.
This returns the correct error in the above case.
Jeff also reported this while testing against his fsync error
patch set[1].
[1]: https://www.spinics.net/lists/linux-btrfs/msg65308.html
"btrfs list corruption and soft lockups while testing writeback error handling"
Fixes: 8407f553268a4611f254 ("Btrfs: fix data corruption after fast fsync and writeback error")
Signed-off-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/file.c | 5 +++--
fs/btrfs/tree-log.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -2056,6 +2056,8 @@ int btrfs_sync_file(struct file *file, l
len = (u64)end - (u64)start + 1;
trace_btrfs_sync_file(file, datasync);
+ btrfs_init_log_ctx(&ctx, inode);
+
/*
* We write the dirty pages in the range and wait until they complete
* out of the ->i_mutex. If so, we can flush the dirty pages by
@@ -2202,8 +2204,6 @@ int btrfs_sync_file(struct file *file, l
}
trans->sync = true;
- btrfs_init_log_ctx(&ctx, inode);
-
ret = btrfs_log_dentry_safe(trans, root, dentry, start, end, &ctx);
if (ret < 0) {
/* Fallthrough and commit/free transaction. */
@@ -2261,6 +2261,7 @@ int btrfs_sync_file(struct file *file, l
ret = btrfs_end_transaction(trans);
}
out:
+ ASSERT(list_empty(&ctx.list));
err = file_check_and_advance_wb_err(file);
if (!ret)
ret = err;
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4100,7 +4100,7 @@ static int log_one_extent(struct btrfs_t
if (ordered_io_err) {
ctx->io_err = -EIO;
- return 0;
+ return ctx->io_err;
}
btrfs_init_map_token(&token);
Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are
queue-4.14/btrfs-bail-out-gracefully-rather-than-bug_on.patch
queue-4.14/btrfs-fix-deadlock-when-writing-out-space-cache.patch
queue-4.14/btrfs-fix-list_add-corruption-and-soft-lockups-in-fsync.patch
This is a note to let you know that I've just added the patch titled
btrfs: fix deadlock when writing out space cache
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-deadlock-when-writing-out-space-cache.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 Thu Feb 1 13:45:42 CET 2018
From: Josef Bacik <jbacik(a)fb.com>
Date: Wed, 15 Nov 2017 16:20:52 -0500
Subject: btrfs: fix deadlock when writing out space cache
From: Josef Bacik <jbacik(a)fb.com>
[ Upstream commit b77000ed558daa3bef0899d29bf171b8c9b5e6a8 ]
If we fail to prepare our pages for whatever reason (out of memory in
our case) we need to make sure to drop the block_group->data_rwsem,
otherwise hilarity ensues.
Signed-off-by: Josef Bacik <jbacik(a)fb.com>
Reviewed-by: Omar Sandoval <osandov(a)fb.com>
Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
[ add label and use existing unlocking code ]
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/free-space-cache.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -1264,7 +1264,7 @@ static int __btrfs_write_out_cache(struc
/* Lock all pages first so we can lock the extent safely. */
ret = io_ctl_prepare_pages(io_ctl, inode, 0);
if (ret)
- goto out;
+ goto out_unlock;
lock_extent_bits(&BTRFS_I(inode)->io_tree, 0, i_size_read(inode) - 1,
&cached_state);
@@ -1358,6 +1358,7 @@ out_nospc_locked:
out_nospc:
cleanup_write_cache_enospc(inode, io_ctl, &cached_state);
+out_unlock:
if (block_group && (block_group->flags & BTRFS_BLOCK_GROUP_DATA))
up_write(&block_group->data_rwsem);
Patches currently in stable-queue which might be from jbacik(a)fb.com are
queue-4.14/btrfs-fix-deadlock-when-writing-out-space-cache.patch
This is a note to let you know that I've just added the patch titled
Btrfs: bail out gracefully rather than BUG_ON
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-bail-out-gracefully-rather-than-bug_on.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 Thu Feb 1 13:45:42 CET 2018
From: Liu Bo <bo.li.liu(a)oracle.com>
Date: Mon, 30 Oct 2017 11:14:38 -0600
Subject: Btrfs: bail out gracefully rather than BUG_ON
From: Liu Bo <bo.li.liu(a)oracle.com>
[ Upstream commit 56a0e706fcf870270878d6d72b71092ae42d229c ]
If a file's DIR_ITEM key is invalid (due to memory errors) and gets
written to disk, a future lookup_path can end up with kernel panic due
to BUG_ON().
This gets rid of the BUG_ON(), meanwhile output the corrupted key and
return ENOENT if it's invalid.
Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com>
Reported-by: Guillaume Bouchard <bouchard(a)mercs-eng.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/inode.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -5500,6 +5500,14 @@ static int btrfs_inode_by_name(struct in
goto out_err;
btrfs_dir_item_key_to_cpu(path->nodes[0], di, location);
+ if (location->type != BTRFS_INODE_ITEM_KEY &&
+ location->type != BTRFS_ROOT_ITEM_KEY) {
+ btrfs_warn(root->fs_info,
+"%s gets something invalid in DIR_ITEM (name %s, directory ino %llu, location(%llu %u %llu))",
+ __func__, name, btrfs_ino(BTRFS_I(dir)),
+ location->objectid, location->type, location->offset);
+ goto out_err;
+ }
out:
btrfs_free_path(path);
return ret;
@@ -5816,8 +5824,6 @@ struct inode *btrfs_lookup_dentry(struct
return inode;
}
- BUG_ON(location.type != BTRFS_ROOT_ITEM_KEY);
-
index = srcu_read_lock(&fs_info->subvol_srcu);
ret = fixup_tree_root_location(fs_info, dir, dentry,
&location, &sub_root);
Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are
queue-4.14/btrfs-bail-out-gracefully-rather-than-bug_on.patch
queue-4.14/btrfs-fix-deadlock-when-writing-out-space-cache.patch
queue-4.14/btrfs-fix-list_add-corruption-and-soft-lockups-in-fsync.patch
This is a note to let you know that I've just added the patch titled
bnxt_en: Fix an error handling path in 'bnxt_get_module_eeprom()'
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-an-error-handling-path-in-bnxt_get_module_eeprom.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 Thu Feb 1 13:45:42 CET 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Tue, 21 Nov 2017 20:46:49 +0100
Subject: bnxt_en: Fix an error handling path in 'bnxt_get_module_eeprom()'
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit dea521a2b9f96e905fa2bb2f95e23ec00c2ec436 ]
Error code returned by 'bnxt_read_sfp_module_eeprom_info()' is handled a
few lines above when reading the A0 portion of the EEPROM.
The same should be done when reading the A2 portion of the EEPROM.
In order to correctly propagate an error, update 'rc' in this 2nd call as
well, otherwise 0 (success) is returned.
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/ethernet/broadcom/bnxt/bnxt_ethtool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
@@ -2133,8 +2133,8 @@ static int bnxt_get_module_eeprom(struct
/* Read A2 portion of the EEPROM */
if (length) {
start -= ETH_MODULE_SFF_8436_LEN;
- bnxt_read_sfp_module_eeprom_info(bp, I2C_DEV_ADDR_A2, 1, start,
- length, data);
+ rc = bnxt_read_sfp_module_eeprom_info(bp, I2C_DEV_ADDR_A2, 1,
+ start, length, data);
}
return rc;
}
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.14/bnxt_en-fix-an-error-handling-path-in-bnxt_get_module_eeprom.patch
queue-4.14/drm-omap-fix-error-handling-path-in-omap_dmm_probe.patch
This is a note to let you know that I've just added the patch titled
bcache: check return value of register_shrinker
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:
bcache-check-return-value-of-register_shrinker.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 Thu Feb 1 13:45:42 CET 2018
From: Michael Lyle <mlyle(a)lyle.org>
Date: Fri, 24 Nov 2017 15:14:27 -0800
Subject: bcache: check return value of register_shrinker
From: Michael Lyle <mlyle(a)lyle.org>
[ Upstream commit 6c4ca1e36cdc1a0a7a84797804b87920ccbebf51 ]
register_shrinker is now __must_check, so check it to kill a warning.
Caller of bch_btree_cache_alloc in super.c appropriately checks return
value so this is fully plumbed through.
This V2 fixes checkpatch warnings and improves the commit description,
as I was too hasty getting the previous version out.
Signed-off-by: Michael Lyle <mlyle(a)lyle.org>
Reviewed-by: Vojtech Pavlik <vojtech(a)suse.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>
---
drivers/md/bcache/btree.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -807,7 +807,10 @@ int bch_btree_cache_alloc(struct cache_s
c->shrink.scan_objects = bch_mca_scan;
c->shrink.seeks = 4;
c->shrink.batch = c->btree_pages * 2;
- register_shrinker(&c->shrink);
+
+ if (register_shrinker(&c->shrink))
+ pr_warn("bcache: %s: could not register shrinker",
+ __func__);
return 0;
}
Patches currently in stable-queue which might be from mlyle(a)lyle.org are
queue-4.14/bcache-check-return-value-of-register_shrinker.patch
This is a note to let you know that I've just added the patch titled
auxdisplay: img-ascii-lcd: Only build on archs that have IOMEM
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:
auxdisplay-img-ascii-lcd-only-build-on-archs-that-have-iomem.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 Thu Feb 1 13:45:42 CET 2018
From: Thomas Meyer <thomas(a)m3y3r.de>
Date: Thu, 10 Aug 2017 10:53:53 +0200
Subject: auxdisplay: img-ascii-lcd: Only build on archs that have IOMEM
From: Thomas Meyer <thomas(a)m3y3r.de>
[ Upstream commit 141cbfba1d0502006463aa80f57c64086226af1a ]
This avoids the MODPOST error:
ERROR: "devm_ioremap_resource" [drivers/auxdisplay/img-ascii-lcd.ko] undefined!
Signed-off-by: Thomas Meyer <thomas(a)m3y3r.de>
Acked-by: Randy Dunlap <rdunlap(a)infradead.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>
---
drivers/auxdisplay/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/auxdisplay/Kconfig
+++ b/drivers/auxdisplay/Kconfig
@@ -136,6 +136,7 @@ config CFAG12864B_RATE
config IMG_ASCII_LCD
tristate "Imagination Technologies ASCII LCD Display"
+ depends on HAS_IOMEM
default y if MIPS_MALTA || MIPS_SEAD3
select SYSCON
help
Patches currently in stable-queue which might be from thomas(a)m3y3r.de are
queue-4.14/auxdisplay-img-ascii-lcd-only-build-on-archs-that-have-iomem.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: NSP: Fix PPI interrupt types
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-nsp-fix-ppi-interrupt-types.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 Thu Feb 1 13:45:42 CET 2018
From: Florian Fainelli <f.fainelli(a)gmail.com>
Date: Tue, 7 Nov 2017 11:10:29 -0800
Subject: ARM: dts: NSP: Fix PPI interrupt types
From: Florian Fainelli <f.fainelli(a)gmail.com>
[ Upstream commit 5f1aa51c7a1eef1c5a60b8334e32c89904964245 ]
Booting a kernel results in the kernel warning us about the following
PPI interrupts configuration:
[ 0.105127] smp: Bringing up secondary CPUs ...
[ 0.110545] GIC: PPI11 is secure or misconfigured
[ 0.110551] GIC: PPI13 is secure or misconfigured
Fix this by using the appropriate edge configuration for PPI11 and
PPI13, this is similar to what was fixed for Northstar (BCM5301X) in
commit 0e34079cd1f6 ("ARM: dts: BCM5301X: Correct GIC_PPI interrupt
flags").
Fixes: 7b2e987de207 ("ARM: NSP: add minimal Northstar Plus device tree")
Fixes: 1a9d53cabaf4 ("ARM: dts: NSP: Add TWD Support to DT")
Acked-by: Jon Mason <jon.mason(a)broadcom.com>
Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -85,7 +85,7 @@
timer@20200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0x20200 0x100>;
- interrupts = <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_PPI 11 IRQ_TYPE_EDGE_RISING>;
clocks = <&periph_clk>;
};
@@ -93,7 +93,7 @@
compatible = "arm,cortex-a9-twd-timer";
reg = <0x20600 0x20>;
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
- IRQ_TYPE_LEVEL_HIGH)>;
+ IRQ_TYPE_EDGE_RISING)>;
clocks = <&periph_clk>;
};
Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are
queue-4.14/arm-dts-nsp-disable-ahci-controller-for-hr-nsp-boards.patch
queue-4.14/arm-dts-nsp-fix-ppi-interrupt-types.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: NSP: Disable AHCI controller for HR NSP boards
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-nsp-disable-ahci-controller-for-hr-nsp-boards.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 Thu Feb 1 13:45:42 CET 2018
From: Florian Fainelli <f.fainelli(a)gmail.com>
Date: Tue, 7 Nov 2017 10:58:34 -0800
Subject: ARM: dts: NSP: Disable AHCI controller for HR NSP boards
From: Florian Fainelli <f.fainelli(a)gmail.com>
[ Upstream commit 77416ab35f5712382e5a792bfa1736ceb70d5bbb ]
The AHCI controller is currently enabled for all of these boards:
bcm958623hr and bcm958625hr would result in a hard hang on boot that we
cannot get rid of. Since this does not appear to have an easy and simple
fix, just disable the AHCI controller for now until this gets resolved.
Fixes: 70725d6e97ac ("ARM: dts: NSP: Enable SATA on bcm958625hr")
Fixes: d454c3762437 ("ARM: dts: NSP: Add new DT file for bcm958623hr")
Acked-by: Jon Mason <jon.mason(a)broadcom.com>
Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/bcm958623hr.dts | 4 ----
arch/arm/boot/dts/bcm958625hr.dts | 4 ----
2 files changed, 8 deletions(-)
--- a/arch/arm/boot/dts/bcm958623hr.dts
+++ b/arch/arm/boot/dts/bcm958623hr.dts
@@ -141,10 +141,6 @@
status = "okay";
};
-&sata {
- status = "okay";
-};
-
&qspi {
bspi-sel = <0>;
flash: m25p80@0 {
--- a/arch/arm/boot/dts/bcm958625hr.dts
+++ b/arch/arm/boot/dts/bcm958625hr.dts
@@ -177,10 +177,6 @@
status = "okay";
};
-&sata {
- status = "okay";
-};
-
&srab {
compatible = "brcm,bcm58625-srab", "brcm,nsp-srab";
status = "okay";
Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are
queue-4.14/arm-dts-nsp-disable-ahci-controller-for-hr-nsp-boards.patch
queue-4.14/arm-dts-nsp-fix-ppi-interrupt-types.patch
Hello Mellanox maintainers,
I'd like to ask you to OK backporting two patches in mlx5 driver to 4.9 stable
tree (they're in master for some time already).
We have multiple deployment in 4.9 that are running into the bug fixed by those
patches. We're deploying patched kernels and the issue disappears.
The patches are:
1410a90ae449061b7e1ae19d275148f36948801b net/mlx5: Define interface bits for fencing UMR wqe
6e8484c5cf07c7ee632587e98c1a12d319dacb7c RDMA/mlx5: set UMR wqe fence according to HCA cap
Regards,
Marta
This is a note to let you know that I've just added the patch titled
VFS: Handle lazytime in do_mount()
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:
vfs-handle-lazytime-in-do_mount.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 d7ee946942bdd12394809305e3df05aa4c8b7b8f Mon Sep 17 00:00:00 2001
From: Markus Trippelsdorf <markus(a)trippelsdorf.de>
Date: Wed, 11 Oct 2017 07:01:31 +0200
Subject: VFS: Handle lazytime in do_mount()
From: Markus Trippelsdorf <markus(a)trippelsdorf.de>
commit d7ee946942bdd12394809305e3df05aa4c8b7b8f upstream.
Since commit e462ec50cb5fa ("VFS: Differentiate mount flags (MS_*) from
internal superblock flags") the lazytime mount option doesn't get passed
on anymore.
Fix the issue by handling the option in do_mount().
Reviewed-by: Lukas Czerner <lczerner(a)redhat.com>
Signed-off-by: Markus Trippelsdorf <markus(a)trippelsdorf.de>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: Holger Hoffstätte <holger(a)applied-asynchrony.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/namespace.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2826,6 +2826,7 @@ long do_mount(const char *dev_name, cons
SB_DIRSYNC |
SB_SILENT |
SB_POSIXACL |
+ SB_LAZYTIME |
SB_I_VERSION);
if (flags & MS_REMOUNT)
Patches currently in stable-queue which might be from markus(a)trippelsdorf.de are
queue-4.14/vfs-handle-lazytime-in-do_mount.patch
This is a note to let you know that I've just added the patch titled
scsi: aacraid: Fix udev inquiry race condition
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:
scsi-aacraid-fix-udev-inquiry-race-condition.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 f4e8708d3104437fd7716e957f38c265b0c509ef Mon Sep 17 00:00:00 2001
From: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com>
Date: Tue, 26 Dec 2017 20:34:22 -0800
Subject: scsi: aacraid: Fix udev inquiry race condition
From: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com>
commit f4e8708d3104437fd7716e957f38c265b0c509ef upstream.
When udev requests for a devices inquiry string, it might create multiple
threads causing a race condition on the shared inquiry resource string.
Created a buffer with the string for each thread.
Fixes: 3bc8070fb75b3315 ([SCSI] aacraid: SMC vendor identification)
Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/aacraid/aachba.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -913,8 +913,16 @@ static void setinqstr(struct aac_dev *de
memset(str, ' ', sizeof(*str));
if (sup_adap_info->adapter_type_text[0]) {
- char *cp = sup_adap_info->adapter_type_text;
int c;
+ char *cp;
+ char *cname = kmemdup(sup_adap_info->adapter_type_text,
+ sizeof(sup_adap_info->adapter_type_text),
+ GFP_ATOMIC);
+
+ if (!cname)
+ return;
+
+ cp = cname;
if ((cp[0] == 'A') && (cp[1] == 'O') && (cp[2] == 'C'))
inqstrcpy("SMC", str->vid);
else {
@@ -923,7 +931,7 @@ static void setinqstr(struct aac_dev *de
++cp;
c = *cp;
*cp = '\0';
- inqstrcpy(sup_adap_info->adapter_type_text, str->vid);
+ inqstrcpy(cname, str->vid);
*cp = c;
while (*cp && *cp != ' ')
++cp;
@@ -937,8 +945,8 @@ static void setinqstr(struct aac_dev *de
cp[sizeof(str->pid)] = '\0';
}
inqstrcpy (cp, str->pid);
- if (c)
- cp[sizeof(str->pid)] = c;
+
+ kfree(cname);
} else {
struct aac_driver_ident *mp = aac_get_driver_ident(dev->cardtype);
Patches currently in stable-queue which might be from RaghavaAditya.Renukunta(a)microsemi.com are
queue-4.14/scsi-aacraid-fix-udev-inquiry-race-condition.patch
queue-4.14/scsi-aacraid-fix-hang-in-kdump.patch
This is a note to let you know that I've just added the patch titled
tools/gpio: Fix build error with musl libc
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:
tools-gpio-fix-build-error-with-musl-libc.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 1696784eb7b52b13b62d160c028ef2c2c981d4f2 Mon Sep 17 00:00:00 2001
From: Joel Stanley <joel(a)jms.id.au>
Date: Thu, 21 Dec 2017 11:11:31 +1030
Subject: tools/gpio: Fix build error with musl libc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Joel Stanley <joel(a)jms.id.au>
commit 1696784eb7b52b13b62d160c028ef2c2c981d4f2 upstream.
The GPIO tools build fails when using a buildroot toolchain that uses musl
as it's C library:
arm-broomstick-linux-musleabi-gcc -Wp,-MD,./.gpio-event-mon.o.d \
-Wp,-MT,gpio-event-mon.o -O2 -Wall -g -D_GNU_SOURCE \
-Iinclude -D"BUILD_STR(s)=#s" -c -o gpio-event-mon.o gpio-event-mon.c
gpio-event-mon.c:30:6: error: unknown type name ‘u_int32_t’; did you mean ‘uint32_t’?
u_int32_t handleflags,
^~~~~~~~~
uint32_t
The glibc headers installed on my laptop include sys/types.h in
unistd.h, but it appears that musl does not.
Fixes: 97f69747d8b1 ("tools/gpio: add the gpio-event-mon tool")
Signed-off-by: Joel Stanley <joel(a)jms.id.au>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/gpio/gpio-event-mon.c | 1 +
1 file changed, 1 insertion(+)
--- a/tools/gpio/gpio-event-mon.c
+++ b/tools/gpio/gpio-event-mon.c
@@ -23,6 +23,7 @@
#include <getopt.h>
#include <inttypes.h>
#include <sys/ioctl.h>
+#include <sys/types.h>
#include <linux/gpio.h>
int monitor_device(const char *device_name,
Patches currently in stable-queue which might be from joel(a)jms.id.au are
queue-4.14/tools-gpio-fix-build-error-with-musl-libc.patch
This is a note to let you know that I've just added the patch titled
scsi: aacraid: Fix hang in kdump
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:
scsi-aacraid-fix-hang-in-kdump.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 c5313ae8e4e037bfaf5e56cb8d6efdb8e92ce437 Mon Sep 17 00:00:00 2001
From: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com>
Date: Tue, 26 Dec 2017 20:34:24 -0800
Subject: scsi: aacraid: Fix hang in kdump
From: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com>
commit c5313ae8e4e037bfaf5e56cb8d6efdb8e92ce437 upstream.
Driver attempts to perform a device scan and device add after coming out
of reset. At times when the kdump kernel loads and it tries to perform
eh recovery, the device scan hangs since its commands are blocked because
of the eh recovery. This should have shown up in normal eh recovery path
(Should have been obvious)
Remove the code that performs scanning.I can live without the rescanning
support in the stable kernels but a hanging kdump/eh recovery needs to be
fixed.
Fixes: a2d0321dd532901e (scsi: aacraid: Reload offlined drives after controller reset)
Reported-by: Douglas Miller <dougmill(a)linux.vnet.ibm.com>
Tested-by: Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com>
Fixes: a2d0321dd532901e (scsi: aacraid: Reload offlined drives after controller reset)
Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/aacraid/aachba.c | 1 -
drivers/scsi/aacraid/commsup.c | 9 +--------
2 files changed, 1 insertion(+), 9 deletions(-)
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -918,7 +918,6 @@ static void setinqstr(struct aac_dev *de
char *cname = kmemdup(sup_adap_info->adapter_type_text,
sizeof(sup_adap_info->adapter_type_text),
GFP_ATOMIC);
-
if (!cname)
return;
--- a/drivers/scsi/aacraid/commsup.c
+++ b/drivers/scsi/aacraid/commsup.c
@@ -1672,14 +1672,7 @@ static int _aac_reset_adapter(struct aac
out:
aac->in_reset = 0;
scsi_unblock_requests(host);
- /*
- * Issue bus rescan to catch any configuration that might have
- * occurred
- */
- if (!retval) {
- dev_info(&aac->pdev->dev, "Issuing bus rescan\n");
- scsi_scan_host(host);
- }
+
if (jafo) {
spin_lock_irq(host->host_lock);
}
Patches currently in stable-queue which might be from RaghavaAditya.Renukunta(a)microsemi.com are
queue-4.14/scsi-aacraid-fix-udev-inquiry-race-condition.patch
queue-4.14/scsi-aacraid-fix-hang-in-kdump.patch
This is a note to let you know that I've just added the patch titled
power: reset: zx-reboot: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
power-reset-zx-reboot-add-missing-module_description-author-license.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 348c7cf5fcbcb68838255759d4cb45d039af36d2 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:58:27 -0800
Subject: power: reset: zx-reboot: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 348c7cf5fcbcb68838255759d4cb45d039af36d2 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/power/reset/zx-reboot.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/power/reset/zx-reboot.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/power/reset/zx-reboot.c
+++ b/drivers/power/reset/zx-reboot.c
@@ -82,3 +82,7 @@ static struct platform_driver zx_reboot_
},
};
module_platform_driver(zx_reboot_driver);
+
+MODULE_DESCRIPTION("ZTE SoCs reset driver");
+MODULE_AUTHOR("Jun Nie <jun.nie(a)linaro.org>");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.14/gpio-iop-add-missing-module_description-author-license.patch
queue-4.14/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.14/gpio-ath79-add-missing-module_description-license.patch
queue-4.14/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: denali_pci: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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-denali_pci-add-missing-module_description-author-license.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 d822401d1c6898a4a4ee03977b78b8cec402e88a Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:57:13 -0800
Subject: mtd: nand: denali_pci: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit d822401d1c6898a4a4ee03977b78b8cec402e88a upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/mtd/nand/denali_pci.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Acked-by: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/denali_pci.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/mtd/nand/denali_pci.c
+++ b/drivers/mtd/nand/denali_pci.c
@@ -124,3 +124,7 @@ static struct pci_driver denali_pci_driv
};
module_pci_driver(denali_pci_driver);
+
+MODULE_DESCRIPTION("PCI driver for Denali NAND controller");
+MODULE_AUTHOR("Intel Corporation and its suppliers");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.14/gpio-iop-add-missing-module_description-author-license.patch
queue-4.14/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.14/gpio-ath79-add-missing-module_description-license.patch
queue-4.14/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
ima/policy: fix parsing of fsuuid
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:
ima-policy-fix-parsing-of-fsuuid.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 36447456e1cca853188505f2a964dbbeacfc7a7a Mon Sep 17 00:00:00 2001
From: Mike Rapoport <rppt(a)linux.vnet.ibm.com>
Date: Wed, 17 Jan 2018 20:27:11 +0200
Subject: ima/policy: fix parsing of fsuuid
From: Mike Rapoport <rppt(a)linux.vnet.ibm.com>
commit 36447456e1cca853188505f2a964dbbeacfc7a7a upstream.
The switch to uuid_t invereted the logic of verfication that &entry->fsuuid
is zero during parsing of "fsuuid=" rule. Instead of making sure the
&entry->fsuuid field is not attempted to be overwritten, we bail out for
perfectly correct rule.
Fixes: 787d8c530af7 ("ima/policy: switch to use uuid_t")
Signed-off-by: Mike Rapoport <rppt(a)linux.vnet.ibm.com>
Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/integrity/ima/ima_policy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -743,7 +743,7 @@ static int ima_parse_rule(char *rule, st
case Opt_fsuuid:
ima_log_string(ab, "fsuuid", args[0].from);
- if (uuid_is_null(&entry->fsuuid)) {
+ if (!uuid_is_null(&entry->fsuuid)) {
result = -EINVAL;
break;
}
Patches currently in stable-queue which might be from rppt(a)linux.vnet.ibm.com are
queue-4.14/ima-policy-fix-parsing-of-fsuuid.patch
This is a note to let you know that I've just added the patch titled
igb: Free IRQs when device is hotplugged
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:
igb-free-irqs-when-device-is-hotplugged.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 888f22931478a05bc81ceb7295c626e1292bf0ed Mon Sep 17 00:00:00 2001
From: Lyude Paul <lyude(a)redhat.com>
Date: Tue, 12 Dec 2017 14:31:30 -0500
Subject: igb: Free IRQs when device is hotplugged
From: Lyude Paul <lyude(a)redhat.com>
commit 888f22931478a05bc81ceb7295c626e1292bf0ed upstream.
Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon
hotplugging my kernel would immediately crash due to igb:
[ 680.825801] kernel BUG at drivers/pci/msi.c:352!
[ 680.828388] invalid opcode: 0000 [#1] SMP
[ 680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb]
[ 680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G O 4.15.0-rc3Lyude-Test+ #6
[ 680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver. 01.03 06/09/2017
[ 680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[ 680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0
[ 680.833271] RSP: 0018:ffffc9000030fbf0 EFLAGS: 00010286
[ 680.833761] RAX: ffff8803405f9c00 RBX: ffff88033e3d2e40 RCX: 000000000000002c
[ 680.834278] RDX: 0000000000000000 RSI: 00000000000000ac RDI: ffff880340be2178
[ 680.834832] RBP: 0000000000000000 R08: ffff880340be1ff0 R09: ffff8803405f9c00
[ 680.835342] R10: 0000000000000000 R11: 0000000000000040 R12: ffff88033d63a298
[ 680.835822] R13: ffff88033d63a000 R14: 0000000000000060 R15: ffff880341959000
[ 680.836332] FS: 0000000000000000(0000) GS:ffff88034f440000(0000) knlGS:0000000000000000
[ 680.836817] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 680.837360] CR2: 000055e64044afdf CR3: 0000000001c09002 CR4: 00000000003606e0
[ 680.837954] Call Trace:
[ 680.838853] pci_disable_msix+0xce/0xf0
[ 680.839616] igb_reset_interrupt_capability+0x5d/0x60 [igb]
[ 680.840278] igb_remove+0x9d/0x110 [igb]
[ 680.840764] pci_device_remove+0x36/0xb0
[ 680.841279] device_release_driver_internal+0x157/0x220
[ 680.841739] pci_stop_bus_device+0x7d/0xa0
[ 680.842255] pci_stop_bus_device+0x2b/0xa0
[ 680.842722] pci_stop_bus_device+0x3d/0xa0
[ 680.843189] pci_stop_and_remove_bus_device+0xe/0x20
[ 680.843627] trim_stale_devices+0xf3/0x140
[ 680.844086] trim_stale_devices+0x94/0x140
[ 680.844532] trim_stale_devices+0xa6/0x140
[ 680.845031] ? get_slot_status+0x90/0xc0
[ 680.845536] acpiphp_check_bridge.part.5+0xfe/0x140
[ 680.846021] acpiphp_hotplug_notify+0x175/0x200
[ 680.846581] ? free_bridge+0x100/0x100
[ 680.847113] acpi_device_hotplug+0x8a/0x490
[ 680.847535] acpi_hotplug_work_fn+0x1a/0x30
[ 680.848076] process_one_work+0x182/0x3a0
[ 680.848543] worker_thread+0x2e/0x380
[ 680.848963] ? process_one_work+0x3a0/0x3a0
[ 680.849373] kthread+0x111/0x130
[ 680.849776] ? kthread_create_worker_on_cpu+0x50/0x50
[ 680.850188] ret_from_fork+0x1f/0x30
[ 680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 <0f> 0b 49 8d b5 a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b
[ 680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: ffffc9000030fbf0
As it turns out, normally the freeing of IRQs that would fix this is called
inside of the scope of __igb_close(). However, since the device is
already gone by the point we try to unregister the netdevice from the
driver due to a hotplug we end up seeing that the netif isn't present
and thus, forget to free any of the device IRQs.
So: make sure that if we're in the process of dismantling the netdev, we
always allow __igb_close() to be called so that IRQs may be freed
normally. Additionally, only allow igb_close() to be called from
__igb_close() if it hasn't already been called for the given adapter.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Fixes: 9474933caf21 ("igb: close/suspend race in netif_device_detach")
Cc: Todd Fujinaka <todd.fujinaka(a)intel.com>
Cc: Stephen Hemminger <stephen(a)networkplumber.org>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3331,7 +3331,7 @@ static int __igb_close(struct net_device
int igb_close(struct net_device *netdev)
{
- if (netif_device_present(netdev))
+ if (netif_device_present(netdev) || netdev->dismantle)
return __igb_close(netdev, false);
return 0;
}
Patches currently in stable-queue which might be from lyude(a)redhat.com are
queue-4.14/igb-free-irqs-when-device-is-hotplugged.patch
This is a note to let you know that I've just added the patch titled
HID: wacom: Fix reporting of touch toggle (WACOM_HID_WD_MUTE_DEVICE) events
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:
hid-wacom-fix-reporting-of-touch-toggle-wacom_hid_wd_mute_device-events.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 403c0f681c1964ff1db8c2fb8de8c4067779d081 Mon Sep 17 00:00:00 2001
From: Jason Gerecke <killertofu(a)gmail.com>
Date: Tue, 26 Dec 2017 14:53:55 -0800
Subject: HID: wacom: Fix reporting of touch toggle (WACOM_HID_WD_MUTE_DEVICE) events
From: Jason Gerecke <killertofu(a)gmail.com>
commit 403c0f681c1964ff1db8c2fb8de8c4067779d081 upstream.
Touch toggle softkeys send a '1' while pressed and a '0' while released,
requring the kernel to keep track of wether touch should be enabled or
disabled. The code does not handle the state transitions properly,
however. If the key is pressed repeatedly, the following four states
of states are cycled through (assuming touch starts out enabled):
Press: shared->is_touch_on => 0, SW_MUTE_DEVICE => 1
Release: shared->is_touch_on => 0, SW_MUTE_DEVICE => 1
Press: shared->is_touch_on => 1, SW_MUTE_DEVICE => 0
Release: shared->is_touch_on => 1, SW_MUTE_DEVICE => 1
The hardware always properly enables/disables touch when the key is
pressed but applications that listen for SW_MUTE_DEVICE events to provide
feedback about the state will only ever show touch as being enabled while
the key is held, and only every-other time. This sequence occurs because
the fallthrough WACOM_HID_WD_TOUCHONOFF case is always handled, and it
uses the value of the *local* is_touch_on variable as the value to
report to userspace. The local value is equal to the shared value when
the button is pressed, but equal to zero when the button is released.
Reporting the shared value to userspace fixes this problem, but the
fallthrough case needs to update the shared value in an incompatible
way (which is why the local variable was introduced in the first place).
To work around this, we just handle both cases in a single block of code
and update the shared variable as appropriate.
Fixes: d793ff8187 ("HID: wacom: generic: support touch on/off softkey")
Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com>
Reviewed-by: Aaron Skomra <aaron.skomra(a)wacom.com>
Tested-by: Aaron Skomra <aaron.skomra(a)wacom.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/wacom_wac.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -1924,7 +1924,6 @@ static void wacom_wac_pad_event(struct h
struct wacom_features *features = &wacom_wac->features;
unsigned equivalent_usage = wacom_equivalent_usage(usage->hid);
int i;
- bool is_touch_on = value;
bool do_report = false;
/*
@@ -1969,16 +1968,17 @@ static void wacom_wac_pad_event(struct h
break;
case WACOM_HID_WD_MUTE_DEVICE:
- if (wacom_wac->shared->touch_input && value) {
- wacom_wac->shared->is_touch_on = !wacom_wac->shared->is_touch_on;
- is_touch_on = wacom_wac->shared->is_touch_on;
- }
-
- /* fall through*/
case WACOM_HID_WD_TOUCHONOFF:
if (wacom_wac->shared->touch_input) {
+ bool *is_touch_on = &wacom_wac->shared->is_touch_on;
+
+ if (equivalent_usage == WACOM_HID_WD_MUTE_DEVICE && value)
+ *is_touch_on = !(*is_touch_on);
+ else if (equivalent_usage == WACOM_HID_WD_TOUCHONOFF)
+ *is_touch_on = value;
+
input_report_switch(wacom_wac->shared->touch_input,
- SW_MUTE_DEVICE, !is_touch_on);
+ SW_MUTE_DEVICE, !(*is_touch_on));
input_sync(wacom_wac->shared->touch_input);
}
break;
Patches currently in stable-queue which might be from killertofu(a)gmail.com are
queue-4.14/hid-wacom-fix-reporting-of-touch-toggle-wacom_hid_wd_mute_device-events.patch
This is a note to let you know that I've just added the patch titled
HID: wacom: EKR: ensure devres groups at higher indexes are released
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:
hid-wacom-ekr-ensure-devres-groups-at-higher-indexes-are-released.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 791ae273731fa85d3332e45064dab177ae663e80 Mon Sep 17 00:00:00 2001
From: Aaron Armstrong Skomra <skomra(a)gmail.com>
Date: Thu, 7 Dec 2017 12:31:56 -0800
Subject: HID: wacom: EKR: ensure devres groups at higher indexes are released
From: Aaron Armstrong Skomra <skomra(a)gmail.com>
commit 791ae273731fa85d3332e45064dab177ae663e80 upstream.
Background: ExpressKey Remotes communicate their events via usb dongle.
Each dongle can hold up to 5 pairings at one time and one EKR (identified
by its serial number) can unfortunately be paired with its dongle
more than once. The pairing takes place in a round-robin fashion.
Input devices are only created once per EKR, when a new serial number
is seen in the list of pairings. However, if a device is created for
a "higher" paring index and subsequently a second pairing occurs at a
lower pairing index, unpairing the remote with that serial number from
any pairing index will currently cause a driver crash. This occurs
infrequently, as two remotes are necessary to trigger this bug and most
users have only one remote.
As an illustration, to trigger the bug you need to have two remotes,
and pair them in this order:
1. slot 0 -> remote 1 (input device created for remote 1)
2. slot 1 -> remote 1 (duplicate pairing - no device created)
3. slot 2 -> remote 1 (duplicate pairing - no device created)
4. slot 3 -> remote 1 (duplicate pairing - no device created)
5. slot 4 -> remote 2 (input device created for remote 2)
6. slot 0 -> remote 2 (1 destroyed and recreated at slot 1)
7. slot 1 -> remote 2 (1 destroyed and recreated at slot 2)
8. slot 2 -> remote 2 (1 destroyed and recreated at slot 3)
9. slot 3 -> remote 2 (1 destroyed and not recreated)
10. slot 4 -> remote 2 (2 was already in this slot so no changes)
11. slot 0 -> remote 1 (The current code sees remote 2 was paired over in
one of the dongle slots it occupied and attempts
to remove all information about remote 2 [1]. It
calls wacom_remote_destroy_one for remote 2, but
the destroy function assumes the lowest index is
where the remote's input device was created. The
code "cleans up" the other remote 2 pairings
including the one which the input device was based
on, assuming they were were just duplicate
pairings. However, the cleanup doesn't call the
devres release function for the input device that
was created in slot 4).
This issue is fixed by this commit.
[1] Remote 2 should subsequently be re-created on the next packet from the
EKR at the lowest numbered slot that it occupies (here slot 1).
Fixes: f9036bd43602 ("HID: wacom: EKR: use devres groups to manage resources")
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra(a)wacom.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/wacom_sys.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -2340,23 +2340,23 @@ static void wacom_remote_destroy_one(str
int i;
unsigned long flags;
- spin_lock_irqsave(&remote->remote_lock, flags);
- remote->remotes[index].registered = false;
- spin_unlock_irqrestore(&remote->remote_lock, flags);
+ for (i = 0; i < WACOM_MAX_REMOTES; i++) {
+ if (remote->remotes[i].serial == serial) {
- if (remote->remotes[index].battery.battery)
- devres_release_group(&wacom->hdev->dev,
- &remote->remotes[index].battery.bat_desc);
+ spin_lock_irqsave(&remote->remote_lock, flags);
+ remote->remotes[i].registered = false;
+ spin_unlock_irqrestore(&remote->remote_lock, flags);
- if (remote->remotes[index].group.name)
- devres_release_group(&wacom->hdev->dev,
- &remote->remotes[index]);
+ if (remote->remotes[i].battery.battery)
+ devres_release_group(&wacom->hdev->dev,
+ &remote->remotes[i].battery.bat_desc);
+
+ if (remote->remotes[i].group.name)
+ devres_release_group(&wacom->hdev->dev,
+ &remote->remotes[i]);
- for (i = 0; i < WACOM_MAX_REMOTES; i++) {
- if (remote->remotes[i].serial == serial) {
remote->remotes[i].serial = 0;
remote->remotes[i].group.name = NULL;
- remote->remotes[i].registered = false;
remote->remotes[i].battery.battery = NULL;
wacom->led.groups[i].select = WACOM_STATUS_UNKNOWN;
}
Patches currently in stable-queue which might be from skomra(a)gmail.com are
queue-4.14/hid-wacom-ekr-ensure-devres-groups-at-higher-indexes-are-released.patch
This is a note to let you know that I've just added the patch titled
gpio: stmpe: i2c transfer are forbiden in atomic context
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:
gpio-stmpe-i2c-transfer-are-forbiden-in-atomic-context.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 b888fb6f2a278442933e3bfab70262e9a5365fb3 Mon Sep 17 00:00:00 2001
From: Patrice Chotard <patrice.chotard(a)st.com>
Date: Fri, 12 Jan 2018 13:16:08 +0100
Subject: gpio: stmpe: i2c transfer are forbiden in atomic context
From: Patrice Chotard <patrice.chotard(a)st.com>
commit b888fb6f2a278442933e3bfab70262e9a5365fb3 upstream.
Move the workaround from stmpe_gpio_irq_unmask() which is executed
in atomic context to stmpe_gpio_irq_sync_unlock() which is not.
It fixes the following issue:
[ 1.500000] BUG: scheduling while atomic: swapper/1/0x00000002
[ 1.500000] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc2-00020-gbd4301f-dirty #28
[ 1.520000] Hardware name: STM32 (Device Tree Support)
[ 1.520000] [<0000bfc9>] (unwind_backtrace) from [<0000b347>] (show_stack+0xb/0xc)
[ 1.530000] [<0000b347>] (show_stack) from [<0001fc49>] (__schedule_bug+0x39/0x58)
[ 1.530000] [<0001fc49>] (__schedule_bug) from [<00168211>] (__schedule+0x23/0x2b2)
[ 1.550000] [<00168211>] (__schedule) from [<001684f7>] (schedule+0x57/0x64)
[ 1.550000] [<001684f7>] (schedule) from [<0016a513>] (schedule_timeout+0x137/0x164)
[ 1.550000] [<0016a513>] (schedule_timeout) from [<00168b91>] (wait_for_common+0x8d/0xfc)
[ 1.570000] [<00168b91>] (wait_for_common) from [<00139753>] (stm32f4_i2c_xfer+0xe9/0xfe)
[ 1.580000] [<00139753>] (stm32f4_i2c_xfer) from [<00138545>] (__i2c_transfer+0x111/0x148)
[ 1.590000] [<00138545>] (__i2c_transfer) from [<001385cf>] (i2c_transfer+0x53/0x70)
[ 1.590000] [<001385cf>] (i2c_transfer) from [<001388a5>] (i2c_smbus_xfer+0x12f/0x36e)
[ 1.600000] [<001388a5>] (i2c_smbus_xfer) from [<00138b49>] (i2c_smbus_read_byte_data+0x1f/0x2a)
[ 1.610000] [<00138b49>] (i2c_smbus_read_byte_data) from [<00124fdd>] (__stmpe_reg_read+0xd/0x24)
[ 1.620000] [<00124fdd>] (__stmpe_reg_read) from [<001252b3>] (stmpe_reg_read+0x19/0x24)
[ 1.630000] [<001252b3>] (stmpe_reg_read) from [<0002c4d1>] (unmask_irq+0x17/0x22)
[ 1.640000] [<0002c4d1>] (unmask_irq) from [<0002c57f>] (irq_startup+0x6f/0x78)
[ 1.650000] [<0002c57f>] (irq_startup) from [<0002b7a1>] (__setup_irq+0x319/0x47c)
[ 1.650000] [<0002b7a1>] (__setup_irq) from [<0002bad3>] (request_threaded_irq+0x6b/0xe8)
[ 1.660000] [<0002bad3>] (request_threaded_irq) from [<0002d0b9>] (devm_request_threaded_irq+0x3b/0x6a)
[ 1.670000] [<0002d0b9>] (devm_request_threaded_irq) from [<001446e7>] (mmc_gpiod_request_cd_irq+0x49/0x8a)
[ 1.680000] [<001446e7>] (mmc_gpiod_request_cd_irq) from [<0013d45d>] (mmc_start_host+0x49/0x60)
[ 1.690000] [<0013d45d>] (mmc_start_host) from [<0013e40b>] (mmc_add_host+0x3b/0x54)
[ 1.700000] [<0013e40b>] (mmc_add_host) from [<00148119>] (mmci_probe+0x4d1/0x60c)
[ 1.710000] [<00148119>] (mmci_probe) from [<000f903b>] (amba_probe+0x7b/0xbe)
[ 1.720000] [<000f903b>] (amba_probe) from [<001170e5>] (driver_probe_device+0x169/0x1f8)
[ 1.730000] [<001170e5>] (driver_probe_device) from [<001171b7>] (__driver_attach+0x43/0x5c)
[ 1.740000] [<001171b7>] (__driver_attach) from [<0011618d>] (bus_for_each_dev+0x3d/0x46)
[ 1.740000] [<0011618d>] (bus_for_each_dev) from [<001165cd>] (bus_add_driver+0xcd/0x124)
[ 1.740000] [<001165cd>] (bus_add_driver) from [<00117713>] (driver_register+0x4d/0x7a)
[ 1.760000] [<00117713>] (driver_register) from [<001fc765>] (do_one_initcall+0xbd/0xe8)
[ 1.770000] [<001fc765>] (do_one_initcall) from [<001fc88b>] (kernel_init_freeable+0xfb/0x134)
[ 1.780000] [<001fc88b>] (kernel_init_freeable) from [<00167ee3>] (kernel_init+0x7/0x9c)
[ 1.790000] [<00167ee3>] (kernel_init) from [<00009b65>] (ret_from_fork+0x11/0x2c)
Signed-off-by: Alexandre TORGUE <alexandre.torgue(a)st.com>
Signed-off-by: Patrice Chotard <patrice.chotard(a)st.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-stmpe.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/drivers/gpio/gpio-stmpe.c
+++ b/drivers/gpio/gpio-stmpe.c
@@ -190,6 +190,16 @@ static void stmpe_gpio_irq_sync_unlock(s
};
int i, j;
+ /*
+ * STMPE1600: to be able to get IRQ from pins,
+ * a read must be done on GPMR register, or a write in
+ * GPSR or GPCR registers
+ */
+ if (stmpe->partnum == STMPE1600) {
+ stmpe_reg_read(stmpe, stmpe->regs[STMPE_IDX_GPMR_LSB]);
+ stmpe_reg_read(stmpe, stmpe->regs[STMPE_IDX_GPMR_CSB]);
+ }
+
for (i = 0; i < CACHE_NR_REGS; i++) {
/* STMPE801 and STMPE1600 don't have RE and FE registers */
if ((stmpe->partnum == STMPE801 ||
@@ -227,21 +237,11 @@ static void stmpe_gpio_irq_unmask(struct
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
struct stmpe_gpio *stmpe_gpio = gpiochip_get_data(gc);
- struct stmpe *stmpe = stmpe_gpio->stmpe;
int offset = d->hwirq;
int regoffset = offset / 8;
int mask = BIT(offset % 8);
stmpe_gpio->regs[REG_IE][regoffset] |= mask;
-
- /*
- * STMPE1600 workaround: to be able to get IRQ from pins,
- * a read must be done on GPMR register, or a write in
- * GPSR or GPCR registers
- */
- if (stmpe->partnum == STMPE1600)
- stmpe_reg_read(stmpe,
- stmpe->regs[STMPE_IDX_GPMR_LSB + regoffset]);
}
static void stmpe_dbg_show_one(struct seq_file *s,
Patches currently in stable-queue which might be from patrice.chotard(a)st.com are
queue-4.14/gpio-stmpe-i2c-transfer-are-forbiden-in-atomic-context.patch
This is a note to let you know that I've just added the patch titled
gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
gpio-iop-add-missing-module_description-author-license.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 97b03136e1b637d7a9d2274c099e44ecf23f1103 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:54:52 -0800
Subject: gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 97b03136e1b637d7a9d2274c099e44ecf23f1103 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-iop.o
see include/linux/module.h for more information
This adds the license as "GPL", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-iop.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/gpio/gpio-iop.c
+++ b/drivers/gpio/gpio-iop.c
@@ -58,3 +58,7 @@ static int __init iop3xx_gpio_init(void)
return platform_driver_register(&iop3xx_gpio_driver);
}
arch_initcall(iop3xx_gpio_init);
+
+MODULE_DESCRIPTION("GPIO handling for Intel IOP3xx processors");
+MODULE_AUTHOR("Lennert Buytenhek <buytenh(a)wantstofly.org>");
+MODULE_LICENSE("GPL");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.14/gpio-iop-add-missing-module_description-author-license.patch
queue-4.14/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.14/gpio-ath79-add-missing-module_description-license.patch
queue-4.14/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
gpio: Fix kernel stack leak to userspace
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:
gpio-fix-kernel-stack-leak-to-userspace.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 24bd3efc9d1efb5f756a7c6f807a36ddb6adc671 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Mon, 22 Jan 2018 13:19:28 +0100
Subject: gpio: Fix kernel stack leak to userspace
From: Linus Walleij <linus.walleij(a)linaro.org>
commit 24bd3efc9d1efb5f756a7c6f807a36ddb6adc671 upstream.
The GPIO event descriptor was leaking kernel stack to
userspace because we don't zero the variable before
use. Ooops. Fix this.
Reported-by: Arnd Bergmann <arnd(a)arndb.de>
Reviewed-by: Bartosz Golaszewski <brgl(a)bgdev.pl>
Reviewed-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpiolib.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -723,6 +723,9 @@ static irqreturn_t lineevent_irq_thread(
struct gpioevent_data ge;
int ret, level;
+ /* Do not leak kernel stack to userspace */
+ memset(&ge, 0, sizeof(ge));
+
ge.timestamp = ktime_get_real_ns();
level = gpiod_get_value_cansleep(le->desc);
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.14/gpio-iop-add-missing-module_description-author-license.patch
queue-4.14/tools-gpio-fix-build-error-with-musl-libc.patch
queue-4.14/gpio-fix-kernel-stack-leak-to-userspace.patch
queue-4.14/gpio-ath79-add-missing-module_description-license.patch
queue-4.14/gpio-stmpe-i2c-transfer-are-forbiden-in-atomic-context.patch
This is a note to let you know that I've just added the patch titled
gpio: ath79: add missing MODULE_DESCRIPTION/LICENSE
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:
gpio-ath79-add-missing-module_description-license.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 539340f37e6d6ed4cd93e8e18c9b2e4eafd4b842 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:54:26 -0800
Subject: gpio: ath79: add missing MODULE_DESCRIPTION/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 539340f37e6d6ed4cd93e8e18c9b2e4eafd4b842 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-ath79.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION is also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Acked-by: Alban Bedel <albeu(a)free.fr>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-ath79.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpio/gpio-ath79.c
+++ b/drivers/gpio/gpio-ath79.c
@@ -323,3 +323,6 @@ static struct platform_driver ath79_gpio
};
module_platform_driver(ath79_gpio_driver);
+
+MODULE_DESCRIPTION("Atheros AR71XX/AR724X/AR913X GPIO API support");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.14/gpio-iop-add-missing-module_description-author-license.patch
queue-4.14/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.14/gpio-ath79-add-missing-module_description-license.patch
queue-4.14/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
crypto: sha3-generic - fixes for alignment and big endian operation
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-sha3-generic-fixes-for-alignment-and-big-endian-operation.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 c013cee99d5a18aec8c71fee8f5f41369cd12595 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Fri, 19 Jan 2018 12:04:33 +0000
Subject: crypto: sha3-generic - fixes for alignment and big endian operation
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
commit c013cee99d5a18aec8c71fee8f5f41369cd12595 upstream.
Ensure that the input is byte swabbed before injecting it into the
SHA3 transform. Use the get_unaligned() accessor for this so that
we don't perform unaligned access inadvertently on architectures
that do not support that.
Fixes: 53964b9ee63b7075 ("crypto: sha3 - Add SHA-3 hash algorithm")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/sha3_generic.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/crypto/sha3_generic.c
+++ b/crypto/sha3_generic.c
@@ -18,6 +18,7 @@
#include <linux/types.h>
#include <crypto/sha3.h>
#include <asm/byteorder.h>
+#include <asm/unaligned.h>
#define KECCAK_ROUNDS 24
@@ -149,7 +150,7 @@ static int sha3_update(struct shash_desc
unsigned int i;
for (i = 0; i < sctx->rsizw; i++)
- sctx->st[i] ^= ((u64 *) src)[i];
+ sctx->st[i] ^= get_unaligned_le64(src + 8 * i);
keccakf(sctx->st);
done += sctx->rsiz;
@@ -174,7 +175,7 @@ static int sha3_final(struct shash_desc
sctx->buf[sctx->rsiz - 1] |= 0x80;
for (i = 0; i < sctx->rsizw; i++)
- sctx->st[i] ^= ((u64 *) sctx->buf)[i];
+ sctx->st[i] ^= get_unaligned_le64(sctx->buf + 8 * i);
keccakf(sctx->st);
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.14/crypto-sha3-generic-fixes-for-alignment-and-big-endian-operation.patch
This is a note to let you know that I've just added the patch titled
crypto: inside-secure - fix hash when length is a multiple of a block
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-fix-hash-when-length-is-a-multiple-of-a-block.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 809778e02cd45d0625439fee67688f655627bb3c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20T=C3=A9nart?= <antoine.tenart(a)free-electrons.com>
Date: Tue, 26 Dec 2017 17:21:17 +0100
Subject: crypto: inside-secure - fix hash when length is a multiple of a block
From: Antoine Tenart <antoine.tenart(a)free-electrons.com>
commit 809778e02cd45d0625439fee67688f655627bb3c upstream.
This patch fixes the hash support in the SafeXcel driver when the update
size is a multiple of a block size, and when a final call is made just
after with a size of 0. In such cases the driver should cache the last
block from the update to avoid handling 0 length data on the final call
(that's a hardware limitation).
Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver")
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: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/inside-secure/safexcel_hash.c | 34 +++++++++++++++++++--------
1 file changed, 24 insertions(+), 10 deletions(-)
--- a/drivers/crypto/inside-secure/safexcel_hash.c
+++ b/drivers/crypto/inside-secure/safexcel_hash.c
@@ -185,17 +185,31 @@ static int safexcel_ahash_send(struct cr
else
cache_len = queued - areq->nbytes;
- /*
- * If this is not the last request and the queued data does not fit
- * into full blocks, cache it for the next send() call.
- */
- extra = queued & (crypto_ahash_blocksize(ahash) - 1);
- if (!req->last_req && extra) {
- sg_pcopy_to_buffer(areq->src, sg_nents(areq->src),
- req->cache_next, extra, areq->nbytes - extra);
+ if (!req->last_req) {
+ /* If this is not the last request and the queued data does not
+ * fit into full blocks, cache it for the next send() call.
+ */
+ extra = queued & (crypto_ahash_blocksize(ahash) - 1);
+ if (!extra)
+ /* If this is not the last request and the queued data
+ * is a multiple of a block, cache the last one for now.
+ */
+ extra = queued - crypto_ahash_blocksize(ahash);
- queued -= extra;
- len -= extra;
+ if (extra) {
+ sg_pcopy_to_buffer(areq->src, sg_nents(areq->src),
+ req->cache_next, extra,
+ areq->nbytes - extra);
+
+ queued -= extra;
+ len -= extra;
+
+ if (!queued) {
+ *commands = 0;
+ *results = 0;
+ return 0;
+ }
+ }
}
spin_lock_bh(&priv->ring[ring].egress_lock);
Patches currently in stable-queue which might be from antoine.tenart(a)free-electrons.com are
queue-4.14/crypto-inside-secure-avoid-unmapping-dma-memory-that-was-not-mapped.patch
queue-4.14/crypto-inside-secure-fix-hash-when-length-is-a-multiple-of-a-block.patch
This is a note to let you know that I've just added the patch titled
crypto: inside-secure - avoid unmapping DMA memory that was not mapped
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-avoid-unmapping-dma-memory-that-was-not-mapped.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 c957f8b3e2e54b29f53ef69decc87bbc858c9b58 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20T=C3=A9nart?= <antoine.tenart(a)free-electrons.com>
Date: Tue, 26 Dec 2017 17:21:16 +0100
Subject: crypto: inside-secure - avoid unmapping DMA memory that was not mapped
From: Antoine Tenart <antoine.tenart(a)free-electrons.com>
commit c957f8b3e2e54b29f53ef69decc87bbc858c9b58 upstream.
This patch adds a parameter in the SafeXcel ahash request structure to
keep track of the number of SG entries mapped. This allows not to call
dma_unmap_sg() when dma_map_sg() wasn't called in the first place. This
also removes a warning when the debugging of the DMA-API is enabled in
the kernel configuration: "DMA-API: device driver tries to free DMA
memory it has not allocated".
Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver")
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: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/inside-secure/safexcel_hash.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
--- a/drivers/crypto/inside-secure/safexcel_hash.c
+++ b/drivers/crypto/inside-secure/safexcel_hash.c
@@ -33,6 +33,8 @@ struct safexcel_ahash_req {
bool finish;
bool hmac;
+ int nents;
+
u8 state_sz; /* expected sate size, only set once */
u32 state[SHA256_DIGEST_SIZE / sizeof(u32)];
@@ -151,8 +153,10 @@ static int safexcel_handle_result(struct
result_sz = crypto_ahash_digestsize(ahash);
memcpy(sreq->state, areq->result, result_sz);
- dma_unmap_sg(priv->dev, areq->src,
- sg_nents_for_len(areq->src, areq->nbytes), DMA_TO_DEVICE);
+ if (sreq->nents) {
+ dma_unmap_sg(priv->dev, areq->src, sreq->nents, DMA_TO_DEVICE);
+ sreq->nents = 0;
+ }
safexcel_free_context(priv, async, sreq->state_sz);
@@ -177,7 +181,7 @@ static int safexcel_ahash_send(struct cr
struct safexcel_command_desc *cdesc, *first_cdesc = NULL;
struct safexcel_result_desc *rdesc;
struct scatterlist *sg;
- int i, nents, queued, len, cache_len, extra, n_cdesc = 0, ret = 0;
+ int i, queued, len, cache_len, extra, n_cdesc = 0, ret = 0;
queued = len = req->len - req->processed;
if (queued < crypto_ahash_blocksize(ahash))
@@ -247,15 +251,15 @@ static int safexcel_ahash_send(struct cr
}
/* Now handle the current ahash request buffer(s) */
- nents = dma_map_sg(priv->dev, areq->src,
- sg_nents_for_len(areq->src, areq->nbytes),
- DMA_TO_DEVICE);
- if (!nents) {
+ req->nents = dma_map_sg(priv->dev, areq->src,
+ sg_nents_for_len(areq->src, areq->nbytes),
+ DMA_TO_DEVICE);
+ if (!req->nents) {
ret = -ENOMEM;
goto cdesc_rollback;
}
- for_each_sg(areq->src, sg, nents, i) {
+ for_each_sg(areq->src, sg, req->nents, i) {
int sglen = sg_dma_len(sg);
/* Do not overflow the request */
Patches currently in stable-queue which might be from antoine.tenart(a)free-electrons.com are
queue-4.14/crypto-inside-secure-avoid-unmapping-dma-memory-that-was-not-mapped.patch
queue-4.14/crypto-inside-secure-fix-hash-when-length-is-a-multiple-of-a-block.patch
This is a note to let you know that I've just added the patch titled
crypto: gcm - add GCM IV size constant
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-gcm-add-gcm-iv-size-constant.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 ef780324592dd639e4bfbc5b9bf8934b234b7c99 Mon Sep 17 00:00:00 2001
From: Corentin LABBE <clabbe.montjoie(a)gmail.com>
Date: Tue, 22 Aug 2017 10:08:08 +0200
Subject: crypto: gcm - add GCM IV size constant
From: Corentin LABBE <clabbe.montjoie(a)gmail.com>
commit ef780324592dd639e4bfbc5b9bf8934b234b7c99 upstream.
Many GCM users use directly GCM IV size instead of using some constant.
This patch add all IV size constant used by GCM.
Signed-off-by: Corentin Labbe <clabbe.montjoie(a)gmail.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/crypto/gcm.h | 8 ++++++++
1 file changed, 8 insertions(+)
--- /dev/null
+++ b/include/crypto/gcm.h
@@ -0,0 +1,8 @@
+#ifndef _CRYPTO_GCM_H
+#define _CRYPTO_GCM_H
+
+#define GCM_AES_IV_SIZE 12
+#define GCM_RFC4106_IV_SIZE 8
+#define GCM_RFC4543_IV_SIZE 8
+
+#endif
Patches currently in stable-queue which might be from clabbe.montjoie(a)gmail.com are
queue-4.14/crypto-gcm-add-gcm-iv-size-constant.patch
queue-4.14/crypto-aesni-use-gcm-iv-size-constant.patch
This is a note to let you know that I've just added the patch titled
crypto: af_alg - whitelist mask and type
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-af_alg-whitelist-mask-and-type.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 bb30b8848c85e18ca7e371d0a869e94b3e383bdf Mon Sep 17 00:00:00 2001
From: Stephan Mueller <smueller(a)chronox.de>
Date: Tue, 2 Jan 2018 08:55:25 +0100
Subject: crypto: af_alg - whitelist mask and type
From: Stephan Mueller <smueller(a)chronox.de>
commit bb30b8848c85e18ca7e371d0a869e94b3e383bdf upstream.
The user space interface allows specifying the type and mask field used
to allocate the cipher. Only a subset of the possible flags are intended
for user space. Therefore, white-list the allowed flags.
In case the user space caller uses at least one non-allowed flag, EINVAL
is returned.
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Stephan Mueller <smueller(a)chronox.de>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/af_alg.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -150,7 +150,7 @@ EXPORT_SYMBOL_GPL(af_alg_release_parent)
static int alg_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
{
- const u32 forbidden = CRYPTO_ALG_INTERNAL;
+ const u32 allowed = CRYPTO_ALG_KERN_DRIVER_ONLY;
struct sock *sk = sock->sk;
struct alg_sock *ask = alg_sk(sk);
struct sockaddr_alg *sa = (void *)uaddr;
@@ -158,6 +158,10 @@ static int alg_bind(struct socket *sock,
void *private;
int err;
+ /* If caller uses non-allowed flag, return error. */
+ if ((sa->salg_feat & ~allowed) || (sa->salg_mask & ~allowed))
+ return -EINVAL;
+
if (sock->state == SS_CONNECTED)
return -EINVAL;
@@ -176,9 +180,7 @@ static int alg_bind(struct socket *sock,
if (IS_ERR(type))
return PTR_ERR(type);
- private = type->bind(sa->salg_name,
- sa->salg_feat & ~forbidden,
- sa->salg_mask & ~forbidden);
+ private = type->bind(sa->salg_name, sa->salg_feat, sa->salg_mask);
if (IS_ERR(private)) {
module_put(type->owner);
return PTR_ERR(private);
Patches currently in stable-queue which might be from smueller(a)chronox.de are
queue-4.14/crypto-af_alg-whitelist-mask-and-type.patch
queue-4.14/crypto-aesni-handle-zero-length-dst-buffer.patch
This is a note to let you know that I've just added the patch titled
crypto: ecdh - fix typo in KPP dependency of CRYPTO_ECDH
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-ecdh-fix-typo-in-kpp-dependency-of-crypto_ecdh.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 b5b9007730ce1d90deaf25d7f678511550744bdc Mon Sep 17 00:00:00 2001
From: Hauke Mehrtens <hauke(a)hauke-m.de>
Date: Sun, 26 Nov 2017 00:16:46 +0100
Subject: crypto: ecdh - fix typo in KPP dependency of CRYPTO_ECDH
From: Hauke Mehrtens <hauke(a)hauke-m.de>
commit b5b9007730ce1d90deaf25d7f678511550744bdc upstream.
This fixes a typo in the CRYPTO_KPP dependency of CRYPTO_ECDH.
Fixes: 3c4b23901a0c ("crypto: ecdh - Add ECDH software support")
Signed-off-by: Hauke Mehrtens <hauke(a)hauke-m.de>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -130,7 +130,7 @@ config CRYPTO_DH
config CRYPTO_ECDH
tristate "ECDH algorithm"
- select CRYTPO_KPP
+ select CRYPTO_KPP
select CRYPTO_RNG_DEFAULT
help
Generic implementation of the ECDH algorithm
Patches currently in stable-queue which might be from hauke(a)hauke-m.de are
queue-4.14/crypto-ecdh-fix-typo-in-kpp-dependency-of-crypto_ecdh.patch
This is a note to let you know that I've just added the patch titled
crypto: aesni - handle zero length dst buffer
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-aesni-handle-zero-length-dst-buffer.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 9c674e1e2f9e24fa4392167efe343749008338e0 Mon Sep 17 00:00:00 2001
From: Stephan Mueller <smueller(a)chronox.de>
Date: Thu, 18 Jan 2018 20:41:09 +0100
Subject: crypto: aesni - handle zero length dst buffer
From: Stephan Mueller <smueller(a)chronox.de>
commit 9c674e1e2f9e24fa4392167efe343749008338e0 upstream.
GCM can be invoked with a zero destination buffer. This is possible if
the AAD and the ciphertext have zero lengths and only the tag exists in
the source buffer (i.e. a source buffer cannot be zero). In this case,
the GCM cipher only performs the authentication and no decryption
operation.
When the destination buffer has zero length, it is possible that no page
is mapped to the SG pointing to the destination. In this case,
sg_page(req->dst) is an invalid access. Therefore, page accesses should
only be allowed if the req->dst->length is non-zero which is the
indicator that a page must exist.
This fixes a crash that can be triggered by user space via AF_ALG.
Signed-off-by: Stephan Mueller <smueller(a)chronox.de>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/aesni-intel_glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -823,7 +823,7 @@ static int gcmaes_decrypt(struct aead_re
if (sg_is_last(req->src) &&
(!PageHighMem(sg_page(req->src)) ||
req->src->offset + req->src->length <= PAGE_SIZE) &&
- sg_is_last(req->dst) &&
+ sg_is_last(req->dst) && req->dst->length &&
(!PageHighMem(sg_page(req->dst)) ||
req->dst->offset + req->dst->length <= PAGE_SIZE)) {
one_entry_in_sg = 1;
Patches currently in stable-queue which might be from smueller(a)chronox.de are
queue-4.14/crypto-af_alg-whitelist-mask-and-type.patch
queue-4.14/crypto-aesni-handle-zero-length-dst-buffer.patch
This is a note to let you know that I've just added the patch titled
crypto: aesni - Use GCM IV size constant
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-aesni-use-gcm-iv-size-constant.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 46d93748e5a3628f9f553832cd64d8a59d8bafde Mon Sep 17 00:00:00 2001
From: Corentin LABBE <clabbe.montjoie(a)gmail.com>
Date: Tue, 22 Aug 2017 10:08:18 +0200
Subject: crypto: aesni - Use GCM IV size constant
From: Corentin LABBE <clabbe.montjoie(a)gmail.com>
commit 46d93748e5a3628f9f553832cd64d8a59d8bafde upstream.
This patch replace GCM IV size value by their constant name.
Signed-off-by: Corentin Labbe <clabbe.montjoie(a)gmail.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/aesni-intel_glue.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -28,6 +28,7 @@
#include <crypto/cryptd.h>
#include <crypto/ctr.h>
#include <crypto/b128ops.h>
+#include <crypto/gcm.h>
#include <crypto/xts.h>
#include <asm/cpu_device_id.h>
#include <asm/fpu/api.h>
@@ -1131,7 +1132,7 @@ static struct aead_alg aesni_aead_algs[]
.setauthsize = common_rfc4106_set_authsize,
.encrypt = helper_rfc4106_encrypt,
.decrypt = helper_rfc4106_decrypt,
- .ivsize = 8,
+ .ivsize = GCM_RFC4106_IV_SIZE,
.maxauthsize = 16,
.base = {
.cra_name = "__gcm-aes-aesni",
@@ -1149,7 +1150,7 @@ static struct aead_alg aesni_aead_algs[]
.setauthsize = rfc4106_set_authsize,
.encrypt = rfc4106_encrypt,
.decrypt = rfc4106_decrypt,
- .ivsize = 8,
+ .ivsize = GCM_RFC4106_IV_SIZE,
.maxauthsize = 16,
.base = {
.cra_name = "rfc4106(gcm(aes))",
@@ -1165,7 +1166,7 @@ static struct aead_alg aesni_aead_algs[]
.setauthsize = generic_gcmaes_set_authsize,
.encrypt = generic_gcmaes_encrypt,
.decrypt = generic_gcmaes_decrypt,
- .ivsize = 12,
+ .ivsize = GCM_AES_IV_SIZE,
.maxauthsize = 16,
.base = {
.cra_name = "gcm(aes)",
Patches currently in stable-queue which might be from clabbe.montjoie(a)gmail.com are
queue-4.14/crypto-gcm-add-gcm-iv-size-constant.patch
queue-4.14/crypto-aesni-use-gcm-iv-size-constant.patch
This is a note to let you know that I've just added the patch titled
crypto: aesni - fix typo in generic_gcmaes_decrypt
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-aesni-fix-typo-in-generic_gcmaes_decrypt.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 106840c41096a01079d3a2025225029c13713802 Mon Sep 17 00:00:00 2001
From: Sabrina Dubroca <sd(a)queasysnail.net>
Date: Wed, 13 Dec 2017 14:53:43 +0100
Subject: crypto: aesni - fix typo in generic_gcmaes_decrypt
From: Sabrina Dubroca <sd(a)queasysnail.net>
commit 106840c41096a01079d3a2025225029c13713802 upstream.
generic_gcmaes_decrypt needs to use generic_gcmaes_ctx, not
aesni_rfc4106_gcm_ctx. This is actually harmless because the fields in
struct generic_gcmaes_ctx share the layout of the same fields in
aesni_rfc4106_gcm_ctx.
Fixes: cce2ea8d90fe ("crypto: aesni - add generic gcm(aes)")
Signed-off-by: Sabrina Dubroca <sd(a)queasysnail.net>
Reviewed-by: Stefano Brivio <sbrivio(a)redhat.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/aesni-intel_glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -1115,7 +1115,7 @@ static int generic_gcmaes_decrypt(struct
{
__be32 counter = cpu_to_be32(1);
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
- struct aesni_rfc4106_gcm_ctx *ctx = aesni_rfc4106_gcm_ctx_get(tfm);
+ struct generic_gcmaes_ctx *ctx = generic_gcmaes_ctx_get(tfm);
void *aes_ctx = &(ctx->aes_key_expanded);
u8 iv[16] __attribute__ ((__aligned__(AESNI_ALIGN)));
Patches currently in stable-queue which might be from sd(a)queasysnail.net are
queue-4.14/crypto-aesni-add-wrapper-for-generic-gcm-aes.patch
queue-4.14/crypto-aesni-fix-typo-in-generic_gcmaes_decrypt.patch
This is a note to let you know that I've just added the patch titled
crypto: aesni - Fix out-of-bounds access of the data buffer in generic-gcm-aesni
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-aesni-fix-out-of-bounds-access-of-the-data-buffer-in-generic-gcm-aesni.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 b20209c91e23a9bbad9cac2f80bc16b3c259e10e Mon Sep 17 00:00:00 2001
From: Junaid Shahid <junaids(a)google.com>
Date: Wed, 20 Dec 2017 17:08:37 -0800
Subject: crypto: aesni - Fix out-of-bounds access of the data buffer in generic-gcm-aesni
From: Junaid Shahid <junaids(a)google.com>
commit b20209c91e23a9bbad9cac2f80bc16b3c259e10e upstream.
The aesni_gcm_enc/dec functions can access memory before the start of
the data buffer if the length of the data buffer is less than 16 bytes.
This is because they perform the read via a single 16-byte load. This
can potentially result in accessing a page that is not mapped and thus
causing the machine to crash. This patch fixes that by reading the
partial block byte-by-byte and optionally an via 8-byte load if the block
was at least 8 bytes.
Fixes: 0487ccac ("crypto: aesni - make non-AVX AES-GCM work with any aadlen")
Signed-off-by: Junaid Shahid <junaids(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/aesni-intel_asm.S | 87 +++++++++++++++++++-------------------
1 file changed, 45 insertions(+), 42 deletions(-)
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -257,6 +257,37 @@ aad_shift_arr:
pxor \TMP1, \GH # result is in TMP1
.endm
+# Reads DLEN bytes starting at DPTR and stores in XMMDst
+# where 0 < DLEN < 16
+# Clobbers %rax, DLEN and XMM1
+.macro READ_PARTIAL_BLOCK DPTR DLEN XMM1 XMMDst
+ cmp $8, \DLEN
+ jl _read_lt8_\@
+ mov (\DPTR), %rax
+ MOVQ_R64_XMM %rax, \XMMDst
+ sub $8, \DLEN
+ jz _done_read_partial_block_\@
+ xor %eax, %eax
+_read_next_byte_\@:
+ shl $8, %rax
+ mov 7(\DPTR, \DLEN, 1), %al
+ dec \DLEN
+ jnz _read_next_byte_\@
+ MOVQ_R64_XMM %rax, \XMM1
+ pslldq $8, \XMM1
+ por \XMM1, \XMMDst
+ jmp _done_read_partial_block_\@
+_read_lt8_\@:
+ xor %eax, %eax
+_read_next_byte_lt8_\@:
+ shl $8, %rax
+ mov -1(\DPTR, \DLEN, 1), %al
+ dec \DLEN
+ jnz _read_next_byte_lt8_\@
+ MOVQ_R64_XMM %rax, \XMMDst
+_done_read_partial_block_\@:
+.endm
+
/*
* if a = number of total plaintext bytes
* b = floor(a/16)
@@ -1386,14 +1417,6 @@ _esb_loop_\@:
*
* AAD Format with 64-bit Extended Sequence Number
*
-* aadLen:
-* from the definition of the spec, aadLen can only be 8 or 12 bytes.
-* The code supports 16 too but for other sizes, the code will fail.
-*
-* TLen:
-* from the definition of the spec, TLen can only be 8, 12 or 16 bytes.
-* For other sizes, the code will fail.
-*
* poly = x^128 + x^127 + x^126 + x^121 + 1
*
*****************************************************************************/
@@ -1487,19 +1510,16 @@ _zero_cipher_left_decrypt:
PSHUFB_XMM %xmm10, %xmm0
ENCRYPT_SINGLE_BLOCK %xmm0, %xmm1 # E(K, Yn)
- sub $16, %r11
- add %r13, %r11
- movdqu (%arg3,%r11,1), %xmm1 # receive the last <16 byte block
- lea SHIFT_MASK+16(%rip), %r12
- sub %r13, %r12
-# adjust the shuffle mask pointer to be able to shift 16-%r13 bytes
-# (%r13 is the number of bytes in plaintext mod 16)
- movdqu (%r12), %xmm2 # get the appropriate shuffle mask
- PSHUFB_XMM %xmm2, %xmm1 # right shift 16-%r13 butes
+ lea (%arg3,%r11,1), %r10
+ mov %r13, %r12
+ READ_PARTIAL_BLOCK %r10 %r12 %xmm2 %xmm1
+
+ lea ALL_F+16(%rip), %r12
+ sub %r13, %r12
movdqa %xmm1, %xmm2
pxor %xmm1, %xmm0 # Ciphertext XOR E(K, Yn)
- movdqu ALL_F-SHIFT_MASK(%r12), %xmm1
+ movdqu (%r12), %xmm1
# get the appropriate mask to mask out top 16-%r13 bytes of %xmm0
pand %xmm1, %xmm0 # mask out top 16-%r13 bytes of %xmm0
pand %xmm1, %xmm2
@@ -1508,9 +1528,6 @@ _zero_cipher_left_decrypt:
pxor %xmm2, %xmm8
GHASH_MUL %xmm8, %xmm13, %xmm9, %xmm10, %xmm11, %xmm5, %xmm6
- # GHASH computation for the last <16 byte block
- sub %r13, %r11
- add $16, %r11
# output %r13 bytes
MOVQ_R64_XMM %xmm0, %rax
@@ -1664,14 +1681,6 @@ ENDPROC(aesni_gcm_dec)
*
* AAD Format with 64-bit Extended Sequence Number
*
-* aadLen:
-* from the definition of the spec, aadLen can only be 8 or 12 bytes.
-* The code supports 16 too but for other sizes, the code will fail.
-*
-* TLen:
-* from the definition of the spec, TLen can only be 8, 12 or 16 bytes.
-* For other sizes, the code will fail.
-*
* poly = x^128 + x^127 + x^126 + x^121 + 1
***************************************************************************/
ENTRY(aesni_gcm_enc)
@@ -1764,19 +1773,16 @@ _zero_cipher_left_encrypt:
movdqa SHUF_MASK(%rip), %xmm10
PSHUFB_XMM %xmm10, %xmm0
-
ENCRYPT_SINGLE_BLOCK %xmm0, %xmm1 # Encrypt(K, Yn)
- sub $16, %r11
- add %r13, %r11
- movdqu (%arg3,%r11,1), %xmm1 # receive the last <16 byte blocks
- lea SHIFT_MASK+16(%rip), %r12
+
+ lea (%arg3,%r11,1), %r10
+ mov %r13, %r12
+ READ_PARTIAL_BLOCK %r10 %r12 %xmm2 %xmm1
+
+ lea ALL_F+16(%rip), %r12
sub %r13, %r12
- # adjust the shuffle mask pointer to be able to shift 16-r13 bytes
- # (%r13 is the number of bytes in plaintext mod 16)
- movdqu (%r12), %xmm2 # get the appropriate shuffle mask
- PSHUFB_XMM %xmm2, %xmm1 # shift right 16-r13 byte
pxor %xmm1, %xmm0 # Plaintext XOR Encrypt(K, Yn)
- movdqu ALL_F-SHIFT_MASK(%r12), %xmm1
+ movdqu (%r12), %xmm1
# get the appropriate mask to mask out top 16-r13 bytes of xmm0
pand %xmm1, %xmm0 # mask out top 16-r13 bytes of xmm0
movdqa SHUF_MASK(%rip), %xmm10
@@ -1785,9 +1791,6 @@ _zero_cipher_left_encrypt:
pxor %xmm0, %xmm8
GHASH_MUL %xmm8, %xmm13, %xmm9, %xmm10, %xmm11, %xmm5, %xmm6
# GHASH computation for the last <16 byte block
- sub %r13, %r11
- add $16, %r11
-
movdqa SHUF_MASK(%rip), %xmm10
PSHUFB_XMM %xmm10, %xmm0
Patches currently in stable-queue which might be from junaids(a)google.com are
queue-4.14/crypto-aesni-fix-out-of-bounds-access-of-the-data-buffer-in-generic-gcm-aesni.patch
queue-4.14/crypto-aesni-fix-out-of-bounds-access-of-the-aad-buffer-in-generic-gcm-aesni.patch
This is a note to let you know that I've just added the patch titled
crypto: aesni - Fix out-of-bounds access of the AAD buffer in generic-gcm-aesni
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-aesni-fix-out-of-bounds-access-of-the-aad-buffer-in-generic-gcm-aesni.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 1ecdd37e308ca149dc378cce225068cbac54e3a6 Mon Sep 17 00:00:00 2001
From: Junaid Shahid <junaids(a)google.com>
Date: Wed, 20 Dec 2017 17:08:38 -0800
Subject: crypto: aesni - Fix out-of-bounds access of the AAD buffer in generic-gcm-aesni
From: Junaid Shahid <junaids(a)google.com>
commit 1ecdd37e308ca149dc378cce225068cbac54e3a6 upstream.
The aesni_gcm_enc/dec functions can access memory after the end of
the AAD buffer if the AAD length is not a multiple of 4 bytes.
It didn't matter with rfc4106-gcm-aesni as in that case the AAD was
always followed by the 8 byte IV, but that is no longer the case with
generic-gcm-aesni. This can potentially result in accessing a page that
is not mapped and thus causing the machine to crash. This patch fixes
that by reading the last <16 byte block of the AAD byte-by-byte and
optionally via an 8-byte load if the block was at least 8 bytes.
Fixes: 0487ccac ("crypto: aesni - make non-AVX AES-GCM work with any aadlen")
Signed-off-by: Junaid Shahid <junaids(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/aesni-intel_asm.S | 112 ++++----------------------------------
1 file changed, 12 insertions(+), 100 deletions(-)
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -90,30 +90,6 @@ SHIFT_MASK: .octa 0x0f0e0d0c0b0a09080706
ALL_F: .octa 0xffffffffffffffffffffffffffffffff
.octa 0x00000000000000000000000000000000
-.section .rodata
-.align 16
-.type aad_shift_arr, @object
-.size aad_shift_arr, 272
-aad_shift_arr:
- .octa 0xffffffffffffffffffffffffffffffff
- .octa 0xffffffffffffffffffffffffffffff0C
- .octa 0xffffffffffffffffffffffffffff0D0C
- .octa 0xffffffffffffffffffffffffff0E0D0C
- .octa 0xffffffffffffffffffffffff0F0E0D0C
- .octa 0xffffffffffffffffffffff0C0B0A0908
- .octa 0xffffffffffffffffffff0D0C0B0A0908
- .octa 0xffffffffffffffffff0E0D0C0B0A0908
- .octa 0xffffffffffffffff0F0E0D0C0B0A0908
- .octa 0xffffffffffffff0C0B0A090807060504
- .octa 0xffffffffffff0D0C0B0A090807060504
- .octa 0xffffffffff0E0D0C0B0A090807060504
- .octa 0xffffffff0F0E0D0C0B0A090807060504
- .octa 0xffffff0C0B0A09080706050403020100
- .octa 0xffff0D0C0B0A09080706050403020100
- .octa 0xff0E0D0C0B0A09080706050403020100
- .octa 0x0F0E0D0C0B0A09080706050403020100
-
-
.text
@@ -304,62 +280,30 @@ _done_read_partial_block_\@:
XMM2 XMM3 XMM4 XMMDst TMP6 TMP7 i i_seq operation
MOVADQ SHUF_MASK(%rip), %xmm14
mov arg7, %r10 # %r10 = AAD
- mov arg8, %r12 # %r12 = aadLen
- mov %r12, %r11
+ mov arg8, %r11 # %r11 = aadLen
pxor %xmm\i, %xmm\i
pxor \XMM2, \XMM2
cmp $16, %r11
- jl _get_AAD_rest8\num_initial_blocks\operation
+ jl _get_AAD_rest\num_initial_blocks\operation
_get_AAD_blocks\num_initial_blocks\operation:
movdqu (%r10), %xmm\i
PSHUFB_XMM %xmm14, %xmm\i # byte-reflect the AAD data
pxor %xmm\i, \XMM2
GHASH_MUL \XMM2, \TMP3, \TMP1, \TMP2, \TMP4, \TMP5, \XMM1
add $16, %r10
- sub $16, %r12
sub $16, %r11
cmp $16, %r11
jge _get_AAD_blocks\num_initial_blocks\operation
movdqu \XMM2, %xmm\i
+
+ /* read the last <16B of AAD */
+_get_AAD_rest\num_initial_blocks\operation:
cmp $0, %r11
je _get_AAD_done\num_initial_blocks\operation
- pxor %xmm\i,%xmm\i
-
- /* read the last <16B of AAD. since we have at least 4B of
- data right after the AAD (the ICV, and maybe some CT), we can
- read 4B/8B blocks safely, and then get rid of the extra stuff */
-_get_AAD_rest8\num_initial_blocks\operation:
- cmp $4, %r11
- jle _get_AAD_rest4\num_initial_blocks\operation
- movq (%r10), \TMP1
- add $8, %r10
- sub $8, %r11
- pslldq $8, \TMP1
- psrldq $8, %xmm\i
- pxor \TMP1, %xmm\i
- jmp _get_AAD_rest8\num_initial_blocks\operation
-_get_AAD_rest4\num_initial_blocks\operation:
- cmp $0, %r11
- jle _get_AAD_rest0\num_initial_blocks\operation
- mov (%r10), %eax
- movq %rax, \TMP1
- add $4, %r10
- sub $4, %r10
- pslldq $12, \TMP1
- psrldq $4, %xmm\i
- pxor \TMP1, %xmm\i
-_get_AAD_rest0\num_initial_blocks\operation:
- /* finalize: shift out the extra bytes we read, and align
- left. since pslldq can only shift by an immediate, we use
- vpshufb and an array of shuffle masks */
- movq %r12, %r11
- salq $4, %r11
- movdqu aad_shift_arr(%r11), \TMP1
- PSHUFB_XMM \TMP1, %xmm\i
-_get_AAD_rest_final\num_initial_blocks\operation:
+ READ_PARTIAL_BLOCK %r10, %r11, \TMP1, %xmm\i
PSHUFB_XMM %xmm14, %xmm\i # byte-reflect the AAD data
pxor \XMM2, %xmm\i
GHASH_MUL %xmm\i, \TMP3, \TMP1, \TMP2, \TMP4, \TMP5, \XMM1
@@ -563,62 +507,30 @@ _initial_blocks_done\num_initial_blocks\
XMM2 XMM3 XMM4 XMMDst TMP6 TMP7 i i_seq operation
MOVADQ SHUF_MASK(%rip), %xmm14
mov arg7, %r10 # %r10 = AAD
- mov arg8, %r12 # %r12 = aadLen
- mov %r12, %r11
+ mov arg8, %r11 # %r11 = aadLen
pxor %xmm\i, %xmm\i
pxor \XMM2, \XMM2
cmp $16, %r11
- jl _get_AAD_rest8\num_initial_blocks\operation
+ jl _get_AAD_rest\num_initial_blocks\operation
_get_AAD_blocks\num_initial_blocks\operation:
movdqu (%r10), %xmm\i
PSHUFB_XMM %xmm14, %xmm\i # byte-reflect the AAD data
pxor %xmm\i, \XMM2
GHASH_MUL \XMM2, \TMP3, \TMP1, \TMP2, \TMP4, \TMP5, \XMM1
add $16, %r10
- sub $16, %r12
sub $16, %r11
cmp $16, %r11
jge _get_AAD_blocks\num_initial_blocks\operation
movdqu \XMM2, %xmm\i
+
+ /* read the last <16B of AAD */
+_get_AAD_rest\num_initial_blocks\operation:
cmp $0, %r11
je _get_AAD_done\num_initial_blocks\operation
- pxor %xmm\i,%xmm\i
-
- /* read the last <16B of AAD. since we have at least 4B of
- data right after the AAD (the ICV, and maybe some PT), we can
- read 4B/8B blocks safely, and then get rid of the extra stuff */
-_get_AAD_rest8\num_initial_blocks\operation:
- cmp $4, %r11
- jle _get_AAD_rest4\num_initial_blocks\operation
- movq (%r10), \TMP1
- add $8, %r10
- sub $8, %r11
- pslldq $8, \TMP1
- psrldq $8, %xmm\i
- pxor \TMP1, %xmm\i
- jmp _get_AAD_rest8\num_initial_blocks\operation
-_get_AAD_rest4\num_initial_blocks\operation:
- cmp $0, %r11
- jle _get_AAD_rest0\num_initial_blocks\operation
- mov (%r10), %eax
- movq %rax, \TMP1
- add $4, %r10
- sub $4, %r10
- pslldq $12, \TMP1
- psrldq $4, %xmm\i
- pxor \TMP1, %xmm\i
-_get_AAD_rest0\num_initial_blocks\operation:
- /* finalize: shift out the extra bytes we read, and align
- left. since pslldq can only shift by an immediate, we use
- vpshufb and an array of shuffle masks */
- movq %r12, %r11
- salq $4, %r11
- movdqu aad_shift_arr(%r11), \TMP1
- PSHUFB_XMM \TMP1, %xmm\i
-_get_AAD_rest_final\num_initial_blocks\operation:
+ READ_PARTIAL_BLOCK %r10, %r11, \TMP1, %xmm\i
PSHUFB_XMM %xmm14, %xmm\i # byte-reflect the AAD data
pxor \XMM2, %xmm\i
GHASH_MUL %xmm\i, \TMP3, \TMP1, \TMP2, \TMP4, \TMP5, \XMM1
Patches currently in stable-queue which might be from junaids(a)google.com are
queue-4.14/crypto-aesni-fix-out-of-bounds-access-of-the-data-buffer-in-generic-gcm-aesni.patch
queue-4.14/crypto-aesni-fix-out-of-bounds-access-of-the-aad-buffer-in-generic-gcm-aesni.patch
This is a note to let you know that I've just added the patch titled
ALSA: hda - Reduce the suspend time consumption for ALC256
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:
alsa-hda-reduce-the-suspend-time-consumption-for-alc256.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 1c9609e3a8cf5997bd35205cfda1ff2218ee793b Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Fri, 19 Jan 2018 14:18:34 +0100
Subject: ALSA: hda - Reduce the suspend time consumption for ALC256
From: Takashi Iwai <tiwai(a)suse.de>
commit 1c9609e3a8cf5997bd35205cfda1ff2218ee793b upstream.
ALC256 has its own quirk to override the shutup call, and it contains
the COEF update for pulling down the headset jack control. Currently,
the COEF update is called after clearing the headphone pin, and this
seems triggering a stall of the codec communication, and results in a
long delay over a second at suspend.
A quick resolution is to swap the calls: at first with the COEF
update, then clear the headphone pin.
Fixes: 4a219ef8f370 ("ALSA: hda/realtek - Add ALC256 HP depop function")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198503
Reported-by: Paul Menzel <pmenzel(a)molgen.mpg.de>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -3131,11 +3131,13 @@ static void alc256_shutup(struct hda_cod
if (hp_pin_sense)
msleep(85);
+ /* 3k pull low control for Headset jack. */
+ /* NOTE: call this before clearing the pin, otherwise codec stalls */
+ alc_update_coef_idx(codec, 0x46, 0, 3 << 12);
+
snd_hda_codec_write(codec, hp_pin, 0,
AC_VERB_SET_PIN_WIDGET_CONTROL, 0x0);
- alc_update_coef_idx(codec, 0x46, 0, 3 << 12); /* 3k pull low control for Headset jack. */
-
if (hp_pin_sense)
msleep(100);
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.14/alsa-hda-reduce-the-suspend-time-consumption-for-alc256.patch
This is a note to let you know that I've just added the patch titled
igb: Free IRQs when device is hotplugged
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:
igb-free-irqs-when-device-is-hotplugged.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 888f22931478a05bc81ceb7295c626e1292bf0ed Mon Sep 17 00:00:00 2001
From: Lyude Paul <lyude(a)redhat.com>
Date: Tue, 12 Dec 2017 14:31:30 -0500
Subject: igb: Free IRQs when device is hotplugged
From: Lyude Paul <lyude(a)redhat.com>
commit 888f22931478a05bc81ceb7295c626e1292bf0ed upstream.
Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon
hotplugging my kernel would immediately crash due to igb:
[ 680.825801] kernel BUG at drivers/pci/msi.c:352!
[ 680.828388] invalid opcode: 0000 [#1] SMP
[ 680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb]
[ 680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G O 4.15.0-rc3Lyude-Test+ #6
[ 680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver. 01.03 06/09/2017
[ 680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[ 680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0
[ 680.833271] RSP: 0018:ffffc9000030fbf0 EFLAGS: 00010286
[ 680.833761] RAX: ffff8803405f9c00 RBX: ffff88033e3d2e40 RCX: 000000000000002c
[ 680.834278] RDX: 0000000000000000 RSI: 00000000000000ac RDI: ffff880340be2178
[ 680.834832] RBP: 0000000000000000 R08: ffff880340be1ff0 R09: ffff8803405f9c00
[ 680.835342] R10: 0000000000000000 R11: 0000000000000040 R12: ffff88033d63a298
[ 680.835822] R13: ffff88033d63a000 R14: 0000000000000060 R15: ffff880341959000
[ 680.836332] FS: 0000000000000000(0000) GS:ffff88034f440000(0000) knlGS:0000000000000000
[ 680.836817] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 680.837360] CR2: 000055e64044afdf CR3: 0000000001c09002 CR4: 00000000003606e0
[ 680.837954] Call Trace:
[ 680.838853] pci_disable_msix+0xce/0xf0
[ 680.839616] igb_reset_interrupt_capability+0x5d/0x60 [igb]
[ 680.840278] igb_remove+0x9d/0x110 [igb]
[ 680.840764] pci_device_remove+0x36/0xb0
[ 680.841279] device_release_driver_internal+0x157/0x220
[ 680.841739] pci_stop_bus_device+0x7d/0xa0
[ 680.842255] pci_stop_bus_device+0x2b/0xa0
[ 680.842722] pci_stop_bus_device+0x3d/0xa0
[ 680.843189] pci_stop_and_remove_bus_device+0xe/0x20
[ 680.843627] trim_stale_devices+0xf3/0x140
[ 680.844086] trim_stale_devices+0x94/0x140
[ 680.844532] trim_stale_devices+0xa6/0x140
[ 680.845031] ? get_slot_status+0x90/0xc0
[ 680.845536] acpiphp_check_bridge.part.5+0xfe/0x140
[ 680.846021] acpiphp_hotplug_notify+0x175/0x200
[ 680.846581] ? free_bridge+0x100/0x100
[ 680.847113] acpi_device_hotplug+0x8a/0x490
[ 680.847535] acpi_hotplug_work_fn+0x1a/0x30
[ 680.848076] process_one_work+0x182/0x3a0
[ 680.848543] worker_thread+0x2e/0x380
[ 680.848963] ? process_one_work+0x3a0/0x3a0
[ 680.849373] kthread+0x111/0x130
[ 680.849776] ? kthread_create_worker_on_cpu+0x50/0x50
[ 680.850188] ret_from_fork+0x1f/0x30
[ 680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 <0f> 0b 49 8d b5 a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b
[ 680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: ffffc9000030fbf0
As it turns out, normally the freeing of IRQs that would fix this is called
inside of the scope of __igb_close(). However, since the device is
already gone by the point we try to unregister the netdevice from the
driver due to a hotplug we end up seeing that the netif isn't present
and thus, forget to free any of the device IRQs.
So: make sure that if we're in the process of dismantling the netdev, we
always allow __igb_close() to be called so that IRQs may be freed
normally. Additionally, only allow igb_close() to be called from
__igb_close() if it hasn't already been called for the given adapter.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Fixes: 9474933caf21 ("igb: close/suspend race in netif_device_detach")
Cc: Todd Fujinaka <todd.fujinaka(a)intel.com>
Cc: Stephen Hemminger <stephen(a)networkplumber.org>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3172,7 +3172,7 @@ static int __igb_close(struct net_device
static int igb_close(struct net_device *netdev)
{
- if (netif_device_present(netdev))
+ if (netif_device_present(netdev) || netdev->dismantle)
return __igb_close(netdev, false);
return 0;
}
Patches currently in stable-queue which might be from lyude(a)redhat.com are
queue-3.18/igb-free-irqs-when-device-is-hotplugged.patch
This is a note to let you know that I've just added the patch titled
gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
gpio-iop-add-missing-module_description-author-license.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 97b03136e1b637d7a9d2274c099e44ecf23f1103 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:54:52 -0800
Subject: gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 97b03136e1b637d7a9d2274c099e44ecf23f1103 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-iop.o
see include/linux/module.h for more information
This adds the license as "GPL", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-iop.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/gpio/gpio-iop.c
+++ b/drivers/gpio/gpio-iop.c
@@ -130,3 +130,7 @@ static int __init iop3xx_gpio_init(void)
return platform_driver_register(&iop3xx_gpio_driver);
}
arch_initcall(iop3xx_gpio_init);
+
+MODULE_DESCRIPTION("GPIO handling for Intel IOP3xx processors");
+MODULE_AUTHOR("Lennert Buytenhek <buytenh(a)wantstofly.org>");
+MODULE_LICENSE("GPL");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-3.18/gpio-iop-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
power: reset: zx-reboot: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
power-reset-zx-reboot-add-missing-module_description-author-license.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 348c7cf5fcbcb68838255759d4cb45d039af36d2 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:58:27 -0800
Subject: power: reset: zx-reboot: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 348c7cf5fcbcb68838255759d4cb45d039af36d2 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/power/reset/zx-reboot.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/power/reset/zx-reboot.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/power/reset/zx-reboot.c
+++ b/drivers/power/reset/zx-reboot.c
@@ -78,3 +78,7 @@ static struct platform_driver zx_reboot_
},
};
module_platform_driver(zx_reboot_driver);
+
+MODULE_DESCRIPTION("ZTE SoCs reset driver");
+MODULE_AUTHOR("Jun Nie <jun.nie(a)linaro.org>");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.4/gpio-iop-add-missing-module_description-author-license.patch
queue-4.4/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.4/gpio-ath79-add-missing-module_description-license.patch
queue-4.4/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: denali_pci: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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-denali_pci-add-missing-module_description-author-license.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 d822401d1c6898a4a4ee03977b78b8cec402e88a Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:57:13 -0800
Subject: mtd: nand: denali_pci: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit d822401d1c6898a4a4ee03977b78b8cec402e88a upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/mtd/nand/denali_pci.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Acked-by: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/denali_pci.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/mtd/nand/denali_pci.c
+++ b/drivers/mtd/nand/denali_pci.c
@@ -119,3 +119,7 @@ static struct pci_driver denali_pci_driv
};
module_pci_driver(denali_pci_driver);
+
+MODULE_DESCRIPTION("PCI driver for Denali NAND controller");
+MODULE_AUTHOR("Intel Corporation and its suppliers");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.4/gpio-iop-add-missing-module_description-author-license.patch
queue-4.4/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.4/gpio-ath79-add-missing-module_description-license.patch
queue-4.4/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
igb: Free IRQs when device is hotplugged
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:
igb-free-irqs-when-device-is-hotplugged.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 888f22931478a05bc81ceb7295c626e1292bf0ed Mon Sep 17 00:00:00 2001
From: Lyude Paul <lyude(a)redhat.com>
Date: Tue, 12 Dec 2017 14:31:30 -0500
Subject: igb: Free IRQs when device is hotplugged
From: Lyude Paul <lyude(a)redhat.com>
commit 888f22931478a05bc81ceb7295c626e1292bf0ed upstream.
Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon
hotplugging my kernel would immediately crash due to igb:
[ 680.825801] kernel BUG at drivers/pci/msi.c:352!
[ 680.828388] invalid opcode: 0000 [#1] SMP
[ 680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb]
[ 680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G O 4.15.0-rc3Lyude-Test+ #6
[ 680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver. 01.03 06/09/2017
[ 680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[ 680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0
[ 680.833271] RSP: 0018:ffffc9000030fbf0 EFLAGS: 00010286
[ 680.833761] RAX: ffff8803405f9c00 RBX: ffff88033e3d2e40 RCX: 000000000000002c
[ 680.834278] RDX: 0000000000000000 RSI: 00000000000000ac RDI: ffff880340be2178
[ 680.834832] RBP: 0000000000000000 R08: ffff880340be1ff0 R09: ffff8803405f9c00
[ 680.835342] R10: 0000000000000000 R11: 0000000000000040 R12: ffff88033d63a298
[ 680.835822] R13: ffff88033d63a000 R14: 0000000000000060 R15: ffff880341959000
[ 680.836332] FS: 0000000000000000(0000) GS:ffff88034f440000(0000) knlGS:0000000000000000
[ 680.836817] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 680.837360] CR2: 000055e64044afdf CR3: 0000000001c09002 CR4: 00000000003606e0
[ 680.837954] Call Trace:
[ 680.838853] pci_disable_msix+0xce/0xf0
[ 680.839616] igb_reset_interrupt_capability+0x5d/0x60 [igb]
[ 680.840278] igb_remove+0x9d/0x110 [igb]
[ 680.840764] pci_device_remove+0x36/0xb0
[ 680.841279] device_release_driver_internal+0x157/0x220
[ 680.841739] pci_stop_bus_device+0x7d/0xa0
[ 680.842255] pci_stop_bus_device+0x2b/0xa0
[ 680.842722] pci_stop_bus_device+0x3d/0xa0
[ 680.843189] pci_stop_and_remove_bus_device+0xe/0x20
[ 680.843627] trim_stale_devices+0xf3/0x140
[ 680.844086] trim_stale_devices+0x94/0x140
[ 680.844532] trim_stale_devices+0xa6/0x140
[ 680.845031] ? get_slot_status+0x90/0xc0
[ 680.845536] acpiphp_check_bridge.part.5+0xfe/0x140
[ 680.846021] acpiphp_hotplug_notify+0x175/0x200
[ 680.846581] ? free_bridge+0x100/0x100
[ 680.847113] acpi_device_hotplug+0x8a/0x490
[ 680.847535] acpi_hotplug_work_fn+0x1a/0x30
[ 680.848076] process_one_work+0x182/0x3a0
[ 680.848543] worker_thread+0x2e/0x380
[ 680.848963] ? process_one_work+0x3a0/0x3a0
[ 680.849373] kthread+0x111/0x130
[ 680.849776] ? kthread_create_worker_on_cpu+0x50/0x50
[ 680.850188] ret_from_fork+0x1f/0x30
[ 680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 <0f> 0b 49 8d b5 a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b
[ 680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: ffffc9000030fbf0
As it turns out, normally the freeing of IRQs that would fix this is called
inside of the scope of __igb_close(). However, since the device is
already gone by the point we try to unregister the netdevice from the
driver due to a hotplug we end up seeing that the netif isn't present
and thus, forget to free any of the device IRQs.
So: make sure that if we're in the process of dismantling the netdev, we
always allow __igb_close() to be called so that IRQs may be freed
normally. Additionally, only allow igb_close() to be called from
__igb_close() if it hasn't already been called for the given adapter.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Fixes: 9474933caf21 ("igb: close/suspend race in netif_device_detach")
Cc: Todd Fujinaka <todd.fujinaka(a)intel.com>
Cc: Stephen Hemminger <stephen(a)networkplumber.org>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3174,7 +3174,7 @@ static int __igb_close(struct net_device
static int igb_close(struct net_device *netdev)
{
- if (netif_device_present(netdev))
+ if (netif_device_present(netdev) || netdev->dismantle)
return __igb_close(netdev, false);
return 0;
}
Patches currently in stable-queue which might be from lyude(a)redhat.com are
queue-4.4/igb-free-irqs-when-device-is-hotplugged.patch
This is a note to let you know that I've just added the patch titled
gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
gpio-iop-add-missing-module_description-author-license.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 97b03136e1b637d7a9d2274c099e44ecf23f1103 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:54:52 -0800
Subject: gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 97b03136e1b637d7a9d2274c099e44ecf23f1103 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-iop.o
see include/linux/module.h for more information
This adds the license as "GPL", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-iop.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/gpio/gpio-iop.c
+++ b/drivers/gpio/gpio-iop.c
@@ -129,3 +129,7 @@ static int __init iop3xx_gpio_init(void)
return platform_driver_register(&iop3xx_gpio_driver);
}
arch_initcall(iop3xx_gpio_init);
+
+MODULE_DESCRIPTION("GPIO handling for Intel IOP3xx processors");
+MODULE_AUTHOR("Lennert Buytenhek <buytenh(a)wantstofly.org>");
+MODULE_LICENSE("GPL");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.4/gpio-iop-add-missing-module_description-author-license.patch
queue-4.4/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.4/gpio-ath79-add-missing-module_description-license.patch
queue-4.4/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
gpio: ath79: add missing MODULE_DESCRIPTION/LICENSE
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:
gpio-ath79-add-missing-module_description-license.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 539340f37e6d6ed4cd93e8e18c9b2e4eafd4b842 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:54:26 -0800
Subject: gpio: ath79: add missing MODULE_DESCRIPTION/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 539340f37e6d6ed4cd93e8e18c9b2e4eafd4b842 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-ath79.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION is also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Acked-by: Alban Bedel <albeu(a)free.fr>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-ath79.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpio/gpio-ath79.c
+++ b/drivers/gpio/gpio-ath79.c
@@ -203,3 +203,6 @@ static struct platform_driver ath79_gpio
};
module_platform_driver(ath79_gpio_driver);
+
+MODULE_DESCRIPTION("Atheros AR71XX/AR724X/AR913X GPIO API support");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.4/gpio-iop-add-missing-module_description-author-license.patch
queue-4.4/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.4/gpio-ath79-add-missing-module_description-license.patch
queue-4.4/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
crypto: aesni - handle zero length dst buffer
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:
crypto-aesni-handle-zero-length-dst-buffer.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 9c674e1e2f9e24fa4392167efe343749008338e0 Mon Sep 17 00:00:00 2001
From: Stephan Mueller <smueller(a)chronox.de>
Date: Thu, 18 Jan 2018 20:41:09 +0100
Subject: crypto: aesni - handle zero length dst buffer
From: Stephan Mueller <smueller(a)chronox.de>
commit 9c674e1e2f9e24fa4392167efe343749008338e0 upstream.
GCM can be invoked with a zero destination buffer. This is possible if
the AAD and the ciphertext have zero lengths and only the tag exists in
the source buffer (i.e. a source buffer cannot be zero). In this case,
the GCM cipher only performs the authentication and no decryption
operation.
When the destination buffer has zero length, it is possible that no page
is mapped to the SG pointing to the destination. In this case,
sg_page(req->dst) is an invalid access. Therefore, page accesses should
only be allowed if the req->dst->length is non-zero which is the
indicator that a page must exist.
This fixes a crash that can be triggered by user space via AF_ALG.
Signed-off-by: Stephan Mueller <smueller(a)chronox.de>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/aesni-intel_glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -965,7 +965,7 @@ static int helper_rfc4106_encrypt(struct
if (sg_is_last(req->src) &&
req->src->offset + req->src->length <= PAGE_SIZE &&
- sg_is_last(req->dst) &&
+ sg_is_last(req->dst) && req->dst->length &&
req->dst->offset + req->dst->length <= PAGE_SIZE) {
one_entry_in_sg = 1;
scatterwalk_start(&src_sg_walk, req->src);
Patches currently in stable-queue which might be from smueller(a)chronox.de are
queue-4.4/crypto-af_alg-whitelist-mask-and-type.patch
queue-4.4/crypto-aesni-handle-zero-length-dst-buffer.patch
This is a note to let you know that I've just added the patch titled
crypto: af_alg - whitelist mask and type
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:
crypto-af_alg-whitelist-mask-and-type.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 bb30b8848c85e18ca7e371d0a869e94b3e383bdf Mon Sep 17 00:00:00 2001
From: Stephan Mueller <smueller(a)chronox.de>
Date: Tue, 2 Jan 2018 08:55:25 +0100
Subject: crypto: af_alg - whitelist mask and type
From: Stephan Mueller <smueller(a)chronox.de>
commit bb30b8848c85e18ca7e371d0a869e94b3e383bdf upstream.
The user space interface allows specifying the type and mask field used
to allocate the cipher. Only a subset of the possible flags are intended
for user space. Therefore, white-list the allowed flags.
In case the user space caller uses at least one non-allowed flag, EINVAL
is returned.
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Stephan Mueller <smueller(a)chronox.de>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/af_alg.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -149,7 +149,7 @@ EXPORT_SYMBOL_GPL(af_alg_release_parent)
static int alg_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
{
- const u32 forbidden = CRYPTO_ALG_INTERNAL;
+ const u32 allowed = CRYPTO_ALG_KERN_DRIVER_ONLY;
struct sock *sk = sock->sk;
struct alg_sock *ask = alg_sk(sk);
struct sockaddr_alg *sa = (void *)uaddr;
@@ -157,6 +157,10 @@ static int alg_bind(struct socket *sock,
void *private;
int err;
+ /* If caller uses non-allowed flag, return error. */
+ if ((sa->salg_feat & ~allowed) || (sa->salg_mask & ~allowed))
+ return -EINVAL;
+
if (sock->state == SS_CONNECTED)
return -EINVAL;
@@ -175,9 +179,7 @@ static int alg_bind(struct socket *sock,
if (IS_ERR(type))
return PTR_ERR(type);
- private = type->bind(sa->salg_name,
- sa->salg_feat & ~forbidden,
- sa->salg_mask & ~forbidden);
+ private = type->bind(sa->salg_name, sa->salg_feat, sa->salg_mask);
if (IS_ERR(private)) {
module_put(type->owner);
return PTR_ERR(private);
Patches currently in stable-queue which might be from smueller(a)chronox.de are
queue-4.4/crypto-af_alg-whitelist-mask-and-type.patch
queue-4.4/crypto-aesni-handle-zero-length-dst-buffer.patch
This is a note to let you know that I've just added the patch titled
tools/gpio: Fix build error with musl libc
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:
tools-gpio-fix-build-error-with-musl-libc.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 1696784eb7b52b13b62d160c028ef2c2c981d4f2 Mon Sep 17 00:00:00 2001
From: Joel Stanley <joel(a)jms.id.au>
Date: Thu, 21 Dec 2017 11:11:31 +1030
Subject: tools/gpio: Fix build error with musl libc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Joel Stanley <joel(a)jms.id.au>
commit 1696784eb7b52b13b62d160c028ef2c2c981d4f2 upstream.
The GPIO tools build fails when using a buildroot toolchain that uses musl
as it's C library:
arm-broomstick-linux-musleabi-gcc -Wp,-MD,./.gpio-event-mon.o.d \
-Wp,-MT,gpio-event-mon.o -O2 -Wall -g -D_GNU_SOURCE \
-Iinclude -D"BUILD_STR(s)=#s" -c -o gpio-event-mon.o gpio-event-mon.c
gpio-event-mon.c:30:6: error: unknown type name ‘u_int32_t’; did you mean ‘uint32_t’?
u_int32_t handleflags,
^~~~~~~~~
uint32_t
The glibc headers installed on my laptop include sys/types.h in
unistd.h, but it appears that musl does not.
Fixes: 97f69747d8b1 ("tools/gpio: add the gpio-event-mon tool")
Signed-off-by: Joel Stanley <joel(a)jms.id.au>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/gpio/gpio-event-mon.c | 1 +
1 file changed, 1 insertion(+)
--- a/tools/gpio/gpio-event-mon.c
+++ b/tools/gpio/gpio-event-mon.c
@@ -23,6 +23,7 @@
#include <getopt.h>
#include <inttypes.h>
#include <sys/ioctl.h>
+#include <sys/types.h>
#include <linux/gpio.h>
int monitor_device(const char *device_name,
Patches currently in stable-queue which might be from joel(a)jms.id.au are
queue-4.9/tools-gpio-fix-build-error-with-musl-libc.patch
This is a note to let you know that I've just added the patch titled
power: reset: zx-reboot: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
power-reset-zx-reboot-add-missing-module_description-author-license.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 348c7cf5fcbcb68838255759d4cb45d039af36d2 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:58:27 -0800
Subject: power: reset: zx-reboot: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 348c7cf5fcbcb68838255759d4cb45d039af36d2 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/power/reset/zx-reboot.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/power/reset/zx-reboot.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/power/reset/zx-reboot.c
+++ b/drivers/power/reset/zx-reboot.c
@@ -81,3 +81,7 @@ static struct platform_driver zx_reboot_
},
};
module_platform_driver(zx_reboot_driver);
+
+MODULE_DESCRIPTION("ZTE SoCs reset driver");
+MODULE_AUTHOR("Jun Nie <jun.nie(a)linaro.org>");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.9/gpio-iop-add-missing-module_description-author-license.patch
queue-4.9/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.9/gpio-ath79-add-missing-module_description-license.patch
queue-4.9/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: denali_pci: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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-denali_pci-add-missing-module_description-author-license.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 d822401d1c6898a4a4ee03977b78b8cec402e88a Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:57:13 -0800
Subject: mtd: nand: denali_pci: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit d822401d1c6898a4a4ee03977b78b8cec402e88a upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/mtd/nand/denali_pci.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Acked-by: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/denali_pci.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/mtd/nand/denali_pci.c
+++ b/drivers/mtd/nand/denali_pci.c
@@ -119,3 +119,7 @@ static struct pci_driver denali_pci_driv
};
module_pci_driver(denali_pci_driver);
+
+MODULE_DESCRIPTION("PCI driver for Denali NAND controller");
+MODULE_AUTHOR("Intel Corporation and its suppliers");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.9/gpio-iop-add-missing-module_description-author-license.patch
queue-4.9/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.9/gpio-ath79-add-missing-module_description-license.patch
queue-4.9/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
igb: Free IRQs when device is hotplugged
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:
igb-free-irqs-when-device-is-hotplugged.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 888f22931478a05bc81ceb7295c626e1292bf0ed Mon Sep 17 00:00:00 2001
From: Lyude Paul <lyude(a)redhat.com>
Date: Tue, 12 Dec 2017 14:31:30 -0500
Subject: igb: Free IRQs when device is hotplugged
From: Lyude Paul <lyude(a)redhat.com>
commit 888f22931478a05bc81ceb7295c626e1292bf0ed upstream.
Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon
hotplugging my kernel would immediately crash due to igb:
[ 680.825801] kernel BUG at drivers/pci/msi.c:352!
[ 680.828388] invalid opcode: 0000 [#1] SMP
[ 680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb]
[ 680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G O 4.15.0-rc3Lyude-Test+ #6
[ 680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver. 01.03 06/09/2017
[ 680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[ 680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0
[ 680.833271] RSP: 0018:ffffc9000030fbf0 EFLAGS: 00010286
[ 680.833761] RAX: ffff8803405f9c00 RBX: ffff88033e3d2e40 RCX: 000000000000002c
[ 680.834278] RDX: 0000000000000000 RSI: 00000000000000ac RDI: ffff880340be2178
[ 680.834832] RBP: 0000000000000000 R08: ffff880340be1ff0 R09: ffff8803405f9c00
[ 680.835342] R10: 0000000000000000 R11: 0000000000000040 R12: ffff88033d63a298
[ 680.835822] R13: ffff88033d63a000 R14: 0000000000000060 R15: ffff880341959000
[ 680.836332] FS: 0000000000000000(0000) GS:ffff88034f440000(0000) knlGS:0000000000000000
[ 680.836817] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 680.837360] CR2: 000055e64044afdf CR3: 0000000001c09002 CR4: 00000000003606e0
[ 680.837954] Call Trace:
[ 680.838853] pci_disable_msix+0xce/0xf0
[ 680.839616] igb_reset_interrupt_capability+0x5d/0x60 [igb]
[ 680.840278] igb_remove+0x9d/0x110 [igb]
[ 680.840764] pci_device_remove+0x36/0xb0
[ 680.841279] device_release_driver_internal+0x157/0x220
[ 680.841739] pci_stop_bus_device+0x7d/0xa0
[ 680.842255] pci_stop_bus_device+0x2b/0xa0
[ 680.842722] pci_stop_bus_device+0x3d/0xa0
[ 680.843189] pci_stop_and_remove_bus_device+0xe/0x20
[ 680.843627] trim_stale_devices+0xf3/0x140
[ 680.844086] trim_stale_devices+0x94/0x140
[ 680.844532] trim_stale_devices+0xa6/0x140
[ 680.845031] ? get_slot_status+0x90/0xc0
[ 680.845536] acpiphp_check_bridge.part.5+0xfe/0x140
[ 680.846021] acpiphp_hotplug_notify+0x175/0x200
[ 680.846581] ? free_bridge+0x100/0x100
[ 680.847113] acpi_device_hotplug+0x8a/0x490
[ 680.847535] acpi_hotplug_work_fn+0x1a/0x30
[ 680.848076] process_one_work+0x182/0x3a0
[ 680.848543] worker_thread+0x2e/0x380
[ 680.848963] ? process_one_work+0x3a0/0x3a0
[ 680.849373] kthread+0x111/0x130
[ 680.849776] ? kthread_create_worker_on_cpu+0x50/0x50
[ 680.850188] ret_from_fork+0x1f/0x30
[ 680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 <0f> 0b 49 8d b5 a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b
[ 680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: ffffc9000030fbf0
As it turns out, normally the freeing of IRQs that would fix this is called
inside of the scope of __igb_close(). However, since the device is
already gone by the point we try to unregister the netdevice from the
driver due to a hotplug we end up seeing that the netif isn't present
and thus, forget to free any of the device IRQs.
So: make sure that if we're in the process of dismantling the netdev, we
always allow __igb_close() to be called so that IRQs may be freed
normally. Additionally, only allow igb_close() to be called from
__igb_close() if it hasn't already been called for the given adapter.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Fixes: 9474933caf21 ("igb: close/suspend race in netif_device_detach")
Cc: Todd Fujinaka <todd.fujinaka(a)intel.com>
Cc: Stephen Hemminger <stephen(a)networkplumber.org>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3273,7 +3273,7 @@ static int __igb_close(struct net_device
int igb_close(struct net_device *netdev)
{
- if (netif_device_present(netdev))
+ if (netif_device_present(netdev) || netdev->dismantle)
return __igb_close(netdev, false);
return 0;
}
Patches currently in stable-queue which might be from lyude(a)redhat.com are
queue-4.9/igb-free-irqs-when-device-is-hotplugged.patch
This is a note to let you know that I've just added the patch titled
HID: wacom: EKR: ensure devres groups at higher indexes are released
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:
hid-wacom-ekr-ensure-devres-groups-at-higher-indexes-are-released.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 791ae273731fa85d3332e45064dab177ae663e80 Mon Sep 17 00:00:00 2001
From: Aaron Armstrong Skomra <skomra(a)gmail.com>
Date: Thu, 7 Dec 2017 12:31:56 -0800
Subject: HID: wacom: EKR: ensure devres groups at higher indexes are released
From: Aaron Armstrong Skomra <skomra(a)gmail.com>
commit 791ae273731fa85d3332e45064dab177ae663e80 upstream.
Background: ExpressKey Remotes communicate their events via usb dongle.
Each dongle can hold up to 5 pairings at one time and one EKR (identified
by its serial number) can unfortunately be paired with its dongle
more than once. The pairing takes place in a round-robin fashion.
Input devices are only created once per EKR, when a new serial number
is seen in the list of pairings. However, if a device is created for
a "higher" paring index and subsequently a second pairing occurs at a
lower pairing index, unpairing the remote with that serial number from
any pairing index will currently cause a driver crash. This occurs
infrequently, as two remotes are necessary to trigger this bug and most
users have only one remote.
As an illustration, to trigger the bug you need to have two remotes,
and pair them in this order:
1. slot 0 -> remote 1 (input device created for remote 1)
2. slot 1 -> remote 1 (duplicate pairing - no device created)
3. slot 2 -> remote 1 (duplicate pairing - no device created)
4. slot 3 -> remote 1 (duplicate pairing - no device created)
5. slot 4 -> remote 2 (input device created for remote 2)
6. slot 0 -> remote 2 (1 destroyed and recreated at slot 1)
7. slot 1 -> remote 2 (1 destroyed and recreated at slot 2)
8. slot 2 -> remote 2 (1 destroyed and recreated at slot 3)
9. slot 3 -> remote 2 (1 destroyed and not recreated)
10. slot 4 -> remote 2 (2 was already in this slot so no changes)
11. slot 0 -> remote 1 (The current code sees remote 2 was paired over in
one of the dongle slots it occupied and attempts
to remove all information about remote 2 [1]. It
calls wacom_remote_destroy_one for remote 2, but
the destroy function assumes the lowest index is
where the remote's input device was created. The
code "cleans up" the other remote 2 pairings
including the one which the input device was based
on, assuming they were were just duplicate
pairings. However, the cleanup doesn't call the
devres release function for the input device that
was created in slot 4).
This issue is fixed by this commit.
[1] Remote 2 should subsequently be re-created on the next packet from the
EKR at the lowest numbered slot that it occupies (here slot 1).
Fixes: f9036bd43602 ("HID: wacom: EKR: use devres groups to manage resources")
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra(a)wacom.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/wacom_sys.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -2192,23 +2192,23 @@ static void wacom_remote_destroy_one(str
int i;
unsigned long flags;
- spin_lock_irqsave(&remote->remote_lock, flags);
- remote->remotes[index].registered = false;
- spin_unlock_irqrestore(&remote->remote_lock, flags);
+ for (i = 0; i < WACOM_MAX_REMOTES; i++) {
+ if (remote->remotes[i].serial == serial) {
- if (remote->remotes[index].battery.battery)
- devres_release_group(&wacom->hdev->dev,
- &remote->remotes[index].battery.bat_desc);
+ spin_lock_irqsave(&remote->remote_lock, flags);
+ remote->remotes[i].registered = false;
+ spin_unlock_irqrestore(&remote->remote_lock, flags);
- if (remote->remotes[index].group.name)
- devres_release_group(&wacom->hdev->dev,
- &remote->remotes[index]);
+ if (remote->remotes[i].battery.battery)
+ devres_release_group(&wacom->hdev->dev,
+ &remote->remotes[i].battery.bat_desc);
+
+ if (remote->remotes[i].group.name)
+ devres_release_group(&wacom->hdev->dev,
+ &remote->remotes[i]);
- for (i = 0; i < WACOM_MAX_REMOTES; i++) {
- if (remote->remotes[i].serial == serial) {
remote->remotes[i].serial = 0;
remote->remotes[i].group.name = NULL;
- remote->remotes[i].registered = false;
remote->remotes[i].battery.battery = NULL;
wacom->led.groups[i].select = WACOM_STATUS_UNKNOWN;
}
Patches currently in stable-queue which might be from skomra(a)gmail.com are
queue-4.9/hid-wacom-ekr-ensure-devres-groups-at-higher-indexes-are-released.patch
This is a note to let you know that I've just added the patch titled
gpio: stmpe: i2c transfer are forbiden in atomic context
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:
gpio-stmpe-i2c-transfer-are-forbiden-in-atomic-context.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 b888fb6f2a278442933e3bfab70262e9a5365fb3 Mon Sep 17 00:00:00 2001
From: Patrice Chotard <patrice.chotard(a)st.com>
Date: Fri, 12 Jan 2018 13:16:08 +0100
Subject: gpio: stmpe: i2c transfer are forbiden in atomic context
From: Patrice Chotard <patrice.chotard(a)st.com>
commit b888fb6f2a278442933e3bfab70262e9a5365fb3 upstream.
Move the workaround from stmpe_gpio_irq_unmask() which is executed
in atomic context to stmpe_gpio_irq_sync_unlock() which is not.
It fixes the following issue:
[ 1.500000] BUG: scheduling while atomic: swapper/1/0x00000002
[ 1.500000] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc2-00020-gbd4301f-dirty #28
[ 1.520000] Hardware name: STM32 (Device Tree Support)
[ 1.520000] [<0000bfc9>] (unwind_backtrace) from [<0000b347>] (show_stack+0xb/0xc)
[ 1.530000] [<0000b347>] (show_stack) from [<0001fc49>] (__schedule_bug+0x39/0x58)
[ 1.530000] [<0001fc49>] (__schedule_bug) from [<00168211>] (__schedule+0x23/0x2b2)
[ 1.550000] [<00168211>] (__schedule) from [<001684f7>] (schedule+0x57/0x64)
[ 1.550000] [<001684f7>] (schedule) from [<0016a513>] (schedule_timeout+0x137/0x164)
[ 1.550000] [<0016a513>] (schedule_timeout) from [<00168b91>] (wait_for_common+0x8d/0xfc)
[ 1.570000] [<00168b91>] (wait_for_common) from [<00139753>] (stm32f4_i2c_xfer+0xe9/0xfe)
[ 1.580000] [<00139753>] (stm32f4_i2c_xfer) from [<00138545>] (__i2c_transfer+0x111/0x148)
[ 1.590000] [<00138545>] (__i2c_transfer) from [<001385cf>] (i2c_transfer+0x53/0x70)
[ 1.590000] [<001385cf>] (i2c_transfer) from [<001388a5>] (i2c_smbus_xfer+0x12f/0x36e)
[ 1.600000] [<001388a5>] (i2c_smbus_xfer) from [<00138b49>] (i2c_smbus_read_byte_data+0x1f/0x2a)
[ 1.610000] [<00138b49>] (i2c_smbus_read_byte_data) from [<00124fdd>] (__stmpe_reg_read+0xd/0x24)
[ 1.620000] [<00124fdd>] (__stmpe_reg_read) from [<001252b3>] (stmpe_reg_read+0x19/0x24)
[ 1.630000] [<001252b3>] (stmpe_reg_read) from [<0002c4d1>] (unmask_irq+0x17/0x22)
[ 1.640000] [<0002c4d1>] (unmask_irq) from [<0002c57f>] (irq_startup+0x6f/0x78)
[ 1.650000] [<0002c57f>] (irq_startup) from [<0002b7a1>] (__setup_irq+0x319/0x47c)
[ 1.650000] [<0002b7a1>] (__setup_irq) from [<0002bad3>] (request_threaded_irq+0x6b/0xe8)
[ 1.660000] [<0002bad3>] (request_threaded_irq) from [<0002d0b9>] (devm_request_threaded_irq+0x3b/0x6a)
[ 1.670000] [<0002d0b9>] (devm_request_threaded_irq) from [<001446e7>] (mmc_gpiod_request_cd_irq+0x49/0x8a)
[ 1.680000] [<001446e7>] (mmc_gpiod_request_cd_irq) from [<0013d45d>] (mmc_start_host+0x49/0x60)
[ 1.690000] [<0013d45d>] (mmc_start_host) from [<0013e40b>] (mmc_add_host+0x3b/0x54)
[ 1.700000] [<0013e40b>] (mmc_add_host) from [<00148119>] (mmci_probe+0x4d1/0x60c)
[ 1.710000] [<00148119>] (mmci_probe) from [<000f903b>] (amba_probe+0x7b/0xbe)
[ 1.720000] [<000f903b>] (amba_probe) from [<001170e5>] (driver_probe_device+0x169/0x1f8)
[ 1.730000] [<001170e5>] (driver_probe_device) from [<001171b7>] (__driver_attach+0x43/0x5c)
[ 1.740000] [<001171b7>] (__driver_attach) from [<0011618d>] (bus_for_each_dev+0x3d/0x46)
[ 1.740000] [<0011618d>] (bus_for_each_dev) from [<001165cd>] (bus_add_driver+0xcd/0x124)
[ 1.740000] [<001165cd>] (bus_add_driver) from [<00117713>] (driver_register+0x4d/0x7a)
[ 1.760000] [<00117713>] (driver_register) from [<001fc765>] (do_one_initcall+0xbd/0xe8)
[ 1.770000] [<001fc765>] (do_one_initcall) from [<001fc88b>] (kernel_init_freeable+0xfb/0x134)
[ 1.780000] [<001fc88b>] (kernel_init_freeable) from [<00167ee3>] (kernel_init+0x7/0x9c)
[ 1.790000] [<00167ee3>] (kernel_init) from [<00009b65>] (ret_from_fork+0x11/0x2c)
Signed-off-by: Alexandre TORGUE <alexandre.torgue(a)st.com>
Signed-off-by: Patrice Chotard <patrice.chotard(a)st.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-stmpe.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/drivers/gpio/gpio-stmpe.c
+++ b/drivers/gpio/gpio-stmpe.c
@@ -190,6 +190,16 @@ static void stmpe_gpio_irq_sync_unlock(s
};
int i, j;
+ /*
+ * STMPE1600: to be able to get IRQ from pins,
+ * a read must be done on GPMR register, or a write in
+ * GPSR or GPCR registers
+ */
+ if (stmpe->partnum == STMPE1600) {
+ stmpe_reg_read(stmpe, stmpe->regs[STMPE_IDX_GPMR_LSB]);
+ stmpe_reg_read(stmpe, stmpe->regs[STMPE_IDX_GPMR_CSB]);
+ }
+
for (i = 0; i < CACHE_NR_REGS; i++) {
/* STMPE801 and STMPE1600 don't have RE and FE registers */
if ((stmpe->partnum == STMPE801 ||
@@ -227,21 +237,11 @@ static void stmpe_gpio_irq_unmask(struct
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
struct stmpe_gpio *stmpe_gpio = gpiochip_get_data(gc);
- struct stmpe *stmpe = stmpe_gpio->stmpe;
int offset = d->hwirq;
int regoffset = offset / 8;
int mask = BIT(offset % 8);
stmpe_gpio->regs[REG_IE][regoffset] |= mask;
-
- /*
- * STMPE1600 workaround: to be able to get IRQ from pins,
- * a read must be done on GPMR register, or a write in
- * GPSR or GPCR registers
- */
- if (stmpe->partnum == STMPE1600)
- stmpe_reg_read(stmpe,
- stmpe->regs[STMPE_IDX_GPMR_LSB + regoffset]);
}
static void stmpe_dbg_show_one(struct seq_file *s,
Patches currently in stable-queue which might be from patrice.chotard(a)st.com are
queue-4.9/gpio-stmpe-i2c-transfer-are-forbiden-in-atomic-context.patch
This is a note to let you know that I've just added the patch titled
gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
gpio-iop-add-missing-module_description-author-license.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 97b03136e1b637d7a9d2274c099e44ecf23f1103 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:54:52 -0800
Subject: gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 97b03136e1b637d7a9d2274c099e44ecf23f1103 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-iop.o
see include/linux/module.h for more information
This adds the license as "GPL", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-iop.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/gpio/gpio-iop.c
+++ b/drivers/gpio/gpio-iop.c
@@ -58,3 +58,7 @@ static int __init iop3xx_gpio_init(void)
return platform_driver_register(&iop3xx_gpio_driver);
}
arch_initcall(iop3xx_gpio_init);
+
+MODULE_DESCRIPTION("GPIO handling for Intel IOP3xx processors");
+MODULE_AUTHOR("Lennert Buytenhek <buytenh(a)wantstofly.org>");
+MODULE_LICENSE("GPL");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.9/gpio-iop-add-missing-module_description-author-license.patch
queue-4.9/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.9/gpio-ath79-add-missing-module_description-license.patch
queue-4.9/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
gpio: ath79: add missing MODULE_DESCRIPTION/LICENSE
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:
gpio-ath79-add-missing-module_description-license.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 539340f37e6d6ed4cd93e8e18c9b2e4eafd4b842 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:54:26 -0800
Subject: gpio: ath79: add missing MODULE_DESCRIPTION/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 539340f37e6d6ed4cd93e8e18c9b2e4eafd4b842 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-ath79.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION is also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Acked-by: Alban Bedel <albeu(a)free.fr>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-ath79.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpio/gpio-ath79.c
+++ b/drivers/gpio/gpio-ath79.c
@@ -323,3 +323,6 @@ static struct platform_driver ath79_gpio
};
module_platform_driver(ath79_gpio_driver);
+
+MODULE_DESCRIPTION("Atheros AR71XX/AR724X/AR913X GPIO API support");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.9/gpio-iop-add-missing-module_description-author-license.patch
queue-4.9/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.9/gpio-ath79-add-missing-module_description-license.patch
queue-4.9/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
gpio: Fix kernel stack leak to userspace
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:
gpio-fix-kernel-stack-leak-to-userspace.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 24bd3efc9d1efb5f756a7c6f807a36ddb6adc671 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Mon, 22 Jan 2018 13:19:28 +0100
Subject: gpio: Fix kernel stack leak to userspace
From: Linus Walleij <linus.walleij(a)linaro.org>
commit 24bd3efc9d1efb5f756a7c6f807a36ddb6adc671 upstream.
The GPIO event descriptor was leaking kernel stack to
userspace because we don't zero the variable before
use. Ooops. Fix this.
Reported-by: Arnd Bergmann <arnd(a)arndb.de>
Reviewed-by: Bartosz Golaszewski <brgl(a)bgdev.pl>
Reviewed-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpiolib.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -705,6 +705,9 @@ static irqreturn_t lineevent_irq_thread(
struct gpioevent_data ge;
int ret, level;
+ /* Do not leak kernel stack to userspace */
+ memset(&ge, 0, sizeof(ge));
+
ge.timestamp = ktime_get_real_ns();
level = gpiod_get_value_cansleep(le->desc);
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.9/gpio-iop-add-missing-module_description-author-license.patch
queue-4.9/tools-gpio-fix-build-error-with-musl-libc.patch
queue-4.9/gpio-fix-kernel-stack-leak-to-userspace.patch
queue-4.9/gpio-ath79-add-missing-module_description-license.patch
queue-4.9/gpio-stmpe-i2c-transfer-are-forbiden-in-atomic-context.patch
This is a note to let you know that I've just added the patch titled
crypto: af_alg - whitelist mask and type
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:
crypto-af_alg-whitelist-mask-and-type.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 bb30b8848c85e18ca7e371d0a869e94b3e383bdf Mon Sep 17 00:00:00 2001
From: Stephan Mueller <smueller(a)chronox.de>
Date: Tue, 2 Jan 2018 08:55:25 +0100
Subject: crypto: af_alg - whitelist mask and type
From: Stephan Mueller <smueller(a)chronox.de>
commit bb30b8848c85e18ca7e371d0a869e94b3e383bdf upstream.
The user space interface allows specifying the type and mask field used
to allocate the cipher. Only a subset of the possible flags are intended
for user space. Therefore, white-list the allowed flags.
In case the user space caller uses at least one non-allowed flag, EINVAL
is returned.
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Stephan Mueller <smueller(a)chronox.de>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/af_alg.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -149,7 +149,7 @@ EXPORT_SYMBOL_GPL(af_alg_release_parent)
static int alg_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
{
- const u32 forbidden = CRYPTO_ALG_INTERNAL;
+ const u32 allowed = CRYPTO_ALG_KERN_DRIVER_ONLY;
struct sock *sk = sock->sk;
struct alg_sock *ask = alg_sk(sk);
struct sockaddr_alg *sa = (void *)uaddr;
@@ -157,6 +157,10 @@ static int alg_bind(struct socket *sock,
void *private;
int err;
+ /* If caller uses non-allowed flag, return error. */
+ if ((sa->salg_feat & ~allowed) || (sa->salg_mask & ~allowed))
+ return -EINVAL;
+
if (sock->state == SS_CONNECTED)
return -EINVAL;
@@ -175,9 +179,7 @@ static int alg_bind(struct socket *sock,
if (IS_ERR(type))
return PTR_ERR(type);
- private = type->bind(sa->salg_name,
- sa->salg_feat & ~forbidden,
- sa->salg_mask & ~forbidden);
+ private = type->bind(sa->salg_name, sa->salg_feat, sa->salg_mask);
if (IS_ERR(private)) {
module_put(type->owner);
return PTR_ERR(private);
Patches currently in stable-queue which might be from smueller(a)chronox.de are
queue-4.9/crypto-af_alg-whitelist-mask-and-type.patch
queue-4.9/crypto-aesni-handle-zero-length-dst-buffer.patch
This is a note to let you know that I've just added the patch titled
crypto: sha3-generic - fixes for alignment and big endian operation
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:
crypto-sha3-generic-fixes-for-alignment-and-big-endian-operation.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 c013cee99d5a18aec8c71fee8f5f41369cd12595 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Fri, 19 Jan 2018 12:04:33 +0000
Subject: crypto: sha3-generic - fixes for alignment and big endian operation
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
commit c013cee99d5a18aec8c71fee8f5f41369cd12595 upstream.
Ensure that the input is byte swabbed before injecting it into the
SHA3 transform. Use the get_unaligned() accessor for this so that
we don't perform unaligned access inadvertently on architectures
that do not support that.
Fixes: 53964b9ee63b7075 ("crypto: sha3 - Add SHA-3 hash algorithm")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/sha3_generic.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/crypto/sha3_generic.c
+++ b/crypto/sha3_generic.c
@@ -18,6 +18,7 @@
#include <linux/types.h>
#include <crypto/sha3.h>
#include <asm/byteorder.h>
+#include <asm/unaligned.h>
#define KECCAK_ROUNDS 24
@@ -149,7 +150,7 @@ static int sha3_update(struct shash_desc
unsigned int i;
for (i = 0; i < sctx->rsizw; i++)
- sctx->st[i] ^= ((u64 *) src)[i];
+ sctx->st[i] ^= get_unaligned_le64(src + 8 * i);
keccakf(sctx->st);
done += sctx->rsiz;
@@ -174,7 +175,7 @@ static int sha3_final(struct shash_desc
sctx->buf[sctx->rsiz - 1] |= 0x80;
for (i = 0; i < sctx->rsizw; i++)
- sctx->st[i] ^= ((u64 *) sctx->buf)[i];
+ sctx->st[i] ^= get_unaligned_le64(sctx->buf + 8 * i);
keccakf(sctx->st);
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.9/crypto-sha3-generic-fixes-for-alignment-and-big-endian-operation.patch
This is a note to let you know that I've just added the patch titled
crypto: ecdh - fix typo in KPP dependency of CRYPTO_ECDH
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:
crypto-ecdh-fix-typo-in-kpp-dependency-of-crypto_ecdh.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 b5b9007730ce1d90deaf25d7f678511550744bdc Mon Sep 17 00:00:00 2001
From: Hauke Mehrtens <hauke(a)hauke-m.de>
Date: Sun, 26 Nov 2017 00:16:46 +0100
Subject: crypto: ecdh - fix typo in KPP dependency of CRYPTO_ECDH
From: Hauke Mehrtens <hauke(a)hauke-m.de>
commit b5b9007730ce1d90deaf25d7f678511550744bdc upstream.
This fixes a typo in the CRYPTO_KPP dependency of CRYPTO_ECDH.
Fixes: 3c4b23901a0c ("crypto: ecdh - Add ECDH software support")
Signed-off-by: Hauke Mehrtens <hauke(a)hauke-m.de>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -120,7 +120,7 @@ config CRYPTO_DH
config CRYPTO_ECDH
tristate "ECDH algorithm"
- select CRYTPO_KPP
+ select CRYPTO_KPP
help
Generic implementation of the ECDH algorithm
Patches currently in stable-queue which might be from hauke(a)hauke-m.de are
queue-4.9/crypto-ecdh-fix-typo-in-kpp-dependency-of-crypto_ecdh.patch
This is a note to let you know that I've just added the patch titled
crypto: aesni - handle zero length dst buffer
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:
crypto-aesni-handle-zero-length-dst-buffer.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 9c674e1e2f9e24fa4392167efe343749008338e0 Mon Sep 17 00:00:00 2001
From: Stephan Mueller <smueller(a)chronox.de>
Date: Thu, 18 Jan 2018 20:41:09 +0100
Subject: crypto: aesni - handle zero length dst buffer
From: Stephan Mueller <smueller(a)chronox.de>
commit 9c674e1e2f9e24fa4392167efe343749008338e0 upstream.
GCM can be invoked with a zero destination buffer. This is possible if
the AAD and the ciphertext have zero lengths and only the tag exists in
the source buffer (i.e. a source buffer cannot be zero). In this case,
the GCM cipher only performs the authentication and no decryption
operation.
When the destination buffer has zero length, it is possible that no page
is mapped to the SG pointing to the destination. In this case,
sg_page(req->dst) is an invalid access. Therefore, page accesses should
only be allowed if the req->dst->length is non-zero which is the
indicator that a page must exist.
This fixes a crash that can be triggered by user space via AF_ALG.
Signed-off-by: Stephan Mueller <smueller(a)chronox.de>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/aesni-intel_glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -906,7 +906,7 @@ static int helper_rfc4106_encrypt(struct
if (sg_is_last(req->src) &&
req->src->offset + req->src->length <= PAGE_SIZE &&
- sg_is_last(req->dst) &&
++ sg_is_last(req->dst) && req->dst->length &&
req->dst->offset + req->dst->length <= PAGE_SIZE) {
one_entry_in_sg = 1;
scatterwalk_start(&src_sg_walk, req->src);
Patches currently in stable-queue which might be from smueller(a)chronox.de are
queue-4.9/crypto-af_alg-whitelist-mask-and-type.patch
queue-4.9/crypto-aesni-handle-zero-length-dst-buffer.patch
This is a note to let you know that I've just added the patch titled
scsi: storvsc: missing error code in storvsc_probe()
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:
scsi-storvsc-missing-error-code-in-storvsc_probe.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 ca8dc694045e9aa248e9916e0f614deb0494cb3d Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 16 Jan 2018 13:40:22 +0300
Subject: scsi: storvsc: missing error code in storvsc_probe()
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit ca8dc694045e9aa248e9916e0f614deb0494cb3d upstream.
We should set the error code if fc_remote_port_add() fails.
Fixes: daf0cd445a21 ("scsi: storvsc: Add support for FC rport.")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Reviewed-by: Cathy Avery <cavery(a)redhat.com>
Acked-by: K. Y. Srinivasan <kys(a)microsoft.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/storvsc_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1834,8 +1834,10 @@ static int storvsc_probe(struct hv_devic
fc_host_node_name(host) = stor_device->node_name;
fc_host_port_name(host) = stor_device->port_name;
stor_device->rport = fc_remote_port_add(host, 0, &ids);
- if (!stor_device->rport)
+ if (!stor_device->rport) {
+ ret = -ENOMEM;
goto err_out4;
+ }
}
#endif
return 0;
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.15/scsi-storvsc-missing-error-code-in-storvsc_probe.patch
This is a note to let you know that I've just added the patch titled
scsi: aacraid: Fix udev inquiry race condition
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:
scsi-aacraid-fix-udev-inquiry-race-condition.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 f4e8708d3104437fd7716e957f38c265b0c509ef Mon Sep 17 00:00:00 2001
From: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com>
Date: Tue, 26 Dec 2017 20:34:22 -0800
Subject: scsi: aacraid: Fix udev inquiry race condition
From: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com>
commit f4e8708d3104437fd7716e957f38c265b0c509ef upstream.
When udev requests for a devices inquiry string, it might create multiple
threads causing a race condition on the shared inquiry resource string.
Created a buffer with the string for each thread.
Fixes: 3bc8070fb75b3315 ([SCSI] aacraid: SMC vendor identification)
Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/aacraid/aachba.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -913,8 +913,16 @@ static void setinqstr(struct aac_dev *de
memset(str, ' ', sizeof(*str));
if (sup_adap_info->adapter_type_text[0]) {
- char *cp = sup_adap_info->adapter_type_text;
int c;
+ char *cp;
+ char *cname = kmemdup(sup_adap_info->adapter_type_text,
+ sizeof(sup_adap_info->adapter_type_text),
+ GFP_ATOMIC);
+
+ if (!cname)
+ return;
+
+ cp = cname;
if ((cp[0] == 'A') && (cp[1] == 'O') && (cp[2] == 'C'))
inqstrcpy("SMC", str->vid);
else {
@@ -923,7 +931,7 @@ static void setinqstr(struct aac_dev *de
++cp;
c = *cp;
*cp = '\0';
- inqstrcpy(sup_adap_info->adapter_type_text, str->vid);
+ inqstrcpy(cname, str->vid);
*cp = c;
while (*cp && *cp != ' ')
++cp;
@@ -937,8 +945,8 @@ static void setinqstr(struct aac_dev *de
cp[sizeof(str->pid)] = '\0';
}
inqstrcpy (cp, str->pid);
- if (c)
- cp[sizeof(str->pid)] = c;
+
+ kfree(cname);
} else {
struct aac_driver_ident *mp = aac_get_driver_ident(dev->cardtype);
Patches currently in stable-queue which might be from RaghavaAditya.Renukunta(a)microsemi.com are
queue-4.15/scsi-aacraid-fix-udev-inquiry-race-condition.patch
queue-4.15/scsi-aacraid-fix-hang-in-kdump.patch
This is a note to let you know that I've just added the patch titled
scsi: aacraid: Fix hang in kdump
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:
scsi-aacraid-fix-hang-in-kdump.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 c5313ae8e4e037bfaf5e56cb8d6efdb8e92ce437 Mon Sep 17 00:00:00 2001
From: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com>
Date: Tue, 26 Dec 2017 20:34:24 -0800
Subject: scsi: aacraid: Fix hang in kdump
From: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com>
commit c5313ae8e4e037bfaf5e56cb8d6efdb8e92ce437 upstream.
Driver attempts to perform a device scan and device add after coming out
of reset. At times when the kdump kernel loads and it tries to perform
eh recovery, the device scan hangs since its commands are blocked because
of the eh recovery. This should have shown up in normal eh recovery path
(Should have been obvious)
Remove the code that performs scanning.I can live without the rescanning
support in the stable kernels but a hanging kdump/eh recovery needs to be
fixed.
Fixes: a2d0321dd532901e (scsi: aacraid: Reload offlined drives after controller reset)
Reported-by: Douglas Miller <dougmill(a)linux.vnet.ibm.com>
Tested-by: Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com>
Fixes: a2d0321dd532901e (scsi: aacraid: Reload offlined drives after controller reset)
Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/aacraid/aachba.c | 1 -
drivers/scsi/aacraid/commsup.c | 9 +--------
2 files changed, 1 insertion(+), 9 deletions(-)
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -918,7 +918,6 @@ static void setinqstr(struct aac_dev *de
char *cname = kmemdup(sup_adap_info->adapter_type_text,
sizeof(sup_adap_info->adapter_type_text),
GFP_ATOMIC);
-
if (!cname)
return;
--- a/drivers/scsi/aacraid/commsup.c
+++ b/drivers/scsi/aacraid/commsup.c
@@ -1643,14 +1643,7 @@ static int _aac_reset_adapter(struct aac
out:
aac->in_reset = 0;
scsi_unblock_requests(host);
- /*
- * Issue bus rescan to catch any configuration that might have
- * occurred
- */
- if (!retval) {
- dev_info(&aac->pdev->dev, "Issuing bus rescan\n");
- scsi_scan_host(host);
- }
+
if (jafo) {
spin_lock_irq(host->host_lock);
}
Patches currently in stable-queue which might be from RaghavaAditya.Renukunta(a)microsemi.com are
queue-4.15/scsi-aacraid-fix-udev-inquiry-race-condition.patch
queue-4.15/scsi-aacraid-fix-hang-in-kdump.patch
This is a note to let you know that I've just added the patch titled
igb: Free IRQs when device is hotplugged
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:
igb-free-irqs-when-device-is-hotplugged.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 888f22931478a05bc81ceb7295c626e1292bf0ed Mon Sep 17 00:00:00 2001
From: Lyude Paul <lyude(a)redhat.com>
Date: Tue, 12 Dec 2017 14:31:30 -0500
Subject: igb: Free IRQs when device is hotplugged
From: Lyude Paul <lyude(a)redhat.com>
commit 888f22931478a05bc81ceb7295c626e1292bf0ed upstream.
Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon
hotplugging my kernel would immediately crash due to igb:
[ 680.825801] kernel BUG at drivers/pci/msi.c:352!
[ 680.828388] invalid opcode: 0000 [#1] SMP
[ 680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb]
[ 680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G O 4.15.0-rc3Lyude-Test+ #6
[ 680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver. 01.03 06/09/2017
[ 680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[ 680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0
[ 680.833271] RSP: 0018:ffffc9000030fbf0 EFLAGS: 00010286
[ 680.833761] RAX: ffff8803405f9c00 RBX: ffff88033e3d2e40 RCX: 000000000000002c
[ 680.834278] RDX: 0000000000000000 RSI: 00000000000000ac RDI: ffff880340be2178
[ 680.834832] RBP: 0000000000000000 R08: ffff880340be1ff0 R09: ffff8803405f9c00
[ 680.835342] R10: 0000000000000000 R11: 0000000000000040 R12: ffff88033d63a298
[ 680.835822] R13: ffff88033d63a000 R14: 0000000000000060 R15: ffff880341959000
[ 680.836332] FS: 0000000000000000(0000) GS:ffff88034f440000(0000) knlGS:0000000000000000
[ 680.836817] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 680.837360] CR2: 000055e64044afdf CR3: 0000000001c09002 CR4: 00000000003606e0
[ 680.837954] Call Trace:
[ 680.838853] pci_disable_msix+0xce/0xf0
[ 680.839616] igb_reset_interrupt_capability+0x5d/0x60 [igb]
[ 680.840278] igb_remove+0x9d/0x110 [igb]
[ 680.840764] pci_device_remove+0x36/0xb0
[ 680.841279] device_release_driver_internal+0x157/0x220
[ 680.841739] pci_stop_bus_device+0x7d/0xa0
[ 680.842255] pci_stop_bus_device+0x2b/0xa0
[ 680.842722] pci_stop_bus_device+0x3d/0xa0
[ 680.843189] pci_stop_and_remove_bus_device+0xe/0x20
[ 680.843627] trim_stale_devices+0xf3/0x140
[ 680.844086] trim_stale_devices+0x94/0x140
[ 680.844532] trim_stale_devices+0xa6/0x140
[ 680.845031] ? get_slot_status+0x90/0xc0
[ 680.845536] acpiphp_check_bridge.part.5+0xfe/0x140
[ 680.846021] acpiphp_hotplug_notify+0x175/0x200
[ 680.846581] ? free_bridge+0x100/0x100
[ 680.847113] acpi_device_hotplug+0x8a/0x490
[ 680.847535] acpi_hotplug_work_fn+0x1a/0x30
[ 680.848076] process_one_work+0x182/0x3a0
[ 680.848543] worker_thread+0x2e/0x380
[ 680.848963] ? process_one_work+0x3a0/0x3a0
[ 680.849373] kthread+0x111/0x130
[ 680.849776] ? kthread_create_worker_on_cpu+0x50/0x50
[ 680.850188] ret_from_fork+0x1f/0x30
[ 680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 <0f> 0b 49 8d b5 a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b
[ 680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: ffffc9000030fbf0
As it turns out, normally the freeing of IRQs that would fix this is called
inside of the scope of __igb_close(). However, since the device is
already gone by the point we try to unregister the netdevice from the
driver due to a hotplug we end up seeing that the netif isn't present
and thus, forget to free any of the device IRQs.
So: make sure that if we're in the process of dismantling the netdev, we
always allow __igb_close() to be called so that IRQs may be freed
normally. Additionally, only allow igb_close() to be called from
__igb_close() if it hasn't already been called for the given adapter.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Fixes: 9474933caf21 ("igb: close/suspend race in netif_device_detach")
Cc: Todd Fujinaka <todd.fujinaka(a)intel.com>
Cc: Stephen Hemminger <stephen(a)networkplumber.org>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3676,7 +3676,7 @@ static int __igb_close(struct net_device
int igb_close(struct net_device *netdev)
{
- if (netif_device_present(netdev))
+ if (netif_device_present(netdev) || netdev->dismantle)
return __igb_close(netdev, false);
return 0;
}
Patches currently in stable-queue which might be from lyude(a)redhat.com are
queue-4.15/igb-free-irqs-when-device-is-hotplugged.patch
This is a note to let you know that I've just added the patch titled
ima/policy: fix parsing of fsuuid
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:
ima-policy-fix-parsing-of-fsuuid.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 36447456e1cca853188505f2a964dbbeacfc7a7a Mon Sep 17 00:00:00 2001
From: Mike Rapoport <rppt(a)linux.vnet.ibm.com>
Date: Wed, 17 Jan 2018 20:27:11 +0200
Subject: ima/policy: fix parsing of fsuuid
From: Mike Rapoport <rppt(a)linux.vnet.ibm.com>
commit 36447456e1cca853188505f2a964dbbeacfc7a7a upstream.
The switch to uuid_t invereted the logic of verfication that &entry->fsuuid
is zero during parsing of "fsuuid=" rule. Instead of making sure the
&entry->fsuuid field is not attempted to be overwritten, we bail out for
perfectly correct rule.
Fixes: 787d8c530af7 ("ima/policy: switch to use uuid_t")
Signed-off-by: Mike Rapoport <rppt(a)linux.vnet.ibm.com>
Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/integrity/ima/ima_policy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -743,7 +743,7 @@ static int ima_parse_rule(char *rule, st
case Opt_fsuuid:
ima_log_string(ab, "fsuuid", args[0].from);
- if (uuid_is_null(&entry->fsuuid)) {
+ if (!uuid_is_null(&entry->fsuuid)) {
result = -EINVAL;
break;
}
Patches currently in stable-queue which might be from rppt(a)linux.vnet.ibm.com are
queue-4.15/ima-policy-fix-parsing-of-fsuuid.patch
Greg,
please add mainline d7ee9469 ("VFS: Handle lazytime in do_mount()") to
4.14. It fixes a regression in 4.14 where the lazytime mount option got
lost in a code reshuffling and mounting with -o lazytime no longer works.
After moving to 4.14 I noticed that lazytime mounts had gone, and that
patch fixes it. It applies cleanly.
thanks,
Holger
When running as Xen pv guest %gs is initialized some time after
C code is started. Depending on stack protector usage this might be
too late, resulting in page faults.
So setup %gs and MSR_GS_BASE in assembly code already.
Cc: stable(a)vger.kernel.org
Signed-off-by: Juergen Gross <jgross(a)suse.com>
---
arch/x86/xen/xen-head.S | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 497cc55a0c16..b47d87076efb 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -9,7 +9,9 @@
#include <asm/boot.h>
#include <asm/asm.h>
+#include <asm/msr.h>
#include <asm/page_types.h>
+#include <asm/percpu.h>
#include <asm/unwind_hints.h>
#include <xen/interface/elfnote.h>
@@ -35,6 +37,18 @@ ENTRY(startup_xen)
mov %_ASM_SI, xen_start_info
mov $init_thread_union+THREAD_SIZE, %_ASM_SP
+ /* Set up %gs.
+ *
+ * The base of %gs always points to the bottom of the irqstack
+ * union. If the stack protector canary is enabled, it is
+ * located at %gs:40. Note that, on SMP, the boot cpu uses
+ * init data section till per cpu areas are set up.
+ */
+ movl $MSR_GS_BASE,%ecx
+ movq $INIT_PER_CPU_VAR(irq_stack_union),%rax
+ cdq
+ wrmsr
+
jmp xen_start_kernel
END(startup_xen)
__FINIT
--
2.13.6
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From ca8dc694045e9aa248e9916e0f614deb0494cb3d Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 16 Jan 2018 13:40:22 +0300
Subject: [PATCH] scsi: storvsc: missing error code in storvsc_probe()
We should set the error code if fc_remote_port_add() fails.
Cc: <stable(a)vger.kernel.org> #v4.12+
Fixes: daf0cd445a21 ("scsi: storvsc: Add support for FC rport.")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Reviewed-by: Cathy Avery <cavery(a)redhat.com>
Acked-by: K. Y. Srinivasan <kys(a)microsoft.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 1b06cf0375dc..e07907d91d04 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1833,8 +1833,10 @@ static int storvsc_probe(struct hv_device *device,
fc_host_node_name(host) = stor_device->node_name;
fc_host_port_name(host) = stor_device->port_name;
stor_device->rport = fc_remote_port_add(host, 0, &ids);
- if (!stor_device->rport)
+ if (!stor_device->rport) {
+ ret = -ENOMEM;
goto err_out4;
+ }
}
#endif
return 0;
This is a note to let you know that I've just added the patch titled
tools/gpio: Fix build error with musl libc
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:
tools-gpio-fix-build-error-with-musl-libc.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 1696784eb7b52b13b62d160c028ef2c2c981d4f2 Mon Sep 17 00:00:00 2001
From: Joel Stanley <joel(a)jms.id.au>
Date: Thu, 21 Dec 2017 11:11:31 +1030
Subject: tools/gpio: Fix build error with musl libc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Joel Stanley <joel(a)jms.id.au>
commit 1696784eb7b52b13b62d160c028ef2c2c981d4f2 upstream.
The GPIO tools build fails when using a buildroot toolchain that uses musl
as it's C library:
arm-broomstick-linux-musleabi-gcc -Wp,-MD,./.gpio-event-mon.o.d \
-Wp,-MT,gpio-event-mon.o -O2 -Wall -g -D_GNU_SOURCE \
-Iinclude -D"BUILD_STR(s)=#s" -c -o gpio-event-mon.o gpio-event-mon.c
gpio-event-mon.c:30:6: error: unknown type name ‘u_int32_t’; did you mean ‘uint32_t’?
u_int32_t handleflags,
^~~~~~~~~
uint32_t
The glibc headers installed on my laptop include sys/types.h in
unistd.h, but it appears that musl does not.
Fixes: 97f69747d8b1 ("tools/gpio: add the gpio-event-mon tool")
Signed-off-by: Joel Stanley <joel(a)jms.id.au>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/gpio/gpio-event-mon.c | 1 +
1 file changed, 1 insertion(+)
--- a/tools/gpio/gpio-event-mon.c
+++ b/tools/gpio/gpio-event-mon.c
@@ -23,6 +23,7 @@
#include <getopt.h>
#include <inttypes.h>
#include <sys/ioctl.h>
+#include <sys/types.h>
#include <linux/gpio.h>
int monitor_device(const char *device_name,
Patches currently in stable-queue which might be from joel(a)jms.id.au are
queue-4.15/tools-gpio-fix-build-error-with-musl-libc.patch
This is a note to let you know that I've just added the patch titled
power: reset: zx-reboot: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
power-reset-zx-reboot-add-missing-module_description-author-license.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 348c7cf5fcbcb68838255759d4cb45d039af36d2 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:58:27 -0800
Subject: power: reset: zx-reboot: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 348c7cf5fcbcb68838255759d4cb45d039af36d2 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/power/reset/zx-reboot.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/power/reset/zx-reboot.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/power/reset/zx-reboot.c
+++ b/drivers/power/reset/zx-reboot.c
@@ -82,3 +82,7 @@ static struct platform_driver zx_reboot_
},
};
module_platform_driver(zx_reboot_driver);
+
+MODULE_DESCRIPTION("ZTE SoCs reset driver");
+MODULE_AUTHOR("Jun Nie <jun.nie(a)linaro.org>");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.15/gpio-iop-add-missing-module_description-author-license.patch
queue-4.15/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.15/gpio-ath79-add-missing-module_description-license.patch
queue-4.15/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
HID: wacom: Fix reporting of touch toggle (WACOM_HID_WD_MUTE_DEVICE) events
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:
hid-wacom-fix-reporting-of-touch-toggle-wacom_hid_wd_mute_device-events.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 403c0f681c1964ff1db8c2fb8de8c4067779d081 Mon Sep 17 00:00:00 2001
From: Jason Gerecke <killertofu(a)gmail.com>
Date: Tue, 26 Dec 2017 14:53:55 -0800
Subject: HID: wacom: Fix reporting of touch toggle (WACOM_HID_WD_MUTE_DEVICE) events
From: Jason Gerecke <killertofu(a)gmail.com>
commit 403c0f681c1964ff1db8c2fb8de8c4067779d081 upstream.
Touch toggle softkeys send a '1' while pressed and a '0' while released,
requring the kernel to keep track of wether touch should be enabled or
disabled. The code does not handle the state transitions properly,
however. If the key is pressed repeatedly, the following four states
of states are cycled through (assuming touch starts out enabled):
Press: shared->is_touch_on => 0, SW_MUTE_DEVICE => 1
Release: shared->is_touch_on => 0, SW_MUTE_DEVICE => 1
Press: shared->is_touch_on => 1, SW_MUTE_DEVICE => 0
Release: shared->is_touch_on => 1, SW_MUTE_DEVICE => 1
The hardware always properly enables/disables touch when the key is
pressed but applications that listen for SW_MUTE_DEVICE events to provide
feedback about the state will only ever show touch as being enabled while
the key is held, and only every-other time. This sequence occurs because
the fallthrough WACOM_HID_WD_TOUCHONOFF case is always handled, and it
uses the value of the *local* is_touch_on variable as the value to
report to userspace. The local value is equal to the shared value when
the button is pressed, but equal to zero when the button is released.
Reporting the shared value to userspace fixes this problem, but the
fallthrough case needs to update the shared value in an incompatible
way (which is why the local variable was introduced in the first place).
To work around this, we just handle both cases in a single block of code
and update the shared variable as appropriate.
Fixes: d793ff8187 ("HID: wacom: generic: support touch on/off softkey")
Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com>
Reviewed-by: Aaron Skomra <aaron.skomra(a)wacom.com>
Tested-by: Aaron Skomra <aaron.skomra(a)wacom.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/wacom_wac.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -1924,7 +1924,6 @@ static void wacom_wac_pad_event(struct h
struct wacom_features *features = &wacom_wac->features;
unsigned equivalent_usage = wacom_equivalent_usage(usage->hid);
int i;
- bool is_touch_on = value;
bool do_report = false;
/*
@@ -1969,16 +1968,17 @@ static void wacom_wac_pad_event(struct h
break;
case WACOM_HID_WD_MUTE_DEVICE:
- if (wacom_wac->shared->touch_input && value) {
- wacom_wac->shared->is_touch_on = !wacom_wac->shared->is_touch_on;
- is_touch_on = wacom_wac->shared->is_touch_on;
- }
-
- /* fall through*/
case WACOM_HID_WD_TOUCHONOFF:
if (wacom_wac->shared->touch_input) {
+ bool *is_touch_on = &wacom_wac->shared->is_touch_on;
+
+ if (equivalent_usage == WACOM_HID_WD_MUTE_DEVICE && value)
+ *is_touch_on = !(*is_touch_on);
+ else if (equivalent_usage == WACOM_HID_WD_TOUCHONOFF)
+ *is_touch_on = value;
+
input_report_switch(wacom_wac->shared->touch_input,
- SW_MUTE_DEVICE, !is_touch_on);
+ SW_MUTE_DEVICE, !(*is_touch_on));
input_sync(wacom_wac->shared->touch_input);
}
break;
Patches currently in stable-queue which might be from killertofu(a)gmail.com are
queue-4.15/hid-wacom-fix-reporting-of-touch-toggle-wacom_hid_wd_mute_device-events.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: denali_pci: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
mtd-nand-denali_pci-add-missing-module_description-author-license.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 d822401d1c6898a4a4ee03977b78b8cec402e88a Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:57:13 -0800
Subject: mtd: nand: denali_pci: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit d822401d1c6898a4a4ee03977b78b8cec402e88a upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/mtd/nand/denali_pci.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Acked-by: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/denali_pci.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/mtd/nand/denali_pci.c
+++ b/drivers/mtd/nand/denali_pci.c
@@ -125,3 +125,7 @@ static struct pci_driver denali_pci_driv
.remove = denali_pci_remove,
};
module_pci_driver(denali_pci_driver);
+
+MODULE_DESCRIPTION("PCI driver for Denali NAND controller");
+MODULE_AUTHOR("Intel Corporation and its suppliers");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.15/gpio-iop-add-missing-module_description-author-license.patch
queue-4.15/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.15/gpio-ath79-add-missing-module_description-license.patch
queue-4.15/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
HID: wacom: EKR: ensure devres groups at higher indexes are released
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:
hid-wacom-ekr-ensure-devres-groups-at-higher-indexes-are-released.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 791ae273731fa85d3332e45064dab177ae663e80 Mon Sep 17 00:00:00 2001
From: Aaron Armstrong Skomra <skomra(a)gmail.com>
Date: Thu, 7 Dec 2017 12:31:56 -0800
Subject: HID: wacom: EKR: ensure devres groups at higher indexes are released
From: Aaron Armstrong Skomra <skomra(a)gmail.com>
commit 791ae273731fa85d3332e45064dab177ae663e80 upstream.
Background: ExpressKey Remotes communicate their events via usb dongle.
Each dongle can hold up to 5 pairings at one time and one EKR (identified
by its serial number) can unfortunately be paired with its dongle
more than once. The pairing takes place in a round-robin fashion.
Input devices are only created once per EKR, when a new serial number
is seen in the list of pairings. However, if a device is created for
a "higher" paring index and subsequently a second pairing occurs at a
lower pairing index, unpairing the remote with that serial number from
any pairing index will currently cause a driver crash. This occurs
infrequently, as two remotes are necessary to trigger this bug and most
users have only one remote.
As an illustration, to trigger the bug you need to have two remotes,
and pair them in this order:
1. slot 0 -> remote 1 (input device created for remote 1)
2. slot 1 -> remote 1 (duplicate pairing - no device created)
3. slot 2 -> remote 1 (duplicate pairing - no device created)
4. slot 3 -> remote 1 (duplicate pairing - no device created)
5. slot 4 -> remote 2 (input device created for remote 2)
6. slot 0 -> remote 2 (1 destroyed and recreated at slot 1)
7. slot 1 -> remote 2 (1 destroyed and recreated at slot 2)
8. slot 2 -> remote 2 (1 destroyed and recreated at slot 3)
9. slot 3 -> remote 2 (1 destroyed and not recreated)
10. slot 4 -> remote 2 (2 was already in this slot so no changes)
11. slot 0 -> remote 1 (The current code sees remote 2 was paired over in
one of the dongle slots it occupied and attempts
to remove all information about remote 2 [1]. It
calls wacom_remote_destroy_one for remote 2, but
the destroy function assumes the lowest index is
where the remote's input device was created. The
code "cleans up" the other remote 2 pairings
including the one which the input device was based
on, assuming they were were just duplicate
pairings. However, the cleanup doesn't call the
devres release function for the input device that
was created in slot 4).
This issue is fixed by this commit.
[1] Remote 2 should subsequently be re-created on the next packet from the
EKR at the lowest numbered slot that it occupies (here slot 1).
Fixes: f9036bd43602 ("HID: wacom: EKR: use devres groups to manage resources")
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra(a)wacom.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/wacom_sys.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -2347,23 +2347,23 @@ static void wacom_remote_destroy_one(str
int i;
unsigned long flags;
- spin_lock_irqsave(&remote->remote_lock, flags);
- remote->remotes[index].registered = false;
- spin_unlock_irqrestore(&remote->remote_lock, flags);
+ for (i = 0; i < WACOM_MAX_REMOTES; i++) {
+ if (remote->remotes[i].serial == serial) {
- if (remote->remotes[index].battery.battery)
- devres_release_group(&wacom->hdev->dev,
- &remote->remotes[index].battery.bat_desc);
+ spin_lock_irqsave(&remote->remote_lock, flags);
+ remote->remotes[i].registered = false;
+ spin_unlock_irqrestore(&remote->remote_lock, flags);
- if (remote->remotes[index].group.name)
- devres_release_group(&wacom->hdev->dev,
- &remote->remotes[index]);
+ if (remote->remotes[i].battery.battery)
+ devres_release_group(&wacom->hdev->dev,
+ &remote->remotes[i].battery.bat_desc);
+
+ if (remote->remotes[i].group.name)
+ devres_release_group(&wacom->hdev->dev,
+ &remote->remotes[i]);
- for (i = 0; i < WACOM_MAX_REMOTES; i++) {
- if (remote->remotes[i].serial == serial) {
remote->remotes[i].serial = 0;
remote->remotes[i].group.name = NULL;
- remote->remotes[i].registered = false;
remote->remotes[i].battery.battery = NULL;
wacom->led.groups[i].select = WACOM_STATUS_UNKNOWN;
}
Patches currently in stable-queue which might be from skomra(a)gmail.com are
queue-4.15/hid-wacom-ekr-ensure-devres-groups-at-higher-indexes-are-released.patch
This is a note to let you know that I've just added the patch titled
gpio: stmpe: i2c transfer are forbiden in atomic context
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:
gpio-stmpe-i2c-transfer-are-forbiden-in-atomic-context.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 b888fb6f2a278442933e3bfab70262e9a5365fb3 Mon Sep 17 00:00:00 2001
From: Patrice Chotard <patrice.chotard(a)st.com>
Date: Fri, 12 Jan 2018 13:16:08 +0100
Subject: gpio: stmpe: i2c transfer are forbiden in atomic context
From: Patrice Chotard <patrice.chotard(a)st.com>
commit b888fb6f2a278442933e3bfab70262e9a5365fb3 upstream.
Move the workaround from stmpe_gpio_irq_unmask() which is executed
in atomic context to stmpe_gpio_irq_sync_unlock() which is not.
It fixes the following issue:
[ 1.500000] BUG: scheduling while atomic: swapper/1/0x00000002
[ 1.500000] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc2-00020-gbd4301f-dirty #28
[ 1.520000] Hardware name: STM32 (Device Tree Support)
[ 1.520000] [<0000bfc9>] (unwind_backtrace) from [<0000b347>] (show_stack+0xb/0xc)
[ 1.530000] [<0000b347>] (show_stack) from [<0001fc49>] (__schedule_bug+0x39/0x58)
[ 1.530000] [<0001fc49>] (__schedule_bug) from [<00168211>] (__schedule+0x23/0x2b2)
[ 1.550000] [<00168211>] (__schedule) from [<001684f7>] (schedule+0x57/0x64)
[ 1.550000] [<001684f7>] (schedule) from [<0016a513>] (schedule_timeout+0x137/0x164)
[ 1.550000] [<0016a513>] (schedule_timeout) from [<00168b91>] (wait_for_common+0x8d/0xfc)
[ 1.570000] [<00168b91>] (wait_for_common) from [<00139753>] (stm32f4_i2c_xfer+0xe9/0xfe)
[ 1.580000] [<00139753>] (stm32f4_i2c_xfer) from [<00138545>] (__i2c_transfer+0x111/0x148)
[ 1.590000] [<00138545>] (__i2c_transfer) from [<001385cf>] (i2c_transfer+0x53/0x70)
[ 1.590000] [<001385cf>] (i2c_transfer) from [<001388a5>] (i2c_smbus_xfer+0x12f/0x36e)
[ 1.600000] [<001388a5>] (i2c_smbus_xfer) from [<00138b49>] (i2c_smbus_read_byte_data+0x1f/0x2a)
[ 1.610000] [<00138b49>] (i2c_smbus_read_byte_data) from [<00124fdd>] (__stmpe_reg_read+0xd/0x24)
[ 1.620000] [<00124fdd>] (__stmpe_reg_read) from [<001252b3>] (stmpe_reg_read+0x19/0x24)
[ 1.630000] [<001252b3>] (stmpe_reg_read) from [<0002c4d1>] (unmask_irq+0x17/0x22)
[ 1.640000] [<0002c4d1>] (unmask_irq) from [<0002c57f>] (irq_startup+0x6f/0x78)
[ 1.650000] [<0002c57f>] (irq_startup) from [<0002b7a1>] (__setup_irq+0x319/0x47c)
[ 1.650000] [<0002b7a1>] (__setup_irq) from [<0002bad3>] (request_threaded_irq+0x6b/0xe8)
[ 1.660000] [<0002bad3>] (request_threaded_irq) from [<0002d0b9>] (devm_request_threaded_irq+0x3b/0x6a)
[ 1.670000] [<0002d0b9>] (devm_request_threaded_irq) from [<001446e7>] (mmc_gpiod_request_cd_irq+0x49/0x8a)
[ 1.680000] [<001446e7>] (mmc_gpiod_request_cd_irq) from [<0013d45d>] (mmc_start_host+0x49/0x60)
[ 1.690000] [<0013d45d>] (mmc_start_host) from [<0013e40b>] (mmc_add_host+0x3b/0x54)
[ 1.700000] [<0013e40b>] (mmc_add_host) from [<00148119>] (mmci_probe+0x4d1/0x60c)
[ 1.710000] [<00148119>] (mmci_probe) from [<000f903b>] (amba_probe+0x7b/0xbe)
[ 1.720000] [<000f903b>] (amba_probe) from [<001170e5>] (driver_probe_device+0x169/0x1f8)
[ 1.730000] [<001170e5>] (driver_probe_device) from [<001171b7>] (__driver_attach+0x43/0x5c)
[ 1.740000] [<001171b7>] (__driver_attach) from [<0011618d>] (bus_for_each_dev+0x3d/0x46)
[ 1.740000] [<0011618d>] (bus_for_each_dev) from [<001165cd>] (bus_add_driver+0xcd/0x124)
[ 1.740000] [<001165cd>] (bus_add_driver) from [<00117713>] (driver_register+0x4d/0x7a)
[ 1.760000] [<00117713>] (driver_register) from [<001fc765>] (do_one_initcall+0xbd/0xe8)
[ 1.770000] [<001fc765>] (do_one_initcall) from [<001fc88b>] (kernel_init_freeable+0xfb/0x134)
[ 1.780000] [<001fc88b>] (kernel_init_freeable) from [<00167ee3>] (kernel_init+0x7/0x9c)
[ 1.790000] [<00167ee3>] (kernel_init) from [<00009b65>] (ret_from_fork+0x11/0x2c)
Signed-off-by: Alexandre TORGUE <alexandre.torgue(a)st.com>
Signed-off-by: Patrice Chotard <patrice.chotard(a)st.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-stmpe.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/drivers/gpio/gpio-stmpe.c
+++ b/drivers/gpio/gpio-stmpe.c
@@ -190,6 +190,16 @@ static void stmpe_gpio_irq_sync_unlock(s
};
int i, j;
+ /*
+ * STMPE1600: to be able to get IRQ from pins,
+ * a read must be done on GPMR register, or a write in
+ * GPSR or GPCR registers
+ */
+ if (stmpe->partnum == STMPE1600) {
+ stmpe_reg_read(stmpe, stmpe->regs[STMPE_IDX_GPMR_LSB]);
+ stmpe_reg_read(stmpe, stmpe->regs[STMPE_IDX_GPMR_CSB]);
+ }
+
for (i = 0; i < CACHE_NR_REGS; i++) {
/* STMPE801 and STMPE1600 don't have RE and FE registers */
if ((stmpe->partnum == STMPE801 ||
@@ -227,21 +237,11 @@ static void stmpe_gpio_irq_unmask(struct
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
struct stmpe_gpio *stmpe_gpio = gpiochip_get_data(gc);
- struct stmpe *stmpe = stmpe_gpio->stmpe;
int offset = d->hwirq;
int regoffset = offset / 8;
int mask = BIT(offset % 8);
stmpe_gpio->regs[REG_IE][regoffset] |= mask;
-
- /*
- * STMPE1600 workaround: to be able to get IRQ from pins,
- * a read must be done on GPMR register, or a write in
- * GPSR or GPCR registers
- */
- if (stmpe->partnum == STMPE1600)
- stmpe_reg_read(stmpe,
- stmpe->regs[STMPE_IDX_GPMR_LSB + regoffset]);
}
static void stmpe_dbg_show_one(struct seq_file *s,
Patches currently in stable-queue which might be from patrice.chotard(a)st.com are
queue-4.15/gpio-stmpe-i2c-transfer-are-forbiden-in-atomic-context.patch
This is a note to let you know that I've just added the patch titled
gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
gpio-iop-add-missing-module_description-author-license.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 97b03136e1b637d7a9d2274c099e44ecf23f1103 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:54:52 -0800
Subject: gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 97b03136e1b637d7a9d2274c099e44ecf23f1103 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-iop.o
see include/linux/module.h for more information
This adds the license as "GPL", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-iop.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/gpio/gpio-iop.c
+++ b/drivers/gpio/gpio-iop.c
@@ -58,3 +58,7 @@ static int __init iop3xx_gpio_init(void)
return platform_driver_register(&iop3xx_gpio_driver);
}
arch_initcall(iop3xx_gpio_init);
+
+MODULE_DESCRIPTION("GPIO handling for Intel IOP3xx processors");
+MODULE_AUTHOR("Lennert Buytenhek <buytenh(a)wantstofly.org>");
+MODULE_LICENSE("GPL");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.15/gpio-iop-add-missing-module_description-author-license.patch
queue-4.15/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.15/gpio-ath79-add-missing-module_description-license.patch
queue-4.15/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
gpio: Fix kernel stack leak to userspace
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:
gpio-fix-kernel-stack-leak-to-userspace.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 24bd3efc9d1efb5f756a7c6f807a36ddb6adc671 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Mon, 22 Jan 2018 13:19:28 +0100
Subject: gpio: Fix kernel stack leak to userspace
From: Linus Walleij <linus.walleij(a)linaro.org>
commit 24bd3efc9d1efb5f756a7c6f807a36ddb6adc671 upstream.
The GPIO event descriptor was leaking kernel stack to
userspace because we don't zero the variable before
use. Ooops. Fix this.
Reported-by: Arnd Bergmann <arnd(a)arndb.de>
Reviewed-by: Bartosz Golaszewski <brgl(a)bgdev.pl>
Reviewed-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpiolib.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -732,6 +732,9 @@ static irqreturn_t lineevent_irq_thread(
struct gpioevent_data ge;
int ret, level;
+ /* Do not leak kernel stack to userspace */
+ memset(&ge, 0, sizeof(ge));
+
ge.timestamp = ktime_get_real_ns();
level = gpiod_get_value_cansleep(le->desc);
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.15/gpio-iop-add-missing-module_description-author-license.patch
queue-4.15/tools-gpio-fix-build-error-with-musl-libc.patch
queue-4.15/gpio-fix-kernel-stack-leak-to-userspace.patch
queue-4.15/gpio-ath79-add-missing-module_description-license.patch
queue-4.15/gpio-stmpe-i2c-transfer-are-forbiden-in-atomic-context.patch
This is a note to let you know that I've just added the patch titled
gpio: ath79: add missing MODULE_DESCRIPTION/LICENSE
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:
gpio-ath79-add-missing-module_description-license.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 539340f37e6d6ed4cd93e8e18c9b2e4eafd4b842 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 12:54:26 -0800
Subject: gpio: ath79: add missing MODULE_DESCRIPTION/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 539340f37e6d6ed4cd93e8e18c9b2e4eafd4b842 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-ath79.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION is also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Acked-by: Alban Bedel <albeu(a)free.fr>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-ath79.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpio/gpio-ath79.c
+++ b/drivers/gpio/gpio-ath79.c
@@ -324,3 +324,6 @@ static struct platform_driver ath79_gpio
};
module_platform_driver(ath79_gpio_driver);
+
+MODULE_DESCRIPTION("Atheros AR71XX/AR724X/AR913X GPIO API support");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.15/gpio-iop-add-missing-module_description-author-license.patch
queue-4.15/power-reset-zx-reboot-add-missing-module_description-author-license.patch
queue-4.15/gpio-ath79-add-missing-module_description-license.patch
queue-4.15/mtd-nand-denali_pci-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
crypto: inside-secure - fix hash when length is a multiple of a block
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:
crypto-inside-secure-fix-hash-when-length-is-a-multiple-of-a-block.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 809778e02cd45d0625439fee67688f655627bb3c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20T=C3=A9nart?= <antoine.tenart(a)free-electrons.com>
Date: Tue, 26 Dec 2017 17:21:17 +0100
Subject: crypto: inside-secure - fix hash when length is a multiple of a block
From: Antoine Tenart <antoine.tenart(a)free-electrons.com>
commit 809778e02cd45d0625439fee67688f655627bb3c upstream.
This patch fixes the hash support in the SafeXcel driver when the update
size is a multiple of a block size, and when a final call is made just
after with a size of 0. In such cases the driver should cache the last
block from the update to avoid handling 0 length data on the final call
(that's a hardware limitation).
Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver")
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: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/inside-secure/safexcel_hash.c | 34 +++++++++++++++++++--------
1 file changed, 24 insertions(+), 10 deletions(-)
--- a/drivers/crypto/inside-secure/safexcel_hash.c
+++ b/drivers/crypto/inside-secure/safexcel_hash.c
@@ -186,17 +186,31 @@ static int safexcel_ahash_send_req(struc
else
cache_len = queued - areq->nbytes;
- /*
- * If this is not the last request and the queued data does not fit
- * into full blocks, cache it for the next send() call.
- */
- extra = queued & (crypto_ahash_blocksize(ahash) - 1);
- if (!req->last_req && extra) {
- sg_pcopy_to_buffer(areq->src, sg_nents(areq->src),
- req->cache_next, extra, areq->nbytes - extra);
+ if (!req->last_req) {
+ /* If this is not the last request and the queued data does not
+ * fit into full blocks, cache it for the next send() call.
+ */
+ extra = queued & (crypto_ahash_blocksize(ahash) - 1);
+ if (!extra)
+ /* If this is not the last request and the queued data
+ * is a multiple of a block, cache the last one for now.
+ */
+ extra = queued - crypto_ahash_blocksize(ahash);
- queued -= extra;
- len -= extra;
+ if (extra) {
+ sg_pcopy_to_buffer(areq->src, sg_nents(areq->src),
+ req->cache_next, extra,
+ areq->nbytes - extra);
+
+ queued -= extra;
+ len -= extra;
+
+ if (!queued) {
+ *commands = 0;
+ *results = 0;
+ return 0;
+ }
+ }
}
spin_lock_bh(&priv->ring[ring].egress_lock);
Patches currently in stable-queue which might be from antoine.tenart(a)free-electrons.com are
queue-4.15/crypto-inside-secure-avoid-unmapping-dma-memory-that-was-not-mapped.patch
queue-4.15/crypto-inside-secure-fix-hash-when-length-is-a-multiple-of-a-block.patch
This is a note to let you know that I've just added the patch titled
crypto: sha3-generic - fixes for alignment and big endian operation
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:
crypto-sha3-generic-fixes-for-alignment-and-big-endian-operation.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 c013cee99d5a18aec8c71fee8f5f41369cd12595 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Fri, 19 Jan 2018 12:04:33 +0000
Subject: crypto: sha3-generic - fixes for alignment and big endian operation
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
commit c013cee99d5a18aec8c71fee8f5f41369cd12595 upstream.
Ensure that the input is byte swabbed before injecting it into the
SHA3 transform. Use the get_unaligned() accessor for this so that
we don't perform unaligned access inadvertently on architectures
that do not support that.
Fixes: 53964b9ee63b7075 ("crypto: sha3 - Add SHA-3 hash algorithm")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/sha3_generic.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/crypto/sha3_generic.c
+++ b/crypto/sha3_generic.c
@@ -18,6 +18,7 @@
#include <linux/types.h>
#include <crypto/sha3.h>
#include <asm/byteorder.h>
+#include <asm/unaligned.h>
#define KECCAK_ROUNDS 24
@@ -149,7 +150,7 @@ static int sha3_update(struct shash_desc
unsigned int i;
for (i = 0; i < sctx->rsizw; i++)
- sctx->st[i] ^= ((u64 *) src)[i];
+ sctx->st[i] ^= get_unaligned_le64(src + 8 * i);
keccakf(sctx->st);
done += sctx->rsiz;
@@ -174,7 +175,7 @@ static int sha3_final(struct shash_desc
sctx->buf[sctx->rsiz - 1] |= 0x80;
for (i = 0; i < sctx->rsizw; i++)
- sctx->st[i] ^= ((u64 *) sctx->buf)[i];
+ sctx->st[i] ^= get_unaligned_le64(sctx->buf + 8 * i);
keccakf(sctx->st);
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.15/crypto-sha3-generic-fixes-for-alignment-and-big-endian-operation.patch
This is a note to let you know that I've just added the patch titled
crypto: ecdh - fix typo in KPP dependency of CRYPTO_ECDH
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:
crypto-ecdh-fix-typo-in-kpp-dependency-of-crypto_ecdh.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 b5b9007730ce1d90deaf25d7f678511550744bdc Mon Sep 17 00:00:00 2001
From: Hauke Mehrtens <hauke(a)hauke-m.de>
Date: Sun, 26 Nov 2017 00:16:46 +0100
Subject: crypto: ecdh - fix typo in KPP dependency of CRYPTO_ECDH
From: Hauke Mehrtens <hauke(a)hauke-m.de>
commit b5b9007730ce1d90deaf25d7f678511550744bdc upstream.
This fixes a typo in the CRYPTO_KPP dependency of CRYPTO_ECDH.
Fixes: 3c4b23901a0c ("crypto: ecdh - Add ECDH software support")
Signed-off-by: Hauke Mehrtens <hauke(a)hauke-m.de>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -130,7 +130,7 @@ config CRYPTO_DH
config CRYPTO_ECDH
tristate "ECDH algorithm"
- select CRYTPO_KPP
+ select CRYPTO_KPP
select CRYPTO_RNG_DEFAULT
help
Generic implementation of the ECDH algorithm
Patches currently in stable-queue which might be from hauke(a)hauke-m.de are
queue-4.15/crypto-ecdh-fix-typo-in-kpp-dependency-of-crypto_ecdh.patch
This is a note to let you know that I've just added the patch titled
crypto: inside-secure - avoid unmapping DMA memory that was not mapped
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:
crypto-inside-secure-avoid-unmapping-dma-memory-that-was-not-mapped.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 c957f8b3e2e54b29f53ef69decc87bbc858c9b58 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20T=C3=A9nart?= <antoine.tenart(a)free-electrons.com>
Date: Tue, 26 Dec 2017 17:21:16 +0100
Subject: crypto: inside-secure - avoid unmapping DMA memory that was not mapped
From: Antoine Tenart <antoine.tenart(a)free-electrons.com>
commit c957f8b3e2e54b29f53ef69decc87bbc858c9b58 upstream.
This patch adds a parameter in the SafeXcel ahash request structure to
keep track of the number of SG entries mapped. This allows not to call
dma_unmap_sg() when dma_map_sg() wasn't called in the first place. This
also removes a warning when the debugging of the DMA-API is enabled in
the kernel configuration: "DMA-API: device driver tries to free DMA
memory it has not allocated".
Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver")
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: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/inside-secure/safexcel_hash.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
--- a/drivers/crypto/inside-secure/safexcel_hash.c
+++ b/drivers/crypto/inside-secure/safexcel_hash.c
@@ -34,6 +34,8 @@ struct safexcel_ahash_req {
bool hmac;
bool needs_inv;
+ int nents;
+
u8 state_sz; /* expected sate size, only set once */
u32 state[SHA256_DIGEST_SIZE / sizeof(u32)] __aligned(sizeof(u32));
@@ -152,8 +154,10 @@ static int safexcel_handle_req_result(st
memcpy(areq->result, sreq->state,
crypto_ahash_digestsize(ahash));
- dma_unmap_sg(priv->dev, areq->src,
- sg_nents_for_len(areq->src, areq->nbytes), DMA_TO_DEVICE);
+ if (sreq->nents) {
+ dma_unmap_sg(priv->dev, areq->src, sreq->nents, DMA_TO_DEVICE);
+ sreq->nents = 0;
+ }
safexcel_free_context(priv, async, sreq->state_sz);
@@ -178,7 +182,7 @@ static int safexcel_ahash_send_req(struc
struct safexcel_command_desc *cdesc, *first_cdesc = NULL;
struct safexcel_result_desc *rdesc;
struct scatterlist *sg;
- int i, nents, queued, len, cache_len, extra, n_cdesc = 0, ret = 0;
+ int i, queued, len, cache_len, extra, n_cdesc = 0, ret = 0;
queued = len = req->len - req->processed;
if (queued < crypto_ahash_blocksize(ahash))
@@ -248,15 +252,15 @@ static int safexcel_ahash_send_req(struc
}
/* Now handle the current ahash request buffer(s) */
- nents = dma_map_sg(priv->dev, areq->src,
- sg_nents_for_len(areq->src, areq->nbytes),
- DMA_TO_DEVICE);
- if (!nents) {
+ req->nents = dma_map_sg(priv->dev, areq->src,
+ sg_nents_for_len(areq->src, areq->nbytes),
+ DMA_TO_DEVICE);
+ if (!req->nents) {
ret = -ENOMEM;
goto cdesc_rollback;
}
- for_each_sg(areq->src, sg, nents, i) {
+ for_each_sg(areq->src, sg, req->nents, i) {
int sglen = sg_dma_len(sg);
/* Do not overflow the request */
Patches currently in stable-queue which might be from antoine.tenart(a)free-electrons.com are
queue-4.15/crypto-inside-secure-avoid-unmapping-dma-memory-that-was-not-mapped.patch
queue-4.15/crypto-inside-secure-fix-hash-when-length-is-a-multiple-of-a-block.patch
This is a note to let you know that I've just added the patch titled
crypto: af_alg - whitelist mask and type
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:
crypto-af_alg-whitelist-mask-and-type.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 bb30b8848c85e18ca7e371d0a869e94b3e383bdf Mon Sep 17 00:00:00 2001
From: Stephan Mueller <smueller(a)chronox.de>
Date: Tue, 2 Jan 2018 08:55:25 +0100
Subject: crypto: af_alg - whitelist mask and type
From: Stephan Mueller <smueller(a)chronox.de>
commit bb30b8848c85e18ca7e371d0a869e94b3e383bdf upstream.
The user space interface allows specifying the type and mask field used
to allocate the cipher. Only a subset of the possible flags are intended
for user space. Therefore, white-list the allowed flags.
In case the user space caller uses at least one non-allowed flag, EINVAL
is returned.
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Stephan Mueller <smueller(a)chronox.de>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/af_alg.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -150,7 +150,7 @@ EXPORT_SYMBOL_GPL(af_alg_release_parent)
static int alg_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
{
- const u32 forbidden = CRYPTO_ALG_INTERNAL;
+ const u32 allowed = CRYPTO_ALG_KERN_DRIVER_ONLY;
struct sock *sk = sock->sk;
struct alg_sock *ask = alg_sk(sk);
struct sockaddr_alg *sa = (void *)uaddr;
@@ -158,6 +158,10 @@ static int alg_bind(struct socket *sock,
void *private;
int err;
+ /* If caller uses non-allowed flag, return error. */
+ if ((sa->salg_feat & ~allowed) || (sa->salg_mask & ~allowed))
+ return -EINVAL;
+
if (sock->state == SS_CONNECTED)
return -EINVAL;
@@ -176,9 +180,7 @@ static int alg_bind(struct socket *sock,
if (IS_ERR(type))
return PTR_ERR(type);
- private = type->bind(sa->salg_name,
- sa->salg_feat & ~forbidden,
- sa->salg_mask & ~forbidden);
+ private = type->bind(sa->salg_name, sa->salg_feat, sa->salg_mask);
if (IS_ERR(private)) {
module_put(type->owner);
return PTR_ERR(private);
Patches currently in stable-queue which might be from smueller(a)chronox.de are
queue-4.15/crypto-af_alg-whitelist-mask-and-type.patch
queue-4.15/crypto-aesni-handle-zero-length-dst-buffer.patch
This is a note to let you know that I've just added the patch titled
crypto: aesni - handle zero length dst buffer
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:
crypto-aesni-handle-zero-length-dst-buffer.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 9c674e1e2f9e24fa4392167efe343749008338e0 Mon Sep 17 00:00:00 2001
From: Stephan Mueller <smueller(a)chronox.de>
Date: Thu, 18 Jan 2018 20:41:09 +0100
Subject: crypto: aesni - handle zero length dst buffer
From: Stephan Mueller <smueller(a)chronox.de>
commit 9c674e1e2f9e24fa4392167efe343749008338e0 upstream.
GCM can be invoked with a zero destination buffer. This is possible if
the AAD and the ciphertext have zero lengths and only the tag exists in
the source buffer (i.e. a source buffer cannot be zero). In this case,
the GCM cipher only performs the authentication and no decryption
operation.
When the destination buffer has zero length, it is possible that no page
is mapped to the SG pointing to the destination. In this case,
sg_page(req->dst) is an invalid access. Therefore, page accesses should
only be allowed if the req->dst->length is non-zero which is the
indicator that a page must exist.
This fixes a crash that can be triggered by user space via AF_ALG.
Signed-off-by: Stephan Mueller <smueller(a)chronox.de>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/aesni-intel_glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -824,7 +824,7 @@ static int gcmaes_decrypt(struct aead_re
if (sg_is_last(req->src) &&
(!PageHighMem(sg_page(req->src)) ||
req->src->offset + req->src->length <= PAGE_SIZE) &&
- sg_is_last(req->dst) &&
+ sg_is_last(req->dst) && req->dst->length &&
(!PageHighMem(sg_page(req->dst)) ||
req->dst->offset + req->dst->length <= PAGE_SIZE)) {
one_entry_in_sg = 1;
Patches currently in stable-queue which might be from smueller(a)chronox.de are
queue-4.15/crypto-af_alg-whitelist-mask-and-type.patch
queue-4.15/crypto-aesni-handle-zero-length-dst-buffer.patch
This is a note to let you know that I've just added the patch titled
crypto: aesni - fix typo in generic_gcmaes_decrypt
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:
crypto-aesni-fix-typo-in-generic_gcmaes_decrypt.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 106840c41096a01079d3a2025225029c13713802 Mon Sep 17 00:00:00 2001
From: Sabrina Dubroca <sd(a)queasysnail.net>
Date: Wed, 13 Dec 2017 14:53:43 +0100
Subject: crypto: aesni - fix typo in generic_gcmaes_decrypt
From: Sabrina Dubroca <sd(a)queasysnail.net>
commit 106840c41096a01079d3a2025225029c13713802 upstream.
generic_gcmaes_decrypt needs to use generic_gcmaes_ctx, not
aesni_rfc4106_gcm_ctx. This is actually harmless because the fields in
struct generic_gcmaes_ctx share the layout of the same fields in
aesni_rfc4106_gcm_ctx.
Fixes: cce2ea8d90fe ("crypto: aesni - add generic gcm(aes)")
Signed-off-by: Sabrina Dubroca <sd(a)queasysnail.net>
Reviewed-by: Stefano Brivio <sbrivio(a)redhat.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/aesni-intel_glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -1117,7 +1117,7 @@ static int generic_gcmaes_decrypt(struct
{
__be32 counter = cpu_to_be32(1);
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
- struct aesni_rfc4106_gcm_ctx *ctx = aesni_rfc4106_gcm_ctx_get(tfm);
+ struct generic_gcmaes_ctx *ctx = generic_gcmaes_ctx_get(tfm);
void *aes_ctx = &(ctx->aes_key_expanded);
u8 iv[16] __attribute__ ((__aligned__(AESNI_ALIGN)));
Patches currently in stable-queue which might be from sd(a)queasysnail.net are
queue-4.15/crypto-aesni-add-wrapper-for-generic-gcm-aes.patch
queue-4.15/crypto-aesni-fix-typo-in-generic_gcmaes_decrypt.patch
This is a note to let you know that I've just added the patch titled
crypto: aesni - Fix out-of-bounds access of the data buffer in generic-gcm-aesni
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:
crypto-aesni-fix-out-of-bounds-access-of-the-data-buffer-in-generic-gcm-aesni.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 b20209c91e23a9bbad9cac2f80bc16b3c259e10e Mon Sep 17 00:00:00 2001
From: Junaid Shahid <junaids(a)google.com>
Date: Wed, 20 Dec 2017 17:08:37 -0800
Subject: crypto: aesni - Fix out-of-bounds access of the data buffer in generic-gcm-aesni
From: Junaid Shahid <junaids(a)google.com>
commit b20209c91e23a9bbad9cac2f80bc16b3c259e10e upstream.
The aesni_gcm_enc/dec functions can access memory before the start of
the data buffer if the length of the data buffer is less than 16 bytes.
This is because they perform the read via a single 16-byte load. This
can potentially result in accessing a page that is not mapped and thus
causing the machine to crash. This patch fixes that by reading the
partial block byte-by-byte and optionally an via 8-byte load if the block
was at least 8 bytes.
Fixes: 0487ccac ("crypto: aesni - make non-AVX AES-GCM work with any aadlen")
Signed-off-by: Junaid Shahid <junaids(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/aesni-intel_asm.S | 87 +++++++++++++++++++-------------------
1 file changed, 45 insertions(+), 42 deletions(-)
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -257,6 +257,37 @@ aad_shift_arr:
pxor \TMP1, \GH # result is in TMP1
.endm
+# Reads DLEN bytes starting at DPTR and stores in XMMDst
+# where 0 < DLEN < 16
+# Clobbers %rax, DLEN and XMM1
+.macro READ_PARTIAL_BLOCK DPTR DLEN XMM1 XMMDst
+ cmp $8, \DLEN
+ jl _read_lt8_\@
+ mov (\DPTR), %rax
+ MOVQ_R64_XMM %rax, \XMMDst
+ sub $8, \DLEN
+ jz _done_read_partial_block_\@
+ xor %eax, %eax
+_read_next_byte_\@:
+ shl $8, %rax
+ mov 7(\DPTR, \DLEN, 1), %al
+ dec \DLEN
+ jnz _read_next_byte_\@
+ MOVQ_R64_XMM %rax, \XMM1
+ pslldq $8, \XMM1
+ por \XMM1, \XMMDst
+ jmp _done_read_partial_block_\@
+_read_lt8_\@:
+ xor %eax, %eax
+_read_next_byte_lt8_\@:
+ shl $8, %rax
+ mov -1(\DPTR, \DLEN, 1), %al
+ dec \DLEN
+ jnz _read_next_byte_lt8_\@
+ MOVQ_R64_XMM %rax, \XMMDst
+_done_read_partial_block_\@:
+.endm
+
/*
* if a = number of total plaintext bytes
* b = floor(a/16)
@@ -1386,14 +1417,6 @@ _esb_loop_\@:
*
* AAD Format with 64-bit Extended Sequence Number
*
-* aadLen:
-* from the definition of the spec, aadLen can only be 8 or 12 bytes.
-* The code supports 16 too but for other sizes, the code will fail.
-*
-* TLen:
-* from the definition of the spec, TLen can only be 8, 12 or 16 bytes.
-* For other sizes, the code will fail.
-*
* poly = x^128 + x^127 + x^126 + x^121 + 1
*
*****************************************************************************/
@@ -1487,19 +1510,16 @@ _zero_cipher_left_decrypt:
PSHUFB_XMM %xmm10, %xmm0
ENCRYPT_SINGLE_BLOCK %xmm0, %xmm1 # E(K, Yn)
- sub $16, %r11
- add %r13, %r11
- movdqu (%arg3,%r11,1), %xmm1 # receive the last <16 byte block
- lea SHIFT_MASK+16(%rip), %r12
- sub %r13, %r12
-# adjust the shuffle mask pointer to be able to shift 16-%r13 bytes
-# (%r13 is the number of bytes in plaintext mod 16)
- movdqu (%r12), %xmm2 # get the appropriate shuffle mask
- PSHUFB_XMM %xmm2, %xmm1 # right shift 16-%r13 butes
+ lea (%arg3,%r11,1), %r10
+ mov %r13, %r12
+ READ_PARTIAL_BLOCK %r10 %r12 %xmm2 %xmm1
+
+ lea ALL_F+16(%rip), %r12
+ sub %r13, %r12
movdqa %xmm1, %xmm2
pxor %xmm1, %xmm0 # Ciphertext XOR E(K, Yn)
- movdqu ALL_F-SHIFT_MASK(%r12), %xmm1
+ movdqu (%r12), %xmm1
# get the appropriate mask to mask out top 16-%r13 bytes of %xmm0
pand %xmm1, %xmm0 # mask out top 16-%r13 bytes of %xmm0
pand %xmm1, %xmm2
@@ -1508,9 +1528,6 @@ _zero_cipher_left_decrypt:
pxor %xmm2, %xmm8
GHASH_MUL %xmm8, %xmm13, %xmm9, %xmm10, %xmm11, %xmm5, %xmm6
- # GHASH computation for the last <16 byte block
- sub %r13, %r11
- add $16, %r11
# output %r13 bytes
MOVQ_R64_XMM %xmm0, %rax
@@ -1664,14 +1681,6 @@ ENDPROC(aesni_gcm_dec)
*
* AAD Format with 64-bit Extended Sequence Number
*
-* aadLen:
-* from the definition of the spec, aadLen can only be 8 or 12 bytes.
-* The code supports 16 too but for other sizes, the code will fail.
-*
-* TLen:
-* from the definition of the spec, TLen can only be 8, 12 or 16 bytes.
-* For other sizes, the code will fail.
-*
* poly = x^128 + x^127 + x^126 + x^121 + 1
***************************************************************************/
ENTRY(aesni_gcm_enc)
@@ -1764,19 +1773,16 @@ _zero_cipher_left_encrypt:
movdqa SHUF_MASK(%rip), %xmm10
PSHUFB_XMM %xmm10, %xmm0
-
ENCRYPT_SINGLE_BLOCK %xmm0, %xmm1 # Encrypt(K, Yn)
- sub $16, %r11
- add %r13, %r11
- movdqu (%arg3,%r11,1), %xmm1 # receive the last <16 byte blocks
- lea SHIFT_MASK+16(%rip), %r12
+
+ lea (%arg3,%r11,1), %r10
+ mov %r13, %r12
+ READ_PARTIAL_BLOCK %r10 %r12 %xmm2 %xmm1
+
+ lea ALL_F+16(%rip), %r12
sub %r13, %r12
- # adjust the shuffle mask pointer to be able to shift 16-r13 bytes
- # (%r13 is the number of bytes in plaintext mod 16)
- movdqu (%r12), %xmm2 # get the appropriate shuffle mask
- PSHUFB_XMM %xmm2, %xmm1 # shift right 16-r13 byte
pxor %xmm1, %xmm0 # Plaintext XOR Encrypt(K, Yn)
- movdqu ALL_F-SHIFT_MASK(%r12), %xmm1
+ movdqu (%r12), %xmm1
# get the appropriate mask to mask out top 16-r13 bytes of xmm0
pand %xmm1, %xmm0 # mask out top 16-r13 bytes of xmm0
movdqa SHUF_MASK(%rip), %xmm10
@@ -1785,9 +1791,6 @@ _zero_cipher_left_encrypt:
pxor %xmm0, %xmm8
GHASH_MUL %xmm8, %xmm13, %xmm9, %xmm10, %xmm11, %xmm5, %xmm6
# GHASH computation for the last <16 byte block
- sub %r13, %r11
- add $16, %r11
-
movdqa SHUF_MASK(%rip), %xmm10
PSHUFB_XMM %xmm10, %xmm0
Patches currently in stable-queue which might be from junaids(a)google.com are
queue-4.15/crypto-aesni-fix-out-of-bounds-access-of-the-data-buffer-in-generic-gcm-aesni.patch
queue-4.15/crypto-aesni-fix-out-of-bounds-access-of-the-aad-buffer-in-generic-gcm-aesni.patch
This is a note to let you know that I've just added the patch titled
crypto: aesni - Fix out-of-bounds access of the AAD buffer in generic-gcm-aesni
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:
crypto-aesni-fix-out-of-bounds-access-of-the-aad-buffer-in-generic-gcm-aesni.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 1ecdd37e308ca149dc378cce225068cbac54e3a6 Mon Sep 17 00:00:00 2001
From: Junaid Shahid <junaids(a)google.com>
Date: Wed, 20 Dec 2017 17:08:38 -0800
Subject: crypto: aesni - Fix out-of-bounds access of the AAD buffer in generic-gcm-aesni
From: Junaid Shahid <junaids(a)google.com>
commit 1ecdd37e308ca149dc378cce225068cbac54e3a6 upstream.
The aesni_gcm_enc/dec functions can access memory after the end of
the AAD buffer if the AAD length is not a multiple of 4 bytes.
It didn't matter with rfc4106-gcm-aesni as in that case the AAD was
always followed by the 8 byte IV, but that is no longer the case with
generic-gcm-aesni. This can potentially result in accessing a page that
is not mapped and thus causing the machine to crash. This patch fixes
that by reading the last <16 byte block of the AAD byte-by-byte and
optionally via an 8-byte load if the block was at least 8 bytes.
Fixes: 0487ccac ("crypto: aesni - make non-AVX AES-GCM work with any aadlen")
Signed-off-by: Junaid Shahid <junaids(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/aesni-intel_asm.S | 112 ++++----------------------------------
1 file changed, 12 insertions(+), 100 deletions(-)
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -90,30 +90,6 @@ SHIFT_MASK: .octa 0x0f0e0d0c0b0a09080706
ALL_F: .octa 0xffffffffffffffffffffffffffffffff
.octa 0x00000000000000000000000000000000
-.section .rodata
-.align 16
-.type aad_shift_arr, @object
-.size aad_shift_arr, 272
-aad_shift_arr:
- .octa 0xffffffffffffffffffffffffffffffff
- .octa 0xffffffffffffffffffffffffffffff0C
- .octa 0xffffffffffffffffffffffffffff0D0C
- .octa 0xffffffffffffffffffffffffff0E0D0C
- .octa 0xffffffffffffffffffffffff0F0E0D0C
- .octa 0xffffffffffffffffffffff0C0B0A0908
- .octa 0xffffffffffffffffffff0D0C0B0A0908
- .octa 0xffffffffffffffffff0E0D0C0B0A0908
- .octa 0xffffffffffffffff0F0E0D0C0B0A0908
- .octa 0xffffffffffffff0C0B0A090807060504
- .octa 0xffffffffffff0D0C0B0A090807060504
- .octa 0xffffffffff0E0D0C0B0A090807060504
- .octa 0xffffffff0F0E0D0C0B0A090807060504
- .octa 0xffffff0C0B0A09080706050403020100
- .octa 0xffff0D0C0B0A09080706050403020100
- .octa 0xff0E0D0C0B0A09080706050403020100
- .octa 0x0F0E0D0C0B0A09080706050403020100
-
-
.text
@@ -304,62 +280,30 @@ _done_read_partial_block_\@:
XMM2 XMM3 XMM4 XMMDst TMP6 TMP7 i i_seq operation
MOVADQ SHUF_MASK(%rip), %xmm14
mov arg7, %r10 # %r10 = AAD
- mov arg8, %r12 # %r12 = aadLen
- mov %r12, %r11
+ mov arg8, %r11 # %r11 = aadLen
pxor %xmm\i, %xmm\i
pxor \XMM2, \XMM2
cmp $16, %r11
- jl _get_AAD_rest8\num_initial_blocks\operation
+ jl _get_AAD_rest\num_initial_blocks\operation
_get_AAD_blocks\num_initial_blocks\operation:
movdqu (%r10), %xmm\i
PSHUFB_XMM %xmm14, %xmm\i # byte-reflect the AAD data
pxor %xmm\i, \XMM2
GHASH_MUL \XMM2, \TMP3, \TMP1, \TMP2, \TMP4, \TMP5, \XMM1
add $16, %r10
- sub $16, %r12
sub $16, %r11
cmp $16, %r11
jge _get_AAD_blocks\num_initial_blocks\operation
movdqu \XMM2, %xmm\i
+
+ /* read the last <16B of AAD */
+_get_AAD_rest\num_initial_blocks\operation:
cmp $0, %r11
je _get_AAD_done\num_initial_blocks\operation
- pxor %xmm\i,%xmm\i
-
- /* read the last <16B of AAD. since we have at least 4B of
- data right after the AAD (the ICV, and maybe some CT), we can
- read 4B/8B blocks safely, and then get rid of the extra stuff */
-_get_AAD_rest8\num_initial_blocks\operation:
- cmp $4, %r11
- jle _get_AAD_rest4\num_initial_blocks\operation
- movq (%r10), \TMP1
- add $8, %r10
- sub $8, %r11
- pslldq $8, \TMP1
- psrldq $8, %xmm\i
- pxor \TMP1, %xmm\i
- jmp _get_AAD_rest8\num_initial_blocks\operation
-_get_AAD_rest4\num_initial_blocks\operation:
- cmp $0, %r11
- jle _get_AAD_rest0\num_initial_blocks\operation
- mov (%r10), %eax
- movq %rax, \TMP1
- add $4, %r10
- sub $4, %r10
- pslldq $12, \TMP1
- psrldq $4, %xmm\i
- pxor \TMP1, %xmm\i
-_get_AAD_rest0\num_initial_blocks\operation:
- /* finalize: shift out the extra bytes we read, and align
- left. since pslldq can only shift by an immediate, we use
- vpshufb and an array of shuffle masks */
- movq %r12, %r11
- salq $4, %r11
- movdqu aad_shift_arr(%r11), \TMP1
- PSHUFB_XMM \TMP1, %xmm\i
-_get_AAD_rest_final\num_initial_blocks\operation:
+ READ_PARTIAL_BLOCK %r10, %r11, \TMP1, %xmm\i
PSHUFB_XMM %xmm14, %xmm\i # byte-reflect the AAD data
pxor \XMM2, %xmm\i
GHASH_MUL %xmm\i, \TMP3, \TMP1, \TMP2, \TMP4, \TMP5, \XMM1
@@ -563,62 +507,30 @@ _initial_blocks_done\num_initial_blocks\
XMM2 XMM3 XMM4 XMMDst TMP6 TMP7 i i_seq operation
MOVADQ SHUF_MASK(%rip), %xmm14
mov arg7, %r10 # %r10 = AAD
- mov arg8, %r12 # %r12 = aadLen
- mov %r12, %r11
+ mov arg8, %r11 # %r11 = aadLen
pxor %xmm\i, %xmm\i
pxor \XMM2, \XMM2
cmp $16, %r11
- jl _get_AAD_rest8\num_initial_blocks\operation
+ jl _get_AAD_rest\num_initial_blocks\operation
_get_AAD_blocks\num_initial_blocks\operation:
movdqu (%r10), %xmm\i
PSHUFB_XMM %xmm14, %xmm\i # byte-reflect the AAD data
pxor %xmm\i, \XMM2
GHASH_MUL \XMM2, \TMP3, \TMP1, \TMP2, \TMP4, \TMP5, \XMM1
add $16, %r10
- sub $16, %r12
sub $16, %r11
cmp $16, %r11
jge _get_AAD_blocks\num_initial_blocks\operation
movdqu \XMM2, %xmm\i
+
+ /* read the last <16B of AAD */
+_get_AAD_rest\num_initial_blocks\operation:
cmp $0, %r11
je _get_AAD_done\num_initial_blocks\operation
- pxor %xmm\i,%xmm\i
-
- /* read the last <16B of AAD. since we have at least 4B of
- data right after the AAD (the ICV, and maybe some PT), we can
- read 4B/8B blocks safely, and then get rid of the extra stuff */
-_get_AAD_rest8\num_initial_blocks\operation:
- cmp $4, %r11
- jle _get_AAD_rest4\num_initial_blocks\operation
- movq (%r10), \TMP1
- add $8, %r10
- sub $8, %r11
- pslldq $8, \TMP1
- psrldq $8, %xmm\i
- pxor \TMP1, %xmm\i
- jmp _get_AAD_rest8\num_initial_blocks\operation
-_get_AAD_rest4\num_initial_blocks\operation:
- cmp $0, %r11
- jle _get_AAD_rest0\num_initial_blocks\operation
- mov (%r10), %eax
- movq %rax, \TMP1
- add $4, %r10
- sub $4, %r10
- pslldq $12, \TMP1
- psrldq $4, %xmm\i
- pxor \TMP1, %xmm\i
-_get_AAD_rest0\num_initial_blocks\operation:
- /* finalize: shift out the extra bytes we read, and align
- left. since pslldq can only shift by an immediate, we use
- vpshufb and an array of shuffle masks */
- movq %r12, %r11
- salq $4, %r11
- movdqu aad_shift_arr(%r11), \TMP1
- PSHUFB_XMM \TMP1, %xmm\i
-_get_AAD_rest_final\num_initial_blocks\operation:
+ READ_PARTIAL_BLOCK %r10, %r11, \TMP1, %xmm\i
PSHUFB_XMM %xmm14, %xmm\i # byte-reflect the AAD data
pxor \XMM2, %xmm\i
GHASH_MUL %xmm\i, \TMP3, \TMP1, \TMP2, \TMP4, \TMP5, \XMM1
Patches currently in stable-queue which might be from junaids(a)google.com are
queue-4.15/crypto-aesni-fix-out-of-bounds-access-of-the-data-buffer-in-generic-gcm-aesni.patch
queue-4.15/crypto-aesni-fix-out-of-bounds-access-of-the-aad-buffer-in-generic-gcm-aesni.patch
This is a note to let you know that I've just added the patch titled
ALSA: hda - Reduce the suspend time consumption for ALC256
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:
alsa-hda-reduce-the-suspend-time-consumption-for-alc256.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 1c9609e3a8cf5997bd35205cfda1ff2218ee793b Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Fri, 19 Jan 2018 14:18:34 +0100
Subject: ALSA: hda - Reduce the suspend time consumption for ALC256
From: Takashi Iwai <tiwai(a)suse.de>
commit 1c9609e3a8cf5997bd35205cfda1ff2218ee793b upstream.
ALC256 has its own quirk to override the shutup call, and it contains
the COEF update for pulling down the headset jack control. Currently,
the COEF update is called after clearing the headphone pin, and this
seems triggering a stall of the codec communication, and results in a
long delay over a second at suspend.
A quick resolution is to swap the calls: at first with the COEF
update, then clear the headphone pin.
Fixes: 4a219ef8f370 ("ALSA: hda/realtek - Add ALC256 HP depop function")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198503
Reported-by: Paul Menzel <pmenzel(a)molgen.mpg.de>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -3154,11 +3154,13 @@ static void alc256_shutup(struct hda_cod
if (hp_pin_sense)
msleep(85);
+ /* 3k pull low control for Headset jack. */
+ /* NOTE: call this before clearing the pin, otherwise codec stalls */
+ alc_update_coef_idx(codec, 0x46, 0, 3 << 12);
+
snd_hda_codec_write(codec, hp_pin, 0,
AC_VERB_SET_PIN_WIDGET_CONTROL, 0x0);
- alc_update_coef_idx(codec, 0x46, 0, 3 << 12); /* 3k pull low control for Headset jack. */
-
if (hp_pin_sense)
msleep(100);
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.15/alsa-hda-reduce-the-suspend-time-consumption-for-alc256.patch
This is a note to let you know that I've just added the patch titled
net/mlx5: Define interface bits for fencing UMR wqe
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-mlx5-define-interface-bits-for-fencing-umr-wqe.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 1410a90ae449061b7e1ae19d275148f36948801b Mon Sep 17 00:00:00 2001
From: Max Gurtovoy <maxg(a)mellanox.com>
Date: Sun, 28 May 2017 10:53:10 +0300
Subject: net/mlx5: Define interface bits for fencing UMR wqe
From: Max Gurtovoy <maxg(a)mellanox.com>
commit 1410a90ae449061b7e1ae19d275148f36948801b upstream.
HW can implement UMR wqe re-transmission in various ways.
Thus, add HCA cap to distinguish the needed fence for UMR to make
sure that the wqe wouldn't fail on mkey checks.
Signed-off-by: Max Gurtovoy <maxg(a)mellanox.com>
Acked-by: Leon Romanovsky <leon(a)kernel.org>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Cc: Marta Rybczynska <mrybczyn(a)kalray.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/mlx5/mlx5_ifc.h | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -737,6 +737,12 @@ enum {
MLX5_CAP_PORT_TYPE_ETH = 0x1,
};
+enum {
+ MLX5_CAP_UMR_FENCE_STRONG = 0x0,
+ MLX5_CAP_UMR_FENCE_SMALL = 0x1,
+ MLX5_CAP_UMR_FENCE_NONE = 0x2,
+};
+
struct mlx5_ifc_cmd_hca_cap_bits {
u8 reserved_at_0[0x80];
@@ -838,7 +844,9 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 striding_rq[0x1];
u8 reserved_at_201[0x2];
u8 ipoib_basic_offloads[0x1];
- u8 reserved_at_205[0xa];
+ u8 reserved_at_205[0x5];
+ u8 umr_fence[0x2];
+ u8 reserved_at_20c[0x3];
u8 drain_sigerr[0x1];
u8 cmdif_checksum[0x2];
u8 sigerr_cqe[0x1];
Patches currently in stable-queue which might be from maxg(a)mellanox.com are
queue-4.9/net-mlx5-define-interface-bits-for-fencing-umr-wqe.patch
queue-4.9/rdma-mlx5-set-umr-wqe-fence-according-to-hca-cap.patch
This is a note to let you know that I've just added the patch titled
x86/pti: Make unpoison of pgd for trusted boot work for real
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:
x86-pti-make-unpoison-of-pgd-for-trusted-boot-work-for-real.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 445b69e3b75e42362a5bdc13c8b8f61599e2228a Mon Sep 17 00:00:00 2001
From: Dave Hansen <dave.hansen(a)linux.intel.com>
Date: Wed, 10 Jan 2018 14:49:39 -0800
Subject: x86/pti: Make unpoison of pgd for trusted boot work for real
From: Dave Hansen <dave.hansen(a)linux.intel.com>
commit 445b69e3b75e42362a5bdc13c8b8f61599e2228a upstream.
The inital fix for trusted boot and PTI potentially misses the pgd clearing
if pud_alloc() sets a PGD. It probably works in *practice* because for two
adjacent calls to map_tboot_page() that share a PGD entry, the first will
clear NX, *then* allocate and set the PGD (without NX clear). The second
call will *not* allocate but will clear the NX bit.
Defer the NX clearing to a point after it is known that all top-level
allocations have occurred. Add a comment to clarify why.
[ tglx: Massaged changelog ]
[hughd notes: I have not tested tboot, but this looks to me as necessary
and as safe in old-Kaiser backports as it is upstream; I'm not submitting
the commit-to-be-fixed 262b6b30087, since it was undone by 445b69e3b75e,
and makes conflict trouble because of 5-level's p4d versus 4-level's pgd.]
Fixes: 262b6b30087 ("x86/tboot: Unbreak tboot with PTI enabled")
Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Jon Masters <jcm(a)redhat.com>
Cc: "Tim Chen" <tim.c.chen(a)linux.intel.com>
Cc: gnomes(a)lxorguk.ukuu.org.uk
Cc: peterz(a)infradead.org
Cc: ning.sun(a)intel.com
Cc: tboot-devel(a)lists.sourceforge.net
Cc: andi(a)firstfloor.org
Cc: luto(a)kernel.org
Cc: law(a)redhat.com
Cc: pbonzini(a)redhat.com
Cc: torvalds(a)linux-foundation.org
Cc: gregkh(a)linux-foundation.org
Cc: dwmw(a)amazon.co.uk
Cc: nickc(a)redhat.com
Cc: stable(a)vger.kernel.org
Link: https://lkml.kernel.org/r/20180110224939.2695CD47@viggo.jf.intel.com
Signed-off-by: Hugh Dickins <hughd(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/tboot.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -140,6 +140,16 @@ static int map_tboot_page(unsigned long
return -1;
set_pte_at(&tboot_mm, vaddr, pte, pfn_pte(pfn, prot));
pte_unmap(pte);
+
+ /*
+ * PTI poisons low addresses in the kernel page tables in the
+ * name of making them unusable for userspace. To execute
+ * code at such a low address, the poison must be cleared.
+ *
+ * Note: 'pgd' actually gets set in pud_alloc().
+ */
+ pgd->pgd &= ~_PAGE_NX;
+
return 0;
}
Patches currently in stable-queue which might be from dave.hansen(a)linux.intel.com are
queue-4.4/x86-pti-make-unpoison-of-pgd-for-trusted-boot-work-for-real.patch
This is a note to let you know that I've just added the patch titled
ALSA: seq: Make ioctls race-free
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:
alsa-seq-make-ioctls-race-free.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 b3defb791b26ea0683a93a4f49c77ec45ec96f10 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Tue, 9 Jan 2018 23:11:03 +0100
Subject: ALSA: seq: Make ioctls race-free
From: Takashi Iwai <tiwai(a)suse.de>
commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream.
The ALSA sequencer ioctls have no protection against racy calls while
the concurrent operations may lead to interfere with each other. As
reported recently, for example, the concurrent calls of setting client
pool with a combination of write calls may lead to either the
unkillable dead-lock or UAF.
As a slightly big hammer solution, this patch introduces the mutex to
make each ioctl exclusive. Although this may reduce performance via
parallel ioctl calls, usually it's not demanded for sequencer usages,
hence it should be negligible.
Reported-by: Luo Quan <a4651386(a)163.com>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
[bwh: Backported to 4.4: ioctl dispatch is done from snd_seq_do_ioctl();
take the mutex and add ret variable there.]
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/seq/seq_clientmgr.c | 10 ++++++++--
sound/core/seq/seq_clientmgr.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -236,6 +236,7 @@ static struct snd_seq_client *seq_create
rwlock_init(&client->ports_lock);
mutex_init(&client->ports_mutex);
INIT_LIST_HEAD(&client->ports_list_head);
+ mutex_init(&client->ioctl_mutex);
/* find free slot in the client table */
spin_lock_irqsave(&clients_lock, flags);
@@ -2195,6 +2196,7 @@ static int snd_seq_do_ioctl(struct snd_s
void __user *arg)
{
struct seq_ioctl_table *p;
+ int ret;
switch (cmd) {
case SNDRV_SEQ_IOCTL_PVERSION:
@@ -2208,8 +2210,12 @@ static int snd_seq_do_ioctl(struct snd_s
if (! arg)
return -EFAULT;
for (p = ioctl_tables; p->cmd; p++) {
- if (p->cmd == cmd)
- return p->func(client, arg);
+ if (p->cmd == cmd) {
+ mutex_lock(&client->ioctl_mutex);
+ ret = p->func(client, arg);
+ mutex_unlock(&client->ioctl_mutex);
+ return ret;
+ }
}
pr_debug("ALSA: seq unknown ioctl() 0x%x (type='%c', number=0x%02x)\n",
cmd, _IOC_TYPE(cmd), _IOC_NR(cmd));
--- a/sound/core/seq/seq_clientmgr.h
+++ b/sound/core/seq/seq_clientmgr.h
@@ -59,6 +59,7 @@ struct snd_seq_client {
struct list_head ports_list_head;
rwlock_t ports_lock;
struct mutex ports_mutex;
+ struct mutex ioctl_mutex;
int convert32; /* convert 32->64bit */
/* output pool */
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.4/alsa-seq-make-ioctls-race-free.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: Fix CPUID function for word 6 (80000001_ECX)
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:
kvm-x86-fix-cpuid-function-for-word-6-80000001_ecx.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 50a671d4d15b859f447fa527191073019b6ce9cb Mon Sep 17 00:00:00 2001
From: Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
Date: Mon, 6 Nov 2017 11:44:23 -0600
Subject: KVM: x86: Fix CPUID function for word 6 (80000001_ECX)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
commit 50a671d4d15b859f447fa527191073019b6ce9cb upstream.
The function for CPUID 80000001 ECX is set to 0xc0000001. Set it to
0x80000001.
Signed-off-by: Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
Reviewed-by: Jim Mattson <jmattson(a)google.com>
Reviewed-by: Krish Sadhukhan <krish.sadhukhan(a)oracle.com>
Reviewed-by: Borislav Petkov <bp(a)suse.de>
Fixes: d6321d493319 ("KVM: x86: generalize guest_cpuid_has_ helpers")
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/cpuid.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kvm/cpuid.h
+++ b/arch/x86/kvm/cpuid.h
@@ -44,7 +44,7 @@ static const struct cpuid_reg reverse_cp
[CPUID_8086_0001_EDX] = {0x80860001, 0, CPUID_EDX},
[CPUID_1_ECX] = { 1, 0, CPUID_ECX},
[CPUID_C000_0001_EDX] = {0xc0000001, 0, CPUID_EDX},
- [CPUID_8000_0001_ECX] = {0xc0000001, 0, CPUID_ECX},
+ [CPUID_8000_0001_ECX] = {0x80000001, 0, CPUID_ECX},
[CPUID_7_0_EBX] = { 7, 0, CPUID_EBX},
[CPUID_D_1_EAX] = { 0xd, 1, CPUID_EAX},
[CPUID_F_0_EDX] = { 0xf, 0, CPUID_EDX},
Patches currently in stable-queue which might be from Janakarajan.Natarajan(a)amd.com are
queue-4.14/kvm-x86-fix-cpuid-function-for-word-6-80000001_ecx.patch
This is a note to let you know that I've just added the patch titled
ALSA: seq: Make ioctls race-free
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:
alsa-seq-make-ioctls-race-free.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 b3defb791b26ea0683a93a4f49c77ec45ec96f10 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Tue, 9 Jan 2018 23:11:03 +0100
Subject: ALSA: seq: Make ioctls race-free
From: Takashi Iwai <tiwai(a)suse.de>
commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream.
The ALSA sequencer ioctls have no protection against racy calls while
the concurrent operations may lead to interfere with each other. As
reported recently, for example, the concurrent calls of setting client
pool with a combination of write calls may lead to either the
unkillable dead-lock or UAF.
As a slightly big hammer solution, this patch introduces the mutex to
make each ioctl exclusive. Although this may reduce performance via
parallel ioctl calls, usually it's not demanded for sequencer usages,
hence it should be negligible.
Reported-by: Luo Quan <a4651386(a)163.com>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
[bwh: Backported to 4.4: ioctl dispatch is done from snd_seq_do_ioctl();
take the mutex and add ret variable there.]
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/seq/seq_clientmgr.c | 10 ++++++++--
sound/core/seq/seq_clientmgr.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -236,6 +236,7 @@ static struct snd_seq_client *seq_create
rwlock_init(&client->ports_lock);
mutex_init(&client->ports_mutex);
INIT_LIST_HEAD(&client->ports_list_head);
+ mutex_init(&client->ioctl_mutex);
/* find free slot in the client table */
spin_lock_irqsave(&clients_lock, flags);
@@ -2200,6 +2201,7 @@ static int snd_seq_do_ioctl(struct snd_s
void __user *arg)
{
struct seq_ioctl_table *p;
+ int ret;
switch (cmd) {
case SNDRV_SEQ_IOCTL_PVERSION:
@@ -2213,8 +2215,12 @@ static int snd_seq_do_ioctl(struct snd_s
if (! arg)
return -EFAULT;
for (p = ioctl_tables; p->cmd; p++) {
- if (p->cmd == cmd)
- return p->func(client, arg);
+ if (p->cmd == cmd) {
+ mutex_lock(&client->ioctl_mutex);
+ ret = p->func(client, arg);
+ mutex_unlock(&client->ioctl_mutex);
+ return ret;
+ }
}
pr_debug("ALSA: seq unknown ioctl() 0x%x (type='%c', number=0x%02x)\n",
cmd, _IOC_TYPE(cmd), _IOC_NR(cmd));
--- a/sound/core/seq/seq_clientmgr.h
+++ b/sound/core/seq/seq_clientmgr.h
@@ -59,6 +59,7 @@ struct snd_seq_client {
struct list_head ports_list_head;
rwlock_t ports_lock;
struct mutex ports_mutex;
+ struct mutex ioctl_mutex;
int convert32; /* convert 32->64bit */
/* output pool */
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-3.18/alsa-seq-make-ioctls-race-free.patch
commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream.
The ALSA sequencer ioctls have no protection against racy calls while
the concurrent operations may lead to interfere with each other. As
reported recently, for example, the concurrent calls of setting client
pool with a combination of write calls may lead to either the
unkillable dead-lock or UAF.
As a slightly big hammer solution, this patch introduces the mutex to
make each ioctl exclusive. Although this may reduce performance via
parallel ioctl calls, usually it's not demanded for sequencer usages,
hence it should be negligible.
Reported-by: Luo Quan <a4651386(a)163.com>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
[bwh: Backported to 4.4: ioctl dispatch is done from snd_seq_do_ioctl();
take the mutex and add ret variable there.]
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
---
sound/core/seq/seq_clientmgr.c | 10 ++++++++--
sound/core/seq/seq_clientmgr.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
index b36de76f24e2..7bb9fe7a2c8e 100644
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -236,6 +236,7 @@ static struct snd_seq_client *seq_create_client1(int client_index, int poolsize)
rwlock_init(&client->ports_lock);
mutex_init(&client->ports_mutex);
INIT_LIST_HEAD(&client->ports_list_head);
+ mutex_init(&client->ioctl_mutex);
/* find free slot in the client table */
spin_lock_irqsave(&clients_lock, flags);
@@ -2195,6 +2196,7 @@ static int snd_seq_do_ioctl(struct snd_seq_client *client, unsigned int cmd,
void __user *arg)
{
struct seq_ioctl_table *p;
+ int ret;
switch (cmd) {
case SNDRV_SEQ_IOCTL_PVERSION:
@@ -2208,8 +2210,12 @@ static int snd_seq_do_ioctl(struct snd_seq_client *client, unsigned int cmd,
if (! arg)
return -EFAULT;
for (p = ioctl_tables; p->cmd; p++) {
- if (p->cmd == cmd)
- return p->func(client, arg);
+ if (p->cmd == cmd) {
+ mutex_lock(&client->ioctl_mutex);
+ ret = p->func(client, arg);
+ mutex_unlock(&client->ioctl_mutex);
+ return ret;
+ }
}
pr_debug("ALSA: seq unknown ioctl() 0x%x (type='%c', number=0x%02x)\n",
cmd, _IOC_TYPE(cmd), _IOC_NR(cmd));
diff --git a/sound/core/seq/seq_clientmgr.h b/sound/core/seq/seq_clientmgr.h
index 20f0a725ec7d..91f8f165bfdc 100644
--- a/sound/core/seq/seq_clientmgr.h
+++ b/sound/core/seq/seq_clientmgr.h
@@ -59,6 +59,7 @@ struct snd_seq_client {
struct list_head ports_list_head;
rwlock_t ports_lock;
struct mutex ports_mutex;
+ struct mutex ioctl_mutex;
int convert32; /* convert 32->64bit */
/* output pool */
--
2.15.0.rc0
From: Alexei Starovoitov <ast(a)fb.com>
commit c131187db2d3fa2f8bf32fdf4e9a4ef805168467 upstream.
when the verifier detects that register contains a runtime constant
and it's compared with another constant it will prune exploration
of the branch that is guaranteed not to be taken at runtime.
This is all correct, but malicious program may be constructed
in such a way that it always has a constant comparison and
the other branch is never taken under any conditions.
In this case such path through the program will not be explored
by the verifier. It won't be taken at run-time either, but since
all instructions are JITed the malicious program may cause JITs
to complain about using reserved fields, etc.
To fix the issue we have to track the instructions explored by
the verifier and sanitize instructions that are dead at run time
with NOPs. We cannot reject such dead code, since llvm generates
it for valid C code, since it doesn't do as much data flow
analysis as the verifier does.
Fixes: 17a5267067f3 ("bpf: verifier (add verifier core)")
Signed-off-by: Alexei Starovoitov <ast(a)kernel.org>
Acked-by: Daniel Borkmann <daniel(a)iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
[bwh: Backported to 4.4:
- s/bpf_verifier_env/verifier_env/
- Adjust context]
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
---
v2: Restore Alexei as author
kernel/bpf/verifier.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 014c2d759916..a62679711de0 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -191,6 +191,7 @@ struct bpf_insn_aux_data {
enum bpf_reg_type ptr_type; /* pointer type for load/store insns */
struct bpf_map *map_ptr; /* pointer for call insn into lookup_elem */
};
+ bool seen; /* this insn was processed by the verifier */
};
#define MAX_USED_MAPS 64 /* max number of maps accessed by one eBPF program */
@@ -1793,6 +1794,7 @@ static int do_check(struct verifier_env *env)
print_bpf_insn(env, insn);
}
+ env->insn_aux_data[insn_idx].seen = true;
if (class == BPF_ALU || class == BPF_ALU64) {
err = check_alu_op(env, insn);
if (err)
@@ -1988,6 +1990,7 @@ process_bpf_exit:
return err;
insn_idx++;
+ env->insn_aux_data[insn_idx].seen = true;
} else {
verbose("invalid BPF_LD mode\n");
return -EINVAL;
@@ -2125,6 +2128,7 @@ static int adjust_insn_aux_data(struct verifier_env *env, u32 prog_len,
u32 off, u32 cnt)
{
struct bpf_insn_aux_data *new_data, *old_data = env->insn_aux_data;
+ int i;
if (cnt == 1)
return 0;
@@ -2134,6 +2138,8 @@ static int adjust_insn_aux_data(struct verifier_env *env, u32 prog_len,
memcpy(new_data, old_data, sizeof(struct bpf_insn_aux_data) * off);
memcpy(new_data + off + cnt - 1, old_data + off,
sizeof(struct bpf_insn_aux_data) * (prog_len - off - cnt + 1));
+ for (i = off; i < off + cnt - 1; i++)
+ new_data[i].seen = true;
env->insn_aux_data = new_data;
vfree(old_data);
return 0;
@@ -2152,6 +2158,25 @@ static struct bpf_prog *bpf_patch_insn_data(struct verifier_env *env, u32 off,
return new_prog;
}
+/* The verifier does more data flow analysis than llvm and will not explore
+ * branches that are dead at run time. Malicious programs can have dead code
+ * too. Therefore replace all dead at-run-time code with nops.
+ */
+static void sanitize_dead_code(struct verifier_env *env)
+{
+ struct bpf_insn_aux_data *aux_data = env->insn_aux_data;
+ struct bpf_insn nop = BPF_MOV64_REG(BPF_REG_0, BPF_REG_0);
+ struct bpf_insn *insn = env->prog->insnsi;
+ const int insn_cnt = env->prog->len;
+ int i;
+
+ for (i = 0; i < insn_cnt; i++) {
+ if (aux_data[i].seen)
+ continue;
+ memcpy(insn + i, &nop, sizeof(nop));
+ }
+}
+
/* convert load instructions that access fields of 'struct __sk_buff'
* into sequence of instructions that access fields of 'struct sk_buff'
*/
@@ -2370,6 +2395,9 @@ skip_full_check:
while (pop_stack(env, NULL) >= 0);
free_states(env);
+ if (ret == 0)
+ sanitize_dead_code(env);
+
if (ret == 0)
/* program is valid, convert *(u32*)(ctx + off) accesses */
ret = convert_ctx_accesses(env);
--
2.15.0.rc0
commit c131187db2d3fa2f8bf32fdf4e9a4ef805168467 upstream.
when the verifier detects that register contains a runtime constant
and it's compared with another constant it will prune exploration
of the branch that is guaranteed not to be taken at runtime.
This is all correct, but malicious program may be constructed
in such a way that it always has a constant comparison and
the other branch is never taken under any conditions.
In this case such path through the program will not be explored
by the verifier. It won't be taken at run-time either, but since
all instructions are JITed the malicious program may cause JITs
to complain about using reserved fields, etc.
To fix the issue we have to track the instructions explored by
the verifier and sanitize instructions that are dead at run time
with NOPs. We cannot reject such dead code, since llvm generates
it for valid C code, since it doesn't do as much data flow
analysis as the verifier does.
Fixes: 17a5267067f3 ("bpf: verifier (add verifier core)")
Signed-off-by: Alexei Starovoitov <ast(a)kernel.org>
Acked-by: Daniel Borkmann <daniel(a)iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
[bwh: Backported to 4.4:
- s/bpf_verifier_env/verifier_env/
- Adjust context]
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
---
kernel/bpf/verifier.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 014c2d759916..a62679711de0 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -191,6 +191,7 @@ struct bpf_insn_aux_data {
enum bpf_reg_type ptr_type; /* pointer type for load/store insns */
struct bpf_map *map_ptr; /* pointer for call insn into lookup_elem */
};
+ bool seen; /* this insn was processed by the verifier */
};
#define MAX_USED_MAPS 64 /* max number of maps accessed by one eBPF program */
@@ -1793,6 +1794,7 @@ static int do_check(struct verifier_env *env)
print_bpf_insn(env, insn);
}
+ env->insn_aux_data[insn_idx].seen = true;
if (class == BPF_ALU || class == BPF_ALU64) {
err = check_alu_op(env, insn);
if (err)
@@ -1988,6 +1990,7 @@ process_bpf_exit:
return err;
insn_idx++;
+ env->insn_aux_data[insn_idx].seen = true;
} else {
verbose("invalid BPF_LD mode\n");
return -EINVAL;
@@ -2125,6 +2128,7 @@ static int adjust_insn_aux_data(struct verifier_env *env, u32 prog_len,
u32 off, u32 cnt)
{
struct bpf_insn_aux_data *new_data, *old_data = env->insn_aux_data;
+ int i;
if (cnt == 1)
return 0;
@@ -2134,6 +2138,8 @@ static int adjust_insn_aux_data(struct verifier_env *env, u32 prog_len,
memcpy(new_data, old_data, sizeof(struct bpf_insn_aux_data) * off);
memcpy(new_data + off + cnt - 1, old_data + off,
sizeof(struct bpf_insn_aux_data) * (prog_len - off - cnt + 1));
+ for (i = off; i < off + cnt - 1; i++)
+ new_data[i].seen = true;
env->insn_aux_data = new_data;
vfree(old_data);
return 0;
@@ -2152,6 +2158,25 @@ static struct bpf_prog *bpf_patch_insn_data(struct verifier_env *env, u32 off,
return new_prog;
}
+/* The verifier does more data flow analysis than llvm and will not explore
+ * branches that are dead at run time. Malicious programs can have dead code
+ * too. Therefore replace all dead at-run-time code with nops.
+ */
+static void sanitize_dead_code(struct verifier_env *env)
+{
+ struct bpf_insn_aux_data *aux_data = env->insn_aux_data;
+ struct bpf_insn nop = BPF_MOV64_REG(BPF_REG_0, BPF_REG_0);
+ struct bpf_insn *insn = env->prog->insnsi;
+ const int insn_cnt = env->prog->len;
+ int i;
+
+ for (i = 0; i < insn_cnt; i++) {
+ if (aux_data[i].seen)
+ continue;
+ memcpy(insn + i, &nop, sizeof(nop));
+ }
+}
+
/* convert load instructions that access fields of 'struct __sk_buff'
* into sequence of instructions that access fields of 'struct sk_buff'
*/
@@ -2370,6 +2395,9 @@ skip_full_check:
while (pop_stack(env, NULL) >= 0);
free_states(env);
+ if (ret == 0)
+ sanitize_dead_code(env);
+
if (ret == 0)
/* program is valid, convert *(u32*)(ctx + off) accesses */
ret = convert_ctx_accesses(env);
--
2.15.0.rc0
From: Dave Hansen <dave.hansen(a)linux.intel.com>
commit 445b69e3b75e42362a5bdc13c8b8f61599e2228a upstream
The inital fix for trusted boot and PTI potentially misses the pgd clearing
if pud_alloc() sets a PGD. It probably works in *practice* because for two
adjacent calls to map_tboot_page() that share a PGD entry, the first will
clear NX, *then* allocate and set the PGD (without NX clear). The second
call will *not* allocate but will clear the NX bit.
Defer the NX clearing to a point after it is known that all top-level
allocations have occurred. Add a comment to clarify why.
[ tglx: Massaged changelog ]
Fixes: 262b6b30087 ("x86/tboot: Unbreak tboot with PTI enabled")
Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Jon Masters <jcm(a)redhat.com>
Cc: Tim Chen <tim.c.chen(a)linux.intel.com>
Cc: gnomes(a)lxorguk.ukuu.org.uk
Cc: peterz(a)infradead.org
Cc: ning.sun(a)intel.com
Cc: tboot-devel(a)lists.sourceforge.net
Cc: andi(a)firstfloor.org
Cc: luto(a)kernel.org
Cc: law(a)redhat.com
Cc: pbonzini(a)redhat.com
Cc: torvalds(a)linux-foundation.org
Cc: gregkh(a)linux-foundation.org
Cc: dwmw(a)amazon.co.uk
Cc: nickc(a)redhat.com
Cc: stable(a)vger.kernel.org
Link: https://lkml.kernel.org/r/20180110224939.2695CD47@viggo.jf.intel.com
Cc: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Hugh Dickins <hughd(a)google.com>
hughd notes: I have not tested tboot, but this looks to me as necessary
and as safe in old-Kaiser backports as it is upstream; I'm not submitting
the commit-to-be-fixed 262b6b30087, since it was undone by 445b69e3b75e,
and makes conflict trouble because of 5-level's p4d versus 4-level's pgd.
---
arch/x86/kernel/tboot.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index 91a4496db434..c77ab1f51fbe 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -140,6 +140,16 @@ static int map_tboot_page(unsigned long vaddr, unsigned long pfn,
return -1;
set_pte_at(&tboot_mm, vaddr, pte, pfn_pte(pfn, prot));
pte_unmap(pte);
+
+ /*
+ * PTI poisons low addresses in the kernel page tables in the
+ * name of making them unusable for userspace. To execute
+ * code at such a low address, the poison must be cleared.
+ *
+ * Note: 'pgd' actually gets set in pud_alloc().
+ */
+ pgd->pgd &= ~_PAGE_NX;
+
return 0;
}
--
2.16.0.rc1.238.g530d649a79-goog
This is a note to let you know that I've just added the patch titled
Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oops
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:
bluetooth-hci_serdev-init-hci_uart-proto_lock-to-avoid-oops.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 d73e172816652772114827abaa2dbc053eecbbd7 Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Fri, 17 Nov 2017 00:54:53 +0100
Subject: Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oops
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Lukas Wunner <lukas(a)wunner.de>
commit d73e172816652772114827abaa2dbc053eecbbd7 upstream.
John Stultz reports a boot time crash with the HiKey board (which uses
hci_serdev) occurring in hci_uart_tx_wakeup(). That function is
contained in hci_ldisc.c, but also called from the newer hci_serdev.c.
It acquires the proto_lock in struct hci_uart and it turns out that we
forgot to init the lock in the serdev code path, thus causing the crash.
John bisected the crash to commit 67d2f8781b9f ("Bluetooth: hci_ldisc:
Allow sleeping while proto locks are held"), but the issue was present
before and the commit merely exposed it. (Perhaps by luck, the crash
did not occur with rwlocks.)
Init the proto_lock in the serdev code path to avoid the oops.
Stack trace for posterity:
Unable to handle kernel read from unreadable memory at 406f127000
[000000406f127000] user address but active_mm is swapper
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Hardware name: HiKey Development Board (DT)
Call trace:
hci_uart_tx_wakeup+0x38/0x148
hci_uart_send_frame+0x28/0x38
hci_send_frame+0x64/0xc0
hci_cmd_work+0x98/0x110
process_one_work+0x134/0x330
worker_thread+0x130/0x468
kthread+0xf8/0x128
ret_from_fork+0x10/0x18
Link: https://lkml.org/lkml/2017/11/15/908
Reported-and-tested-by: John Stultz <john.stultz(a)linaro.org>
Cc: Ronald Tschalär <ronald(a)innovation.ch>
Cc: Rob Herring <rob.herring(a)linaro.org>
Cc: Sumit Semwal <sumit.semwal(a)linaro.org>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/hci_serdev.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/bluetooth/hci_serdev.c
+++ b/drivers/bluetooth/hci_serdev.c
@@ -304,6 +304,7 @@ int hci_uart_register_device(struct hci_
hci_set_drvdata(hdev, hu);
INIT_WORK(&hu->write_work, hci_uart_write_work);
+ percpu_init_rwsem(&hu->proto_lock);
/* Only when vendor specific setup callback is provided, consider
* the manufacturer information valid. This avoids filling in the
Patches currently in stable-queue which might be from lukas(a)wunner.de are
queue-4.14/bluetooth-hci_serdev-init-hci_uart-proto_lock-to-avoid-oops.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oops
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:
bluetooth-hci_serdev-init-hci_uart-proto_lock-to-avoid-oops.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 d73e172816652772114827abaa2dbc053eecbbd7 Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Fri, 17 Nov 2017 00:54:53 +0100
Subject: Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oops
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Lukas Wunner <lukas(a)wunner.de>
commit d73e172816652772114827abaa2dbc053eecbbd7 upstream.
John Stultz reports a boot time crash with the HiKey board (which uses
hci_serdev) occurring in hci_uart_tx_wakeup(). That function is
contained in hci_ldisc.c, but also called from the newer hci_serdev.c.
It acquires the proto_lock in struct hci_uart and it turns out that we
forgot to init the lock in the serdev code path, thus causing the crash.
John bisected the crash to commit 67d2f8781b9f ("Bluetooth: hci_ldisc:
Allow sleeping while proto locks are held"), but the issue was present
before and the commit merely exposed it. (Perhaps by luck, the crash
did not occur with rwlocks.)
Init the proto_lock in the serdev code path to avoid the oops.
Stack trace for posterity:
Unable to handle kernel read from unreadable memory at 406f127000
[000000406f127000] user address but active_mm is swapper
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Hardware name: HiKey Development Board (DT)
Call trace:
hci_uart_tx_wakeup+0x38/0x148
hci_uart_send_frame+0x28/0x38
hci_send_frame+0x64/0xc0
hci_cmd_work+0x98/0x110
process_one_work+0x134/0x330
worker_thread+0x130/0x468
kthread+0xf8/0x128
ret_from_fork+0x10/0x18
Link: https://lkml.org/lkml/2017/11/15/908
Reported-and-tested-by: John Stultz <john.stultz(a)linaro.org>
Cc: Ronald Tschalär <ronald(a)innovation.ch>
Cc: Rob Herring <rob.herring(a)linaro.org>
Cc: Sumit Semwal <sumit.semwal(a)linaro.org>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/hci_serdev.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/bluetooth/hci_serdev.c
+++ b/drivers/bluetooth/hci_serdev.c
@@ -303,6 +303,7 @@ int hci_uart_register_device(struct hci_
hci_set_drvdata(hdev, hu);
INIT_WORK(&hu->write_work, hci_uart_write_work);
+ percpu_init_rwsem(&hu->proto_lock);
/* Only when vendor specific setup callback is provided, consider
* the manufacturer information valid. This avoids filling in the
Patches currently in stable-queue which might be from lukas(a)wunner.de are
queue-4.15/bluetooth-hci_serdev-init-hci_uart-proto_lock-to-avoid-oops.patch
On Thu, Feb 1, 2018 at 2:27 AM, Amir Goldstein <amir73il(a)gmail.com> wrote:
> On Mon, Jan 29, 2018 at 5:50 PM, Darrick J. Wong
> <darrick.wong(a)oracle.com> wrote:
>> On Mon, Jan 29, 2018 at 01:07:36PM +0200, Amir Goldstein wrote:
>>> On Fri, Jan 26, 2018 at 11:44 PM, Darrick J. Wong
>>> <darrick.wong(a)oracle.com> wrote:
>>> > On Fri, Jan 26, 2018 at 09:44:29AM +0200, Amir Goldstein wrote:
>>> >> Commit 66f364649d870 ("xfs: remove if_rdev") moved storing of rdev
>>> >> value for special inodes to VFS inodes, but forgot to preserve the
>>> >> value of i_rdev when recycling a reclaimable xfs_inode.
>>> >>
>>> >> This was detected by xfstest overlay/017 with inodex=on mount option
>>> >> and xfs base fs. The test does a lookup of overlay chardev and blockdev
>>> >> right after drop caches.
>>> >>
>>> >> Overlayfs inodes hold a reference on underlying xfs inodes when mount
>>> >> option index=on is configured. If drop caches reclaim xfs inodes, before
>>> >> it relclaims overlayfs inodes, that can sometimes leave a reclaimable xfs
>>> >> inode and that test hits that case quite often.
>>> >>
>>> >> When that happens, the xfs inode cache remains broken (zere i_rdev)
>>> >> until the next cycle mount or drop caches.
>>> >>
>>> >> Fixes: 66f364649d870 ("xfs: remove if_rdev")
>>> >> Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
>>> >
>>> > Looks ok,
>>> > Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com>
>>> >
>>>
>>> I recon that now we should now also strap:
>>> Cc: <stable(a)vger.kernel.org> #v4.15
>>>
>>> Can I assume, you'll add it on apply?
>>
>> I'll do a proper backport of this and a couple other critical cow
>> fixes after I get the 4.16 stuff merged.
>>
>
> I am not sure what "proper backport" means in the context of
> this patch.
> This is a v4.15-rc1 regression fix that is based on v4.15-rc8.
> It applied cleanly on v4.15.
>
> CC'ing stable for attention.
>
> This patch is now in master, but due to its timing it did not
> get the CC: stable tag.
>
Now really CC stable.
Amir.
From: Michal Hocko <mhocko(a)suse.com>
Subject: mm, memory_hotplug: fix memmap initialization
Bharata has noticed that onlining a newly added memory doesn't increase
the total memory, pointing to f7f99100d8d9 ("mm: stop zeroing memory
during allocation in vmemmap") as a culprit. This commit has changed the
way how the memory for memmaps is initialized and moves it from the
allocation time to the initialization time. This works properly for the
early memmap init path.
It doesn't work for the memory hotplug though because we need to mark page
as reserved when the sparsemem section is created and later initialize it
completely during onlining. memmap_init_zone is called in the early stage
of onlining. With the current code it calls __init_single_page and as
such it clears up the whole stage and therefore online_pages_range skips
those pages.
Fix this by skipping mm_zero_struct_page in __init_single_page for memory
hotplug path. This is quite uggly but unifying both early init and memory
hotplug init paths is a large project. Make sure we plug the regression
at least.
Link: http://lkml.kernel.org/r/20180130101141.GW21609@dhcp22.suse.cz
Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: Bharata B Rao <bharata(a)linux.vnet.ibm.com>
Tested-by: Bharata B Rao <bharata(a)linux.vnet.ibm.com>
Reviewed-by: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Cc: Steven Sistare <steven.sistare(a)oracle.com>
Cc: Daniel Jordan <daniel.m.jordan(a)oracle.com>
Cc: Bob Picco <bob.picco(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_alloc.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff -puN mm/page_alloc.c~mm-memory_hotplug-fix-memmap-initialization mm/page_alloc.c
--- a/mm/page_alloc.c~mm-memory_hotplug-fix-memmap-initialization
+++ a/mm/page_alloc.c
@@ -1177,9 +1177,10 @@ static void free_one_page(struct zone *z
}
static void __meminit __init_single_page(struct page *page, unsigned long pfn,
- unsigned long zone, int nid)
+ unsigned long zone, int nid, bool zero)
{
- mm_zero_struct_page(page);
+ if (zero)
+ mm_zero_struct_page(page);
set_page_links(page, zone, nid, pfn);
init_page_count(page);
page_mapcount_reset(page);
@@ -1194,9 +1195,9 @@ static void __meminit __init_single_page
}
static void __meminit __init_single_pfn(unsigned long pfn, unsigned long zone,
- int nid)
+ int nid, bool zero)
{
- return __init_single_page(pfn_to_page(pfn), pfn, zone, nid);
+ return __init_single_page(pfn_to_page(pfn), pfn, zone, nid, zero);
}
#ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
@@ -1217,7 +1218,7 @@ static void __meminit init_reserved_page
if (pfn >= zone->zone_start_pfn && pfn < zone_end_pfn(zone))
break;
}
- __init_single_pfn(pfn, zid, nid);
+ __init_single_pfn(pfn, zid, nid, true);
}
#else
static inline void init_reserved_page(unsigned long pfn)
@@ -1534,7 +1535,7 @@ static unsigned long __init deferred_in
} else {
page++;
}
- __init_single_page(page, pfn, zid, nid);
+ __init_single_page(page, pfn, zid, nid, true);
nr_pages++;
}
return (nr_pages);
@@ -5399,15 +5400,20 @@ not_early:
* can be created for invalid pages (for alignment)
* check here not to call set_pageblock_migratetype() against
* pfn out of zone.
+ *
+ * Please note that MEMMAP_HOTPLUG path doesn't clear memmap
+ * because this is done early in sparse_add_one_section
*/
if (!(pfn & (pageblock_nr_pages - 1))) {
struct page *page = pfn_to_page(pfn);
- __init_single_page(page, pfn, zone, nid);
+ __init_single_page(page, pfn, zone, nid,
+ context != MEMMAP_HOTPLUG);
set_pageblock_migratetype(page, MIGRATE_MOVABLE);
cond_resched();
} else {
- __init_single_pfn(pfn, zone, nid);
+ __init_single_pfn(pfn, zone, nid,
+ context != MEMMAP_HOTPLUG);
}
}
}
_
From: Gang He <ghe(a)suse.com>
Subject: ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE
If we can't get inode lock immediately in the function
ocfs2_inode_lock_with_page() when reading a page, we should not return
directly here, since this will lead to a softlockup problem when the
kernel is configured with CONFIG_PREEMPT is not set. The method is to get
a blocking lock and immediately unlock before returning, this can avoid
CPU resource waste due to lots of retries, and benefits fairness in
getting lock among multiple nodes, increase efficiency in case modifying
the same file frequently from multiple nodes.
The softlockup crash (when set /proc/sys/kernel/softlockup_panic to 1)
looks like:
Kernel panic - not syncing: softlockup: hung tasks
CPU: 0 PID: 885 Comm: multi_mmap Tainted: G L 4.12.14-6.1-default #1
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Call Trace:
<IRQ>
dump_stack+0x5c/0x82
panic+0xd5/0x21e
watchdog_timer_fn+0x208/0x210
? watchdog_park_threads+0x70/0x70
__hrtimer_run_queues+0xcc/0x200
hrtimer_interrupt+0xa6/0x1f0
smp_apic_timer_interrupt+0x34/0x50
apic_timer_interrupt+0x96/0xa0
</IRQ>
RIP: 0010:unlock_page+0x17/0x30
RSP: 0000:ffffaf154080bc88 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
RAX: dead000000000100 RBX: fffff21e009f5300 RCX: 0000000000000004
RDX: dead0000000000ff RSI: 0000000000000202 RDI: fffff21e009f5300
RBP: 0000000000000000 R08: 0000000000000000 R09: ffffaf154080bb00
R10: ffffaf154080bc30 R11: 0000000000000040 R12: ffff993749a39518
R13: 0000000000000000 R14: fffff21e009f5300 R15: fffff21e009f5300
ocfs2_inode_lock_with_page+0x25/0x30 [ocfs2]
ocfs2_readpage+0x41/0x2d0 [ocfs2]
? pagecache_get_page+0x30/0x200
filemap_fault+0x12b/0x5c0
? recalc_sigpending+0x17/0x50
? __set_task_blocked+0x28/0x70
? __set_current_blocked+0x3d/0x60
ocfs2_fault+0x29/0xb0 [ocfs2]
__do_fault+0x1a/0xa0
__handle_mm_fault+0xbe8/0x1090
handle_mm_fault+0xaa/0x1f0
__do_page_fault+0x235/0x4b0
trace_do_page_fault+0x3c/0x110
async_page_fault+0x28/0x30
RIP: 0033:0x7fa75ded638e
RSP: 002b:00007ffd6657db18 EFLAGS: 00010287
RAX: 000055c7662fb700 RBX: 0000000000000001 RCX: 000055c7662fb700
RDX: 0000000000001770 RSI: 00007fa75e909000 RDI: 000055c7662fb700
RBP: 0000000000000003 R08: 000000000000000e R09: 0000000000000000
R10: 0000000000000483 R11: 00007fa75ded61b0 R12: 00007fa75e90a770
R13: 000000000000000e R14: 0000000000001770 R15: 0000000000000000
About performance improvement, we can see the testing time is reduced, and
CPU utilization decreases, the detailed data is as follows. I ran
multi_mmap test case in ocfs2-test package in a three nodes cluster.
Before applying this patch:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2754 ocfs2te+ 20 0 170248 6980 4856 D 80.73 0.341 0:18.71 multi_mmap
1505 root rt 0 222236 123060 97224 S 2.658 6.015 0:01.44 corosync
5 root 20 0 0 0 0 S 1.329 0.000 0:00.19 kworker/u8:0
95 root 20 0 0 0 0 S 1.329 0.000 0:00.25 kworker/u8:1
2728 root 20 0 0 0 0 S 0.997 0.000 0:00.24 jbd2/sda1-33
2721 root 20 0 0 0 0 S 0.664 0.000 0:00.07 ocfs2dc-3C8CFD4
2750 ocfs2te+ 20 0 142976 4652 3532 S 0.664 0.227 0:00.28 mpirun
ocfs2test@tb-node2:~>multiple_run.sh -i ens3 -k ~/linux-4.4.21-69.tar.gz -o
~/ocfs2mullog -C hacluster -s pcmk -n tb-node2,tb-node1,tb-node3 -d
/dev/sda1 -b 4096 -c 32768 -t multi_mmap /mnt/shared
Tests with "-b 4096 -C 32768"
Thu Dec 28 14:44:52 CST 2017
multi_mmap..................................................Passed.
Runtime 783 seconds.
After apply this patch:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2508 ocfs2te+ 20 0 170248 6804 4680 R 54.00 0.333 0:55.37 multi_mmap
155 root 20 0 0 0 0 S 2.667 0.000 0:01.20 kworker/u8:3
95 root 20 0 0 0 0 S 2.000 0.000 0:01.58 kworker/u8:1
2504 ocfs2te+ 20 0 142976 4604 3480 R 1.667 0.225 0:01.65 mpirun
5 root 20 0 0 0 0 S 1.000 0.000 0:01.36 kworker/u8:0
2482 root 20 0 0 0 0 S 1.000 0.000 0:00.86 jbd2/sda1-33
299 root 0 -20 0 0 0 S 0.333 0.000 0:00.13 kworker/2:1H
335 root 0 -20 0 0 0 S 0.333 0.000 0:00.17 kworker/1:1H
535 root 20 0 12140 7268 1456 S 0.333 0.355 0:00.34 haveged
1282 root rt 0 222284 123108 97224 S 0.333 6.017 0:01.33 corosync
ocfs2test@tb-node2:~>multiple_run.sh -i ens3 -k ~/linux-4.4.21-69.tar.gz -o
~/ocfs2mullog -C hacluster -s pcmk -n tb-node2,tb-node1,tb-node3 -d
/dev/sda1 -b 4096 -c 32768 -t multi_mmap /mnt/shared
Tests with "-b 4096 -C 32768"
Thu Dec 28 15:04:12 CST 2017
multi_mmap..................................................Passed.
Runtime 487 seconds.
Link: http://lkml.kernel.org/r/1514447305-30814-1-git-send-email-ghe@suse.com
Fixes: 1cce4df04f37 ("ocfs2: do not lock/unlock() inode DLM lock")
Signed-off-by: Gang He <ghe(a)suse.com>
Reviewed-by: Eric Ren <zren(a)suse.com>
Acked-by: alex chen <alex.chen(a)huawei.com>
Acked-by: piaojun <piaojun(a)huawei.com>
Cc: Mark Fasheh <mfasheh(a)versity.com>
Cc: Joel Becker <jlbec(a)evilplan.org>
Cc: Junxiao Bi <junxiao.bi(a)oracle.com>
Cc: Joseph Qi <jiangqi903(a)gmail.com>
Cc: Changwei Ge <ge.changwei(a)h3c.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/ocfs2/dlmglue.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff -puN fs/ocfs2/dlmglue.c~ocfs2-try-a-blocking-lock-before-return-aop_truncated_page fs/ocfs2/dlmglue.c
--- a/fs/ocfs2/dlmglue.c~ocfs2-try-a-blocking-lock-before-return-aop_truncated_page
+++ a/fs/ocfs2/dlmglue.c
@@ -2486,6 +2486,15 @@ int ocfs2_inode_lock_with_page(struct in
ret = ocfs2_inode_lock_full(inode, ret_bh, ex, OCFS2_LOCK_NONBLOCK);
if (ret == -EAGAIN) {
unlock_page(page);
+ /*
+ * If we can't get inode lock immediately, we should not return
+ * directly here, since this will lead to a softlockup problem.
+ * The method is to get a blocking lock and immediately unlock
+ * before returning, this can avoid CPU resource waste due to
+ * lots of retries, and benefits fairness in getting lock.
+ */
+ if (ocfs2_inode_lock(inode, ret_bh, ex) == 0)
+ ocfs2_inode_unlock(inode, ex);
ret = AOP_TRUNCATED_PAGE;
}
_
From: Jim Mattson <jmattson(a)google.com>
The potential performance advantages of a vmcs02 pool have never been
realized. To simplify the code, eliminate the pool. Instead, a single
vmcs02 is allocated per VCPU when the VCPU enters VMX operation.
Cc: stable(a)vger.kernel.org # prereq for Spectre mitigation
Signed-off-by: Jim Mattson <jmattson(a)google.com>
Signed-off-by: Mark Kanda <mark.kanda(a)oracle.com>
Reviewed-by: Ameya More <ameya.more(a)oracle.com>
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
---
arch/x86/kvm/vmx.c | 146 +++++++++--------------------------------------------
1 file changed, 23 insertions(+), 123 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c829d89e2e63..ad6a883b7a32 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -185,7 +185,6 @@ module_param(ple_window_max, int, S_IRUGO);
extern const ulong vmx_return;
#define NR_AUTOLOAD_MSRS 8
-#define VMCS02_POOL_SIZE 1
struct vmcs {
u32 revision_id;
@@ -226,7 +225,7 @@ struct shared_msr_entry {
* stored in guest memory specified by VMPTRLD, but is opaque to the guest,
* which must access it using VMREAD/VMWRITE/VMCLEAR instructions.
* More than one of these structures may exist, if L1 runs multiple L2 guests.
- * nested_vmx_run() will use the data here to build a vmcs02: a VMCS for the
+ * nested_vmx_run() will use the data here to build the vmcs02: a VMCS for the
* underlying hardware which will be used to run L2.
* This structure is packed to ensure that its layout is identical across
* machines (necessary for live migration).
@@ -409,13 +408,6 @@ struct __packed vmcs12 {
*/
#define VMCS12_SIZE 0x1000
-/* Used to remember the last vmcs02 used for some recently used vmcs12s */
-struct vmcs02_list {
- struct list_head list;
- gpa_t vmptr;
- struct loaded_vmcs vmcs02;
-};
-
/*
* The nested_vmx structure is part of vcpu_vmx, and holds information we need
* for correct emulation of VMX (i.e., nested VMX) on this vcpu.
@@ -440,15 +432,15 @@ struct nested_vmx {
*/
bool sync_shadow_vmcs;
- /* vmcs02_list cache of VMCSs recently used to run L2 guests */
- struct list_head vmcs02_pool;
- int vmcs02_num;
bool change_vmcs01_virtual_x2apic_mode;
/* L2 must run next, and mustn't decide to exit to L1. */
bool nested_run_pending;
+
+ struct loaded_vmcs vmcs02;
+
/*
- * Guest pages referred to in vmcs02 with host-physical pointers, so
- * we must keep them pinned while L2 runs.
+ * Guest pages referred to in the vmcs02 with host-physical
+ * pointers, so we must keep them pinned while L2 runs.
*/
struct page *apic_access_page;
struct page *virtual_apic_page;
@@ -6973,94 +6965,6 @@ static int handle_monitor(struct kvm_vcpu *vcpu)
return handle_nop(vcpu);
}
-/*
- * To run an L2 guest, we need a vmcs02 based on the L1-specified vmcs12.
- * We could reuse a single VMCS for all the L2 guests, but we also want the
- * option to allocate a separate vmcs02 for each separate loaded vmcs12 - this
- * allows keeping them loaded on the processor, and in the future will allow
- * optimizations where prepare_vmcs02 doesn't need to set all the fields on
- * every entry if they never change.
- * So we keep, in vmx->nested.vmcs02_pool, a cache of size VMCS02_POOL_SIZE
- * (>=0) with a vmcs02 for each recently loaded vmcs12s, most recent first.
- *
- * The following functions allocate and free a vmcs02 in this pool.
- */
-
-/* Get a VMCS from the pool to use as vmcs02 for the current vmcs12. */
-static struct loaded_vmcs *nested_get_current_vmcs02(struct vcpu_vmx *vmx)
-{
- struct vmcs02_list *item;
- list_for_each_entry(item, &vmx->nested.vmcs02_pool, list)
- if (item->vmptr == vmx->nested.current_vmptr) {
- list_move(&item->list, &vmx->nested.vmcs02_pool);
- return &item->vmcs02;
- }
-
- if (vmx->nested.vmcs02_num >= max(VMCS02_POOL_SIZE, 1)) {
- /* Recycle the least recently used VMCS. */
- item = list_last_entry(&vmx->nested.vmcs02_pool,
- struct vmcs02_list, list);
- item->vmptr = vmx->nested.current_vmptr;
- list_move(&item->list, &vmx->nested.vmcs02_pool);
- return &item->vmcs02;
- }
-
- /* Create a new VMCS */
- item = kzalloc(sizeof(struct vmcs02_list), GFP_KERNEL);
- if (!item)
- return NULL;
- item->vmcs02.vmcs = alloc_vmcs();
- item->vmcs02.shadow_vmcs = NULL;
- if (!item->vmcs02.vmcs) {
- kfree(item);
- return NULL;
- }
- loaded_vmcs_init(&item->vmcs02);
- item->vmptr = vmx->nested.current_vmptr;
- list_add(&(item->list), &(vmx->nested.vmcs02_pool));
- vmx->nested.vmcs02_num++;
- return &item->vmcs02;
-}
-
-/* Free and remove from pool a vmcs02 saved for a vmcs12 (if there is one) */
-static void nested_free_vmcs02(struct vcpu_vmx *vmx, gpa_t vmptr)
-{
- struct vmcs02_list *item;
- list_for_each_entry(item, &vmx->nested.vmcs02_pool, list)
- if (item->vmptr == vmptr) {
- free_loaded_vmcs(&item->vmcs02);
- list_del(&item->list);
- kfree(item);
- vmx->nested.vmcs02_num--;
- return;
- }
-}
-
-/*
- * Free all VMCSs saved for this vcpu, except the one pointed by
- * vmx->loaded_vmcs. We must be running L1, so vmx->loaded_vmcs
- * must be &vmx->vmcs01.
- */
-static void nested_free_all_saved_vmcss(struct vcpu_vmx *vmx)
-{
- struct vmcs02_list *item, *n;
-
- WARN_ON(vmx->loaded_vmcs != &vmx->vmcs01);
- list_for_each_entry_safe(item, n, &vmx->nested.vmcs02_pool, list) {
- /*
- * Something will leak if the above WARN triggers. Better than
- * a use-after-free.
- */
- if (vmx->loaded_vmcs == &item->vmcs02)
- continue;
-
- free_loaded_vmcs(&item->vmcs02);
- list_del(&item->list);
- kfree(item);
- vmx->nested.vmcs02_num--;
- }
-}
-
/*
* The following 3 functions, nested_vmx_succeed()/failValid()/failInvalid(),
* set the success or error code of an emulated VMX instruction, as specified
@@ -7242,6 +7146,12 @@ static int enter_vmx_operation(struct kvm_vcpu *vcpu)
struct vcpu_vmx *vmx = to_vmx(vcpu);
struct vmcs *shadow_vmcs;
+ vmx->nested.vmcs02.vmcs = alloc_vmcs();
+ vmx->nested.vmcs02.shadow_vmcs = NULL;
+ if (!vmx->nested.vmcs02.vmcs)
+ goto out_vmcs02;
+ loaded_vmcs_init(&vmx->nested.vmcs02);
+
if (cpu_has_vmx_msr_bitmap()) {
vmx->nested.msr_bitmap =
(unsigned long *)__get_free_page(GFP_KERNEL);
@@ -7264,9 +7174,6 @@ static int enter_vmx_operation(struct kvm_vcpu *vcpu)
vmx->vmcs01.shadow_vmcs = shadow_vmcs;
}
- INIT_LIST_HEAD(&(vmx->nested.vmcs02_pool));
- vmx->nested.vmcs02_num = 0;
-
hrtimer_init(&vmx->nested.preemption_timer, CLOCK_MONOTONIC,
HRTIMER_MODE_REL_PINNED);
vmx->nested.preemption_timer.function = vmx_preemption_timer_fn;
@@ -7281,6 +7188,9 @@ static int enter_vmx_operation(struct kvm_vcpu *vcpu)
free_page((unsigned long)vmx->nested.msr_bitmap);
out_msr_bitmap:
+ free_loaded_vmcs(&vmx->nested.vmcs02);
+
+out_vmcs02:
return -ENOMEM;
}
@@ -7434,7 +7344,7 @@ static void free_nested(struct vcpu_vmx *vmx)
vmx->vmcs01.shadow_vmcs = NULL;
}
kfree(vmx->nested.cached_vmcs12);
- /* Unpin physical memory we referred to in current vmcs02 */
+ /* Unpin physical memory we referred to in the vmcs02 */
if (vmx->nested.apic_access_page) {
kvm_release_page_dirty(vmx->nested.apic_access_page);
vmx->nested.apic_access_page = NULL;
@@ -7450,7 +7360,7 @@ static void free_nested(struct vcpu_vmx *vmx)
vmx->nested.pi_desc = NULL;
}
- nested_free_all_saved_vmcss(vmx);
+ free_loaded_vmcs(&vmx->nested.vmcs02);
}
/* Emulate the VMXOFF instruction */
@@ -7493,8 +7403,6 @@ static int handle_vmclear(struct kvm_vcpu *vcpu)
vmptr + offsetof(struct vmcs12, launch_state),
&zero, sizeof(zero));
- nested_free_vmcs02(vmx, vmptr);
-
nested_vmx_succeed(vcpu);
return kvm_skip_emulated_instruction(vcpu);
}
@@ -8406,10 +8314,11 @@ static bool nested_vmx_exit_reflected(struct kvm_vcpu *vcpu, u32 exit_reason)
/*
* The host physical addresses of some pages of guest memory
- * are loaded into VMCS02 (e.g. L1's Virtual APIC Page). The CPU
- * may write to these pages via their host physical address while
- * L2 is running, bypassing any address-translation-based dirty
- * tracking (e.g. EPT write protection).
+ * are loaded into the vmcs02 (e.g. vmcs12's Virtual APIC
+ * Page). The CPU may write to these pages via their host
+ * physical address while L2 is running, bypassing any
+ * address-translation-based dirty tracking (e.g. EPT write
+ * protection).
*
* Mark them dirty on every exit from L2 to prevent them from
* getting out of sync with dirty tracking.
@@ -10903,20 +10812,15 @@ static int enter_vmx_non_root_mode(struct kvm_vcpu *vcpu, bool from_vmentry)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
- struct loaded_vmcs *vmcs02;
u32 msr_entry_idx;
u32 exit_qual;
- vmcs02 = nested_get_current_vmcs02(vmx);
- if (!vmcs02)
- return -ENOMEM;
-
enter_guest_mode(vcpu);
if (!(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_DEBUG_CONTROLS))
vmx->nested.vmcs01_debugctl = vmcs_read64(GUEST_IA32_DEBUGCTL);
- vmx_switch_vmcs(vcpu, vmcs02);
+ vmx_switch_vmcs(vcpu, &vmx->nested.vmcs02);
vmx_segment_cache_clear(vmx);
if (prepare_vmcs02(vcpu, vmcs12, from_vmentry, &exit_qual)) {
@@ -11534,10 +11438,6 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 exit_reason,
vm_exit_controls_reset_shadow(vmx);
vmx_segment_cache_clear(vmx);
- /* if no vmcs02 cache requested, remove the one we used */
- if (VMCS02_POOL_SIZE == 0)
- nested_free_vmcs02(vmx, vmx->nested.current_vmptr);
-
/* Update any VMCS fields that might have changed while L2 ran */
vmcs_write32(VM_EXIT_MSR_LOAD_COUNT, vmx->msr_autoload.nr);
vmcs_write32(VM_ENTRY_MSR_LOAD_COUNT, vmx->msr_autoload.nr);
--
2.14.3
Initialize the request queue lock earlier such that the following
race can no longer occur:
blk_init_queue_node blkcg_print_blkgs
blk_alloc_queue_node (1)
q->queue_lock = &q->__queue_lock (2)
blkcg_init_queue(q) (3)
spin_lock_irq(blkg->q->queue_lock) (4)
q->queue_lock = lock (5)
spin_unlock_irq(blkg->q->queue_lock) (6)
(1) allocate an uninitialized queue;
(2) initialize queue_lock to its default internal lock;
(3) initialize blkcg part of request queue, which will create blkg and
then insert it to blkg_list;
(4) traverse blkg_list and find the created blkg, and then take its
queue lock, here it is the default *internal lock*;
(5) *race window*, now queue_lock is overridden with *driver specified
lock*;
(6) now unlock *driver specified lock*, not the locked *internal lock*,
unlock balance breaks.
The changes in this patch are as follows:
- Rename blk_alloc_queue_node() into blk_alloc_queue_node2() and add
a new queue lock argument.
- Introduce a wrapper function with the same name and behavior as the
old blk_alloc_queue_node() function.
- Move the .queue_lock initialization from blk_init_queue_node() into
blk_alloc_queue_node2().
- For all all block drivers that initialize .queue_lock explicitly,
change the blk_alloc_queue() call in the driver into a
blk_alloc_queue_node2() call and remove the explicit .queue_lock
initialization. Additionally, initialize the spin lock that will
be used as queue lock earlier if necessary.
Reported-by: Joseph Qi <joseph.qi(a)linux.alibaba.com>
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Joseph Qi <joseph.qi(a)linux.alibaba.com>
Cc: Philipp Reisner <philipp.reisner(a)linbit.com>
Cc: Ulf Hansson <ulf.hansson(a)linaro.org>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: <stable(a)vger.kernel.org>
---
block/blk-core.c | 33 ++++++++++++++++++++++++---------
drivers/block/drbd/drbd_main.c | 4 ++--
drivers/block/umem.c | 7 +++----
drivers/mmc/core/queue.c | 3 +--
include/linux/blkdev.h | 2 ++
5 files changed, 32 insertions(+), 17 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index bd43bc50740a..cb18f57e5b13 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -946,7 +946,22 @@ static void blk_rq_timed_out_timer(struct timer_list *t)
kblockd_schedule_work(&q->timeout_work);
}
-struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, int node_id)
+/**
+ * blk_alloc_queue_node2 - allocate a request queue
+ * @gfp_mask: memory allocation flags
+ * @node_id: NUMA node to allocate memory from
+ * @lock: Pointer to a spinlock that will be used to e.g. serialize calls to
+ * the legacy .request_fn(). Only set this pointer for queues that use
+ * legacy mode and not for queues that use blk-mq.
+ *
+ * Note: use this function instead of calling blk_alloc_queue_node() and
+ * setting the queue lock pointer explicitly to avoid triggering a crash in
+ * the blkcg throttling code. That code namely makes sysfs attributes visible
+ * in user space before this function returns and the show method of these
+ * attributes uses the queue lock.
+ */
+struct request_queue *blk_alloc_queue_node2(gfp_t gfp_mask, int node_id,
+ spinlock_t *lock)
{
struct request_queue *q;
@@ -997,11 +1012,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, int node_id)
mutex_init(&q->sysfs_lock);
spin_lock_init(&q->__queue_lock);
- /*
- * By default initialize queue_lock to internal lock and driver can
- * override it later if need be.
- */
- q->queue_lock = &q->__queue_lock;
+ q->queue_lock = lock ? : &q->__queue_lock;
/*
* A queue starts its life with bypass turned on to avoid
@@ -1042,6 +1053,12 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, int node_id)
kmem_cache_free(blk_requestq_cachep, q);
return NULL;
}
+EXPORT_SYMBOL(blk_alloc_queue_node2);
+
+struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, int node_id)
+{
+ return blk_alloc_queue_node2(gfp_mask, node_id, NULL);
+}
EXPORT_SYMBOL(blk_alloc_queue_node);
/**
@@ -1088,13 +1105,11 @@ blk_init_queue_node(request_fn_proc *rfn, spinlock_t *lock, int node_id)
{
struct request_queue *q;
- q = blk_alloc_queue_node(GFP_KERNEL, node_id);
+ q = blk_alloc_queue_node2(GFP_KERNEL, node_id, lock);
if (!q)
return NULL;
q->request_fn = rfn;
- if (lock)
- q->queue_lock = lock;
if (blk_init_allocated_queue(q) < 0) {
blk_cleanup_queue(q);
return NULL;
diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
index 4b4697a1f963..965e80b13443 100644
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@ -2822,7 +2822,8 @@ enum drbd_ret_code drbd_create_device(struct drbd_config_context *adm_ctx, unsig
drbd_init_set_defaults(device);
- q = blk_alloc_queue(GFP_KERNEL);
+ q = blk_alloc_queue_node2(GFP_KERNEL, NUMA_NO_NODE,
+ &resource->req_lock);
if (!q)
goto out_no_q;
device->rq_queue = q;
@@ -2854,7 +2855,6 @@ enum drbd_ret_code drbd_create_device(struct drbd_config_context *adm_ctx, unsig
/* Setting the max_hw_sectors to an odd value of 8kibyte here
This triggers a max_bio_size message upon first attach or connect */
blk_queue_max_hw_sectors(q, DRBD_MAX_BIO_SIZE_SAFE >> 8);
- q->queue_lock = &resource->req_lock;
device->md_io.page = alloc_page(GFP_KERNEL);
if (!device->md_io.page)
diff --git a/drivers/block/umem.c b/drivers/block/umem.c
index 8077123678ad..f6bb78782afa 100644
--- a/drivers/block/umem.c
+++ b/drivers/block/umem.c
@@ -888,13 +888,14 @@ static int mm_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
card->Active = -1; /* no page is active */
card->bio = NULL;
card->biotail = &card->bio;
+ spin_lock_init(&card->lock);
- card->queue = blk_alloc_queue(GFP_KERNEL);
+ card->queue = blk_alloc_queue_node2(GFP_KERNEL, NUMA_NO_NODE,
+ &card->lock);
if (!card->queue)
goto failed_alloc;
blk_queue_make_request(card->queue, mm_make_request);
- card->queue->queue_lock = &card->lock;
card->queue->queuedata = card;
tasklet_init(&card->tasklet, process_page, (unsigned long)card);
@@ -968,8 +969,6 @@ static int mm_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
dev_printk(KERN_INFO, &card->dev->dev,
"Window size %d bytes, IRQ %d\n", data, dev->irq);
- spin_lock_init(&card->lock);
-
pci_set_drvdata(dev, card);
if (pci_write_cmd != 0x0F) /* If not Memory Write & Invalidate */
diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index 5ecd54088988..274a8c6c8d64 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -216,10 +216,9 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
int ret = -ENOMEM;
mq->card = card;
- mq->queue = blk_alloc_queue(GFP_KERNEL);
+ mq->queue = blk_alloc_queue_node2(GFP_KERNEL, NUMA_NO_NODE, lock);
if (!mq->queue)
return -ENOMEM;
- mq->queue->queue_lock = lock;
mq->queue->request_fn = mmc_request_fn;
mq->queue->init_rq_fn = mmc_init_request;
mq->queue->exit_rq_fn = mmc_exit_request;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 781992c4124e..37723a8b799c 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1331,6 +1331,8 @@ extern long nr_blockdev_pages(void);
bool __must_check blk_get_queue(struct request_queue *);
struct request_queue *blk_alloc_queue(gfp_t);
struct request_queue *blk_alloc_queue_node(gfp_t, int);
+struct request_queue *blk_alloc_queue_node2(gfp_t gfp_mask, int node_id,
+ spinlock_t *lock);
extern void blk_put_queue(struct request_queue *);
extern void blk_set_queue_dying(struct request_queue *);
--
2.16.0
This is a note to let you know that I've just added the patch titled
loop: fix concurrent lo_open/lo_release
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:
loop-fix-concurrent-lo_open-lo_release.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 ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Fri, 5 Jan 2018 16:26:00 -0800
Subject: loop: fix concurrent lo_open/lo_release
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5 upstream.
范龙飞 reports that KASAN can report a use-after-free in __lock_acquire.
The reason is due to insufficient serialization in lo_release(), which
will continue to use the loop device even after it has decremented the
lo_refcnt to zero.
In the meantime, another process can come in, open the loop device
again as it is being shut down. Confusion ensues.
Reported-by: 范龙飞 <long7573(a)126.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/loop.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1558,9 +1558,8 @@ out:
return err;
}
-static void lo_release(struct gendisk *disk, fmode_t mode)
+static void __lo_release(struct loop_device *lo)
{
- struct loop_device *lo = disk->private_data;
int err;
if (atomic_dec_return(&lo->lo_refcnt))
@@ -1586,6 +1585,13 @@ static void lo_release(struct gendisk *d
mutex_unlock(&lo->lo_ctl_mutex);
}
+static void lo_release(struct gendisk *disk, fmode_t mode)
+{
+ mutex_lock(&loop_index_mutex);
+ __lo_release(disk->private_data);
+ mutex_unlock(&loop_index_mutex);
+}
+
static const struct block_device_operations lo_fops = {
.owner = THIS_MODULE,
.open = lo_open,
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-4.9/loop-fix-concurrent-lo_open-lo_release.patch
This is a note to let you know that I've just added the patch titled
loop: fix concurrent lo_open/lo_release
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:
loop-fix-concurrent-lo_open-lo_release.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 ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Fri, 5 Jan 2018 16:26:00 -0800
Subject: loop: fix concurrent lo_open/lo_release
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5 upstream.
范龙飞 reports that KASAN can report a use-after-free in __lock_acquire.
The reason is due to insufficient serialization in lo_release(), which
will continue to use the loop device even after it has decremented the
lo_refcnt to zero.
In the meantime, another process can come in, open the loop device
again as it is being shut down. Confusion ensues.
Reported-by: 范龙飞 <long7573(a)126.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/loop.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1569,9 +1569,8 @@ out:
return err;
}
-static void lo_release(struct gendisk *disk, fmode_t mode)
+static void __lo_release(struct loop_device *lo)
{
- struct loop_device *lo = disk->private_data;
int err;
if (atomic_dec_return(&lo->lo_refcnt))
@@ -1597,6 +1596,13 @@ static void lo_release(struct gendisk *d
mutex_unlock(&lo->lo_ctl_mutex);
}
+static void lo_release(struct gendisk *disk, fmode_t mode)
+{
+ mutex_lock(&loop_index_mutex);
+ __lo_release(disk->private_data);
+ mutex_unlock(&loop_index_mutex);
+}
+
static const struct block_device_operations lo_fops = {
.owner = THIS_MODULE,
.open = lo_open,
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-4.4/loop-fix-concurrent-lo_open-lo_release.patch
This is a note to let you know that I've just added the patch titled
loop: fix concurrent lo_open/lo_release
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:
loop-fix-concurrent-lo_open-lo_release.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 ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Fri, 5 Jan 2018 16:26:00 -0800
Subject: loop: fix concurrent lo_open/lo_release
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5 upstream.
范龙飞 reports that KASAN can report a use-after-free in __lock_acquire.
The reason is due to insufficient serialization in lo_release(), which
will continue to use the loop device even after it has decremented the
lo_refcnt to zero.
In the meantime, another process can come in, open the loop device
again as it is being shut down. Confusion ensues.
Reported-by: 范龙飞 <long7573(a)126.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/loop.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1576,9 +1576,8 @@ out:
return err;
}
-static void lo_release(struct gendisk *disk, fmode_t mode)
+static void __lo_release(struct loop_device *lo)
{
- struct loop_device *lo = disk->private_data;
int err;
if (atomic_dec_return(&lo->lo_refcnt))
@@ -1605,6 +1604,13 @@ static void lo_release(struct gendisk *d
mutex_unlock(&lo->lo_ctl_mutex);
}
+static void lo_release(struct gendisk *disk, fmode_t mode)
+{
+ mutex_lock(&loop_index_mutex);
+ __lo_release(disk->private_data);
+ mutex_unlock(&loop_index_mutex);
+}
+
static const struct block_device_operations lo_fops = {
.owner = THIS_MODULE,
.open = lo_open,
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-4.14/futex-fix-owner_dead-fixup.patch
queue-4.14/loop-fix-concurrent-lo_open-lo_release.patch
This is a note to let you know that I've just added the patch titled
loop: fix concurrent lo_open/lo_release
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:
loop-fix-concurrent-lo_open-lo_release.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 ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Fri, 5 Jan 2018 16:26:00 -0800
Subject: loop: fix concurrent lo_open/lo_release
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5 upstream.
范龙飞 reports that KASAN can report a use-after-free in __lock_acquire.
The reason is due to insufficient serialization in lo_release(), which
will continue to use the loop device even after it has decremented the
lo_refcnt to zero.
In the meantime, another process can come in, open the loop device
again as it is being shut down. Confusion ensues.
Reported-by: 范龙飞 <long7573(a)126.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/loop.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1512,9 +1512,8 @@ out:
return err;
}
-static void lo_release(struct gendisk *disk, fmode_t mode)
+static void __lo_release(struct loop_device *lo)
{
- struct loop_device *lo = disk->private_data;
int err;
mutex_lock(&lo->lo_ctl_mutex);
@@ -1542,6 +1541,13 @@ out:
mutex_unlock(&lo->lo_ctl_mutex);
}
+static void lo_release(struct gendisk *disk, fmode_t mode)
+{
+ mutex_lock(&loop_index_mutex);
+ __lo_release(disk->private_data);
+ mutex_unlock(&loop_index_mutex);
+}
+
static const struct block_device_operations lo_fops = {
.owner = THIS_MODULE,
.open = lo_open,
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-3.18/loop-fix-concurrent-lo_open-lo_release.patch
Please queue up this commit for stable:
69c64866ce07 dccp: CVE-2017-8824: use-after-free in DCCP code
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
In the past the ast driver relied upon the fbdev emulation helpers to
call ->load_lut at boot-up. But since
commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
Author: Peter Rosin <peda(a)axentia.se>
Date: Tue Jul 4 12:36:57 2017 +0200
drm/fb-helper: factor out pseudo-palette
that's cleaned up and drivers are expected to boot into a consistent
lut state. This patch fixes that.
Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette")
Cc: Peter Rosin <peda(a)axenita.se>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: <stable(a)vger.kernel.org> # v4.14+
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198123
Cc: Bill Fraser <bill.fraser(a)gmail.com>
Reported-and-Tested-by: Bill Fraser <bill.fraser(a)gmail.com>
Tested-by: Konstantin Khlebnikov <koct9i(a)gmail.com>
Tested-by: Paul Tobias <tobias.pal(a)gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com>
---
drivers/gpu/drm/ast/ast_mode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 9555a3542022..831b73392d82 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -644,6 +644,7 @@ static void ast_crtc_commit(struct drm_crtc *crtc)
{
struct ast_private *ast = crtc->dev->dev_private;
ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT, 0x1, 0xdf, 0);
+ ast_crtc_load_lut(crtc);
}
--
2.15.1
This is a note to let you know that I've just added the patch titled
futex: Fix OWNER_DEAD fixup
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:
futex-fix-owner_dead-fixup.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 a97cb0e7b3f4c6297fd857055ae8e895f402f501 Mon Sep 17 00:00:00 2001
From: Peter Zijlstra <peterz(a)infradead.org>
Date: Mon, 22 Jan 2018 11:39:47 +0100
Subject: futex: Fix OWNER_DEAD fixup
From: Peter Zijlstra <peterz(a)infradead.org>
commit a97cb0e7b3f4c6297fd857055ae8e895f402f501 upstream.
Both Geert and DaveJ reported that the recent futex commit:
c1e2f0eaf015 ("futex: Avoid violating the 10th rule of futex")
introduced a problem with setting OWNER_DEAD. We set the bit on an
uninitialized variable and then entirely optimize it away as a
dead-store.
Move the setting of the bit to where it is more useful.
Reported-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Reported-by: Dave Jones <davej(a)codemonkey.org.uk>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Paul E. McKenney <paulmck(a)us.ibm.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Fixes: c1e2f0eaf015 ("futex: Avoid violating the 10th rule of futex")
Link: http://lkml.kernel.org/r/20180122103947.GD2228@hirez.programming.kicks-ass.…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Ozkan Sezer <sezeroz(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/futex.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2311,9 +2311,6 @@ static int fixup_pi_state_owner(u32 __us
raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock);
oldowner = pi_state->owner;
- /* Owner died? */
- if (!pi_state->owner)
- newtid |= FUTEX_OWNER_DIED;
/*
* We are here because either:
@@ -2374,6 +2371,9 @@ retry:
}
newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
+ /* Owner died? */
+ if (!pi_state->owner)
+ newtid |= FUTEX_OWNER_DIED;
if (get_futex_value_locked(&uval, uaddr))
goto handle_fault;
Patches currently in stable-queue which might be from peterz(a)infradead.org are
queue-4.14/futex-fix-owner_dead-fixup.patch
When introducing support for irqchip in userspace we needed a way to
mask the timer signal to prevent the guest continuously exiting due to a
screaming timer.
We did this by disabling the corresponding percpu interrupt on the
host interrupt controller, because we cannot rely on the host system
having a GIC, and therefore cannot make any assumptions about having an
active state to hide the timer signal.
Unfortunately, when introducing this feature, it became entirely
possible that a VCPU which belongs to a VM that has a userspace irqchip
can disable the vtimer irq on the host on some physical CPU, and then go
away without ever enabling the vtimer irq on that physical CPU again.
This means that using irqchips in userspace on a system that also
supports running VMs with an in-kernel GIC can prevent forward progress
from in-kernel GIC VMs.
Later on, when we started taking virtual timer interrupts in the arch
timer code, we would also leave this timer state active for userspace
irqchip VMs, because we leave it up to a VGIC-enabled guest to
deactivate the hardware IRQ using the HW bit in the LR.
Both issues are solved by only using the enable/disable trick on systems
that do not have a host GIC which supports the active state, because all
VMs on such systems must use irqchips in userspace. Systems that have a
working GIC with support for an active state use the active state to
mask the timer signal for both userspace and in-kernel irqchips.
Cc: Alexander Graf <agraf(a)suse.de>
Cc: <stable(a)vger.kernel.org> # v4.12+
Fixes: d9e139778376 ("KVM: arm/arm64: Support arch timers with a userspace gic")
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
---
This conflicts horribly with everything when applied to either
kvmarm/queue or kvmarm/master. Therefore, this patch is written for
(and applies to) v4.15 with kvmarm/queue merged and should therefore
apply cleanly after v4.16-rc1. An example with this patch applied can
be found on kvmarm/temp-for-v4.16-rc2. I plan on sending this along
with any other potential fixes post v4.16-rc1.
Changes since v1:
- Added userspace_irqchip() wrapper to simplify logic
- Changed has_gic_active_state to a static key
- Fixed typos in commentary and commit message
- Clear the active state on sync for userspace irqchips on systems
with a working GIC.
- Get rid of __timer_snapshot_state() in unmaks_vtimer_irq_user()
because kvm_timer_should_fire() has already been reworked in other
patches to look at the timer state when it's loaded onto the
hardware. As a result, we don't need the
__timer_snapshot_state() indirection anymore and this logic is
now inlined in vtimer_save_state().
virt/kvm/arm/arch_timer.c | 116 +++++++++++++++++++++++++---------------------
1 file changed, 64 insertions(+), 52 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 70268c0bec79..70f4c30918eb 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -36,6 +36,8 @@ static struct timecounter *timecounter;
static unsigned int host_vtimer_irq;
static u32 host_vtimer_irq_flags;
+static DEFINE_STATIC_KEY_FALSE(has_gic_active_state);
+
static const struct kvm_irq_level default_ptimer_irq = {
.irq = 30,
.level = 1,
@@ -56,6 +58,12 @@ u64 kvm_phys_timer_read(void)
return timecounter->cc->read(timecounter->cc);
}
+static inline bool userspace_irqchip(struct kvm *kvm)
+{
+ return static_branch_unlikely(&userspace_irqchip_in_use) &&
+ unlikely(!irqchip_in_kernel(kvm));
+}
+
static void soft_timer_start(struct hrtimer *hrt, u64 ns)
{
hrtimer_start(hrt, ktime_add_ns(ktime_get(), ns),
@@ -69,25 +77,6 @@ static void soft_timer_cancel(struct hrtimer *hrt, struct work_struct *work)
cancel_work_sync(work);
}
-static void kvm_vtimer_update_mask_user(struct kvm_vcpu *vcpu)
-{
- struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
-
- /*
- * When using a userspace irqchip with the architected timers, we must
- * prevent continuously exiting from the guest, and therefore mask the
- * physical interrupt by disabling it on the host interrupt controller
- * when the virtual level is high, such that the guest can make
- * forward progress. Once we detect the output level being
- * de-asserted, we unmask the interrupt again so that we exit from the
- * guest when the timer fires.
- */
- if (vtimer->irq.level)
- disable_percpu_irq(host_vtimer_irq);
- else
- enable_percpu_irq(host_vtimer_irq, 0);
-}
-
static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
{
struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
@@ -106,9 +95,9 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
if (kvm_timer_should_fire(vtimer))
kvm_timer_update_irq(vcpu, true, vtimer);
- if (static_branch_unlikely(&userspace_irqchip_in_use) &&
- unlikely(!irqchip_in_kernel(vcpu->kvm)))
- kvm_vtimer_update_mask_user(vcpu);
+ if (userspace_irqchip(vcpu->kvm) &&
+ !static_branch_unlikely(&has_gic_active_state))
+ disable_percpu_irq(host_vtimer_irq);
return IRQ_HANDLED;
}
@@ -290,8 +279,7 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
trace_kvm_timer_update_irq(vcpu->vcpu_id, timer_ctx->irq.irq,
timer_ctx->irq.level);
- if (!static_branch_unlikely(&userspace_irqchip_in_use) ||
- likely(irqchip_in_kernel(vcpu->kvm))) {
+ if (!userspace_irqchip(vcpu->kvm)) {
ret = kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
timer_ctx->irq.irq,
timer_ctx->irq.level,
@@ -350,12 +338,6 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
phys_timer_emulate(vcpu);
}
-static void __timer_snapshot_state(struct arch_timer_context *timer)
-{
- timer->cnt_ctl = read_sysreg_el0(cntv_ctl);
- timer->cnt_cval = read_sysreg_el0(cntv_cval);
-}
-
static void vtimer_save_state(struct kvm_vcpu *vcpu)
{
struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
@@ -367,8 +349,10 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
if (!vtimer->loaded)
goto out;
- if (timer->enabled)
- __timer_snapshot_state(vtimer);
+ if (timer->enabled) {
+ vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
+ vtimer->cnt_cval = read_sysreg_el0(cntv_cval);
+ }
/* Disable the virtual timer */
write_sysreg_el0(0, cntv_ctl);
@@ -460,23 +444,43 @@ static void set_cntvoff(u64 cntvoff)
kvm_call_hyp(__kvm_timer_set_cntvoff, low, high);
}
-static void kvm_timer_vcpu_load_vgic(struct kvm_vcpu *vcpu)
+static inline void set_vtimer_irq_phys_active(struct kvm_vcpu *vcpu, bool active)
+{
+ int r;
+ r = irq_set_irqchip_state(host_vtimer_irq, IRQCHIP_STATE_ACTIVE, active);
+ WARN_ON(r);
+}
+
+static void kvm_timer_vcpu_load_gic(struct kvm_vcpu *vcpu)
{
struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
bool phys_active;
- int ret;
- phys_active = kvm_vgic_map_is_active(vcpu, vtimer->irq.irq);
-
- ret = irq_set_irqchip_state(host_vtimer_irq,
- IRQCHIP_STATE_ACTIVE,
- phys_active);
- WARN_ON(ret);
+ if (irqchip_in_kernel(vcpu->kvm))
+ phys_active = kvm_vgic_map_is_active(vcpu, vtimer->irq.irq);
+ else
+ phys_active = vtimer->irq.level;
+ set_vtimer_irq_phys_active(vcpu, phys_active);
}
-static void kvm_timer_vcpu_load_user(struct kvm_vcpu *vcpu)
+static void kvm_timer_vcpu_load_nogic(struct kvm_vcpu *vcpu)
{
- kvm_vtimer_update_mask_user(vcpu);
+ struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
+
+ /*
+ * When using a userspace irqchip with the architected timers and a
+ * host interrupt controller that doesn't support an active state, we
+ * must still prevent continuously exiting from the guest, and
+ * therefore mask the physical interrupt by disabling it on the host
+ * interrupt controller when the virtual level is high, such that the
+ * guest can make forward progress. Once we detect the output level
+ * being de-asserted, we unmask the interrupt again so that we exit
+ * from the guest when the timer fires.
+ */
+ if (vtimer->irq.level)
+ disable_percpu_irq(host_vtimer_irq);
+ else
+ enable_percpu_irq(host_vtimer_irq, host_vtimer_irq_flags);
}
void kvm_timer_vcpu_load(struct kvm_vcpu *vcpu)
@@ -487,10 +491,10 @@ void kvm_timer_vcpu_load(struct kvm_vcpu *vcpu)
if (unlikely(!timer->enabled))
return;
- if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
- kvm_timer_vcpu_load_user(vcpu);
+ if (static_branch_likely(&has_gic_active_state))
+ kvm_timer_vcpu_load_gic(vcpu);
else
- kvm_timer_vcpu_load_vgic(vcpu);
+ kvm_timer_vcpu_load_nogic(vcpu);
set_cntvoff(vtimer->cntvoff);
@@ -555,18 +559,24 @@ static void unmask_vtimer_irq_user(struct kvm_vcpu *vcpu)
{
struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
- if (unlikely(!irqchip_in_kernel(vcpu->kvm))) {
- __timer_snapshot_state(vtimer);
- if (!kvm_timer_should_fire(vtimer)) {
- kvm_timer_update_irq(vcpu, false, vtimer);
- kvm_vtimer_update_mask_user(vcpu);
- }
+ if (!kvm_timer_should_fire(vtimer)) {
+ kvm_timer_update_irq(vcpu, false, vtimer);
+ if (static_branch_likely(&has_gic_active_state))
+ set_vtimer_irq_phys_active(vcpu, false);
+ else
+ enable_percpu_irq(host_vtimer_irq, host_vtimer_irq_flags);
}
}
void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
{
- unmask_vtimer_irq_user(vcpu);
+ struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+
+ if (unlikely(!timer->enabled))
+ return;
+
+ if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
+ unmask_vtimer_irq_user(vcpu);
}
int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)
@@ -753,6 +763,8 @@ int kvm_timer_hyp_init(bool has_gic)
kvm_err("kvm_arch_timer: error setting vcpu affinity\n");
goto out_free_irq;
}
+
+ static_branch_enable(&has_gic_active_state);
}
kvm_info("virtual timer IRQ%d\n", host_vtimer_irq);
--
2.14.2
This is a note to let you know that I've just added the patch titled
um: Stop abusing __KERNEL__
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:
um-stop-abusing-__kernel__.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 298e20ba8c197e8d429a6c8671550c41c7919033 Mon Sep 17 00:00:00 2001
From: Richard Weinberger <richard(a)nod.at>
Date: Sun, 31 May 2015 19:50:57 +0200
Subject: um: Stop abusing __KERNEL__
From: Richard Weinberger <richard(a)nod.at>
commit 298e20ba8c197e8d429a6c8671550c41c7919033 upstream.
Currently UML is abusing __KERNEL__ to distinguish between
kernel and host code (os-Linux). It is better to use a custom
define such that existing users of __KERNEL__ don't get confused.
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Cc: Greg Hackmann <ghackmann(a)google.com>
Cc: Bernie Innocenti <codewiz(a)google.com>
Cc: Lorenzo Colitti <lorenzo(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/um/Makefile | 7 ++++---
arch/um/drivers/mconsole.h | 2 +-
arch/um/include/shared/init.h | 4 ++--
arch/um/include/shared/user.h | 2 +-
arch/x86/um/shared/sysdep/tls.h | 6 +++---
5 files changed, 11 insertions(+), 10 deletions(-)
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -68,9 +68,10 @@ KBUILD_CFLAGS += $(CFLAGS) $(CFLAGS-y) -
KBUILD_AFLAGS += $(ARCH_INCLUDE)
-USER_CFLAGS = $(patsubst $(KERNEL_DEFINES),,$(patsubst -D__KERNEL__,,\
- $(patsubst -I%,,$(KBUILD_CFLAGS)))) $(ARCH_INCLUDE) $(MODE_INCLUDE) \
- $(filter -I%,$(CFLAGS)) -D_FILE_OFFSET_BITS=64 -idirafter include
+USER_CFLAGS = $(patsubst $(KERNEL_DEFINES),,$(patsubst -I%,,$(KBUILD_CFLAGS))) \
+ $(ARCH_INCLUDE) $(MODE_INCLUDE) $(filter -I%,$(CFLAGS)) \
+ -D_FILE_OFFSET_BITS=64 -idirafter include \
+ -D__KERNEL__ -D__UM_HOST__
#This will adjust *FLAGS accordingly to the platform.
include $(srctree)/$(ARCH_DIR)/Makefile-os-$(OS)
--- a/arch/um/drivers/mconsole.h
+++ b/arch/um/drivers/mconsole.h
@@ -7,7 +7,7 @@
#ifndef __MCONSOLE_H__
#define __MCONSOLE_H__
-#ifndef __KERNEL__
+#ifdef __UM_HOST__
#include <stdint.h>
#define u32 uint32_t
#endif
--- a/arch/um/include/shared/init.h
+++ b/arch/um/include/shared/init.h
@@ -40,7 +40,7 @@
typedef int (*initcall_t)(void);
typedef void (*exitcall_t)(void);
-#ifndef __KERNEL__
+#ifdef __UM_HOST__
#ifndef __section
# define __section(S) __attribute__ ((__section__(#S)))
#endif
@@ -131,7 +131,7 @@ extern struct uml_param __uml_setup_star
#define __uml_postsetup_call __used __section(.uml.postsetup.init)
#define __uml_exit_call __used __section(.uml.exitcall.exit)
-#ifndef __KERNEL__
+#ifdef __UM_HOST__
#define __define_initcall(level,fn) \
static initcall_t __initcall_##fn __used \
--- a/arch/um/include/shared/user.h
+++ b/arch/um/include/shared/user.h
@@ -17,7 +17,7 @@
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
/* This is to get size_t */
-#ifdef __KERNEL__
+#ifndef __UM_HOST__
#include <linux/types.h>
#else
#include <stddef.h>
--- a/arch/x86/um/shared/sysdep/tls.h
+++ b/arch/x86/um/shared/sysdep/tls.h
@@ -1,7 +1,7 @@
#ifndef _SYSDEP_TLS_H
#define _SYSDEP_TLS_H
-# ifndef __KERNEL__
+#ifdef __UM_HOST__
/* Change name to avoid conflicts with the original one from <asm/ldt.h>, which
* may be named user_desc (but in 2.4 and in header matching its API was named
@@ -22,11 +22,11 @@ typedef struct um_dup_user_desc {
#endif
} user_desc_t;
-# else /* __KERNEL__ */
+#else /* __UM_HOST__ */
typedef struct user_desc user_desc_t;
-# endif /* __KERNEL__ */
+#endif /* __UM_HOST__ */
extern int os_set_thread_area(user_desc_t *info, int pid);
extern int os_get_thread_area(user_desc_t *info, int pid);
Patches currently in stable-queue which might be from richard(a)nod.at are
queue-3.18/um-stop-abusing-__kernel__.patch
queue-3.18/um-link-vmlinux-with-no-pie.patch
queue-3.18/um-remove-copy-paste-code-from-init.h.patch
This is a note to let you know that I've just added the patch titled
um: Remove copy&paste code from init.h
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:
um-remove-copy-paste-code-from-init.h.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 30b11ee9ae23d78de66b9ae315880af17a64ba83 Mon Sep 17 00:00:00 2001
From: Richard Weinberger <richard(a)nod.at>
Date: Sun, 31 May 2015 22:15:58 +0200
Subject: um: Remove copy&paste code from init.h
From: Richard Weinberger <richard(a)nod.at>
commit 30b11ee9ae23d78de66b9ae315880af17a64ba83 upstream.
As we got rid of the __KERNEL__ abuse, we can directly
include linux/compiler.h now.
This also allows gcc 5 to build UML.
Reported-by: Hans-Werner Hilse <hwhilse(a)gmail.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Cc: Greg Hackmann <ghackmann(a)google.com>
Cc: Bernie Innocenti <codewiz(a)google.com>
Cc: Lorenzo Colitti <lorenzo(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/um/include/shared/init.h | 22 +---------------------
1 file changed, 1 insertion(+), 21 deletions(-)
--- a/arch/um/include/shared/init.h
+++ b/arch/um/include/shared/init.h
@@ -40,28 +40,8 @@
typedef int (*initcall_t)(void);
typedef void (*exitcall_t)(void);
-#ifdef __UM_HOST__
-#ifndef __section
-# define __section(S) __attribute__ ((__section__(#S)))
-#endif
-
-#if __GNUC__ == 3
-
-#if __GNUC_MINOR__ >= 3
-# define __used __attribute__((__used__))
-#else
-# define __used __attribute__((__unused__))
-#endif
-
-#else
-#if __GNUC__ == 4
-# define __used __attribute__((__used__))
-#endif
-#endif
-
-#else
#include <linux/compiler.h>
-#endif
+
/* These are for everybody (although not all archs will actually
discard it in modules) */
#define __init __section(.init.text)
Patches currently in stable-queue which might be from richard(a)nod.at are
queue-3.18/um-stop-abusing-__kernel__.patch
queue-3.18/um-link-vmlinux-with-no-pie.patch
queue-3.18/um-remove-copy-paste-code-from-init.h.patch
This is a note to let you know that I've just added the patch titled
um: link vmlinux with -no-pie
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:
um-link-vmlinux-with-no-pie.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 883354afbc109c57f925ccc19840055193da0cc0 Mon Sep 17 00:00:00 2001
From: Thomas Meyer <thomas(a)m3y3r.de>
Date: Sun, 20 Aug 2017 13:26:04 +0200
Subject: um: link vmlinux with -no-pie
From: Thomas Meyer <thomas(a)m3y3r.de>
commit 883354afbc109c57f925ccc19840055193da0cc0 upstream.
Debian's gcc defaults to pie. The global Makefile already defines the -fno-pie option.
Link UML dynamic kernel image also with -no-pie to fix the build.
Signed-off-by: Thomas Meyer <thomas(a)m3y3r.de>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Cc: Bernie Innocenti <codewiz(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/um/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -116,7 +116,7 @@ archheaders:
archprepare: include/generated/user_constants.h
LINK-$(CONFIG_LD_SCRIPT_STATIC) += -static
-LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib
+LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib $(call cc-option, -no-pie)
CFLAGS_NO_HARDENING := $(call cc-option, -fno-PIC,) $(call cc-option, -fno-pic,) \
$(call cc-option, -fno-stack-protector,) \
Patches currently in stable-queue which might be from thomas(a)m3y3r.de are
queue-3.18/um-link-vmlinux-with-no-pie.patch
This is a note to let you know that I've just added the patch titled
Input: do not emit unneeded EV_SYN when suspending
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:
input-do-not-emit-unneeded-ev_syn-when-suspending.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 00159f19a5057cb779146afce1cceede692af346 Mon Sep 17 00:00:00 2001
From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Date: Thu, 6 Aug 2015 19:15:30 -0700
Subject: Input: do not emit unneeded EV_SYN when suspending
From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
commit 00159f19a5057cb779146afce1cceede692af346 upstream.
Do not emit EV_SYN/SYN_REPORT on suspend if there were no keys that are
still pressed as we are suspending the device (and in all other cases when
input core is forcibly releasing keys via input_dev_release_keys() call).
Reviewed-by: Benson Leung <bleung(a)chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Bo Hu <bohu(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 78d24990a816..5391abd28b27 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -674,13 +674,19 @@ EXPORT_SYMBOL(input_close_device);
*/
static void input_dev_release_keys(struct input_dev *dev)
{
+ bool need_sync = false;
int code;
if (is_event_supported(EV_KEY, dev->evbit, EV_MAX)) {
- for_each_set_bit(code, dev->key, KEY_CNT)
+ for_each_set_bit(code, dev->key, KEY_CNT) {
input_pass_event(dev, EV_KEY, code, 0);
+ need_sync = true;
+ }
+
+ if (need_sync)
+ input_pass_event(dev, EV_SYN, SYN_REPORT, 1);
+
memset(dev->key, 0, sizeof(dev->key));
- input_pass_event(dev, EV_SYN, SYN_REPORT, 1);
}
}
Patches currently in stable-queue which might be from dmitry.torokhov(a)gmail.com are
queue-3.18/input-do-not-emit-unneeded-ev_syn-when-suspending.patch
Hi Marcin,
Since it's been a week, could you confirm the patch is ok as-is or do
you think some comment(s) from James should be incorporated ?
On Tue, Jan 23, 2018 at 3:17 PM, James Hogan <jhogan(a)kernel.org> wrote:
> On Thu, Dec 21, 2017 at 10:00:59PM +0100, Mathieu Malaterre wrote:
>> From: Marcin Nowakowski <marcin.nowakowski(a)mips.com>
>>
>> Change 73fbc1eba7ff added a fix to ensure that the memory range between
>
> Please refer to commits with e.g. commit 73fbc1eba7ff ("MIPS: fix
> mem=X@Y commandline processing").
>
>> PHYS_OFFSET and low memory address specified by mem= cmdline argument is
>> not later processed by free_all_bootmem.
>> This change was incorrect for systems where the commandline specifies
>> more than 1 mem argument, as it will cause all memory between
>> PHYS_OFFSET and each of the memory offsets to be marked as reserved,
>> which results in parts of the RAM marked as reserved (Creator CI20's
>> u-boot has a default commandline argument 'mem=256M@0x0
>> mem=768M@0x30000000').
>>
>> Change the behaviour to ensure that only the range between PHYS_OFFSET
>> and the lowest start address of the memories is marked as protected.
>>
>> This change also ensures that the range is marked protected even if it's
>> only defined through the devicetree and not only via commandline
>> arguments.
>>
>> Reported-by: Mathieu Malaterre <mathieu.malaterre(a)gmail.com>
>> Signed-off-by: Marcin Nowakowski <marcin.nowakowski(a)mips.com>
>> Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing")
>> Cc: <stable(a)vger.kernel.org> # v4.11
>
> I'm guessing that should technically be v4.11+
My fault, if this is the only change, I can re-submit.
>> ---
>> v2: Use updated email adress, add tag for stable.
>> arch/mips/kernel/setup.c | 19 ++++++++++++++++---
>> 1 file changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
>> index 702c678de116..f19d61224c71 100644
>> --- a/arch/mips/kernel/setup.c
>> +++ b/arch/mips/kernel/setup.c
>> @@ -375,6 +375,7 @@ static void __init bootmem_init(void)
>> unsigned long reserved_end;
>> unsigned long mapstart = ~0UL;
>> unsigned long bootmap_size;
>> + phys_addr_t ramstart = ~0UL;
>
> Although practically it might not matter, technically phys_addr_t may be
> 64-bits (CONFIG_PHYS_ADDR_T_64BIT) even on a 32-bit kernels, in which
> case ~0UL may not be sufficiently large.
>
> Maybe that should be ~(phys_addr_t)0, or perhaps (phys_addr_t)ULLONG_MAX
> to match add_memory_region().
>
>> bool bootmap_valid = false;
>> int i;
>>
>> @@ -395,6 +396,21 @@ static void __init bootmem_init(void)
>> max_low_pfn = 0;
>>
>> /*
>> + * Reserve any memory between the start of RAM and PHYS_OFFSET
>> + */
>> + for (i = 0; i < boot_mem_map.nr_map; i++) {
>> + if (boot_mem_map.map[i].type != BOOT_MEM_RAM)
>> + continue;
>> +
>> + ramstart = min(ramstart, boot_mem_map.map[i].addr);
>
> Is it worth incorporating this into the existing loop below ...
>
>> + }
>> +
>> + if (ramstart > PHYS_OFFSET)
>> + add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET,
>> + BOOT_MEM_RESERVED);
>
> ... and this then placed below that loop?
>
> Otherwise I can't find fault with this patch, though i'm not intimately
> familiar with bootmem.
>
> Cheers
> James
>
>> +
>> +
>> + /*
>> * Find the highest page frame number we have available.
>> */
>> for (i = 0; i < boot_mem_map.nr_map; i++) {
>> @@ -664,9 +680,6 @@ static int __init early_parse_mem(char *p)
>>
>> add_memory_region(start, size, BOOT_MEM_RAM);
>>
>> - if (start && start > PHYS_OFFSET)
>> - add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
>> - BOOT_MEM_RESERVED);
>> return 0;
>> }
>> early_param("mem", early_parse_mem);
>> --
>> 2.11.0
>>
When introducing support for irqchip in userspace we needed a way to
mask the timer signal to prevent the guest continuously exiting due to a
screaming timer.
We did this by disabling the corresponding percpu interrupt on the
host interrupt controller, because we cannot rely on the host system
having a GIC, and therefore cannot make any assumptions about having an
active state to hide the timer signal.
Unfortunately, when introducing this feature, it became entirely
possible that a VCPU which belongs to a VM that has a userspace irqchip
can disable the vtimer irq on the host on some physical CPU, and then go
away without ever enabling the vimter irq on that physical CPU again.
This means that using irqchips in userspace on a system that also
supports running VMs with an in-kernel GIC can prevent forward progress
from in-kernel GIC VMs.
Later on, when we started taking virtual timer interrupts in the arch
timer code, we would also leave this timer state active for userspace
irqchip VMs, because we leave it up to a VGIC-enabled guest to
deactivate the hardware IRQ using the HW bit in the LR.
Both issues are solved by only using the enable/disable trick on systems
that do not have a host GIC which supports the active state, because all
VMs on such systems must use irqchips in userspace. Systems that have a
working GIC with support for an active state use the active state to
mask the timer signal for both userspace an in-kernel irqchips.
Cc: Alexander Graf <agraf(a)suse.de>
Cc: <stable(a)vger.kernel.org> # v4.12+
Fixes: d9e139778376 ("KVM: arm/arm64: Support arch timers with a userspace gic")
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
---
This conflicts horribly with everything when applied to either
kvmarm/queue or kvmarm/master. Therefore, this patch is written for
(and applies to) v4.15 with kvmarm/queue merged and should therefore
apply cleanly after v4.16-rc1. An example with this patch applied can
be found on kvmarm/temp-for-v4.16-rc2. I plan on sending this along
with any other potential fixes post v4.16-rc1.
virt/kvm/arm/arch_timer.c | 77 ++++++++++++++++++++++++++---------------------
1 file changed, 42 insertions(+), 35 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 70268c0bec79..228906ceb722 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -35,6 +35,7 @@
static struct timecounter *timecounter;
static unsigned int host_vtimer_irq;
static u32 host_vtimer_irq_flags;
+static bool has_gic_active_state;
static const struct kvm_irq_level default_ptimer_irq = {
.irq = 30,
@@ -69,25 +70,6 @@ static void soft_timer_cancel(struct hrtimer *hrt, struct work_struct *work)
cancel_work_sync(work);
}
-static void kvm_vtimer_update_mask_user(struct kvm_vcpu *vcpu)
-{
- struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
-
- /*
- * When using a userspace irqchip with the architected timers, we must
- * prevent continuously exiting from the guest, and therefore mask the
- * physical interrupt by disabling it on the host interrupt controller
- * when the virtual level is high, such that the guest can make
- * forward progress. Once we detect the output level being
- * de-asserted, we unmask the interrupt again so that we exit from the
- * guest when the timer fires.
- */
- if (vtimer->irq.level)
- disable_percpu_irq(host_vtimer_irq);
- else
- enable_percpu_irq(host_vtimer_irq, 0);
-}
-
static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
{
struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
@@ -107,8 +89,8 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
kvm_timer_update_irq(vcpu, true, vtimer);
if (static_branch_unlikely(&userspace_irqchip_in_use) &&
- unlikely(!irqchip_in_kernel(vcpu->kvm)))
- kvm_vtimer_update_mask_user(vcpu);
+ unlikely(!irqchip_in_kernel(vcpu->kvm)) && !has_gic_active_state)
+ disable_percpu_irq(host_vtimer_irq);
return IRQ_HANDLED;
}
@@ -460,13 +442,16 @@ static void set_cntvoff(u64 cntvoff)
kvm_call_hyp(__kvm_timer_set_cntvoff, low, high);
}
-static void kvm_timer_vcpu_load_vgic(struct kvm_vcpu *vcpu)
+static void kvm_timer_vcpu_load_gic(struct kvm_vcpu *vcpu)
{
struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
bool phys_active;
int ret;
- phys_active = kvm_vgic_map_is_active(vcpu, vtimer->irq.irq);
+ if (irqchip_in_kernel(vcpu->kvm))
+ phys_active = kvm_vgic_map_is_active(vcpu, vtimer->irq.irq);
+ else
+ phys_active = vtimer->irq.level;
ret = irq_set_irqchip_state(host_vtimer_irq,
IRQCHIP_STATE_ACTIVE,
@@ -474,9 +459,24 @@ static void kvm_timer_vcpu_load_vgic(struct kvm_vcpu *vcpu)
WARN_ON(ret);
}
-static void kvm_timer_vcpu_load_user(struct kvm_vcpu *vcpu)
+static void kvm_timer_vcpu_load_nogic(struct kvm_vcpu *vcpu)
{
- kvm_vtimer_update_mask_user(vcpu);
+ struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
+
+ /*
+ * When using a userspace irqchip with the architected timers and a
+ * host interrupt controller that doesn't support an active state, we
+ * must still we must prevent continuously exiting from the guest, and
+ * therefore mask the physical interrupt by disabling it on the host
+ * interrupt controller when the virtual level is high, such that the
+ * guest can make forward progress. Once we detect the output level
+ * being de-asserted, we unmask the interrupt again so that we exit
+ * from the guest when the timer fires.
+ */
+ if (vtimer->irq.level)
+ disable_percpu_irq(host_vtimer_irq);
+ else
+ enable_percpu_irq(host_vtimer_irq, host_vtimer_irq_flags);
}
void kvm_timer_vcpu_load(struct kvm_vcpu *vcpu)
@@ -487,10 +487,10 @@ void kvm_timer_vcpu_load(struct kvm_vcpu *vcpu)
if (unlikely(!timer->enabled))
return;
- if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
- kvm_timer_vcpu_load_user(vcpu);
+ if (has_gic_active_state)
+ kvm_timer_vcpu_load_gic(vcpu);
else
- kvm_timer_vcpu_load_vgic(vcpu);
+ kvm_timer_vcpu_load_nogic(vcpu);
set_cntvoff(vtimer->cntvoff);
@@ -555,18 +555,23 @@ static void unmask_vtimer_irq_user(struct kvm_vcpu *vcpu)
{
struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
- if (unlikely(!irqchip_in_kernel(vcpu->kvm))) {
- __timer_snapshot_state(vtimer);
- if (!kvm_timer_should_fire(vtimer)) {
- kvm_timer_update_irq(vcpu, false, vtimer);
- kvm_vtimer_update_mask_user(vcpu);
- }
+ __timer_snapshot_state(vtimer);
+ if (!kvm_timer_should_fire(vtimer)) {
+ kvm_timer_update_irq(vcpu, false, vtimer);
+ if (!has_gic_active_state)
+ enable_percpu_irq(host_vtimer_irq, host_vtimer_irq_flags);
}
}
void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
{
- unmask_vtimer_irq_user(vcpu);
+ struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+
+ if (unlikely(!timer->enabled))
+ return;
+
+ if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
+ unmask_vtimer_irq_user(vcpu);
}
int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)
@@ -753,6 +758,8 @@ int kvm_timer_hyp_init(bool has_gic)
kvm_err("kvm_arch_timer: error setting vcpu affinity\n");
goto out_free_irq;
}
+
+ has_gic_active_state = true;
}
kvm_info("virtual timer IRQ%d\n", host_vtimer_irq);
--
2.14.2
In the past the ast driver relied upon the fbdev emulation helpers to
call ->load_lut at boot-up. But since
commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
Author: Peter Rosin <peda(a)axentia.se>
Date: Tue Jul 4 12:36:57 2017 +0200
drm/fb-helper: factor out pseudo-palette
that's cleaned up and drivers are expected to boot into a consistent
lut state. This patch fixes that.
Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette")
Cc: Peter Rosin <peda(a)axenita.se>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: <stable(a)vger.kernel.org> # v4.14+
References: https://bugzilla.kernel.org/show_bug.cgi?id=198123
Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com>
---
drivers/gpu/drm/cirrus/cirrus_mode.c | 40 +++++++++++++++++++++---------------
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c b/drivers/gpu/drm/cirrus/cirrus_mode.c
index cd23b1b28259..c91b9b054e3f 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -294,22 +294,7 @@ static void cirrus_crtc_prepare(struct drm_crtc *crtc)
{
}
-/*
- * This is called after a mode is programmed. It should reverse anything done
- * by the prepare function
- */
-static void cirrus_crtc_commit(struct drm_crtc *crtc)
-{
-}
-
-/*
- * The core can pass us a set of gamma values to program. We actually only
- * use this for 8-bit mode so can't perform smooth fades on deeper modes,
- * but it's a requirement that we provide the function
- */
-static int cirrus_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
- u16 *blue, uint32_t size,
- struct drm_modeset_acquire_ctx *ctx)
+static void cirrus_crtc_load_lut(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
struct cirrus_device *cdev = dev->dev_private;
@@ -317,7 +302,7 @@ static int cirrus_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
int i;
if (!crtc->enabled)
- return 0;
+ return;
r = crtc->gamma_store;
g = r + crtc->gamma_size;
@@ -330,6 +315,27 @@ static int cirrus_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
WREG8(PALETTE_DATA, *g++ >> 8);
WREG8(PALETTE_DATA, *b++ >> 8);
}
+}
+
+/*
+ * This is called after a mode is programmed. It should reverse anything done
+ * by the prepare function
+ */
+static void cirrus_crtc_commit(struct drm_crtc *crtc)
+{
+ cirrus_crtc_load_lut(crtc);
+}
+
+/*
+ * The core can pass us a set of gamma values to program. We actually only
+ * use this for 8-bit mode so can't perform smooth fades on deeper modes,
+ * but it's a requirement that we provide the function
+ */
+static int cirrus_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
+ u16 *blue, uint32_t size,
+ struct drm_modeset_acquire_ctx *ctx)
+{
+ cirrus_crtc_load_lut(crtc);
return 0;
}
--
2.15.1
In the past the ast driver relied upon the fbdev emulation helpers to
call ->load_lut at boot-up. But since
commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
Author: Peter Rosin <peda(a)axentia.se>
Date: Tue Jul 4 12:36:57 2017 +0200
drm/fb-helper: factor out pseudo-palette
that's cleaned up and drivers are expected to boot into a consistent
lut state. This patch fixes that.
Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette")
Cc: Peter Rosin <peda(a)axenita.se>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: <stable(a)vger.kernel.org> # v4.14+
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198123
Cc: Bill Fraser <bill.fraser(a)gmail.com>
Reported-and-Tested-by: Bill Fraser <bill.fraser(a)gmail.com>
Tested-by: Konstantin Khlebnikov <koct9i(a)gmail.com>
Tested-by: Paul Tobias <tobias.pal(a)gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com>
---
drivers/gpu/drm/ast/ast_mode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 9555a3542022..831b73392d82 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -644,6 +644,7 @@ static void ast_crtc_commit(struct drm_crtc *crtc)
{
struct ast_private *ast = crtc->dev->dev_private;
ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT, 0x1, 0xdf, 0);
+ ast_crtc_load_lut(crtc);
}
--
2.15.1
The bounce buffer is gone from the MMC core, and now we found out
that there are some (crippled) i.MX boards out there that have broken
ADMA (cannot do scatter-gather), and also broken PIO so they must
use SDMA. Closer examination shows a less significant slowdown
also on SDMA-only capable Laptop hosts.
SDMA sets down the number of segments to one, so that each segment
gets turned into a singular request that ping-pongs to the block
layer before the next request/segment is issued.
Apparently it happens a lot that the block layer send requests
that include a lot of physically discontiguous segments. My guess
is that this phenomenon is coming from the file system.
These devices that cannot handle scatterlists in hardware can see
major benefits from a DMA-contiguous bounce buffer.
This patch accumulates those fragmented scatterlists in a physically
contiguous bounce buffer so that we can issue bigger DMA data chunks
to/from the card.
When tested with a PCI-integrated host (1217:8221) that
only supports SDMA:
0b:00.0 SD Host controller: O2 Micro, Inc. OZ600FJ0/OZ900FJ0/OZ600FJS
SD/MMC Card Reader Controller (rev 05)
This patch gave ~1Mbyte/s improved throughput on large reads and
writes when testing using iozone than without the patch.
dmesg:
sdhci-pci 0000:0b:00.0: SDHCI controller found [1217:8221] (rev 5)
mmc0 bounce up to 128 segments into one, max segment size 65536 bytes
mmc0: SDHCI controller on PCI [0000:0b:00.0] using DMA
On the i.MX SDHCI controllers on the crippled i.MX 25 and i.MX 35
the patch restores the performance to what it was before we removed
the bounce buffers.
Cc: Pierre Ossman <pierre(a)ossman.eu>
Cc: Benoît Thébaudeau <benoit(a)wsystem.com>
Cc: Fabio Estevam <fabio.estevam(a)nxp.com>
Cc: Benjamin Beckmeyer <beckmeyer.b(a)rittal.de>
Cc: stable(a)vger.kernel.org # v4.14+
Fixes: de3ee99b097d ("mmc: Delete bounce buffer handling")
Tested-by: Benjamin Beckmeyer <beckmeyer.b(a)rittal.de>
Acked-by: Adrian Hunter <adrian.hunter(a)intel.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
---
ChangeLog v7->v8:
- Fixed bad information and spelling mistakes in the commit
message.
- Use sdhci_sdma_address() in one more spot identified by Adrian.
- Collected Adrian's ACK.
ChangeLog v6->v7:
- Fix the directions on dma_sync_for[device|cpu]() so the
ownership of the buffer gets swapped properly and in the right
direction for every transfer. Didn't see this because x86 PCI is
DMA coherent...
- Tested and greelighted on i.MX 25.
- Also tested on the PCI version.
ChangeLog v5->v6:
- Again switch back to explicit sync of buffers. I want to get this
solution to work because it gives more control and it's more
elegant.
- Update host->max_req_size as noted by Adrian, hopefully this
fixes the i.MX. I was just lucky on my Intel laptop I guess:
the block stack never requested anything bigger than 64KB and
that was why it worked even if max_req_size was bigger than
what would fit in the bounce buffer.
- Copy the number of bytes in the mmc_data instead of the number
of bytes in the bounce buffer. For RX this is blksize * blocks
and for TX this is bytes_xfered.
- Break out a sdhci_sdma_address() for getting the DMA address
for either the raw sglist or the bounce buffer depending on
configuration.
- Add some explicit bounds check for the data so that we do not
attempt to copy more than the bounce buffer size even if the
block layer is erroneously configured.
- Move allocation of bounce buffer out to its own function.
- Use pr_[info|err] throughout so all debug prints from the
driver come out in the same manner and style.
- Use unsigned int for the bounce buffer size.
- Re-tested with iozone: we still get the same nice performance
improvements.
- Request a text on i.MX (hi Benjamin)
ChangeLog v4->v5:
- Go back to dma_alloc_coherent() as this apparently works better.
- Keep the other changes, cap for 64KB, fall back to single segments.
- Requesting a test of this on i.MX. (Sorry Benjamin.)
ChangeLog v3->v4:
- Cap the bounce buffer to 64KB instead of the biggest segment
as we experience diminishing returns with buffers > 64KB.
- Instead of using dma_alloc_coherent(), use good old devm_kmalloc()
and issue dma_sync_single_for*() to explicitly switch
ownership between CPU and the device. This way we exercise the
cache better and may consume less CPU.
- Bail out with single segments if we cannot allocate a bounce
buffer.
- Tested on the PCI SDHCI on my laptop: requesting a new test
on i.MX from Benjamin. (Please!)
ChangeLog v2->v3:
- Rewrite the commit message a bit
- Add Benjamin's Tested-by
- Add Fixes and stable tags
ChangeLog v1->v2:
- Skip the remapping and fiddling with the buffer, instead use
dma_alloc_coherent() and use a simple, coherent bounce buffer.
- Couple kernel messages to ->parent of the mmc_host as it relates
to the hardware characteristics.
---
drivers/mmc/host/sdhci.c | 164 ++++++++++++++++++++++++++++++++++++++++++++---
drivers/mmc/host/sdhci.h | 3 +
2 files changed, 159 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index e9290a3439d5..d24306b2b839 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -21,6 +21,7 @@
#include <linux/dma-mapping.h>
#include <linux/slab.h>
#include <linux/scatterlist.h>
+#include <linux/sizes.h>
#include <linux/swiotlb.h>
#include <linux/regulator/consumer.h>
#include <linux/pm_runtime.h>
@@ -502,8 +503,35 @@ static int sdhci_pre_dma_transfer(struct sdhci_host *host,
if (data->host_cookie == COOKIE_PRE_MAPPED)
return data->sg_count;
- sg_count = dma_map_sg(mmc_dev(host->mmc), data->sg, data->sg_len,
- mmc_get_dma_dir(data));
+ /* Bounce write requests to the bounce buffer */
+ if (host->bounce_buffer) {
+ unsigned int length = data->blksz * data->blocks;
+
+ if (length > host->bounce_buffer_size) {
+ pr_err("%s: asked for transfer of %u bytes exceeds bounce buffer %u bytes\n",
+ mmc_hostname(host->mmc), length,
+ host->bounce_buffer_size);
+ return -EIO;
+ }
+ if (mmc_get_dma_dir(data) == DMA_TO_DEVICE) {
+ /* Copy the data to the bounce buffer */
+ sg_copy_to_buffer(data->sg, data->sg_len,
+ host->bounce_buffer,
+ length);
+ }
+ /* Switch ownership to the DMA */
+ dma_sync_single_for_device(host->mmc->parent,
+ host->bounce_addr,
+ host->bounce_buffer_size,
+ mmc_get_dma_dir(data));
+ /* Just a dummy value */
+ sg_count = 1;
+ } else {
+ /* Just access the data directly from memory */
+ sg_count = dma_map_sg(mmc_dev(host->mmc),
+ data->sg, data->sg_len,
+ mmc_get_dma_dir(data));
+ }
if (sg_count == 0)
return -ENOSPC;
@@ -673,6 +701,14 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
}
}
+static u32 sdhci_sdma_address(struct sdhci_host *host)
+{
+ if (host->bounce_buffer)
+ return host->bounce_addr;
+ else
+ return sg_dma_address(host->data->sg);
+}
+
static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
{
u8 count;
@@ -858,8 +894,8 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd)
SDHCI_ADMA_ADDRESS_HI);
} else {
WARN_ON(sg_cnt != 1);
- sdhci_writel(host, sg_dma_address(data->sg),
- SDHCI_DMA_ADDRESS);
+ sdhci_writel(host, sdhci_sdma_address(host),
+ SDHCI_DMA_ADDRESS);
}
}
@@ -2248,7 +2284,12 @@ static void sdhci_pre_req(struct mmc_host *mmc, struct mmc_request *mrq)
mrq->data->host_cookie = COOKIE_UNMAPPED;
- if (host->flags & SDHCI_REQ_USE_DMA)
+ /*
+ * No pre-mapping in the pre hook if we're using the bounce buffer,
+ * for that we would need two bounce buffers since one buffer is
+ * in flight when this is getting called.
+ */
+ if (host->flags & SDHCI_REQ_USE_DMA && !host->bounce_buffer)
sdhci_pre_dma_transfer(host, mrq->data, COOKIE_PRE_MAPPED);
}
@@ -2352,8 +2393,45 @@ static bool sdhci_request_done(struct sdhci_host *host)
struct mmc_data *data = mrq->data;
if (data && data->host_cookie == COOKIE_MAPPED) {
- dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len,
- mmc_get_dma_dir(data));
+ if (host->bounce_buffer) {
+ /*
+ * On reads, copy the bounced data into the
+ * sglist
+ */
+ if (mmc_get_dma_dir(data) == DMA_FROM_DEVICE) {
+ unsigned int length = data->bytes_xfered;
+
+ if (length > host->bounce_buffer_size) {
+ pr_err("%s: bounce buffer is %u bytes but DMA claims to have transferred %u bytes\n",
+ mmc_hostname(host->mmc),
+ host->bounce_buffer_size,
+ data->bytes_xfered);
+ /* Cap it down and continue */
+ length = host->bounce_buffer_size;
+ }
+ dma_sync_single_for_cpu(
+ host->mmc->parent,
+ host->bounce_addr,
+ host->bounce_buffer_size,
+ DMA_FROM_DEVICE);
+ sg_copy_from_buffer(data->sg,
+ data->sg_len,
+ host->bounce_buffer,
+ length);
+ } else {
+ /* No copying, just switch ownership */
+ dma_sync_single_for_cpu(
+ host->mmc->parent,
+ host->bounce_addr,
+ host->bounce_buffer_size,
+ mmc_get_dma_dir(data));
+ }
+ } else {
+ /* Unmap the raw data */
+ dma_unmap_sg(mmc_dev(host->mmc), data->sg,
+ data->sg_len,
+ mmc_get_dma_dir(data));
+ }
data->host_cookie = COOKIE_UNMAPPED;
}
}
@@ -2636,7 +2714,8 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
*/
if (intmask & SDHCI_INT_DMA_END) {
u32 dmastart, dmanow;
- dmastart = sg_dma_address(host->data->sg);
+
+ dmastart = sdhci_sdma_address(host);
dmanow = dmastart + host->data->bytes_xfered;
/*
* Force update to the next DMA block boundary.
@@ -3217,6 +3296,68 @@ void __sdhci_read_caps(struct sdhci_host *host, u16 *ver, u32 *caps, u32 *caps1)
}
EXPORT_SYMBOL_GPL(__sdhci_read_caps);
+static int sdhci_allocate_bounce_buffer(struct sdhci_host *host)
+{
+ struct mmc_host *mmc = host->mmc;
+ unsigned int max_blocks;
+ unsigned int bounce_size;
+ int ret;
+
+ /*
+ * Cap the bounce buffer at 64KB. Using a bigger bounce buffer
+ * has diminishing returns, this is probably because SD/MMC
+ * cards are usually optimized to handle this size of requests.
+ */
+ bounce_size = SZ_64K;
+ /*
+ * Adjust downwards to maximum request size if this is less
+ * than our segment size, else hammer down the maximum
+ * request size to the maximum buffer size.
+ */
+ if (mmc->max_req_size < bounce_size)
+ bounce_size = mmc->max_req_size;
+ max_blocks = bounce_size / 512;
+
+ /*
+ * When we just support one segment, we can get significant
+ * speedups by the help of a bounce buffer to group scattered
+ * reads/writes together.
+ */
+ host->bounce_buffer = devm_kmalloc(mmc->parent,
+ bounce_size,
+ GFP_KERNEL);
+ if (!host->bounce_buffer) {
+ pr_err("%s: failed to allocate %u bytes for bounce buffer, falling back to single segments\n",
+ mmc_hostname(mmc),
+ bounce_size);
+ /*
+ * Exiting with zero here makes sure we proceed with
+ * mmc->max_segs == 1.
+ */
+ return 0;
+ }
+
+ host->bounce_addr = dma_map_single(mmc->parent,
+ host->bounce_buffer,
+ bounce_size,
+ DMA_BIDIRECTIONAL);
+ ret = dma_mapping_error(mmc->parent, host->bounce_addr);
+ if (ret)
+ /* Again fall back to max_segs == 1 */
+ return 0;
+ host->bounce_buffer_size = bounce_size;
+
+ /* Lie about this since we're bouncing */
+ mmc->max_segs = max_blocks;
+ mmc->max_seg_size = bounce_size;
+ mmc->max_req_size = bounce_size;
+
+ pr_info("%s bounce up to %u segments into one, max segment size %u bytes\n",
+ mmc_hostname(mmc), max_blocks, bounce_size);
+
+ return 0;
+}
+
int sdhci_setup_host(struct sdhci_host *host)
{
struct mmc_host *mmc;
@@ -3713,6 +3854,13 @@ int sdhci_setup_host(struct sdhci_host *host)
*/
mmc->max_blk_count = (host->quirks & SDHCI_QUIRK_NO_MULTIBLOCK) ? 1 : 65535;
+ if (mmc->max_segs == 1) {
+ /* This may alter mmc->*_blk_* parameters */
+ ret = sdhci_allocate_bounce_buffer(host);
+ if (ret)
+ return ret;
+ }
+
return 0;
unreg:
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 54bc444c317f..1d7d61e25dbf 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -440,6 +440,9 @@ struct sdhci_host {
int irq; /* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
+ char *bounce_buffer; /* For packing SDMA reads/writes */
+ dma_addr_t bounce_addr;
+ unsigned int bounce_buffer_size;
const struct sdhci_ops *ops; /* Low level hw interface */
--
2.14.3
From: James Morse <james.morse(a)arm.com>
cpu_pm_enter() calls the pm notifier chain with CPU_PM_ENTER, then if
there is a failure: CPU_PM_ENTER_FAILED.
When KVM receives CPU_PM_ENTER it calls cpu_hyp_reset() which will
return us to the hyp-stub. If we subsequently get a CPU_PM_ENTER_FAILED,
KVM does nothing, leaving the CPU running with the hyp-stub, at odds
with kvm_arm_hardware_enabled.
Add CPU_PM_ENTER_FAILED as a fallthrough for CPU_PM_EXIT, this reloads
KVM based on kvm_arm_hardware_enabled. This is safe even if CPU_PM_ENTER
never gets as far as KVM, as cpu_hyp_reinit() calls cpu_hyp_reset()
to make sure the hyp-stub is loaded before reloading KVM.
Fixes: 67f691976662 ("arm64: kvm: allows kvm cpu hotplug")
Cc: <stable(a)vger.kernel.org> # v4.7+
CC: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: James Morse <james.morse(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
---
virt/kvm/arm/arm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index 59d8e04c19fa..639dca0c0560 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -1262,6 +1262,7 @@ static int hyp_init_cpu_pm_notifier(struct notifier_block *self,
cpu_hyp_reset();
return NOTIFY_OK;
+ case CPU_PM_ENTER_FAILED:
case CPU_PM_EXIT:
if (__this_cpu_read(kvm_arm_hardware_enabled))
/* The hardware was enabled before suspend. */
--
2.14.2
From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com>
[ Upstream commit 56026645e2b6f11ede34a5e6ab69d3eb56f9c8fc ]
After commit aa7519af450d (cpufreq: Use transition_delay_us for legacy
governors as well) the sampling_rate field of struct dbs_data may be
less than the tick period which causes dbs_update() to produce
incorrect results, so make the code ensure that the value of that
field will always be sufficiently large.
Cc: 4.14 <stable(a)vger.kernel.org> # 4.14
Fixes: aa7519af450d (cpufreq: Use transition_delay_us for legacy governors as well)
Reported-by: Andy Tang <andy.tang(a)nxp.com>
Reported-by: Doug Smythies <dsmythies(a)telus.net>
Tested-by: Andy Tang <andy.tang(a)nxp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
drivers/cpufreq/cpufreq_governor.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 58d4f4e1ad6a..ca38229b045a 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -22,6 +22,8 @@
#include "cpufreq_governor.h"
+#define CPUFREQ_DBS_MIN_SAMPLING_INTERVAL (2 * TICK_NSEC / NSEC_PER_USEC)
+
static DEFINE_PER_CPU(struct cpu_dbs_info, cpu_dbs);
static DEFINE_MUTEX(gov_dbs_data_mutex);
@@ -47,11 +49,15 @@ ssize_t store_sampling_rate(struct gov_attr_set *attr_set, const char *buf,
{
struct dbs_data *dbs_data = to_dbs_data(attr_set);
struct policy_dbs_info *policy_dbs;
+ unsigned int sampling_interval;
int ret;
- ret = sscanf(buf, "%u", &dbs_data->sampling_rate);
- if (ret != 1)
+
+ ret = sscanf(buf, "%u", &sampling_interval);
+ if (ret != 1 || sampling_interval < CPUFREQ_DBS_MIN_SAMPLING_INTERVAL)
return -EINVAL;
+ dbs_data->sampling_rate = sampling_interval;
+
/*
* We are operating under dbs_data->mutex and so the list and its
* entries can't be freed concurrently.
@@ -430,7 +436,14 @@ int cpufreq_dbs_governor_init(struct cpufreq_policy *policy)
if (ret)
goto free_policy_dbs_info;
- dbs_data->sampling_rate = cpufreq_policy_transition_delay_us(policy);
+ /*
+ * The sampling interval should not be less than the transition latency
+ * of the CPU and it also cannot be too small for dbs_update() to work
+ * correctly.
+ */
+ dbs_data->sampling_rate = max_t(unsigned int,
+ CPUFREQ_DBS_MIN_SAMPLING_INTERVAL,
+ cpufreq_policy_transition_delay_us(policy));
if (!have_governor_per_policy())
gov->gdbs_data = dbs_data;
--
2.15.0.194.g9af6a3dea062
This is the start of the stable review cycle for the 3.18.93 release.
There are 52 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 Jan 31 12:36:07 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.93-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 3.18.93-rc1
Jim Westfall <jwestfall(a)surrealistic.net>
ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY
Mike Maloney <maloney(a)google.com>
ipv6: fix udpv6 sendmsg crash caused by too small MTU
Jim Westfall <jwestfall(a)surrealistic.net>
net: Allow neigh contructor functions ability to modify the primary_key
Neil Horman <nhorman(a)tuxdriver.com>
vmxnet3: repair memory leak
Xin Long <lucien.xin(a)gmail.com>
sctp: return error if the asoc has been peeled off in sctp_wait_for_sndbuf
Xin Long <lucien.xin(a)gmail.com>
sctp: do not allow the v4 socket to bind a v4mapped v6 address
Guillaume Nault <g.nault(a)alphalink.fr>
pppoe: take ->needed_headroom of lower device into account on xmit
Eric Dumazet <edumazet(a)google.com>
net: qdisc_pkt_len_init() should be more robust
Craig Gallek <kraig(a)google.com>
tcp: __tcp_hdrlen() helper
Felix Fietkau <nbd(a)nbd.name>
net: igmp: fix source address check for IGMPv3 reports
Alexey Kodanev <alexey.kodanev(a)oracle.com>
dccp: don't restart ccid2_hc_tx_rto_expire() if sk in closed state
Dan Streetman <ddstreet(a)ieee.org>
net: tcp: close sock if net namespace is exiting
Jia Zhang <zhang.jia(a)linux.alibaba.com>
x86/microcode/intel: Extend BDW late-loading further with LLC size check
Richard Weinberger <richard(a)nod.at>
um: Remove copy&paste code from init.h
Richard Weinberger <richard(a)nod.at>
um: Stop abusing __KERNEL__
Greg KH <gregkh(a)linuxfoundation.org>
eventpoll.h: add missing epoll event masks
Thomas Meyer <thomas(a)m3y3r.de>
um: link vmlinux with -no-pie
Johannes Thumshirn <jthumshirn(a)suse.de>
scsi: libiscsi: fix shifting of DID_REQUEUE host byte
Jiri Slaby <jslaby(a)suse.cz>
fs/fcntl: f_setown, avoid undefined behaviour
Jeff Mahoney <jeffm(a)suse.com>
reiserfs: don't preallocate blocks for extended attributes
Jeff Mahoney <jeffm(a)suse.com>
reiserfs: fix race in prealloc discard
Kevin Cernekee <cernekee(a)chromium.org>
netfilter: xt_osf: Add missing permission checks
Kevin Cernekee <cernekee(a)chromium.org>
netfilter: nfnetlink_cthelper: Add missing permission checks
Ulrich Weber <ulrich.weber(a)riverbed.com>
netfilter: nf_conntrack_sip: extend request line validation
Florian Westphal <fw(a)strlen.de>
netfilter: restart search if moved to other chain
Liping Zhang <liping.zhang(a)spreadtrum.com>
netfilter: nf_ct_expect: remove the redundant slash when policy name is empty
Jiri Slaby <jslaby(a)suse.cz>
ipc: msg, make msgrcv work with LONG_MIN
Michal Hocko <mhocko(a)suse.com>
hwpoison, memcg: forcibly uncharge LRU pages
Michal Hocko <mhocko(a)suse.com>
mm/mmap.c: do not blow on PROT_NONE MAP_FIXED holes in the stack
Marc Kleine-Budde <mkl(a)pengutronix.de>
can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once
Marc Kleine-Budde <mkl(a)pengutronix.de>
can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
Jonathan Dieter <jdieter(a)lesbg.com>
usbip: Fix implicit fallthrough warning
Andy Lutomirski <luto(a)kernel.org>
x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
Jonas Gorski <jonas.gorski(a)gmail.com>
MIPS: AR7: ensure the port type's FCR value is used
Marc Zyngier <marc.zyngier(a)arm.com>
arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
Dennis Yang <dennisyang(a)qnap.com>
dm thin metadata: THIN_MAX_CONCURRENT_LOCKS should be 6
Joe Thornber <thornber(a)redhat.com>
dm btree: fix serious bug in btree_split_beneath()
Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
ARM: dts: kirkwood: fix pin-muxing of MPP7 on OpenBlocks A7
Arnd Bergmann <arnd(a)arndb.de>
phy: work around 'phys' references to usb-nop-xceiv devices
Johan Hovold <johan(a)kernel.org>
Input: twl4030-vibra - fix sibling-node lookup
Marek Belisko <marek(a)goldelico.com>
Input: twl4030-vibra - fix ERROR: Bad of_node_put() warning
Johan Hovold <johan(a)kernel.org>
Input: twl6040-vibra - fix child-node lookup
H. Nikolaus Schaller <hns(a)goldelico.com>
Input: twl6040-vibra - fix DT node memory management
Johan Hovold <johan(a)kernel.org>
Input: 88pm860x-ts - fix child-node lookup
Joe Lawrence <joe.lawrence(a)redhat.com>
pipe: avoid round_pipe_size() nr_pages overflow on 32-bit
Eric Biggers <ebiggers(a)google.com>
af_key: fix buffer overread in parse_exthdrs()
Eric Biggers <ebiggers(a)google.com>
af_key: fix buffer overread in verify_address_len()
Takashi Iwai <tiwai(a)suse.de>
ALSA: hda - Apply the existing quirk to iMac 14,1
Takashi Iwai <tiwai(a)suse.de>
ALSA: pcm: Remove yet superfluous WARN_ON()
Li Jinyue <lijinyue(a)huawei.com>
futex: Prevent overflow by strengthen input validation
Hannes Reinecke <hare(a)suse.de>
scsi: sg: disable SET_FORCE_LOW_DMA
Arnd Bergmann <arnd(a)arndb.de>
gcov: disable for COMPILE_TEST
-------------
Diffstat:
Makefile | 4 ++--
arch/arm/boot/dts/kirkwood-openblocks_a7.dts | 10 ++++++++--
arch/arm64/kvm/handle_exit.c | 4 ++--
arch/mips/ar7/platform.c | 2 +-
arch/um/Makefile | 9 +++++----
arch/um/drivers/mconsole.h | 2 +-
arch/um/include/shared/init.h | 24 ++--------------------
arch/um/include/shared/user.h | 2 +-
arch/x86/include/asm/processor.h | 2 +-
arch/x86/kernel/cpu/microcode/intel.c | 20 +++++++++++++++++--
arch/x86/um/shared/sysdep/tls.h | 6 +++---
drivers/input/misc/twl4030-vibra.c | 7 +++++--
drivers/input/misc/twl6040-vibra.c | 2 +-
drivers/input/touchscreen/88pm860x-ts.c | 16 +++++++++++----
drivers/md/dm-thin-metadata.c | 6 +++++-
drivers/md/persistent-data/dm-btree.c | 19 ++----------------
drivers/net/ppp/pppoe.c | 11 +++++-----
drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
drivers/phy/phy-core.c | 4 ++++
drivers/scsi/libiscsi.c | 2 +-
drivers/scsi/sg.c | 30 +++++++++-------------------
fs/fcntl.c | 4 ++++
fs/pipe.c | 18 +++++++++++++++--
fs/reiserfs/bitmap.c | 14 ++++++++++---
include/linux/tcp.h | 7 ++++++-
include/net/arp.h | 3 +++
include/net/net_namespace.h | 10 ++++++++++
include/scsi/sg.h | 1 -
include/uapi/linux/eventpoll.h | 13 ++++++++++++
ipc/msg.c | 5 ++++-
kernel/futex.c | 3 +++
kernel/gcov/Kconfig | 1 +
mm/memcontrol.c | 2 +-
mm/memory-failure.c | 7 +++++++
mm/mmap.c | 6 ++++--
net/can/af_can.c | 22 ++++++++++----------
net/core/dev.c | 19 ++++++++++++++----
net/core/neighbour.c | 4 ++--
net/dccp/ccids/ccid2.c | 3 +++
net/ipv4/arp.c | 7 ++++++-
net/ipv4/igmp.c | 2 +-
net/ipv4/tcp.c | 3 +++
net/ipv4/tcp_timer.c | 15 ++++++++++++++
net/ipv6/ip6_output.c | 6 ++++--
net/key/af_key.c | 8 ++++++++
net/netfilter/nf_conntrack_core.c | 7 +++++++
net/netfilter/nf_conntrack_expect.c | 2 +-
net/netfilter/nf_conntrack_sip.c | 5 ++++-
net/netfilter/nfnetlink_cthelper.c | 10 ++++++++++
net/netfilter/xt_osf.c | 7 +++++++
net/sctp/socket.c | 30 +++++++++++-----------------
sound/core/pcm_lib.c | 1 -
sound/pci/hda/patch_cirrus.c | 1 +
tools/usb/usbip/src/usbip.c | 2 ++
54 files changed, 284 insertions(+), 148 deletions(-)
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: v4l2-compat-ioctl32.c: make ctrl_is_pointer work for subdevs
Author: Hans Verkuil <hansverk(a)cisco.com>
Date: Tue Jan 30 10:18:32 2018 -0500
If the device is of type VFL_TYPE_SUBDEV then vdev->ioctl_ops
is NULL so the 'if (!ops->vidioc_query_ext_ctrl)' check would crash.
Add a test for !ops to the condition.
All sub-devices that have controls will use the control framework,
so they do not have an equivalent to ops->vidioc_query_ext_ctrl.
Returning false if ops is NULL is the correct thing to do here.
Fixes: b8c601e8af ("v4l2-compat-ioctl32.c: fix ctrl_is_pointer")
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Reported-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Cc: <stable(a)vger.kernel.org> # for v4.15 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index bdb5c226d01c..5198c9eeb348 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -770,7 +770,7 @@ static inline bool ctrl_is_pointer(struct file *file, u32 id)
return ctrl && ctrl->is_ptr;
}
- if (!ops->vidioc_query_ext_ctrl)
+ if (!ops || !ops->vidioc_query_ext_ctrl)
return false;
return !ops->vidioc_query_ext_ctrl(file, fh, &qec) &&
The fcp_rsp_info structure as defined in the FC spec has an initial 3 bytes
reserved field. The ibmvfc driver mistakenly defined this field as 4 bytes
resulting in the rsp_code field being defined in what should be the start of
the second reserved field and thus always being reported as zero by the
driver.
Ideally, we should wire ibmvfc up with libfc for the sake of code
deduplication, and ease of maintaining standardized structures in a single
place. However, for now simply fixup the definition in ibmvfc for
backporting to distros on older kernels. Wiring up with libfc will be done
in a followup patch.
Cc: stable(a)vger.kernel.org
Reported-by: Hannes Reinecke <hare(a)suse.de>
Signed-off-by: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
---
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.h b/drivers/scsi/ibmvscsi/ibmvfc.h
index 9a0696f..b81a53c 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.h
+++ b/drivers/scsi/ibmvscsi/ibmvfc.h
@@ -367,7 +367,7 @@ enum ibmvfc_fcp_rsp_info_codes {
};
struct ibmvfc_fcp_rsp_info {
- __be16 reserved;
+ u8 reserved[3];
u8 rsp_code;
u8 reserved2[4];
}__attribute__((packed, aligned (2)));
--
2.7.4
commit 1005bccd7a4a ("crypto: caam - enable instantiation of all RNG4 state
handles") introduces a control when incrementing ent_delay which contains
the following comment above it:
/*
* If either SH were instantiated by somebody else
* (e.g. u-boot) then it is assumed that the entropy
* parameters are properly set and thus the function
* setting these (kick_trng(...)) is skipped.
* Also, if a handle was instantiated, do not change
* the TRNG parameters.
*/
This is a problem observed when sec_init() has been run in u-boot and
and TrustZone is enabled. We can fix this by instantiating all rng state
handles in u-boot but, on the Kernel side we should ensure that this
non-terminating path is dealt with.
Fixes: 1005bccd7a4a ("crypto: caam - enable instantiation of all RNG4 state
handles")
Reported-by: Ryan Harkin <ryan.harkin(a)linaro.org>
Cc: "Horia Geantă" <horia.geanta(a)nxp.com>
Cc: Aymen Sghaier <aymen.sghaier(a)nxp.com>
Cc: Fabio Estevam <fabio.estevam(a)nxp.com>
Cc: Peng Fan <peng.fan(a)nxp.com>
Cc: "David S. Miller" <davem(a)davemloft.net>
Cc: Lukas Auer <lukas.auer(a)aisec.fraunhofer.de>
Cc: <stable(a)vger.kernel.org> # 4.12+
Signed-off-by: Bryan O'Donoghue <pure.logic(a)nexus-software.ie>
---
drivers/crypto/caam/ctrl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 98986d3..0a1e96b 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -704,7 +704,10 @@ static int caam_probe(struct platform_device *pdev)
ent_delay);
kick_trng(pdev, ent_delay);
ent_delay += 400;
+ } else if (ctrlpriv->rng4_sh_init && inst_handles) {
+ ent_delay += 400;
}
+
/*
* if instantiate_rng(...) fails, the loop will rerun
* and the kick_trng(...) function will modfiy the
--
2.7.4
The patch titled
Subject: mm, memory_hotplug: fix memmap initialization
has been added to the -mm tree. Its filename is
mm-memory_hotplug-fix-memmap-initialization.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-memory_hotplug-fix-memmap-initi…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-memory_hotplug-fix-memmap-initi…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Michal Hocko <mhocko(a)suse.com>
Subject: mm, memory_hotplug: fix memmap initialization
Bharata has noticed that onlining a newly added memory doesn't increase
the total memory, pointing to f7f99100d8d9 ("mm: stop zeroing memory
during allocation in vmemmap") as a culprit. This commit has changed the
way how the memory for memmaps is initialized and moves it from the
allocation time to the initialization time. This works properly for the
early memmap init path.
It doesn't work for the memory hotplug though because we need to mark page
as reserved when the sparsemem section is created and later initialize it
completely during onlining. memmap_init_zone is called in the early stage
of onlining. With the current code it calls __init_single_page and as
such it clears up the whole stage and therefore online_pages_range skips
those pages.
Fix this by skipping mm_zero_struct_page in __init_single_page for memory
hotplug path. This is quite uggly but unifying both early init and memory
hotplug init paths is a large project. Make sure we plug the regression
at least.
Link: http://lkml.kernel.org/r/20180130101141.GW21609@dhcp22.suse.cz
Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: Bharata B Rao <bharata(a)linux.vnet.ibm.com>
Tested-by: Bharata B Rao <bharata(a)linux.vnet.ibm.com>
Reviewed-by: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Cc: Steven Sistare <steven.sistare(a)oracle.com>
Cc: Daniel Jordan <daniel.m.jordan(a)oracle.com>
Cc: Bob Picco <bob.picco(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_alloc.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff -puN mm/page_alloc.c~mm-memory_hotplug-fix-memmap-initialization mm/page_alloc.c
--- a/mm/page_alloc.c~mm-memory_hotplug-fix-memmap-initialization
+++ a/mm/page_alloc.c
@@ -1178,9 +1178,10 @@ static void free_one_page(struct zone *z
}
static void __meminit __init_single_page(struct page *page, unsigned long pfn,
- unsigned long zone, int nid)
+ unsigned long zone, int nid, bool zero)
{
- mm_zero_struct_page(page);
+ if (zero)
+ mm_zero_struct_page(page);
set_page_links(page, zone, nid, pfn);
init_page_count(page);
page_mapcount_reset(page);
@@ -1195,9 +1196,9 @@ static void __meminit __init_single_page
}
static void __meminit __init_single_pfn(unsigned long pfn, unsigned long zone,
- int nid)
+ int nid, bool zero)
{
- return __init_single_page(pfn_to_page(pfn), pfn, zone, nid);
+ return __init_single_page(pfn_to_page(pfn), pfn, zone, nid, zero);
}
#ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
@@ -1218,7 +1219,7 @@ static void __meminit init_reserved_page
if (pfn >= zone->zone_start_pfn && pfn < zone_end_pfn(zone))
break;
}
- __init_single_pfn(pfn, zid, nid);
+ __init_single_pfn(pfn, zid, nid, true);
}
#else
static inline void init_reserved_page(unsigned long pfn)
@@ -1535,7 +1536,7 @@ static unsigned long __init deferred_in
} else {
page++;
}
- __init_single_page(page, pfn, zid, nid);
+ __init_single_page(page, pfn, zid, nid, true);
nr_pages++;
}
return (nr_pages);
@@ -5400,15 +5401,20 @@ not_early:
* can be created for invalid pages (for alignment)
* check here not to call set_pageblock_migratetype() against
* pfn out of zone.
+ *
+ * Please note that MEMMAP_HOTPLUG path doesn't clear memmap
+ * because this is done early in sparse_add_one_section
*/
if (!(pfn & (pageblock_nr_pages - 1))) {
struct page *page = pfn_to_page(pfn);
- __init_single_page(page, pfn, zone, nid);
+ __init_single_page(page, pfn, zone, nid,
+ context != MEMMAP_HOTPLUG);
set_pageblock_migratetype(page, MIGRATE_MOVABLE);
cond_resched();
} else {
- __init_single_pfn(pfn, zone, nid);
+ __init_single_pfn(pfn, zone, nid,
+ context != MEMMAP_HOTPLUG);
}
}
}
_
Patches currently in -mm which might be from mhocko(a)suse.com are
mm-drop-hotplug-lock-from-lru_add_drain_all.patch
mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix-2.patch
mm-hugetlb-drop-hugepages_treat_as_movable-sysctl.patch
mm-introduce-map_fixed_safe.patch
fs-elf-drop-map_fixed-usage-from-elf_map.patch
fs-elf-drop-map_fixed-usage-from-elf_map-fix-fix.patch
mm-numa-rework-do_pages_move.patch
mm-migrate-remove-reason-argument-from-new_page_t.patch
mm-migrate-remove-reason-argument-from-new_page_t-fix-3.patch
mm-unclutter-thp-migration.patch
mm-hugetlb-unify-core-page-allocation-accounting-and-initialization.patch
mm-hugetlb-integrate-giga-hugetlb-more-naturally-to-the-allocation-path.patch
mm-hugetlb-do-not-rely-on-overcommit-limit-during-migration.patch
mm-hugetlb-get-rid-of-surplus-page-accounting-tricks.patch
mm-hugetlb-further-simplify-hugetlb-allocation-api.patch
hugetlb-mempolicy-fix-the-mbind-hugetlb-migration.patch
hugetlb-mbind-fall-back-to-default-policy-if-vma-is-null.patch
mm-memory_hotplug-fix-memmap-initialization.patch
This is the start of the stable review cycle for the 4.14.16 release.
There are 71 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 Jan 31 12:37:59 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.16-rc1.gz
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.16-rc1
Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
cpufreq: governor: Ensure sufficiently large sampling intervals
Daniel Borkmann <daniel(a)iogearbox.net>
bpf, arm64: fix stack_depth tracking in combination with tail calls
Daniel Borkmann <daniel(a)iogearbox.net>
bpf: reject stores into ctx via st and xadd
Alexei Starovoitov <ast(a)kernel.org>
bpf: fix 32-bit divide by zero
Eric Dumazet <edumazet(a)google.com>
bpf: fix divides by zero
Daniel Borkmann <daniel(a)iogearbox.net>
bpf: avoid false sharing of map refcount with max_entries
Alexei Starovoitov <ast(a)kernel.org>
bpf: introduce BPF_JIT_ALWAYS_ON config
Thomas Gleixner <tglx(a)linutronix.de>
hrtimer: Reset hrtimer cpu base proper on CPU hotplug
Andy Lutomirski <luto(a)kernel.org>
x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems
Borislav Petkov <bp(a)suse.de>
x86/microcode: Fix again accessing initrd after having been freed
Jia Zhang <zhang.jia(a)linux.alibaba.com>
x86/microcode/intel: Extend BDW late-loading further with LLC size check
Xiao Liang <xiliang(a)redhat.com>
perf/x86/amd/power: Do not load AMD power module on !AMD platforms
Neil Horman <nhorman(a)tuxdriver.com>
vmxnet3: repair memory leak
Lorenzo Colitti <lorenzo(a)google.com>
net: ipv4: Make "ip route get" match iif lo rules again.
Sabrina Dubroca <sd(a)queasysnail.net>
tls: reset crypto_info when do_tls_setsockopt_tx fails
Sabrina Dubroca <sd(a)queasysnail.net>
tls: return -EBUSY if crypto_info is already set
Sabrina Dubroca <sd(a)queasysnail.net>
tls: fix sw_ctx leak
Ilya Lesokhin <ilyal(a)mellanox.com>
net/tls: Only attach to sockets in ESTABLISHED state
Xin Long <lucien.xin(a)gmail.com>
netlink: reset extack earlier in netlink_rcv_skb
Jakub Kicinski <jakub.kicinski(a)netronome.com>
nfp: use the correct index for link speed table
Talat Batheesh <talatb(a)mellanox.com>
net/mlx5e: Fix fixpoint divide exception in mlx5e_am_stats_compare
David Ahern <dsahern(a)gmail.com>
netlink: extack needs to be reset each time through loop
Xin Long <lucien.xin(a)gmail.com>
sctp: reinit stream if stream outcnt has been change by sinit in sendmsg
Eric Dumazet <edumazet(a)google.com>
flow_dissector: properly cap thoff field
Cong Wang <xiyou.wangcong(a)gmail.com>
tun: fix a memory leak for tfile->tx_array
Yuval Mintz <yuvalm(a)mellanox.com>
mlxsw: spectrum_router: Don't log an error on missing neighbor
Willem de Bruijn <willemb(a)google.com>
gso: validate gso_type in GSO handlers
Alexey Kodanev <alexey.kodanev(a)oracle.com>
ip6_gre: init dev->mtu and dev->hard_header_len correctly
Ivan Vecera <cera(a)cera.cz>
be2net: restore properly promisc mode after queues reconfiguration
Guillaume Nault <g.nault(a)alphalink.fr>
ppp: unlock all_ppp_mutex before registering device
Saeed Mahameed <saeedm(a)mellanox.com>
net/mlx5: Fix get vector affinity helper function
Eran Ben Elisha <eranbe(a)mellanox.com>
{net,ib}/mlx5: Don't disable local loopback multicast traffic when needed
Cong Wang <xiyou.wangcong(a)gmail.com>
tipc: fix a memory leak in tipc_nl_node_get_link()
Xin Long <lucien.xin(a)gmail.com>
sctp: return error if the asoc has been peeled off in sctp_wait_for_sndbuf
Xin Long <lucien.xin(a)gmail.com>
sctp: do not allow the v4 socket to bind a v4mapped v6 address
Francois Romieu <romieu(a)fr.zoreil.com>
r8169: fix memory corruption on retrieval of hardware statistics.
Guillaume Nault <g.nault(a)alphalink.fr>
pppoe: take ->needed_headroom of lower device into account on xmit
David Ahern <dsahern(a)gmail.com>
net: vrf: Add support for sends to local broadcast address
r.hering(a)avm.de <r.hering(a)avm.de>
net/tls: Fix inverted error codes to avoid endless loop
Dan Streetman <ddstreet(a)ieee.org>
net: tcp: close sock if net namespace is exiting
Eric Dumazet <edumazet(a)google.com>
net: qdisc_pkt_len_init() should be more robust
Felix Fietkau <nbd(a)nbd.name>
net: igmp: fix source address check for IGMPv3 reports
Yuiko Oshino <yuiko.oshino(a)microchip.com>
lan78xx: Fix failure in USB Full Speed
Eric Dumazet <edumazet(a)google.com>
ipv6: ip6_make_skb() needs to clear cork.base.dst
Mike Maloney <maloney(a)google.com>
ipv6: fix udpv6 sendmsg crash caused by too small MTU
Ben Hutchings <ben.hutchings(a)codethink.co.uk>
ipv6: Fix getsockopt() for sockets with default IPV6_AUTOFLOWLABEL
Alexey Kodanev <alexey.kodanev(a)oracle.com>
dccp: don't restart ccid2_hc_tx_rto_expire() if sk in closed state
Jim Westfall <jwestfall(a)surrealistic.net>
ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY
Jim Westfall <jwestfall(a)surrealistic.net>
net: Allow neigh contructor functions ability to modify the primary_key
Boris Brezillon <boris.brezillon(a)free-electrons.com>
drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()
Russell King <rmk+kernel(a)armlinux.org.uk>
ARM: net: bpf: clarify tail_call index
Russell King <rmk+kernel(a)armlinux.org.uk>
ARM: net: bpf: fix LDX instructions
Russell King <rmk+kernel(a)armlinux.org.uk>
ARM: net: bpf: fix register saving
Russell King <rmk+kernel(a)armlinux.org.uk>
ARM: net: bpf: correct stack layout documentation
Russell King <rmk+kernel(a)armlinux.org.uk>
ARM: net: bpf: move stack documentation
Russell King <rmk+kernel(a)armlinux.org.uk>
ARM: net: bpf: fix stack alignment
Russell King <rmk+kernel(a)armlinux.org.uk>
ARM: net: bpf: fix tail call jumps
Russell King <rmk+kernel(a)armlinux.org.uk>
ARM: net: bpf: avoid 'bx' instruction on non-Thumb capable CPUs
Martin Brandenburg <martin(a)omnibond.com>
orangefs: fix deadlock; do not write i_size in read_iter
Christian Borntraeger <borntraeger(a)de.ibm.com>
KVM: s390: add proper locking for CMMA migration bitmap
Josef Bacik <jbacik(a)fb.com>
Btrfs: fix stale entries in readdir
Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Input: trackpoint - only expose supported controls for Elan, ALPS and NXP
Aaron Ma <aaron.ma(a)canonical.com>
Input: trackpoint - force 3 buttons if 0 button is reported
Mark Furneaux <mark(a)furneaux.ca>
Input: xpad - add support for PDP Xbox One controllers
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Revert "module: Add retpoline tag to VERMAGIC"
Steffen Klassert <steffen.klassert(a)secunet.com>
xfrm: Fix a race in the xdst pcpu cache.
Kevin Cernekee <cernekee(a)chromium.org>
netfilter: xt_osf: Add missing permission checks
Kevin Cernekee <cernekee(a)chromium.org>
netfilter: nfnetlink_cthelper: Add missing permission checks
Vlastimil Babka <vbabka(a)suse.cz>
mm, page_alloc: fix potential false positive in __zone_watermark_ok
Martin Brandenburg <martin(a)omnibond.com>
orangefs: initialize op on loop restart in orangefs_devreq_read
Martin Brandenburg <martin(a)omnibond.com>
orangefs: use list_for_each_entry_safe in purge_waiting_ops
-------------
Diffstat:
Makefile | 4 +-
arch/arm/net/bpf_jit_32.c | 225 ++++++++++---------
arch/arm64/net/bpf_jit_comp.c | 20 +-
arch/s390/kvm/kvm-s390.c | 18 +-
arch/x86/events/amd/power.c | 2 +-
arch/x86/kernel/cpu/microcode/core.c | 2 +-
arch/x86/kernel/cpu/microcode/intel.c | 20 +-
arch/x86/mm/tlb.c | 34 ++-
drivers/cpufreq/cpufreq_governor.c | 19 +-
drivers/gpu/drm/vc4/vc4_gem.c | 12 +-
drivers/infiniband/hw/mlx5/main.c | 9 +-
drivers/input/joystick/xpad.c | 19 ++
drivers/input/mouse/trackpoint.c | 245 +++++++++++++--------
drivers/input/mouse/trackpoint.h | 34 +--
drivers/net/ethernet/emulex/benet/be_main.c | 9 +
drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c | 6 +
.../net/ethernet/mellanox/mlx5/core/en_selftest.c | 27 ++-
drivers/net/ethernet/mellanox/mlx5/core/main.c | 3 +-
drivers/net/ethernet/mellanox/mlx5/core/vport.c | 22 +-
.../net/ethernet/mellanox/mlxsw/spectrum_router.c | 10 +-
.../net/ethernet/netronome/nfp/nfp_net_ethtool.c | 2 +-
drivers/net/ethernet/realtek/r8169.c | 9 +-
drivers/net/ppp/ppp_generic.c | 5 +-
drivers/net/ppp/pppoe.c | 11 +-
drivers/net/tun.c | 15 +-
drivers/net/usb/lan78xx.c | 1 +
drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
drivers/net/vrf.c | 5 +-
fs/btrfs/delayed-inode.c | 26 +--
fs/orangefs/devorangefs-req.c | 3 +-
fs/orangefs/file.c | 7 +-
fs/orangefs/orangefs-kernel.h | 11 -
fs/orangefs/waitqueue.c | 4 +-
include/linux/bpf.h | 21 +-
include/linux/mlx5/driver.h | 19 +-
include/linux/mlx5/mlx5_ifc.h | 5 +-
include/linux/vermagic.h | 8 +-
include/net/arp.h | 3 +
include/net/ipv6.h | 1 +
include/net/net_namespace.h | 10 +
include/net/tls.h | 2 +-
init/Kconfig | 7 +
kernel/bpf/core.c | 23 +-
kernel/bpf/verifier.c | 37 ++++
kernel/time/hrtimer.c | 3 +
lib/test_bpf.c | 11 +-
mm/page_alloc.c | 6 +-
net/core/dev.c | 19 +-
net/core/filter.c | 10 +-
net/core/flow_dissector.c | 3 +-
net/core/neighbour.c | 4 +-
net/core/sysctl_net_core.c | 6 +
net/dccp/ccids/ccid2.c | 3 +
net/ipv4/arp.c | 7 +-
net/ipv4/esp4_offload.c | 3 +
net/ipv4/igmp.c | 2 +-
net/ipv4/route.c | 1 +
net/ipv4/tcp.c | 3 +
net/ipv4/tcp_offload.c | 3 +
net/ipv4/tcp_timer.c | 15 ++
net/ipv4/udp_offload.c | 3 +
net/ipv6/esp6_offload.c | 3 +
net/ipv6/ip6_gre.c | 14 +-
net/ipv6/ip6_output.c | 9 +-
net/ipv6/ipv6_sockglue.c | 2 +-
net/ipv6/tcpv6_offload.c | 3 +
net/ipv6/udp_offload.c | 3 +
net/netfilter/nfnetlink_cthelper.c | 10 +
net/netfilter/xt_osf.c | 7 +
net/netlink/af_netlink.c | 3 +-
net/sctp/offload.c | 3 +
net/sctp/socket.c | 40 ++--
net/socket.c | 9 +
net/tipc/node.c | 26 ++-
net/tls/tls_main.c | 17 +-
net/tls/tls_sw.c | 16 +-
net/xfrm/xfrm_policy.c | 8 +-
tools/testing/selftests/bpf/test_verifier.c | 29 ++-
78 files changed, 843 insertions(+), 438 deletions(-)
From: Hans Verkuil <hans.verkuil(a)cisco.com>
Some ioctls need to copy back the result even if the ioctl returned
an error. However, don't do this for the error code -ENOTTY.
It makes no sense in that cases.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org> # for v4.15 and up
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 7ee3777cbe9c..3a1fca1440ac 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -968,6 +968,9 @@ static long do_video_ioctl(struct file *file, unsigned int cmd, unsigned long ar
set_fs(old_fs);
}
+ if (err == -ENOTTY)
+ return err;
+
/* Special case: even after an error we need to put the
results back for these ioctls since the error_idx will
contain information on which control failed. */
--
2.15.1
From: Hans Verkuil <hans.verkuil(a)cisco.com>
ctrl_is_pointer just hardcoded two known string controls, but that
caused problems when using e.g. custom controls that use a pointer
for the payload.
Reimplement this function: it now finds the v4l2_ctrl (if the driver
uses the control framework) or it calls vidioc_query_ext_ctrl (if the
driver implements that directly).
In both cases it can now check if the control is a pointer control
or not.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Cc: <stable(a)vger.kernel.org> # for v4.15 and up
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 57 ++++++++++++++++++---------
1 file changed, 38 insertions(+), 19 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 7dff9b4aeb19..30c5be1f0549 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -18,6 +18,8 @@
#include <linux/videodev2.h>
#include <linux/v4l2-subdev.h>
#include <media/v4l2-dev.h>
+#include <media/v4l2-fh.h>
+#include <media/v4l2-ctrls.h>
#include <media/v4l2-ioctl.h>
static long native_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
@@ -601,24 +603,39 @@ struct v4l2_ext_control32 {
};
} __attribute__ ((packed));
-/* The following function really belong in v4l2-common, but that causes
- a circular dependency between modules. We need to think about this, but
- for now this will do. */
-
-/* Return non-zero if this control is a pointer type. Currently only
- type STRING is a pointer type. */
-static inline int ctrl_is_pointer(u32 id)
+/* Return true if this control is a pointer type. */
+static inline bool ctrl_is_pointer(struct file *file, u32 id)
{
- switch (id) {
- case V4L2_CID_RDS_TX_PS_NAME:
- case V4L2_CID_RDS_TX_RADIO_TEXT:
- return 1;
- default:
- return 0;
+ struct video_device *vdev = video_devdata(file);
+ struct v4l2_fh *fh = NULL;
+ struct v4l2_ctrl_handler *hdl = NULL;
+ struct v4l2_query_ext_ctrl qec = { id };
+ const struct v4l2_ioctl_ops *ops = vdev->ioctl_ops;
+
+ if (test_bit(V4L2_FL_USES_V4L2_FH, &vdev->flags))
+ fh = file->private_data;
+
+ if (fh && fh->ctrl_handler)
+ hdl = fh->ctrl_handler;
+ else if (vdev->ctrl_handler)
+ hdl = vdev->ctrl_handler;
+
+ if (hdl) {
+ struct v4l2_ctrl *ctrl = v4l2_ctrl_find(hdl, id);
+
+ return ctrl && ctrl->is_ptr;
}
+
+ if (!ops->vidioc_query_ext_ctrl)
+ return false;
+
+ return !ops->vidioc_query_ext_ctrl(file, fh, &qec) &&
+ (qec.flags & V4L2_CTRL_FLAG_HAS_PAYLOAD);
}
-static int get_v4l2_ext_controls32(struct v4l2_ext_controls *kp, struct v4l2_ext_controls32 __user *up)
+static int get_v4l2_ext_controls32(struct file *file,
+ struct v4l2_ext_controls *kp,
+ struct v4l2_ext_controls32 __user *up)
{
struct v4l2_ext_control32 __user *ucontrols;
struct v4l2_ext_control __user *kcontrols;
@@ -651,7 +668,7 @@ static int get_v4l2_ext_controls32(struct v4l2_ext_controls *kp, struct v4l2_ext
return -EFAULT;
if (get_user(id, &kcontrols->id))
return -EFAULT;
- if (ctrl_is_pointer(id)) {
+ if (ctrl_is_pointer(file, id)) {
void __user *s;
if (get_user(p, &ucontrols->string))
@@ -666,7 +683,9 @@ static int get_v4l2_ext_controls32(struct v4l2_ext_controls *kp, struct v4l2_ext
return 0;
}
-static int put_v4l2_ext_controls32(struct v4l2_ext_controls *kp, struct v4l2_ext_controls32 __user *up)
+static int put_v4l2_ext_controls32(struct file *file,
+ struct v4l2_ext_controls *kp,
+ struct v4l2_ext_controls32 __user *up)
{
struct v4l2_ext_control32 __user *ucontrols;
struct v4l2_ext_control __user *kcontrols =
@@ -698,7 +717,7 @@ static int put_v4l2_ext_controls32(struct v4l2_ext_controls *kp, struct v4l2_ext
/* Do not modify the pointer when copying a pointer control.
The contents of the pointer was changed, not the pointer
itself. */
- if (ctrl_is_pointer(id))
+ if (ctrl_is_pointer(file, id))
size -= sizeof(ucontrols->value64);
if (copy_in_user(ucontrols, kcontrols, size))
return -EFAULT;
@@ -912,7 +931,7 @@ static long do_video_ioctl(struct file *file, unsigned int cmd, unsigned long ar
case VIDIOC_G_EXT_CTRLS:
case VIDIOC_S_EXT_CTRLS:
case VIDIOC_TRY_EXT_CTRLS:
- err = get_v4l2_ext_controls32(&karg.v2ecs, up);
+ err = get_v4l2_ext_controls32(file, &karg.v2ecs, up);
compatible_arg = 0;
break;
case VIDIOC_DQEVENT:
@@ -939,7 +958,7 @@ static long do_video_ioctl(struct file *file, unsigned int cmd, unsigned long ar
case VIDIOC_G_EXT_CTRLS:
case VIDIOC_S_EXT_CTRLS:
case VIDIOC_TRY_EXT_CTRLS:
- if (put_v4l2_ext_controls32(&karg.v2ecs, up))
+ if (put_v4l2_ext_controls32(file, &karg.v2ecs, up))
err = -EFAULT;
break;
case VIDIOC_S_EDID:
--
2.15.1
Currently we see sporadic timeouts during CDCLK changing both on BXT and
GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by
changing the frequency in a tight loop after blanking the display. The
upper bound for the completion time is 800us based on my tests, so
increase it from the current 500us to 2ms; with that I couldn't trigger
the problem either on BXT or GLK.
Note that timeouts happened during both the change notification and the
voltage level setting PCODE request. (For the latter one BSpec doesn't
require us to wait for completion before further HW programming.)
This issue is similar to
2c7d0602c815 ("drm/i915/gen9: Fix PCODE polling during CDCLK change
notification")
but there the PCODE request does complete (as shown by the mbox
busy flag), only the reply we get from PCODE indicates a failure.
So there we keep resending the request until a success reply, here we
just have to increase the timeout for the one PCODE request we send.
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: stable(a)vger.kernel.org # v4.4+
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
---
drivers/gpu/drm/i915/i915_drv.h | 6 +++++-
drivers/gpu/drm/i915/intel_cdclk.c | 20 +++++++++++++++-----
drivers/gpu/drm/i915/intel_pm.c | 6 +++---
3 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 454d8f937fae..5e293be4e51d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3723,7 +3723,11 @@ extern void intel_display_print_error_state(struct drm_i915_error_state_buf *e,
struct intel_display_error_state *error);
int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32 *val);
-int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox, u32 val);
+int snb_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32 val,
+ int timeout_us);
+#define sandybridge_pcode_write(dev_priv, mbox, val) \
+ snb_pcode_request(dev_priv, mbox, val, 500)
+
int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32 request,
u32 reply_mask, u32 reply, int timeout_base_ms);
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c
index c4392ea34a3d..5057336c40ba 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1370,10 +1370,14 @@ static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
break;
}
- /* Inform power controller of upcoming frequency change */
+ /*
+ * Inform power controller of upcoming frequency change. BSpec
+ * requires us to wait up to 150usec, but that leads to timeouts;
+ * the 2ms used here is based on experiment.
+ */
mutex_lock(&dev_priv->pcu_lock);
- ret = sandybridge_pcode_write(dev_priv, HSW_PCODE_DE_WRITE_FREQ_REQ,
- 0x80000000);
+ ret = snb_pcode_request(dev_priv, HSW_PCODE_DE_WRITE_FREQ_REQ,
+ 0x80000000, 2000);
mutex_unlock(&dev_priv->pcu_lock);
if (ret) {
@@ -1404,8 +1408,14 @@ static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
I915_WRITE(CDCLK_CTL, val);
mutex_lock(&dev_priv->pcu_lock);
- ret = sandybridge_pcode_write(dev_priv, HSW_PCODE_DE_WRITE_FREQ_REQ,
- cdclk_state->voltage_level);
+ /*
+ * The timeout isn't specified, the 2ms used here is based on
+ * experiment.
+ * FIXME: Waiting for the request completion could be delayed until
+ * the next PCODE request based on BSpec.
+ */
+ ret = snb_pcode_request(dev_priv, HSW_PCODE_DE_WRITE_FREQ_REQ,
+ cdclk_state->voltage_level, 2000);
mutex_unlock(&dev_priv->pcu_lock);
if (ret) {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0b92ea1dbd40..f6f4dbacb9af 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -9169,8 +9169,8 @@ int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32 *val
return 0;
}
-int sandybridge_pcode_write(struct drm_i915_private *dev_priv,
- u32 mbox, u32 val)
+int snb_pcode_request(struct drm_i915_private *dev_priv,
+ u32 mbox, u32 val, int timeout_us)
{
int status;
@@ -9193,7 +9193,7 @@ int sandybridge_pcode_write(struct drm_i915_private *dev_priv,
if (__intel_wait_for_register_fw(dev_priv,
GEN6_PCODE_MAILBOX, GEN6_PCODE_READY, 0,
- 500, 0, NULL)) {
+ timeout_us, 0, NULL)) {
DRM_ERROR("timeout waiting for pcode write of 0x%08x to mbox %x to finish for %ps\n",
val, mbox, __builtin_return_address(0));
return -ETIMEDOUT;
--
2.13.2
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: v4l2-compat-ioctl32.c: don't copy back the result for certain errors
Author: Hans Verkuil <hans.verkuil(a)cisco.com>
Date: Fri Jan 26 03:24:53 2018 -0500
Some ioctls need to copy back the result even if the ioctl returned
an error. However, don't do this for the error code -ENOTTY.
It makes no sense in that cases.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org> # for v4.15 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 3 +++
1 file changed, 3 insertions(+)
---
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 7ee3777cbe9c..3a1fca1440ac 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -968,6 +968,9 @@ static long do_video_ioctl(struct file *file, unsigned int cmd, unsigned long ar
set_fs(old_fs);
}
+ if (err == -ENOTTY)
+ return err;
+
/* Special case: even after an error we need to put the
results back for these ioctls since the error_idx will
contain information on which control failed. */