* [PATCH 4.14 001/199] bus: sunxi-rsb: Return correct data when mixing 16-bit and 8-bit reads
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 002/199] net: vxge: fix wrong __VA_ARGS__ usage Greg Kroah-Hartman
` (129 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ondrej Jirman, Chen-Yu Tsai,
Maxime Ripard, Sasha Levin
From: Ondrej Jirman <megous@megous.com>
[ Upstream commit a43ab30dcd4a1abcdd0d2461bf1cf7c0817f6cd3 ]
When doing a 16-bit read that returns data in the MSB byte, the
RSB_DATA register will keep the MSB byte unchanged when doing
the following 8-bit read. sunxi_rsb_read() will then return
a result that contains high byte from 16-bit read mixed with
the 8-bit result.
The consequence is that after this happens the PMIC's regmap will
look like this: (0x33 is the high byte from the 16-bit read)
% cat /sys/kernel/debug/regmap/sunxi-rsb-3a3/registers
00: 33
01: 33
02: 33
03: 33
04: 33
05: 33
06: 33
07: 33
08: 33
09: 33
0a: 33
0b: 33
0c: 33
0d: 33
0e: 33
[snip]
Fix this by masking the result of the read with the correct mask
based on the size of the read. There are no 16-bit users in the
mainline kernel, so this doesn't need to get into the stable tree.
Signed-off-by: Ondrej Jirman <megous@megous.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/bus/sunxi-rsb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
index 1b76d95859027..2ca2cc56bcef6 100644
--- a/drivers/bus/sunxi-rsb.c
+++ b/drivers/bus/sunxi-rsb.c
@@ -345,7 +345,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 rtaddr, u8 addr,
if (ret)
goto unlock;
- *buf = readl(rsb->regs + RSB_DATA);
+ *buf = readl(rsb->regs + RSB_DATA) & GENMASK(len * 8 - 1, 0);
unlock:
mutex_unlock(&rsb->lock);
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 002/199] net: vxge: fix wrong __VA_ARGS__ usage
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 001/199] bus: sunxi-rsb: Return correct data when mixing 16-bit and 8-bit reads Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 003/199] hinic: fix a bug of waitting for IO stopped Greg Kroah-Hartman
` (128 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Zheng Wei, David S. Miller, Sasha Levin
From: Zheng Wei <wei.zheng@vivo.com>
[ Upstream commit b317538c47943f9903860d83cc0060409e12d2ff ]
printk in macro vxge_debug_ll uses __VA_ARGS__ without "##" prefix,
it causes a build error when there is no variable
arguments(e.g. only fmt is specified.).
Signed-off-by: Zheng Wei <wei.zheng@vivo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/neterion/vxge/vxge-config.h | 2 +-
drivers/net/ethernet/neterion/vxge/vxge-main.h | 14 +++++++-------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-config.h b/drivers/net/ethernet/neterion/vxge/vxge-config.h
index cfa970417f818..fe4a4315d20d4 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-config.h
+++ b/drivers/net/ethernet/neterion/vxge/vxge-config.h
@@ -2065,7 +2065,7 @@ vxge_hw_vpath_strip_fcs_check(struct __vxge_hw_device *hldev, u64 vpath_mask);
if ((level >= VXGE_ERR && VXGE_COMPONENT_LL & VXGE_DEBUG_ERR_MASK) || \
(level >= VXGE_TRACE && VXGE_COMPONENT_LL & VXGE_DEBUG_TRACE_MASK))\
if ((mask & VXGE_DEBUG_MASK) == mask) \
- printk(fmt "\n", __VA_ARGS__); \
+ printk(fmt "\n", ##__VA_ARGS__); \
} while (0)
#else
#define vxge_debug_ll(level, mask, fmt, ...)
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-main.h b/drivers/net/ethernet/neterion/vxge/vxge-main.h
index 3a79d93b84453..5b535aa10d23e 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-main.h
+++ b/drivers/net/ethernet/neterion/vxge/vxge-main.h
@@ -454,49 +454,49 @@ int vxge_fw_upgrade(struct vxgedev *vdev, char *fw_name, int override);
#if (VXGE_DEBUG_LL_CONFIG & VXGE_DEBUG_MASK)
#define vxge_debug_ll_config(level, fmt, ...) \
- vxge_debug_ll(level, VXGE_DEBUG_LL_CONFIG, fmt, __VA_ARGS__)
+ vxge_debug_ll(level, VXGE_DEBUG_LL_CONFIG, fmt, ##__VA_ARGS__)
#else
#define vxge_debug_ll_config(level, fmt, ...)
#endif
#if (VXGE_DEBUG_INIT & VXGE_DEBUG_MASK)
#define vxge_debug_init(level, fmt, ...) \
- vxge_debug_ll(level, VXGE_DEBUG_INIT, fmt, __VA_ARGS__)
+ vxge_debug_ll(level, VXGE_DEBUG_INIT, fmt, ##__VA_ARGS__)
#else
#define vxge_debug_init(level, fmt, ...)
#endif
#if (VXGE_DEBUG_TX & VXGE_DEBUG_MASK)
#define vxge_debug_tx(level, fmt, ...) \
- vxge_debug_ll(level, VXGE_DEBUG_TX, fmt, __VA_ARGS__)
+ vxge_debug_ll(level, VXGE_DEBUG_TX, fmt, ##__VA_ARGS__)
#else
#define vxge_debug_tx(level, fmt, ...)
#endif
#if (VXGE_DEBUG_RX & VXGE_DEBUG_MASK)
#define vxge_debug_rx(level, fmt, ...) \
- vxge_debug_ll(level, VXGE_DEBUG_RX, fmt, __VA_ARGS__)
+ vxge_debug_ll(level, VXGE_DEBUG_RX, fmt, ##__VA_ARGS__)
#else
#define vxge_debug_rx(level, fmt, ...)
#endif
#if (VXGE_DEBUG_MEM & VXGE_DEBUG_MASK)
#define vxge_debug_mem(level, fmt, ...) \
- vxge_debug_ll(level, VXGE_DEBUG_MEM, fmt, __VA_ARGS__)
+ vxge_debug_ll(level, VXGE_DEBUG_MEM, fmt, ##__VA_ARGS__)
#else
#define vxge_debug_mem(level, fmt, ...)
#endif
#if (VXGE_DEBUG_ENTRYEXIT & VXGE_DEBUG_MASK)
#define vxge_debug_entryexit(level, fmt, ...) \
- vxge_debug_ll(level, VXGE_DEBUG_ENTRYEXIT, fmt, __VA_ARGS__)
+ vxge_debug_ll(level, VXGE_DEBUG_ENTRYEXIT, fmt, ##__VA_ARGS__)
#else
#define vxge_debug_entryexit(level, fmt, ...)
#endif
#if (VXGE_DEBUG_INTR & VXGE_DEBUG_MASK)
#define vxge_debug_intr(level, fmt, ...) \
- vxge_debug_ll(level, VXGE_DEBUG_INTR, fmt, __VA_ARGS__)
+ vxge_debug_ll(level, VXGE_DEBUG_INTR, fmt, ##__VA_ARGS__)
#else
#define vxge_debug_intr(level, fmt, ...)
#endif
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 003/199] hinic: fix a bug of waitting for IO stopped
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 001/199] bus: sunxi-rsb: Return correct data when mixing 16-bit and 8-bit reads Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 002/199] net: vxge: fix wrong __VA_ARGS__ usage Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 004/199] hinic: fix wrong para of wait_for_completion_timeout Greg Kroah-Hartman
` (127 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Luo bin, David S. Miller, Sasha Levin
From: Luo bin <luobin9@huawei.com>
[ Upstream commit 96758117dc528e6d84bd23d205e8cf7f31eda029 ]
it's unreliable for fw to check whether IO is stopped, so driver
wait for enough time to ensure IO process is done in hw before
freeing resources
Signed-off-by: Luo bin <luobin9@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/ethernet/huawei/hinic/hinic_hw_dev.c | 51 +------------------
1 file changed, 2 insertions(+), 49 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
index 46aba02b8672b..5763e333a9afe 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
@@ -373,50 +373,6 @@ static int wait_for_db_state(struct hinic_hwdev *hwdev)
return -EFAULT;
}
-static int wait_for_io_stopped(struct hinic_hwdev *hwdev)
-{
- struct hinic_cmd_io_status cmd_io_status;
- struct hinic_hwif *hwif = hwdev->hwif;
- struct pci_dev *pdev = hwif->pdev;
- struct hinic_pfhwdev *pfhwdev;
- unsigned long end;
- u16 out_size;
- int err;
-
- if (!HINIC_IS_PF(hwif) && !HINIC_IS_PPF(hwif)) {
- dev_err(&pdev->dev, "Unsupported PCI Function type\n");
- return -EINVAL;
- }
-
- pfhwdev = container_of(hwdev, struct hinic_pfhwdev, hwdev);
-
- cmd_io_status.func_idx = HINIC_HWIF_FUNC_IDX(hwif);
-
- end = jiffies + msecs_to_jiffies(IO_STATUS_TIMEOUT);
- do {
- err = hinic_msg_to_mgmt(&pfhwdev->pf_to_mgmt, HINIC_MOD_COMM,
- HINIC_COMM_CMD_IO_STATUS_GET,
- &cmd_io_status, sizeof(cmd_io_status),
- &cmd_io_status, &out_size,
- HINIC_MGMT_MSG_SYNC);
- if ((err) || (out_size != sizeof(cmd_io_status))) {
- dev_err(&pdev->dev, "Failed to get IO status, ret = %d\n",
- err);
- return err;
- }
-
- if (cmd_io_status.status == IO_STOPPED) {
- dev_info(&pdev->dev, "IO stopped\n");
- return 0;
- }
-
- msleep(20);
- } while (time_before(jiffies, end));
-
- dev_err(&pdev->dev, "Wait for IO stopped - Timeout\n");
- return -ETIMEDOUT;
-}
-
/**
* clear_io_resource - set the IO resources as not active in the NIC
* @hwdev: the NIC HW device
@@ -436,11 +392,8 @@ static int clear_io_resources(struct hinic_hwdev *hwdev)
return -EINVAL;
}
- err = wait_for_io_stopped(hwdev);
- if (err) {
- dev_err(&pdev->dev, "IO has not stopped yet\n");
- return err;
- }
+ /* sleep 100ms to wait for firmware stopping I/O */
+ msleep(100);
cmd_clear_io_res.func_idx = HINIC_HWIF_FUNC_IDX(hwif);
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 004/199] hinic: fix wrong para of wait_for_completion_timeout
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 003/199] hinic: fix a bug of waitting for IO stopped Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 005/199] cxgb4/ptp: pass the sign of offset delta in FW CMD Greg Kroah-Hartman
` (126 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Luo bin, David S. Miller, Sasha Levin
From: Luo bin <luobin9@huawei.com>
[ Upstream commit 0da7c322f116210ebfdda59c7da663a6fc5e9cc8 ]
the second input parameter of wait_for_completion_timeout should
be jiffies instead of millisecond
Signed-off-by: Luo bin <luobin9@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c | 3 ++-
drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c | 5 +++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
index 7d95f0866fb0b..e1de97effcd24 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
@@ -398,7 +398,8 @@ static int cmdq_sync_cmd_direct_resp(struct hinic_cmdq *cmdq,
spin_unlock_bh(&cmdq->cmdq_lock);
- if (!wait_for_completion_timeout(&done, CMDQ_TIMEOUT)) {
+ if (!wait_for_completion_timeout(&done,
+ msecs_to_jiffies(CMDQ_TIMEOUT))) {
spin_lock_bh(&cmdq->cmdq_lock);
if (cmdq->errcode[curr_prod_idx] == &errcode)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
index 278dc13f3dae8..9fcf2e5e00039 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
@@ -52,7 +52,7 @@
#define MSG_NOT_RESP 0xFFFF
-#define MGMT_MSG_TIMEOUT 1000
+#define MGMT_MSG_TIMEOUT 5000
#define mgmt_to_pfhwdev(pf_mgmt) \
container_of(pf_mgmt, struct hinic_pfhwdev, pf_to_mgmt)
@@ -276,7 +276,8 @@ static int msg_to_mgmt_sync(struct hinic_pf_to_mgmt *pf_to_mgmt,
goto unlock_sync_msg;
}
- if (!wait_for_completion_timeout(recv_done, MGMT_MSG_TIMEOUT)) {
+ if (!wait_for_completion_timeout(recv_done,
+ msecs_to_jiffies(MGMT_MSG_TIMEOUT))) {
dev_err(&pdev->dev, "MGMT timeout, MSG id = %d\n", msg_id);
err = -ETIMEDOUT;
goto unlock_sync_msg;
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 005/199] cxgb4/ptp: pass the sign of offset delta in FW CMD
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 004/199] hinic: fix wrong para of wait_for_completion_timeout Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 006/199] qlcnic: Fix bad kzalloc null test Greg Kroah-Hartman
` (125 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Raju Rangoju, David S. Miller, Sasha Levin
From: Raju Rangoju <rajur@chelsio.com>
[ Upstream commit 50e0d28d3808146cc19b0d5564ef4ba9e5bf3846 ]
cxgb4_ptp_fineadjtime() doesn't pass the signedness of offset delta
in FW_PTP_CMD. Fix it by passing correct sign.
Signed-off-by: Raju Rangoju <rajur@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c
index 9f9d6cae39d55..758f2b8363282 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c
@@ -246,6 +246,9 @@ static int cxgb4_ptp_fineadjtime(struct adapter *adapter, s64 delta)
FW_PTP_CMD_PORTID_V(0));
c.retval_len16 = cpu_to_be32(FW_CMD_LEN16_V(sizeof(c) / 16));
c.u.ts.sc = FW_PTP_SC_ADJ_FTIME;
+ c.u.ts.sign = (delta < 0) ? 1 : 0;
+ if (delta < 0)
+ delta = -delta;
c.u.ts.tm = cpu_to_be64(delta);
err = t4_wr_mbox(adapter, adapter->mbox, &c, sizeof(c), NULL);
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 006/199] qlcnic: Fix bad kzalloc null test
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 005/199] cxgb4/ptp: pass the sign of offset delta in FW CMD Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 007/199] i2c: st: fix missing struct parameter description Greg Kroah-Hartman
` (124 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Xu Wang, David S. Miller, Sasha Levin
From: Xu Wang <vulab@iscas.ac.cn>
[ Upstream commit bcaeb886ade124331a6f3a5cef34a3f1484c0a03 ]
In qlcnic_83xx_get_reset_instruction_template, the variable
of null test is bad, so correct it.
Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
index 07f9067affc65..cda5b0a9e9489 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
@@ -1720,7 +1720,7 @@ static int qlcnic_83xx_get_reset_instruction_template(struct qlcnic_adapter *p_d
ahw->reset.seq_error = 0;
ahw->reset.buff = kzalloc(QLC_83XX_RESTART_TEMPLATE_SIZE, GFP_KERNEL);
- if (p_dev->ahw->reset.buff == NULL)
+ if (ahw->reset.buff == NULL)
return -ENOMEM;
p_buff = p_dev->ahw->reset.buff;
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 007/199] i2c: st: fix missing struct parameter description
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 006/199] qlcnic: Fix bad kzalloc null test Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 008/199] null_blk: Fix the null_add_dev() error path Greg Kroah-Hartman
` (123 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alain Volmat, Patrice Chotard,
Wolfram Sang, Sasha Levin
From: Alain Volmat <avolmat@me.com>
[ Upstream commit f491c6687332920e296d0209e366fe2ca7eab1c6 ]
Fix a missing struct parameter description to allow
warning free W=1 compilation.
Signed-off-by: Alain Volmat <avolmat@me.com>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/i2c/busses/i2c-st.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/i2c-st.c b/drivers/i2c/busses/i2c-st.c
index 9e62f893958aa..81158ae8bfe36 100644
--- a/drivers/i2c/busses/i2c-st.c
+++ b/drivers/i2c/busses/i2c-st.c
@@ -437,6 +437,7 @@ static void st_i2c_wr_fill_tx_fifo(struct st_i2c_dev *i2c_dev)
/**
* st_i2c_rd_fill_tx_fifo() - Fill the Tx FIFO in read mode
* @i2c_dev: Controller's private data
+ * @max: Maximum amount of data to fill into the Tx FIFO
*
* This functions fills the Tx FIFO with fixed pattern when
* in read mode to trigger clock.
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 008/199] null_blk: Fix the null_add_dev() error path
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 007/199] i2c: st: fix missing struct parameter description Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 009/199] null_blk: Handle null_add_dev() failures properly Greg Kroah-Hartman
` (122 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bart Van Assche, Chaitanya Kulkarni,
Johannes Thumshirn, Hannes Reinecke, Ming Lei, Christoph Hellwig,
Jens Axboe, Sasha Levin
From: Bart Van Assche <bvanassche@acm.org>
[ Upstream commit 2004bfdef945fe55196db6b9cdf321fbc75bb0de ]
If null_add_dev() fails, clear dev->nullb.
This patch fixes the following KASAN complaint:
BUG: KASAN: use-after-free in nullb_device_submit_queues_store+0xcf/0x160 [null_blk]
Read of size 8 at addr ffff88803280fc30 by task check/8409
Call Trace:
dump_stack+0xa5/0xe6
print_address_description.constprop.0+0x26/0x260
__kasan_report.cold+0x7b/0x99
kasan_report+0x16/0x20
__asan_load8+0x58/0x90
nullb_device_submit_queues_store+0xcf/0x160 [null_blk]
configfs_write_file+0x1c4/0x250 [configfs]
__vfs_write+0x4c/0x90
vfs_write+0x145/0x2c0
ksys_write+0xd7/0x180
__x64_sys_write+0x47/0x50
do_syscall_64+0x6f/0x2f0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7ff370926317
Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
RSP: 002b:00007fff2dd2da48 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007ff370926317
RDX: 0000000000000002 RSI: 0000559437ef23f0 RDI: 0000000000000001
RBP: 0000559437ef23f0 R08: 000000000000000a R09: 0000000000000001
R10: 0000559436703471 R11: 0000000000000246 R12: 0000000000000002
R13: 00007ff370a006a0 R14: 00007ff370a014a0 R15: 00007ff370a008a0
Allocated by task 8409:
save_stack+0x23/0x90
__kasan_kmalloc.constprop.0+0xcf/0xe0
kasan_kmalloc+0xd/0x10
kmem_cache_alloc_node_trace+0x129/0x4c0
null_add_dev+0x24a/0xe90 [null_blk]
nullb_device_power_store+0x1b6/0x270 [null_blk]
configfs_write_file+0x1c4/0x250 [configfs]
__vfs_write+0x4c/0x90
vfs_write+0x145/0x2c0
ksys_write+0xd7/0x180
__x64_sys_write+0x47/0x50
do_syscall_64+0x6f/0x2f0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 8409:
save_stack+0x23/0x90
__kasan_slab_free+0x112/0x160
kasan_slab_free+0x12/0x20
kfree+0xdf/0x250
null_add_dev+0xaf3/0xe90 [null_blk]
nullb_device_power_store+0x1b6/0x270 [null_blk]
configfs_write_file+0x1c4/0x250 [configfs]
__vfs_write+0x4c/0x90
vfs_write+0x145/0x2c0
ksys_write+0xd7/0x180
__x64_sys_write+0x47/0x50
do_syscall_64+0x6f/0x2f0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fixes: 2984c8684f96 ("nullb: factor disk parameters")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Cc: Johannes Thumshirn <jth@kernel.org>
Cc: Hannes Reinecke <hare@suse.com>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/block/null_blk.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c
index f01d4a8a783ac..e9776ca0996b0 100644
--- a/drivers/block/null_blk.c
+++ b/drivers/block/null_blk.c
@@ -1919,6 +1919,7 @@ out_cleanup_queues:
cleanup_queues(nullb);
out_free_nullb:
kfree(nullb);
+ dev->nullb = NULL;
out:
return rv;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 009/199] null_blk: Handle null_add_dev() failures properly
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 008/199] null_blk: Fix the null_add_dev() error path Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 010/199] null_blk: fix spurious IO errors after failed past-wp access Greg Kroah-Hartman
` (121 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bart Van Assche, Chaitanya Kulkarni,
Johannes Thumshirn, Hannes Reinecke, Ming Lei, Christoph Hellwig,
Jens Axboe, Sasha Levin
From: Bart Van Assche <bvanassche@acm.org>
[ Upstream commit 9b03b713082a31a5b90e0a893c72aa620e255c26 ]
If null_add_dev() fails then null_del_dev() is called with a NULL argument.
Make null_del_dev() handle this scenario correctly. This patch fixes the
following KASAN complaint:
null-ptr-deref in null_del_dev+0x28/0x280 [null_blk]
Read of size 8 at addr 0000000000000000 by task find/1062
Call Trace:
dump_stack+0xa5/0xe6
__kasan_report.cold+0x65/0x99
kasan_report+0x16/0x20
__asan_load8+0x58/0x90
null_del_dev+0x28/0x280 [null_blk]
nullb_group_drop_item+0x7e/0xa0 [null_blk]
client_drop_item+0x53/0x80 [configfs]
configfs_rmdir+0x395/0x4e0 [configfs]
vfs_rmdir+0xb6/0x220
do_rmdir+0x238/0x2c0
__x64_sys_unlinkat+0x75/0x90
do_syscall_64+0x6f/0x2f0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Cc: Johannes Thumshirn <jth@kernel.org>
Cc: Hannes Reinecke <hare@suse.com>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/block/null_blk.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c
index e9776ca0996b0..b4078901dbcb9 100644
--- a/drivers/block/null_blk.c
+++ b/drivers/block/null_blk.c
@@ -1593,7 +1593,12 @@ static void null_nvm_unregister(struct nullb *nullb) {}
static void null_del_dev(struct nullb *nullb)
{
- struct nullb_device *dev = nullb->dev;
+ struct nullb_device *dev;
+
+ if (!nullb)
+ return;
+
+ dev = nullb->dev;
ida_simple_remove(&nullb_indexes, nullb->index);
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 010/199] null_blk: fix spurious IO errors after failed past-wp access
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 009/199] null_blk: Handle null_add_dev() failures properly Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 011/199] x86: Dont let pgprot_modify() change the page encryption bit Greg Kroah-Hartman
` (120 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christoph Hellwig,
Alexey Dobriyan (SK hynix),
Jens Axboe, Sasha Levin
From: Alexey Dobriyan <adobriyan@gmail.com>
[ Upstream commit ff77042296d0a54535ddf74412c5ae92cb4ec76a ]
Steps to reproduce:
BLKRESETZONE zone 0
// force EIO
pwrite(fd, buf, 4096, 4096);
[issue more IO including zone ioctls]
It will start failing randomly including IO to unrelated zones because of
->error "reuse". Trigger can be partition detection as well if test is not
run immediately which is even more entertaining.
The fix is of course to clear ->error where necessary.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alexey Dobriyan (SK hynix) <adobriyan@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/block/null_blk.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c
index b4078901dbcb9..b12e373aa956a 100644
--- a/drivers/block/null_blk.c
+++ b/drivers/block/null_blk.c
@@ -622,6 +622,7 @@ static struct nullb_cmd *__alloc_cmd(struct nullb_queue *nq)
if (tag != -1U) {
cmd = &nq->cmds[tag];
cmd->tag = tag;
+ cmd->error = BLK_STS_OK;
cmd->nq = nq;
if (nq->dev->irqmode == NULL_IRQ_TIMER) {
hrtimer_init(&cmd->timer, CLOCK_MONOTONIC,
@@ -1399,6 +1400,7 @@ static blk_status_t null_queue_rq(struct blk_mq_hw_ctx *hctx,
cmd->timer.function = null_cmd_timer_expired;
}
cmd->rq = bd->rq;
+ cmd->error = BLK_STS_OK;
cmd->nq = nq;
blk_mq_start_request(bd->rq);
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 011/199] x86: Dont let pgprot_modify() change the page encryption bit
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 010/199] null_blk: fix spurious IO errors after failed past-wp access Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 012/199] block: keep bdi->io_pages in sync with max_sectors_kb for stacked devices Greg Kroah-Hartman
` (119 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas Hellstrom, Borislav Petkov,
Dave Hansen, Tom Lendacky, Sasha Levin
From: Thomas Hellstrom <thellstrom@vmware.com>
[ Upstream commit 6db73f17c5f155dbcfd5e48e621c706270b84df0 ]
When SEV or SME is enabled and active, vm_get_page_prot() typically
returns with the encryption bit set. This means that users of
pgprot_modify(, vm_get_page_prot()) (mprotect_fixup(), do_mmap()) end up
with a value of vma->vm_pg_prot that is not consistent with the intended
protection of the PTEs.
This is also important for fault handlers that rely on the VMA
vm_page_prot to set the page protection. Fix this by not allowing
pgprot_modify() to change the encryption bit, similar to how it's done
for PAT bits.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lkml.kernel.org/r/20200304114527.3636-2-thomas_os@shipmail.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/include/asm/pgtable.h | 7 +++++--
arch/x86/include/asm/pgtable_types.h | 2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 6a4b1a54ff479..98a337e3835d6 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -588,12 +588,15 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
return __pmd(val);
}
-/* mprotect needs to preserve PAT bits when updating vm_page_prot */
+/*
+ * mprotect needs to preserve PAT and encryption bits when updating
+ * vm_page_prot
+ */
#define pgprot_modify pgprot_modify
static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
{
pgprotval_t preservebits = pgprot_val(oldprot) & _PAGE_CHG_MASK;
- pgprotval_t addbits = pgprot_val(newprot);
+ pgprotval_t addbits = pgprot_val(newprot) & ~_PAGE_CHG_MASK;
return __pgprot(preservebits | addbits);
}
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 85f8279c885ac..e6c870c240657 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -124,7 +124,7 @@
*/
#define _PAGE_CHG_MASK (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | \
_PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \
- _PAGE_SOFT_DIRTY | _PAGE_DEVMAP)
+ _PAGE_SOFT_DIRTY | _PAGE_DEVMAP | _PAGE_ENC)
#define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE)
/*
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 012/199] block: keep bdi->io_pages in sync with max_sectors_kb for stacked devices
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 011/199] x86: Dont let pgprot_modify() change the page encryption bit Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 013/199] irqchip/versatile-fpga: Handle chained IRQs properly Greg Kroah-Hartman
` (118 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paul Menzel, Bob Liu,
Konstantin Khlebnikov, Song Liu, Sasha Levin
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
[ Upstream commit e74d93e96d721c4297f2a900ad0191890d2fc2b0 ]
Field bdi->io_pages added in commit 9491ae4aade6 ("mm: don't cap request
size based on read-ahead setting") removes unneeded split of read requests.
Stacked drivers do not call blk_queue_max_hw_sectors(). Instead they set
limits of their devices by blk_set_stacking_limits() + disk_stack_limits().
Field bio->io_pages stays zero until user set max_sectors_kb via sysfs.
This patch updates io_pages after merging limits in disk_stack_limits().
Commit c6d6e9b0f6b4 ("dm: do not allow readahead to limit IO size") fixed
the same problem for device-mapper devices, this one fixes MD RAIDs.
Fixes: 9491ae4aade6 ("mm: don't cap request size based on read-ahead setting")
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
block/blk-settings.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/block/blk-settings.c b/block/blk-settings.c
index 6c2faaa38cc1e..e0a744921ed3d 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -717,6 +717,9 @@ void disk_stack_limits(struct gendisk *disk, struct block_device *bdev,
printk(KERN_NOTICE "%s: Warning: Device %s is misaligned\n",
top, bottom);
}
+
+ t->backing_dev_info->io_pages =
+ t->limits.max_sectors >> (PAGE_SHIFT - 9);
}
EXPORT_SYMBOL(disk_stack_limits);
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 013/199] irqchip/versatile-fpga: Handle chained IRQs properly
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 012/199] block: keep bdi->io_pages in sync with max_sectors_kb for stacked devices Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 014/199] sched: Avoid scale real weight down to zero Greg Kroah-Hartman
` (117 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sungbo Eo, Marc Zyngier, Sasha Levin
From: Sungbo Eo <mans0n@gorani.run>
[ Upstream commit 486562da598c59e9f835b551d7cf19507de2d681 ]
Enclose the chained handler with chained_irq_{enter,exit}(), so that the
muxed interrupts get properly acked.
This patch also fixes a reboot bug on OX820 SoC, where the jiffies timer
interrupt is never acked. The kernel waits a clock tick forever in
calibrate_delay_converge(), which leads to a boot hang.
Fixes: c41b16f8c9d9 ("ARM: integrator/versatile: consolidate FPGA IRQ handling code")
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200319023448.1479701-1-mans0n@gorani.run
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/irqchip/irq-versatile-fpga.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-versatile-fpga.c b/drivers/irqchip/irq-versatile-fpga.c
index 928858dada756..70e2cfff8175f 100644
--- a/drivers/irqchip/irq-versatile-fpga.c
+++ b/drivers/irqchip/irq-versatile-fpga.c
@@ -6,6 +6,7 @@
#include <linux/irq.h>
#include <linux/io.h>
#include <linux/irqchip.h>
+#include <linux/irqchip/chained_irq.h>
#include <linux/irqchip/versatile-fpga.h>
#include <linux/irqdomain.h>
#include <linux/module.h>
@@ -68,12 +69,16 @@ static void fpga_irq_unmask(struct irq_data *d)
static void fpga_irq_handle(struct irq_desc *desc)
{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
struct fpga_irq_data *f = irq_desc_get_handler_data(desc);
- u32 status = readl(f->base + IRQ_STATUS);
+ u32 status;
+
+ chained_irq_enter(chip, desc);
+ status = readl(f->base + IRQ_STATUS);
if (status == 0) {
do_bad_IRQ(desc);
- return;
+ goto out;
}
do {
@@ -82,6 +87,9 @@ static void fpga_irq_handle(struct irq_desc *desc)
status &= ~(1 << irq);
generic_handle_irq(irq_find_mapping(f->domain, irq));
} while (status);
+
+out:
+ chained_irq_exit(chip, desc);
}
/*
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 014/199] sched: Avoid scale real weight down to zero
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 013/199] irqchip/versatile-fpga: Handle chained IRQs properly Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 015/199] selftests/x86/ptrace_syscall_32: Fix no-vDSO segfault Greg Kroah-Hartman
` (116 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter Zijlstra, Michael Wang,
Vincent Guittot, Sasha Levin
From: Michael Wang <yun.wang@linux.alibaba.com>
[ Upstream commit 26cf52229efc87e2effa9d788f9b33c40fb3358a ]
During our testing, we found a case that shares no longer
working correctly, the cgroup topology is like:
/sys/fs/cgroup/cpu/A (shares=102400)
/sys/fs/cgroup/cpu/A/B (shares=2)
/sys/fs/cgroup/cpu/A/B/C (shares=1024)
/sys/fs/cgroup/cpu/D (shares=1024)
/sys/fs/cgroup/cpu/D/E (shares=1024)
/sys/fs/cgroup/cpu/D/E/F (shares=1024)
The same benchmark is running in group C & F, no other tasks are
running, the benchmark is capable to consumed all the CPUs.
We suppose the group C will win more CPU resources since it could
enjoy all the shares of group A, but it's F who wins much more.
The reason is because we have group B with shares as 2, since
A->cfs_rq.load.weight == B->se.load.weight == B->shares/nr_cpus,
so A->cfs_rq.load.weight become very small.
And in calc_group_shares() we calculate shares as:
load = max(scale_load_down(cfs_rq->load.weight), cfs_rq->avg.load_avg);
shares = (tg_shares * load) / tg_weight;
Since the 'cfs_rq->load.weight' is too small, the load become 0
after scale down, although 'tg_shares' is 102400, shares of the se
which stand for group A on root cfs_rq become 2.
While the se of D on root cfs_rq is far more bigger than 2, so it
wins the battle.
Thus when scale_load_down() scale real weight down to 0, it's no
longer telling the real story, the caller will have the wrong
information and the calculation will be buggy.
This patch add check in scale_load_down(), so the real weight will
be >= MIN_SHARES after scale, after applied the group C wins as
expected.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Michael Wang <yun.wang@linux.alibaba.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
Link: https://lkml.kernel.org/r/38e8e212-59a1-64b2-b247-b6d0b52d8dc1@linux.alibaba.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/sched/sched.h | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 268f560ec9986..391d73a12ad72 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -89,7 +89,13 @@ static inline void cpu_load_update_active(struct rq *this_rq) { }
#ifdef CONFIG_64BIT
# define NICE_0_LOAD_SHIFT (SCHED_FIXEDPOINT_SHIFT + SCHED_FIXEDPOINT_SHIFT)
# define scale_load(w) ((w) << SCHED_FIXEDPOINT_SHIFT)
-# define scale_load_down(w) ((w) >> SCHED_FIXEDPOINT_SHIFT)
+# define scale_load_down(w) \
+({ \
+ unsigned long __w = (w); \
+ if (__w) \
+ __w = max(2UL, __w >> SCHED_FIXEDPOINT_SHIFT); \
+ __w; \
+})
#else
# define NICE_0_LOAD_SHIFT (SCHED_FIXEDPOINT_SHIFT)
# define scale_load(w) (w)
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 015/199] selftests/x86/ptrace_syscall_32: Fix no-vDSO segfault
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 014/199] sched: Avoid scale real weight down to zero Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 016/199] PCI/switchtec: Fix init_completion race condition with poll_wait() Greg Kroah-Hartman
` (115 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, kbuild test robot, Andy Lutomirski,
Borislav Petkov, Sasha Levin
From: Andy Lutomirski <luto@kernel.org>
[ Upstream commit 630b99ab60aa972052a4202a1ff96c7e45eb0054 ]
If AT_SYSINFO is not present, don't try to call a NULL pointer.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/faaf688265a7e1a5b944d6f8bc0f6368158306d3.1584052409.git.luto@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/x86/ptrace_syscall.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/x86/ptrace_syscall.c b/tools/testing/selftests/x86/ptrace_syscall.c
index 6f22238f32173..12aaa063196e7 100644
--- a/tools/testing/selftests/x86/ptrace_syscall.c
+++ b/tools/testing/selftests/x86/ptrace_syscall.c
@@ -414,8 +414,12 @@ int main()
#if defined(__i386__) && (!defined(__GLIBC__) || __GLIBC__ > 2 || __GLIBC_MINOR__ >= 16)
vsyscall32 = (void *)getauxval(AT_SYSINFO);
- printf("[RUN]\tCheck AT_SYSINFO return regs\n");
- test_sys32_regs(do_full_vsyscall32);
+ if (vsyscall32) {
+ printf("[RUN]\tCheck AT_SYSINFO return regs\n");
+ test_sys32_regs(do_full_vsyscall32);
+ } else {
+ printf("[SKIP]\tAT_SYSINFO is not available\n");
+ }
#endif
test_ptrace_syscall_restart();
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 016/199] PCI/switchtec: Fix init_completion race condition with poll_wait()
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 015/199] selftests/x86/ptrace_syscall_32: Fix no-vDSO segfault Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 017/199] libata: Remove extra scsi_host_put() in ata_scsi_add_hosts() Greg Kroah-Hartman
` (114 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sebastian Andrzej Siewior,
Logan Gunthorpe, Thomas Gleixner, Peter Zijlstra (Intel),
Bjorn Helgaas, Sasha Levin
From: Logan Gunthorpe <logang@deltatee.com>
[ Upstream commit efbdc769601f4d50018bf7ca50fc9f7c67392ece ]
The call to init_completion() in mrpc_queue_cmd() can theoretically
race with the call to poll_wait() in switchtec_dev_poll().
poll() write()
switchtec_dev_poll() switchtec_dev_write()
poll_wait(&s->comp.wait); mrpc_queue_cmd()
init_completion(&s->comp)
init_waitqueue_head(&s->comp.wait)
To my knowledge, no one has hit this bug.
Fix this by using reinit_completion() instead of init_completion() in
mrpc_queue_cmd().
Fixes: 080b47def5e5 ("MicroSemi Switchtec management interface driver")
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lkml.kernel.org/r/20200313183608.2646-1-logang@deltatee.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/pci/switch/switchtec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index bf229b442e723..6ef0d4b756f09 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -412,7 +412,7 @@ static int mrpc_queue_cmd(struct switchtec_user *stuser)
kref_get(&stuser->kref);
stuser->read_len = sizeof(stuser->data);
stuser_set_state(stuser, MRPC_QUEUED);
- init_completion(&stuser->comp);
+ reinit_completion(&stuser->comp);
list_add_tail(&stuser->list, &stdev->mrpc_queue);
mrpc_cmd_submit(stdev);
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 017/199] libata: Remove extra scsi_host_put() in ata_scsi_add_hosts()
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 016/199] PCI/switchtec: Fix init_completion race condition with poll_wait() Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 018/199] gfs2: Dont demote a glock until its revokes are written Greg Kroah-Hartman
` (113 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, John Garry, Jens Axboe, Sasha Levin
From: John Garry <john.garry@huawei.com>
[ Upstream commit 1d72f7aec3595249dbb83291ccac041a2d676c57 ]
If the call to scsi_add_host_with_dma() in ata_scsi_add_hosts() fails,
then we may get use-after-free KASAN warns:
==================================================================
BUG: KASAN: use-after-free in kobject_put+0x24/0x180
Read of size 1 at addr ffff0026b8c80364 by task swapper/0/1
CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 5.6.0-rc3-00004-g5a71b206ea82-dirty #1765
Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDD, BIOS 2280-V2 CS V3.B160.01 02/24/2020
Call trace:
dump_backtrace+0x0/0x298
show_stack+0x14/0x20
dump_stack+0x118/0x190
print_address_description.isra.9+0x6c/0x3b8
__kasan_report+0x134/0x23c
kasan_report+0xc/0x18
__asan_load1+0x5c/0x68
kobject_put+0x24/0x180
put_device+0x10/0x20
scsi_host_put+0x10/0x18
ata_devres_release+0x74/0xb0
release_nodes+0x2d0/0x470
devres_release_all+0x50/0x78
really_probe+0x2d4/0x560
driver_probe_device+0x7c/0x148
device_driver_attach+0x94/0xa0
__driver_attach+0xa8/0x110
bus_for_each_dev+0xe8/0x158
driver_attach+0x30/0x40
bus_add_driver+0x220/0x2e0
driver_register+0xbc/0x1d0
__pci_register_driver+0xbc/0xd0
ahci_pci_driver_init+0x20/0x28
do_one_initcall+0xf0/0x608
kernel_init_freeable+0x31c/0x384
kernel_init+0x10/0x118
ret_from_fork+0x10/0x18
Allocated by task 5:
save_stack+0x28/0xc8
__kasan_kmalloc.isra.8+0xbc/0xd8
kasan_kmalloc+0xc/0x18
__kmalloc+0x1a8/0x280
scsi_host_alloc+0x44/0x678
ata_scsi_add_hosts+0x74/0x268
ata_host_register+0x228/0x488
ahci_host_activate+0x1c4/0x2a8
ahci_init_one+0xd18/0x1298
local_pci_probe+0x74/0xf0
work_for_cpu_fn+0x2c/0x48
process_one_work+0x488/0xc08
worker_thread+0x330/0x5d0
kthread+0x1c8/0x1d0
ret_from_fork+0x10/0x18
Freed by task 5:
save_stack+0x28/0xc8
__kasan_slab_free+0x118/0x180
kasan_slab_free+0x10/0x18
slab_free_freelist_hook+0xa4/0x1a0
kfree+0xd4/0x3a0
scsi_host_dev_release+0x100/0x148
device_release+0x7c/0xe0
kobject_put+0xb0/0x180
put_device+0x10/0x20
scsi_host_put+0x10/0x18
ata_scsi_add_hosts+0x210/0x268
ata_host_register+0x228/0x488
ahci_host_activate+0x1c4/0x2a8
ahci_init_one+0xd18/0x1298
local_pci_probe+0x74/0xf0
work_for_cpu_fn+0x2c/0x48
process_one_work+0x488/0xc08
worker_thread+0x330/0x5d0
kthread+0x1c8/0x1d0
ret_from_fork+0x10/0x18
There is also refcount issue, as well:
WARNING: CPU: 1 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0xf8/0x170
The issue is that we make an erroneous extra call to scsi_host_put()
for that host:
So in ahci_init_one()->ata_host_alloc_pinfo()->ata_host_alloc(), we setup
a device release method - ata_devres_release() - which intends to release
the SCSI hosts:
static void ata_devres_release(struct device *gendev, void *res)
{
...
for (i = 0; i < host->n_ports; i++) {
struct ata_port *ap = host->ports[i];
if (!ap)
continue;
if (ap->scsi_host)
scsi_host_put(ap->scsi_host);
}
...
}
However in the ata_scsi_add_hosts() error path, we also call
scsi_host_put() for the SCSI hosts.
Fix by removing the the scsi_host_put() calls in ata_scsi_add_hosts() and
leave this to ata_devres_release().
Fixes: f31871951b38 ("libata: separate out ata_host_alloc() and ata_host_register()")
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ata/libata-scsi.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index eb0c4ee205258..2f81d65342709 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -4571,22 +4571,19 @@ int ata_scsi_add_hosts(struct ata_host *host, struct scsi_host_template *sht)
*/
shost->max_host_blocked = 1;
- rc = scsi_add_host_with_dma(ap->scsi_host,
- &ap->tdev, ap->host->dev);
+ rc = scsi_add_host_with_dma(shost, &ap->tdev, ap->host->dev);
if (rc)
- goto err_add;
+ goto err_alloc;
}
return 0;
- err_add:
- scsi_host_put(host->ports[i]->scsi_host);
err_alloc:
while (--i >= 0) {
struct Scsi_Host *shost = host->ports[i]->scsi_host;
+ /* scsi_host_put() is in ata_devres_release() */
scsi_remove_host(shost);
- scsi_host_put(shost);
}
return rc;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 018/199] gfs2: Dont demote a glock until its revokes are written
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (16 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 017/199] libata: Remove extra scsi_host_put() in ata_scsi_add_hosts() Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 019/199] x86/boot: Use unsigned comparison for addresses Greg Kroah-Hartman
` (112 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bob Peterson, Andreas Gruenbacher,
Sasha Levin
From: Bob Peterson <rpeterso@redhat.com>
[ Upstream commit df5db5f9ee112e76b5202fbc331f990a0fc316d6 ]
Before this patch, run_queue would demote glocks based on whether
there are any more holders. But if the glock has pending revokes that
haven't been written to the media, giving up the glock might end in
file system corruption if the revokes never get written due to
io errors, node crashes and fences, etc. In that case, another node
will replay the metadata blocks associated with the glock, but
because the revoke was never written, it could replay that block
even though the glock had since been granted to another node who
might have made changes.
This patch changes the logic in run_queue so that it never demotes
a glock until its count of pending revokes reaches zero.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/gfs2/glock.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index aea1ed0aebd0f..1e2ff4b32c79a 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -636,6 +636,9 @@ __acquires(&gl->gl_lockref.lock)
goto out_unlock;
if (nonblock)
goto out_sched;
+ smp_mb();
+ if (atomic_read(&gl->gl_revokes) != 0)
+ goto out_sched;
set_bit(GLF_DEMOTE_IN_PROGRESS, &gl->gl_flags);
GLOCK_BUG_ON(gl, gl->gl_demote_state == LM_ST_EXCLUSIVE);
gl->gl_target = gl->gl_demote_state;
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 019/199] x86/boot: Use unsigned comparison for addresses
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (17 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 018/199] gfs2: Dont demote a glock until its revokes are written Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 020/199] efi/x86: Ignore the memory attributes table on i386 Greg Kroah-Hartman
` (111 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arvind Sankar, Ard Biesheuvel,
Ingo Molnar, Sasha Levin
From: Arvind Sankar <nivedita@alum.mit.edu>
[ Upstream commit 81a34892c2c7c809f9c4e22c5ac936ae673fb9a2 ]
The load address is compared with LOAD_PHYSICAL_ADDR using a signed
comparison currently (using jge instruction).
When loading a 64-bit kernel using the new efi32_pe_entry() point added by:
97aa276579b2 ("efi/x86: Add true mixed mode entry point into .compat section")
using Qemu with -m 3072, the firmware actually loads us above 2Gb,
resulting in a very early crash.
Use the JAE instruction to perform a unsigned comparison instead, as physical
addresses should be considered unsigned.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200301230436.2246909-6-nivedita@alum.mit.edu
Link: https://lore.kernel.org/r/20200308080859.21568-14-ardb@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/boot/compressed/head_32.S | 2 +-
arch/x86/boot/compressed/head_64.S | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/boot/compressed/head_32.S b/arch/x86/boot/compressed/head_32.S
index 37380c0d59996..01d628ea34024 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -106,7 +106,7 @@ ENTRY(startup_32)
notl %eax
andl %eax, %ebx
cmpl $LOAD_PHYSICAL_ADDR, %ebx
- jge 1f
+ jae 1f
#endif
movl $LOAD_PHYSICAL_ADDR, %ebx
1:
diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
index 39fdede523f21..a25127916e679 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -105,7 +105,7 @@ ENTRY(startup_32)
notl %eax
andl %eax, %ebx
cmpl $LOAD_PHYSICAL_ADDR, %ebx
- jge 1f
+ jae 1f
#endif
movl $LOAD_PHYSICAL_ADDR, %ebx
1:
@@ -280,7 +280,7 @@ ENTRY(startup_64)
notq %rax
andq %rax, %rbp
cmpq $LOAD_PHYSICAL_ADDR, %rbp
- jge 1f
+ jae 1f
#endif
movq $LOAD_PHYSICAL_ADDR, %rbp
1:
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 020/199] efi/x86: Ignore the memory attributes table on i386
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (18 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 019/199] x86/boot: Use unsigned comparison for addresses Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 021/199] genirq/irqdomain: Check pointer in irq_domain_alloc_irqs_hierarchy() Greg Kroah-Hartman
` (110 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arvind Sankar, Ard Biesheuvel,
Ingo Molnar, Sasha Levin
From: Ard Biesheuvel <ardb@kernel.org>
[ Upstream commit dd09fad9d2caad2325a39b766ce9e79cfc690184 ]
Commit:
3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE initialization common across all architectures")
moved the call to efi_memattr_init() from ARM specific to the generic
EFI init code, in order to be able to apply the restricted permissions
described in that table on x86 as well.
We never enabled this feature fully on i386, and so mapping and
reserving this table is pointless. However, due to the early call to
memblock_reserve(), the memory bookkeeping gets confused to the point
where it produces the splat below when we try to map the memory later
on:
------------[ cut here ]------------
ioremap on RAM at 0x3f251000 - 0x3fa1afff
WARNING: CPU: 0 PID: 0 at arch/x86/mm/ioremap.c:166 __ioremap_caller ...
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.20.0 #48
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
EIP: __ioremap_caller.constprop.0+0x249/0x260
Code: 90 0f b7 05 4e 38 40 de 09 45 e0 e9 09 ff ff ff 90 8d 45 ec c6 05 ...
EAX: 00000029 EBX: 00000000 ECX: de59c228 EDX: 00000001
ESI: 3f250fff EDI: 00000000 EBP: de3edf20 ESP: de3edee0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00200296
CR0: 80050033 CR2: ffd17000 CR3: 1e58c000 CR4: 00040690
Call Trace:
ioremap_cache+0xd/0x10
? old_map_region+0x72/0x9d
old_map_region+0x72/0x9d
efi_map_region+0x8/0xa
efi_enter_virtual_mode+0x260/0x43b
start_kernel+0x329/0x3aa
i386_start_kernel+0xa7/0xab
startup_32_smp+0x164/0x168
---[ end trace e15ccf6b9f356833 ]---
Let's work around this by disregarding the memory attributes table
altogether on i386, which does not result in a loss of functionality
or protection, given that we never consumed the contents.
Fixes: 3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE ... ")
Tested-by: Arvind Sankar <nivedita@alum.mit.edu>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200304165917.5893-1-ardb@kernel.org
Link: https://lore.kernel.org/r/20200308080859.21568-21-ardb@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/firmware/efi/efi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index f50072b51aefb..b39b7e6d4e4dc 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -550,7 +550,7 @@ int __init efi_config_parse_tables(void *config_tables, int count, int sz,
}
}
- if (efi_enabled(EFI_MEMMAP))
+ if (!IS_ENABLED(CONFIG_X86_32) && efi_enabled(EFI_MEMMAP))
efi_memattr_init();
/* Parse the EFI Properties table if it exists */
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 021/199] genirq/irqdomain: Check pointer in irq_domain_alloc_irqs_hierarchy()
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (19 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 020/199] efi/x86: Ignore the memory attributes table on i386 Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 022/199] block: Fix use-after-free issue accessing struct io_cq Greg Kroah-Hartman
` (109 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexander Sverdlin, Thomas Gleixner,
Sasha Levin
From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
[ Upstream commit 87f2d1c662fa1761359fdf558246f97e484d177a ]
irq_domain_alloc_irqs_hierarchy() has 3 call sites in the compilation unit
but only one of them checks for the pointer which is being dereferenced
inside the called function. Move the check into the function. This allows
for catching the error instead of the following crash:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
PC is at 0x0
LR is at gpiochip_hierarchy_irq_domain_alloc+0x11f/0x140
...
[<c06c23ff>] (gpiochip_hierarchy_irq_domain_alloc)
[<c0462a89>] (__irq_domain_alloc_irqs)
[<c0462dad>] (irq_create_fwspec_mapping)
[<c06c2251>] (gpiochip_to_irq)
[<c06c1c9b>] (gpiod_to_irq)
[<bf973073>] (gpio_irqs_init [gpio_irqs])
[<bf974048>] (gpio_irqs_exit+0xecc/0xe84 [gpio_irqs])
Code: bad PC value
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20200306174720.82604-1-alexander.sverdlin@nokia.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/irq/irqdomain.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index b269ae16b10cd..0d54f8256b9f4 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1372,6 +1372,11 @@ int irq_domain_alloc_irqs_hierarchy(struct irq_domain *domain,
unsigned int irq_base,
unsigned int nr_irqs, void *arg)
{
+ if (!domain->ops->alloc) {
+ pr_debug("domain->ops->alloc() is NULL\n");
+ return -ENOSYS;
+ }
+
return domain->ops->alloc(domain, irq_base, nr_irqs, arg);
}
@@ -1409,11 +1414,6 @@ int __irq_domain_alloc_irqs(struct irq_domain *domain, int irq_base,
return -EINVAL;
}
- if (!domain->ops->alloc) {
- pr_debug("domain->ops->alloc() is NULL\n");
- return -ENOSYS;
- }
-
if (realloc && irq_base >= 0) {
virq = irq_base;
} else {
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 022/199] block: Fix use-after-free issue accessing struct io_cq
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (20 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 021/199] genirq/irqdomain: Check pointer in irq_domain_alloc_irqs_hierarchy() Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 023/199] usb: dwc3: core: add support for disabling SS instances in park mode Greg Kroah-Hartman
` (108 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sahitya Tummala, Pradeep P V K,
Jens Axboe, Sasha Levin
From: Sahitya Tummala <stummala@codeaurora.org>
[ Upstream commit 30a2da7b7e225ef6c87a660419ea04d3cef3f6a7 ]
There is a potential race between ioc_release_fn() and
ioc_clear_queue() as shown below, due to which below kernel
crash is observed. It also can result into use-after-free
issue.
context#1: context#2:
ioc_release_fn() __ioc_clear_queue() gets the same icq
->spin_lock(&ioc->lock); ->spin_lock(&ioc->lock);
->ioc_destroy_icq(icq);
->list_del_init(&icq->q_node);
->call_rcu(&icq->__rcu_head,
icq_free_icq_rcu);
->spin_unlock(&ioc->lock);
->ioc_destroy_icq(icq);
->hlist_del_init(&icq->ioc_node);
This results into below crash as this memory
is now used by icq->__rcu_head in context#1.
There is a chance that icq could be free'd
as well.
22150.386550: <6> Unable to handle kernel write to read-only memory
at virtual address ffffffaa8d31ca50
...
Call trace:
22150.607350: <2> ioc_destroy_icq+0x44/0x110
22150.611202: <2> ioc_clear_queue+0xac/0x148
22150.615056: <2> blk_cleanup_queue+0x11c/0x1a0
22150.619174: <2> __scsi_remove_device+0xdc/0x128
22150.623465: <2> scsi_forget_host+0x2c/0x78
22150.627315: <2> scsi_remove_host+0x7c/0x2a0
22150.631257: <2> usb_stor_disconnect+0x74/0xc8
22150.635371: <2> usb_unbind_interface+0xc8/0x278
22150.639665: <2> device_release_driver_internal+0x198/0x250
22150.644897: <2> device_release_driver+0x24/0x30
22150.649176: <2> bus_remove_device+0xec/0x140
22150.653204: <2> device_del+0x270/0x460
22150.656712: <2> usb_disable_device+0x120/0x390
22150.660918: <2> usb_disconnect+0xf4/0x2e0
22150.664684: <2> hub_event+0xd70/0x17e8
22150.668197: <2> process_one_work+0x210/0x480
22150.672222: <2> worker_thread+0x32c/0x4c8
Fix this by adding a new ICQ_DESTROYED flag in ioc_destroy_icq() to
indicate this icq is once marked as destroyed. Also, ensure
__ioc_clear_queue() is accessing icq within rcu_read_lock/unlock so
that icq doesn't get free'd up while it is still using it.
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Co-developed-by: Pradeep P V K <ppvk@codeaurora.org>
Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
block/blk-ioc.c | 7 +++++++
include/linux/iocontext.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/block/blk-ioc.c b/block/blk-ioc.c
index f23311e4b201f..e56a480b6f929 100644
--- a/block/blk-ioc.c
+++ b/block/blk-ioc.c
@@ -87,6 +87,7 @@ static void ioc_destroy_icq(struct io_cq *icq)
* making it impossible to determine icq_cache. Record it in @icq.
*/
icq->__rcu_icq_cache = et->icq_cache;
+ icq->flags |= ICQ_DESTROYED;
call_rcu(&icq->__rcu_head, icq_free_icq_rcu);
}
@@ -230,15 +231,21 @@ static void __ioc_clear_queue(struct list_head *icq_list)
{
unsigned long flags;
+ rcu_read_lock();
while (!list_empty(icq_list)) {
struct io_cq *icq = list_entry(icq_list->next,
struct io_cq, q_node);
struct io_context *ioc = icq->ioc;
spin_lock_irqsave(&ioc->lock, flags);
+ if (icq->flags & ICQ_DESTROYED) {
+ spin_unlock_irqrestore(&ioc->lock, flags);
+ continue;
+ }
ioc_destroy_icq(icq);
spin_unlock_irqrestore(&ioc->lock, flags);
}
+ rcu_read_unlock();
}
/**
diff --git a/include/linux/iocontext.h b/include/linux/iocontext.h
index dba15ca8e60bc..1dcd9198beb7f 100644
--- a/include/linux/iocontext.h
+++ b/include/linux/iocontext.h
@@ -8,6 +8,7 @@
enum {
ICQ_EXITED = 1 << 2,
+ ICQ_DESTROYED = 1 << 3,
};
/*
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 023/199] usb: dwc3: core: add support for disabling SS instances in park mode
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (21 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 022/199] block: Fix use-after-free issue accessing struct io_cq Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 024/199] irqchip/gic-v4: Provide irq_retrigger to avoid circular locking dependency Greg Kroah-Hartman
` (107 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dongjin Kim, Jianxin Pan,
Thinh Nguyen, Jun Li, Tim, Neil Armstrong, Felipe Balbi,
Sasha Levin
From: Neil Armstrong <narmstrong@baylibre.com>
[ Upstream commit 7ba6b09fda5e0cb741ee56f3264665e0edc64822 ]
In certain circumstances, the XHCI SuperSpeed instance in park mode
can fail to recover, thus on Amlogic G12A/G12B/SM1 SoCs when there is high
load on the single XHCI SuperSpeed instance, the controller can crash like:
xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
xhci-hcd xhci-hcd.0.auto: Host halt failed, -110
xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
hub 2-1.1:1.0: hub_ext_port_status failed (err = -22)
xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
usb 2-1.1-port1: cannot reset (err = -22)
Setting the PARKMODE_DISABLE_SS bit in the DWC3_USB3_GUCTL1 mitigates
the issue. The bit is described as :
"When this bit is set to '1' all SS bus instances in park mode are disabled"
Synopsys explains:
The GUCTL1.PARKMODE_DISABLE_SS is only available in
dwc_usb3 controller running in host mode.
This should not be set for other IPs.
This can be disabled by default based on IP, but I recommend to have a
property to enable this feature for devices that need this.
CC: Dongjin Kim <tobetter@gmail.com>
Cc: Jianxin Pan <jianxin.pan@amlogic.com>
Cc: Thinh Nguyen <thinhn@synopsys.com>
Cc: Jun Li <lijun.kernel@gmail.com>
Reported-by: Tim <elatllat@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/usb/dwc3/core.c | 5 +++++
drivers/usb/dwc3/core.h | 4 ++++
2 files changed, 9 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 021899c580288..010201dbd029a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -867,6 +867,9 @@ static int dwc3_core_init(struct dwc3 *dwc)
if (dwc->dis_tx_ipgap_linecheck_quirk)
reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
+ if (dwc->parkmode_disable_ss_quirk)
+ reg |= DWC3_GUCTL1_PARKMODE_DISABLE_SS;
+
dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
}
@@ -1107,6 +1110,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
"snps,dis-del-phy-power-chg-quirk");
dwc->dis_tx_ipgap_linecheck_quirk = device_property_read_bool(dev,
"snps,dis-tx-ipgap-linecheck-quirk");
+ dwc->parkmode_disable_ss_quirk = device_property_read_bool(dev,
+ "snps,parkmode-disable-ss-quirk");
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 40bf0e0768d96..8747f9f02229e 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -206,6 +206,7 @@
#define DWC3_GCTL_DSBLCLKGTNG BIT(0)
/* Global User Control 1 Register */
+#define DWC3_GUCTL1_PARKMODE_DISABLE_SS BIT(17)
#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
#define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW BIT(24)
@@ -863,6 +864,8 @@ struct dwc3_scratchpad_array {
* change quirk.
* @dis_tx_ipgap_linecheck_quirk: set if we disable u2mac linestate
* check during HS transmit.
+ * @parkmode_disable_ss_quirk: set if we need to disable all SuperSpeed
+ * instances in park mode.
* @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
* @tx_de_emphasis: Tx de-emphasis value
* 0 - -6dB de-emphasis
@@ -1022,6 +1025,7 @@ struct dwc3 {
unsigned dis_u2_freeclk_exists_quirk:1;
unsigned dis_del_phy_power_chg_quirk:1;
unsigned dis_tx_ipgap_linecheck_quirk:1;
+ unsigned parkmode_disable_ss_quirk:1;
unsigned tx_de_emphasis_quirk:1;
unsigned tx_de_emphasis:2;
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 024/199] irqchip/gic-v4: Provide irq_retrigger to avoid circular locking dependency
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (22 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 023/199] usb: dwc3: core: add support for disabling SS instances in park mode Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 025/199] locking/lockdep: Avoid recursion in lockdep_count_{for,back}ward_deps() Greg Kroah-Hartman
` (106 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Marc Zyngier, Sasha Levin
From: Marc Zyngier <maz@kernel.org>
[ Upstream commit 7809f7011c3bce650e502a98afeb05961470d865 ]
On a very heavily loaded D05 with GICv4, I managed to trigger the
following lockdep splat:
[ 6022.598864] ======================================================
[ 6022.605031] WARNING: possible circular locking dependency detected
[ 6022.611200] 5.6.0-rc4-00026-geee7c7b0f498 #680 Tainted: G E
[ 6022.618061] ------------------------------------------------------
[ 6022.624227] qemu-system-aar/7569 is trying to acquire lock:
[ 6022.629789] ffff042f97606808 (&p->pi_lock){-.-.}, at: try_to_wake_up+0x54/0x7a0
[ 6022.637102]
[ 6022.637102] but task is already holding lock:
[ 6022.642921] ffff002fae424cf0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x5c/0x98
[ 6022.651350]
[ 6022.651350] which lock already depends on the new lock.
[ 6022.651350]
[ 6022.659512]
[ 6022.659512] the existing dependency chain (in reverse order) is:
[ 6022.666980]
[ 6022.666980] -> #2 (&irq_desc_lock_class){-.-.}:
[ 6022.672983] _raw_spin_lock_irqsave+0x50/0x78
[ 6022.677848] __irq_get_desc_lock+0x5c/0x98
[ 6022.682453] irq_set_vcpu_affinity+0x40/0xc0
[ 6022.687236] its_make_vpe_non_resident+0x6c/0xb8
[ 6022.692364] vgic_v4_put+0x54/0x70
[ 6022.696273] vgic_v3_put+0x20/0xd8
[ 6022.700183] kvm_vgic_put+0x30/0x48
[ 6022.704182] kvm_arch_vcpu_put+0x34/0x50
[ 6022.708614] kvm_sched_out+0x34/0x50
[ 6022.712700] __schedule+0x4bc/0x7f8
[ 6022.716697] schedule+0x50/0xd8
[ 6022.720347] kvm_arch_vcpu_ioctl_run+0x5f0/0x978
[ 6022.725473] kvm_vcpu_ioctl+0x3d4/0x8f8
[ 6022.729820] ksys_ioctl+0x90/0xd0
[ 6022.733642] __arm64_sys_ioctl+0x24/0x30
[ 6022.738074] el0_svc_common.constprop.3+0xa8/0x1e8
[ 6022.743373] do_el0_svc+0x28/0x88
[ 6022.747198] el0_svc+0x14/0x40
[ 6022.750761] el0_sync_handler+0x124/0x2b8
[ 6022.755278] el0_sync+0x140/0x180
[ 6022.759100]
[ 6022.759100] -> #1 (&rq->lock){-.-.}:
[ 6022.764143] _raw_spin_lock+0x38/0x50
[ 6022.768314] task_fork_fair+0x40/0x128
[ 6022.772572] sched_fork+0xe0/0x210
[ 6022.776484] copy_process+0x8c4/0x18d8
[ 6022.780742] _do_fork+0x88/0x6d8
[ 6022.784478] kernel_thread+0x64/0x88
[ 6022.788563] rest_init+0x30/0x270
[ 6022.792390] arch_call_rest_init+0x14/0x1c
[ 6022.796995] start_kernel+0x498/0x4c4
[ 6022.801164]
[ 6022.801164] -> #0 (&p->pi_lock){-.-.}:
[ 6022.806382] __lock_acquire+0xdd8/0x15c8
[ 6022.810813] lock_acquire+0xd0/0x218
[ 6022.814896] _raw_spin_lock_irqsave+0x50/0x78
[ 6022.819761] try_to_wake_up+0x54/0x7a0
[ 6022.824018] wake_up_process+0x1c/0x28
[ 6022.828276] wakeup_softirqd+0x38/0x40
[ 6022.832533] __tasklet_schedule_common+0xc4/0xf0
[ 6022.837658] __tasklet_schedule+0x24/0x30
[ 6022.842176] check_irq_resend+0xc8/0x158
[ 6022.846609] irq_startup+0x74/0x128
[ 6022.850606] __enable_irq+0x6c/0x78
[ 6022.854602] enable_irq+0x54/0xa0
[ 6022.858431] its_make_vpe_non_resident+0xa4/0xb8
[ 6022.863557] vgic_v4_put+0x54/0x70
[ 6022.867469] kvm_arch_vcpu_blocking+0x28/0x38
[ 6022.872336] kvm_vcpu_block+0x48/0x490
[ 6022.876594] kvm_handle_wfx+0x18c/0x310
[ 6022.880938] handle_exit+0x138/0x198
[ 6022.885022] kvm_arch_vcpu_ioctl_run+0x4d4/0x978
[ 6022.890148] kvm_vcpu_ioctl+0x3d4/0x8f8
[ 6022.894494] ksys_ioctl+0x90/0xd0
[ 6022.898317] __arm64_sys_ioctl+0x24/0x30
[ 6022.902748] el0_svc_common.constprop.3+0xa8/0x1e8
[ 6022.908046] do_el0_svc+0x28/0x88
[ 6022.911871] el0_svc+0x14/0x40
[ 6022.915434] el0_sync_handler+0x124/0x2b8
[ 6022.919951] el0_sync+0x140/0x180
[ 6022.923773]
[ 6022.923773] other info that might help us debug this:
[ 6022.923773]
[ 6022.931762] Chain exists of:
[ 6022.931762] &p->pi_lock --> &rq->lock --> &irq_desc_lock_class
[ 6022.931762]
[ 6022.942101] Possible unsafe locking scenario:
[ 6022.942101]
[ 6022.948007] CPU0 CPU1
[ 6022.952523] ---- ----
[ 6022.957039] lock(&irq_desc_lock_class);
[ 6022.961036] lock(&rq->lock);
[ 6022.966595] lock(&irq_desc_lock_class);
[ 6022.973109] lock(&p->pi_lock);
[ 6022.976324]
[ 6022.976324] *** DEADLOCK ***
This is happening because we have a pending doorbell that requires
retrigger. As SW retriggering is done in a tasklet, we trigger the
circular dependency above.
The easy cop-out is to provide a retrigger callback that doesn't
require acquiring any extra lock.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200310184921.23552-5-maz@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/irqchip/irq-gic-v3-its.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 799df1e598db3..84b23d902d5b8 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -2591,12 +2591,18 @@ static int its_vpe_set_irqchip_state(struct irq_data *d,
return 0;
}
+static int its_vpe_retrigger(struct irq_data *d)
+{
+ return !its_vpe_set_irqchip_state(d, IRQCHIP_STATE_PENDING, true);
+}
+
static struct irq_chip its_vpe_irq_chip = {
.name = "GICv4-vpe",
.irq_mask = its_vpe_mask_irq,
.irq_unmask = its_vpe_unmask_irq,
.irq_eoi = irq_chip_eoi_parent,
.irq_set_affinity = its_vpe_set_affinity,
+ .irq_retrigger = its_vpe_retrigger,
.irq_set_irqchip_state = its_vpe_set_irqchip_state,
.irq_set_vcpu_affinity = its_vpe_set_vcpu_affinity,
};
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 025/199] locking/lockdep: Avoid recursion in lockdep_count_{for,back}ward_deps()
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (23 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 024/199] irqchip/gic-v4: Provide irq_retrigger to avoid circular locking dependency Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 026/199] block, bfq: fix use-after-free in bfq_idle_slice_timer_body Greg Kroah-Hartman
` (105 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Qian Cai, Boqun Feng,
Peter Zijlstra (Intel),
Sasha Levin
From: Boqun Feng <boqun.feng@gmail.com>
[ Upstream commit 25016bd7f4caf5fc983bbab7403d08e64cba3004 ]
Qian Cai reported a bug when PROVE_RCU_LIST=y, and read on /proc/lockdep
triggered a warning:
[ ] DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)
...
[ ] Call Trace:
[ ] lock_is_held_type+0x5d/0x150
[ ] ? rcu_lockdep_current_cpu_online+0x64/0x80
[ ] rcu_read_lock_any_held+0xac/0x100
[ ] ? rcu_read_lock_held+0xc0/0xc0
[ ] ? __slab_free+0x421/0x540
[ ] ? kasan_kmalloc+0x9/0x10
[ ] ? __kmalloc_node+0x1d7/0x320
[ ] ? kvmalloc_node+0x6f/0x80
[ ] __bfs+0x28a/0x3c0
[ ] ? class_equal+0x30/0x30
[ ] lockdep_count_forward_deps+0x11a/0x1a0
The warning got triggered because lockdep_count_forward_deps() call
__bfs() without current->lockdep_recursion being set, as a result
a lockdep internal function (__bfs()) is checked by lockdep, which is
unexpected, and the inconsistency between the irq-off state and the
state traced by lockdep caused the warning.
Apart from this warning, lockdep internal functions like __bfs() should
always be protected by current->lockdep_recursion to avoid potential
deadlocks and data inconsistency, therefore add the
current->lockdep_recursion on-and-off section to protect __bfs() in both
lockdep_count_forward_deps() and lockdep_count_backward_deps()
Reported-by: Qian Cai <cai@lca.pw>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200312151258.128036-1-boqun.feng@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/locking/lockdep.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 90a3469a7a888..03e3ab61a2edd 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1297,9 +1297,11 @@ unsigned long lockdep_count_forward_deps(struct lock_class *class)
this.class = class;
raw_local_irq_save(flags);
+ current->lockdep_recursion = 1;
arch_spin_lock(&lockdep_lock);
ret = __lockdep_count_forward_deps(&this);
arch_spin_unlock(&lockdep_lock);
+ current->lockdep_recursion = 0;
raw_local_irq_restore(flags);
return ret;
@@ -1324,9 +1326,11 @@ unsigned long lockdep_count_backward_deps(struct lock_class *class)
this.class = class;
raw_local_irq_save(flags);
+ current->lockdep_recursion = 1;
arch_spin_lock(&lockdep_lock);
ret = __lockdep_count_backward_deps(&this);
arch_spin_unlock(&lockdep_lock);
+ current->lockdep_recursion = 0;
raw_local_irq_restore(flags);
return ret;
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 026/199] block, bfq: fix use-after-free in bfq_idle_slice_timer_body
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (24 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 025/199] locking/lockdep: Avoid recursion in lockdep_count_{for,back}ward_deps() Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 027/199] btrfs: remove a BUG_ON() from merge_reloc_roots() Greg Kroah-Hartman
` (104 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paolo Valente, Wang Wang,
Zhiqiang Liu, Feilong Lin, Jens Axboe, Sasha Levin
From: Zhiqiang Liu <liuzhiqiang26@huawei.com>
[ Upstream commit 2f95fa5c955d0a9987ffdc3a095e2f4e62c5f2a9 ]
In bfq_idle_slice_timer func, bfqq = bfqd->in_service_queue is
not in bfqd-lock critical section. The bfqq, which is not
equal to NULL in bfq_idle_slice_timer, may be freed after passing
to bfq_idle_slice_timer_body. So we will access the freed memory.
In addition, considering the bfqq may be in race, we should
firstly check whether bfqq is in service before doing something
on it in bfq_idle_slice_timer_body func. If the bfqq in race is
not in service, it means the bfqq has been expired through
__bfq_bfqq_expire func, and wait_request flags has been cleared in
__bfq_bfqd_reset_in_service func. So we do not need to re-clear the
wait_request of bfqq which is not in service.
KASAN log is given as follows:
[13058.354613] ==================================================================
[13058.354640] BUG: KASAN: use-after-free in bfq_idle_slice_timer+0xac/0x290
[13058.354644] Read of size 8 at addr ffffa02cf3e63f78 by task fork13/19767
[13058.354646]
[13058.354655] CPU: 96 PID: 19767 Comm: fork13
[13058.354661] Call trace:
[13058.354667] dump_backtrace+0x0/0x310
[13058.354672] show_stack+0x28/0x38
[13058.354681] dump_stack+0xd8/0x108
[13058.354687] print_address_description+0x68/0x2d0
[13058.354690] kasan_report+0x124/0x2e0
[13058.354697] __asan_load8+0x88/0xb0
[13058.354702] bfq_idle_slice_timer+0xac/0x290
[13058.354707] __hrtimer_run_queues+0x298/0x8b8
[13058.354710] hrtimer_interrupt+0x1b8/0x678
[13058.354716] arch_timer_handler_phys+0x4c/0x78
[13058.354722] handle_percpu_devid_irq+0xf0/0x558
[13058.354731] generic_handle_irq+0x50/0x70
[13058.354735] __handle_domain_irq+0x94/0x110
[13058.354739] gic_handle_irq+0x8c/0x1b0
[13058.354742] el1_irq+0xb8/0x140
[13058.354748] do_wp_page+0x260/0xe28
[13058.354752] __handle_mm_fault+0x8ec/0x9b0
[13058.354756] handle_mm_fault+0x280/0x460
[13058.354762] do_page_fault+0x3ec/0x890
[13058.354765] do_mem_abort+0xc0/0x1b0
[13058.354768] el0_da+0x24/0x28
[13058.354770]
[13058.354773] Allocated by task 19731:
[13058.354780] kasan_kmalloc+0xe0/0x190
[13058.354784] kasan_slab_alloc+0x14/0x20
[13058.354788] kmem_cache_alloc_node+0x130/0x440
[13058.354793] bfq_get_queue+0x138/0x858
[13058.354797] bfq_get_bfqq_handle_split+0xd4/0x328
[13058.354801] bfq_init_rq+0x1f4/0x1180
[13058.354806] bfq_insert_requests+0x264/0x1c98
[13058.354811] blk_mq_sched_insert_requests+0x1c4/0x488
[13058.354818] blk_mq_flush_plug_list+0x2d4/0x6e0
[13058.354826] blk_flush_plug_list+0x230/0x548
[13058.354830] blk_finish_plug+0x60/0x80
[13058.354838] read_pages+0xec/0x2c0
[13058.354842] __do_page_cache_readahead+0x374/0x438
[13058.354846] ondemand_readahead+0x24c/0x6b0
[13058.354851] page_cache_sync_readahead+0x17c/0x2f8
[13058.354858] generic_file_buffered_read+0x588/0xc58
[13058.354862] generic_file_read_iter+0x1b4/0x278
[13058.354965] ext4_file_read_iter+0xa8/0x1d8 [ext4]
[13058.354972] __vfs_read+0x238/0x320
[13058.354976] vfs_read+0xbc/0x1c0
[13058.354980] ksys_read+0xdc/0x1b8
[13058.354984] __arm64_sys_read+0x50/0x60
[13058.354990] el0_svc_common+0xb4/0x1d8
[13058.354994] el0_svc_handler+0x50/0xa8
[13058.354998] el0_svc+0x8/0xc
[13058.354999]
[13058.355001] Freed by task 19731:
[13058.355007] __kasan_slab_free+0x120/0x228
[13058.355010] kasan_slab_free+0x10/0x18
[13058.355014] kmem_cache_free+0x288/0x3f0
[13058.355018] bfq_put_queue+0x134/0x208
[13058.355022] bfq_exit_icq_bfqq+0x164/0x348
[13058.355026] bfq_exit_icq+0x28/0x40
[13058.355030] ioc_exit_icq+0xa0/0x150
[13058.355035] put_io_context_active+0x250/0x438
[13058.355038] exit_io_context+0xd0/0x138
[13058.355045] do_exit+0x734/0xc58
[13058.355050] do_group_exit+0x78/0x220
[13058.355054] __wake_up_parent+0x0/0x50
[13058.355058] el0_svc_common+0xb4/0x1d8
[13058.355062] el0_svc_handler+0x50/0xa8
[13058.355066] el0_svc+0x8/0xc
[13058.355067]
[13058.355071] The buggy address belongs to the object at ffffa02cf3e63e70#012 which belongs to the cache bfq_queue of size 464
[13058.355075] The buggy address is located 264 bytes inside of#012 464-byte region [ffffa02cf3e63e70, ffffa02cf3e64040)
[13058.355077] The buggy address belongs to the page:
[13058.355083] page:ffff7e80b3cf9800 count:1 mapcount:0 mapping:ffff802db5c90780 index:0xffffa02cf3e606f0 compound_mapcount: 0
[13058.366175] flags: 0x2ffffe0000008100(slab|head)
[13058.370781] raw: 2ffffe0000008100 ffff7e80b53b1408 ffffa02d730c1c90 ffff802db5c90780
[13058.370787] raw: ffffa02cf3e606f0 0000000000370023 00000001ffffffff 0000000000000000
[13058.370789] page dumped because: kasan: bad access detected
[13058.370791]
[13058.370792] Memory state around the buggy address:
[13058.370797] ffffa02cf3e63e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb
[13058.370801] ffffa02cf3e63e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[13058.370805] >ffffa02cf3e63f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[13058.370808] ^
[13058.370811] ffffa02cf3e63f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[13058.370815] ffffa02cf3e64000: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[13058.370817] ==================================================================
[13058.370820] Disabling lock debugging due to kernel taint
Here, we directly pass the bfqd to bfq_idle_slice_timer_body func.
--
V2->V3: rewrite the comment as suggested by Paolo Valente
V1->V2: add one comment, and add Fixes and Reported-by tag.
Fixes: aee69d78d ("block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler")
Acked-by: Paolo Valente <paolo.valente@linaro.org>
Reported-by: Wang Wang <wangwang2@huawei.com>
Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Signed-off-by: Feilong Lin <linfeilong@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
block/bfq-iosched.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 93863c6173e66..959bee9fa9118 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -4541,20 +4541,28 @@ static void bfq_prepare_request(struct request *rq, struct bio *bio)
spin_unlock_irq(&bfqd->lock);
}
-static void bfq_idle_slice_timer_body(struct bfq_queue *bfqq)
+static void
+bfq_idle_slice_timer_body(struct bfq_data *bfqd, struct bfq_queue *bfqq)
{
- struct bfq_data *bfqd = bfqq->bfqd;
enum bfqq_expiration reason;
unsigned long flags;
spin_lock_irqsave(&bfqd->lock, flags);
- bfq_clear_bfqq_wait_request(bfqq);
+ /*
+ * Considering that bfqq may be in race, we should firstly check
+ * whether bfqq is in service before doing something on it. If
+ * the bfqq in race is not in service, it has already been expired
+ * through __bfq_bfqq_expire func and its wait_request flags has
+ * been cleared in __bfq_bfqd_reset_in_service func.
+ */
if (bfqq != bfqd->in_service_queue) {
spin_unlock_irqrestore(&bfqd->lock, flags);
return;
}
+ bfq_clear_bfqq_wait_request(bfqq);
+
if (bfq_bfqq_budget_timeout(bfqq))
/*
* Also here the queue can be safely expired
@@ -4599,7 +4607,7 @@ static enum hrtimer_restart bfq_idle_slice_timer(struct hrtimer *timer)
* early.
*/
if (bfqq)
- bfq_idle_slice_timer_body(bfqq);
+ bfq_idle_slice_timer_body(bfqd, bfqq);
return HRTIMER_NORESTART;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 027/199] btrfs: remove a BUG_ON() from merge_reloc_roots()
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (25 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 026/199] block, bfq: fix use-after-free in bfq_idle_slice_timer_body Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 028/199] btrfs: track reloc roots based on their commit root bytenr Greg Kroah-Hartman
` (103 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Qu Wenruo, Josef Bacik, David Sterba,
Sasha Levin
From: Josef Bacik <josef@toxicpanda.com>
[ Upstream commit 7b7b74315b24dc064bc1c683659061c3d48f8668 ]
This was pretty subtle, we default to reloc roots having 0 root refs, so
if we crash in the middle of the relocation they can just be deleted.
If we successfully complete the relocation operations we'll set our root
refs to 1 in prepare_to_merge() and then go on to merge_reloc_roots().
At prepare_to_merge() time if any of the reloc roots have a 0 reference
still, we will remove that reloc root from our reloc root rb tree, and
then clean it up later.
However this only happens if we successfully start a transaction. If
we've aborted previously we will skip this step completely, and only
have reloc roots with a reference count of 0, but were never properly
removed from the reloc control's rb tree.
This isn't a problem per-se, our references are held by the list the
reloc roots are on, and by the original root the reloc root belongs to.
If we end up in this situation all the reloc roots will be added to the
dirty_reloc_list, and then properly dropped at that point. The reloc
control will be free'd and the rb tree is no longer used.
There were two options when fixing this, one was to remove the BUG_ON(),
the other was to make prepare_to_merge() handle the case where we
couldn't start a trans handle.
IMO this is the cleaner solution. I started with handling the error in
prepare_to_merge(), but it turned out super ugly. And in the end this
BUG_ON() simply doesn't matter, the cleanup was happening properly, we
were just panicing because this BUG_ON() only matters in the success
case. So I've opted to just remove it and add a comment where it was.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/relocation.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index d4c00edd16d2b..42f388ed0796b 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2480,7 +2480,21 @@ out:
free_reloc_roots(&reloc_roots);
}
- BUG_ON(!RB_EMPTY_ROOT(&rc->reloc_root_tree.rb_root));
+ /*
+ * We used to have
+ *
+ * BUG_ON(!RB_EMPTY_ROOT(&rc->reloc_root_tree.rb_root));
+ *
+ * here, but it's wrong. If we fail to start the transaction in
+ * prepare_to_merge() we will have only 0 ref reloc roots, none of which
+ * have actually been removed from the reloc_root_tree rb tree. This is
+ * fine because we're bailing here, and we hold a reference on the root
+ * for the list that holds it, so these roots will be cleaned up when we
+ * do the reloc_dirty_list afterwards. Meanwhile the root->reloc_root
+ * will be cleaned up on unmount.
+ *
+ * The remaining nodes will be cleaned up by free_reloc_control.
+ */
}
static void free_block_list(struct rb_root *blocks)
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 028/199] btrfs: track reloc roots based on their commit root bytenr
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (26 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 027/199] btrfs: remove a BUG_ON() from merge_reloc_roots() Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 029/199] uapi: rename ext2_swab() to swab() and share globally in swab.h Greg Kroah-Hartman
` (102 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Josef Bacik, David Sterba, Sasha Levin
From: Josef Bacik <josef@toxicpanda.com>
[ Upstream commit ea287ab157c2816bf12aad4cece41372f9d146b4 ]
We always search the commit root of the extent tree for looking up back
references, however we track the reloc roots based on their current
bytenr.
This is wrong, if we commit the transaction between relocating tree
blocks we could end up in this code in build_backref_tree
if (key.objectid == key.offset) {
/*
* Only root blocks of reloc trees use backref
* pointing to itself.
*/
root = find_reloc_root(rc, cur->bytenr);
ASSERT(root);
cur->root = root;
break;
}
find_reloc_root() is looking based on the bytenr we had in the commit
root, but if we've COWed this reloc root we will not find that bytenr,
and we will trip over the ASSERT(root).
Fix this by using the commit_root->start bytenr for indexing the commit
root. Then we change the __update_reloc_root() caller to be used when
we switch the commit root for the reloc root during commit.
This fixes the panic I was seeing when we started throttling relocation
for delayed refs.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/relocation.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 42f388ed0796b..04db7c5f5ca4e 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1306,7 +1306,7 @@ static int __must_check __add_reloc_root(struct btrfs_root *root)
if (!node)
return -ENOMEM;
- node->bytenr = root->node->start;
+ node->bytenr = root->commit_root->start;
node->data = root;
spin_lock(&rc->reloc_root_tree.lock);
@@ -1337,10 +1337,11 @@ static void __del_reloc_root(struct btrfs_root *root)
if (rc && root->node) {
spin_lock(&rc->reloc_root_tree.lock);
rb_node = tree_search(&rc->reloc_root_tree.rb_root,
- root->node->start);
+ root->commit_root->start);
if (rb_node) {
node = rb_entry(rb_node, struct mapping_node, rb_node);
rb_erase(&node->rb_node, &rc->reloc_root_tree.rb_root);
+ RB_CLEAR_NODE(&node->rb_node);
}
spin_unlock(&rc->reloc_root_tree.lock);
if (!node)
@@ -1358,7 +1359,7 @@ static void __del_reloc_root(struct btrfs_root *root)
* helper to update the 'address of tree root -> reloc tree'
* mapping
*/
-static int __update_reloc_root(struct btrfs_root *root, u64 new_bytenr)
+static int __update_reloc_root(struct btrfs_root *root)
{
struct btrfs_fs_info *fs_info = root->fs_info;
struct rb_node *rb_node;
@@ -1367,7 +1368,7 @@ static int __update_reloc_root(struct btrfs_root *root, u64 new_bytenr)
spin_lock(&rc->reloc_root_tree.lock);
rb_node = tree_search(&rc->reloc_root_tree.rb_root,
- root->node->start);
+ root->commit_root->start);
if (rb_node) {
node = rb_entry(rb_node, struct mapping_node, rb_node);
rb_erase(&node->rb_node, &rc->reloc_root_tree.rb_root);
@@ -1379,7 +1380,7 @@ static int __update_reloc_root(struct btrfs_root *root, u64 new_bytenr)
BUG_ON((struct btrfs_root *)node->data != root);
spin_lock(&rc->reloc_root_tree.lock);
- node->bytenr = new_bytenr;
+ node->bytenr = root->node->start;
rb_node = tree_insert(&rc->reloc_root_tree.rb_root,
node->bytenr, &node->rb_node);
spin_unlock(&rc->reloc_root_tree.lock);
@@ -1524,6 +1525,7 @@ int btrfs_update_reloc_root(struct btrfs_trans_handle *trans,
}
if (reloc_root->commit_root != reloc_root->node) {
+ __update_reloc_root(reloc_root);
btrfs_set_root_node(root_item, reloc_root->node);
free_extent_buffer(reloc_root->commit_root);
reloc_root->commit_root = btrfs_root_node(reloc_root);
@@ -4712,11 +4714,6 @@ int btrfs_reloc_cow_block(struct btrfs_trans_handle *trans,
BUG_ON(rc->stage == UPDATE_DATA_PTRS &&
root->root_key.objectid == BTRFS_DATA_RELOC_TREE_OBJECTID);
- if (root->root_key.objectid == BTRFS_TREE_RELOC_OBJECTID) {
- if (buf == root->node)
- __update_reloc_root(root, cow->start);
- }
-
level = btrfs_header_level(buf);
if (btrfs_header_generation(buf) <=
btrfs_root_last_snapshot(&root->root_item))
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 029/199] uapi: rename ext2_swab() to swab() and share globally in swab.h
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (27 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 028/199] btrfs: track reloc roots based on their commit root bytenr Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 030/199] misc: rtsx: set correct pcr_ops for rts522A Greg Kroah-Hartman
` (101 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yury Norov, Allison Randal,
Joe Perches, Thomas Gleixner, William Breathitt Gray,
Andrew Morton, Linus Torvalds, Sasha Levin
From: Yury Norov <yury.norov@gmail.com>
[ Upstream commit d5767057c9a76a29f073dad66b7fa12a90e8c748 ]
ext2_swab() is defined locally in lib/find_bit.c However it is not
specific to ext2, neither to bitmaps.
There are many potential users of it, so rename it to just swab() and
move to include/uapi/linux/swab.h
ABI guarantees that size of unsigned long corresponds to BITS_PER_LONG,
therefore drop unneeded cast.
Link: http://lkml.kernel.org/r/20200103202846.21616-1-yury.norov@gmail.com
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Cc: Allison Randal <allison@lohutok.net>
Cc: Joe Perches <joe@perches.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/swab.h | 1 +
include/uapi/linux/swab.h | 10 ++++++++++
lib/find_bit.c | 16 ++--------------
3 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/include/linux/swab.h b/include/linux/swab.h
index e466fd159c857..bcff5149861a9 100644
--- a/include/linux/swab.h
+++ b/include/linux/swab.h
@@ -7,6 +7,7 @@
# define swab16 __swab16
# define swab32 __swab32
# define swab64 __swab64
+# define swab __swab
# define swahw32 __swahw32
# define swahb32 __swahb32
# define swab16p __swab16p
diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
index 23cd84868cc3b..fa7f97da5b768 100644
--- a/include/uapi/linux/swab.h
+++ b/include/uapi/linux/swab.h
@@ -4,6 +4,7 @@
#include <linux/types.h>
#include <linux/compiler.h>
+#include <asm/bitsperlong.h>
#include <asm/swab.h>
/*
@@ -132,6 +133,15 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
__fswab64(x))
#endif
+static __always_inline unsigned long __swab(const unsigned long y)
+{
+#if BITS_PER_LONG == 64
+ return __swab64(y);
+#else /* BITS_PER_LONG == 32 */
+ return __swab32(y);
+#endif
+}
+
/**
* __swahw32 - return a word-swapped 32-bit value
* @x: value to wordswap
diff --git a/lib/find_bit.c b/lib/find_bit.c
index 6ed74f78380ce..883ef3755a1cb 100644
--- a/lib/find_bit.c
+++ b/lib/find_bit.c
@@ -133,18 +133,6 @@ EXPORT_SYMBOL(find_last_bit);
#ifdef __BIG_ENDIAN
-/* include/linux/byteorder does not support "unsigned long" type */
-static inline unsigned long ext2_swab(const unsigned long y)
-{
-#if BITS_PER_LONG == 64
- return (unsigned long) __swab64((u64) y);
-#elif BITS_PER_LONG == 32
- return (unsigned long) __swab32((u32) y);
-#else
-#error BITS_PER_LONG not defined
-#endif
-}
-
#if !defined(find_next_bit_le) || !defined(find_next_zero_bit_le)
static unsigned long _find_next_bit_le(const unsigned long *addr,
unsigned long nbits, unsigned long start, unsigned long invert)
@@ -157,7 +145,7 @@ static unsigned long _find_next_bit_le(const unsigned long *addr,
tmp = addr[start / BITS_PER_LONG] ^ invert;
/* Handle 1st word. */
- tmp &= ext2_swab(BITMAP_FIRST_WORD_MASK(start));
+ tmp &= swab(BITMAP_FIRST_WORD_MASK(start));
start = round_down(start, BITS_PER_LONG);
while (!tmp) {
@@ -168,7 +156,7 @@ static unsigned long _find_next_bit_le(const unsigned long *addr,
tmp = addr[start / BITS_PER_LONG] ^ invert;
}
- return min(start + __ffs(ext2_swab(tmp)), nbits);
+ return min(start + __ffs(swab(tmp)), nbits);
}
#endif
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 030/199] misc: rtsx: set correct pcr_ops for rts522A
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (28 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 029/199] uapi: rename ext2_swab() to swab() and share globally in swab.h Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 031/199] slub: improve bit diffusion for freelist ptr obfuscation Greg Kroah-Hartman
` (100 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, YueHaibing, Sasha Levin
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit 10cea23b6aae15e8324f4101d785687f2c514fe5 ]
rts522a should use rts522a_pcr_ops, which is
diffrent with rts5227 in phy/hw init setting.
Fixes: ce6a5acc9387 ("mfd: rtsx: Add support for rts522A")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200326032618.20472-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/mfd/rts5227.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index ff296a4bf3d23..dc6a9432a4b65 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -369,6 +369,7 @@ static const struct pcr_ops rts522a_pcr_ops = {
void rts522a_init_params(struct rtsx_pcr *pcr)
{
rts5227_init_params(pcr);
+ pcr->ops = &rts522a_pcr_ops;
pcr->reg_pm_ctrl3 = RTS522A_PM_CTRL3;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 031/199] slub: improve bit diffusion for freelist ptr obfuscation
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (29 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 030/199] misc: rtsx: set correct pcr_ops for rts522A Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 032/199] ASoC: fix regwmask Greg Kroah-Hartman
` (99 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Silvio Cesare, Kees Cook,
Andrew Morton, Christoph Lameter, Pekka Enberg, David Rientjes,
Joonsoo Kim, Linus Torvalds
From: Kees Cook <keescook@chromium.org>
commit 1ad53d9fa3f6168ebcf48a50e08b170432da2257 upstream.
Under CONFIG_SLAB_FREELIST_HARDENED=y, the obfuscation was relatively weak
in that the ptr and ptr address were usually so close that the first XOR
would result in an almost entirely 0-byte value[1], leaving most of the
"secret" number ultimately being stored after the third XOR. A single
blind memory content exposure of the freelist was generally sufficient to
learn the secret.
Add a swab() call to mix bits a little more. This is a cheap way (1
cycle) to make attacks need more than a single exposure to learn the
secret (or to know _where_ the exposure is in memory).
kmalloc-32 freelist walk, before:
ptr ptr_addr stored value secret
ffff90c22e019020@ffff90c22e019000 is 86528eb656b3b5bd (86528eb656b3b59d)
ffff90c22e019040@ffff90c22e019020 is 86528eb656b3b5fd (86528eb656b3b59d)
ffff90c22e019060@ffff90c22e019040 is 86528eb656b3b5bd (86528eb656b3b59d)
ffff90c22e019080@ffff90c22e019060 is 86528eb656b3b57d (86528eb656b3b59d)
ffff90c22e0190a0@ffff90c22e019080 is 86528eb656b3b5bd (86528eb656b3b59d)
...
after:
ptr ptr_addr stored value secret
ffff9eed6e019020@ffff9eed6e019000 is 793d1135d52cda42 (86528eb656b3b59d)
ffff9eed6e019040@ffff9eed6e019020 is 593d1135d52cda22 (86528eb656b3b59d)
ffff9eed6e019060@ffff9eed6e019040 is 393d1135d52cda02 (86528eb656b3b59d)
ffff9eed6e019080@ffff9eed6e019060 is 193d1135d52cdae2 (86528eb656b3b59d)
ffff9eed6e0190a0@ffff9eed6e019080 is f93d1135d52cdac2 (86528eb656b3b59d)
[1] https://blog.infosectcbr.com.au/2020/03/weaknesses-in-linux-kernel-heap.html
Fixes: 2482ddec670f ("mm: add SLUB free list pointer obfuscation")
Reported-by: Silvio Cesare <silvio.cesare@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/202003051623.AF4F8CB@keescook
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[kees: Backport to v4.19 which doesn't call kasan_reset_untag()]
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/slub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -248,7 +248,7 @@ static inline void *freelist_ptr(const s
unsigned long ptr_addr)
{
#ifdef CONFIG_SLAB_FREELIST_HARDENED
- return (void *)((unsigned long)ptr ^ s->random ^ ptr_addr);
+ return (void *)((unsigned long)ptr ^ s->random ^ swab(ptr_addr));
#else
return ptr;
#endif
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 032/199] ASoC: fix regwmask
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (30 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 031/199] slub: improve bit diffusion for freelist ptr obfuscation Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:55 ` [PATCH 4.14 033/199] ASoC: dapm: connect virtual mux with default value Greg Kroah-Hartman
` (98 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Gyeongtaek Lee, Mark Brown
From: 이경택 <gt82.lee@samsung.com>
commit 0ab070917afdc93670c2d0ea02ab6defb6246a7c upstream.
If regwshift is 32 and the selected architecture compiles '<<' operator
for signed int literal into rotating shift, '1<<regwshift' became 1 and
it makes regwmask to 0x0.
The literal is set to unsigned long to get intended regwmask.
Signed-off-by: Gyeongtaek Lee <gt82.lee@samsung.com>
Link: https://lore.kernel.org/r/001001d60665$db7af3e0$9270dba0$@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/soc-ops.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/soc/soc-ops.c
+++ b/sound/soc/soc-ops.c
@@ -837,7 +837,7 @@ int snd_soc_get_xr_sx(struct snd_kcontro
unsigned int regbase = mc->regbase;
unsigned int regcount = mc->regcount;
unsigned int regwshift = component->val_bytes * BITS_PER_BYTE;
- unsigned int regwmask = (1<<regwshift)-1;
+ unsigned int regwmask = (1UL<<regwshift)-1;
unsigned int invert = mc->invert;
unsigned long mask = (1UL<<mc->nbits)-1;
long min = mc->min;
@@ -886,7 +886,7 @@ int snd_soc_put_xr_sx(struct snd_kcontro
unsigned int regbase = mc->regbase;
unsigned int regcount = mc->regcount;
unsigned int regwshift = component->val_bytes * BITS_PER_BYTE;
- unsigned int regwmask = (1<<regwshift)-1;
+ unsigned int regwmask = (1UL<<regwshift)-1;
unsigned int invert = mc->invert;
unsigned long mask = (1UL<<mc->nbits)-1;
long max = mc->max;
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 033/199] ASoC: dapm: connect virtual mux with default value
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (31 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 032/199] ASoC: fix regwmask Greg Kroah-Hartman
@ 2020-04-22 9:55 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 034/199] ASoC: dpcm: allow start or stop during pause for backend Greg Kroah-Hartman
` (97 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:55 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Gyeongtaek Lee, Mark Brown
From: 이경택 <gt82.lee@samsung.com>
commit 3bbbb7728fc853d71dbce4073fef9f281fbfb4dd upstream.
Since a virtual mixer has no backing registers
to decide which path to connect,
it will try to match with initial state.
This is to ensure that the default mixer choice will be
correctly powered up during initialization.
Invert flag is used to select initial state of the virtual switch.
Since actual hardware can't be disconnected by virtual switch,
connected is better choice as initial state in many cases.
Signed-off-by: Gyeongtaek Lee <gt82.lee@samsung.com>
Link: https://lore.kernel.org/r/01a301d60731$b724ea10$256ebe30$@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/soc-dapm.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -799,7 +799,13 @@ static void dapm_set_mixer_path_status(s
val = max - val;
p->connect = !!val;
} else {
- p->connect = 0;
+ /* since a virtual mixer has no backing registers to
+ * decide which path to connect, it will try to match
+ * with initial state. This is to ensure
+ * that the default mixer choice will be
+ * correctly powered up during initialization.
+ */
+ p->connect = invert;
}
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 034/199] ASoC: dpcm: allow start or stop during pause for backend
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (32 preceding siblings ...)
2020-04-22 9:55 ` [PATCH 4.14 033/199] ASoC: dapm: connect virtual mux with default value Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 035/199] ASoC: topology: use name_prefix for new kcontrol Greg Kroah-Hartman
` (96 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Gyeongtaek Lee, Vinod Koul, Mark Brown
From: 이경택 <gt82.lee@samsung.com>
commit 21fca8bdbb64df1297e8c65a746c4c9f4a689751 upstream.
soc_compr_trigger_fe() allows start or stop after pause_push.
In dpcm_be_dai_trigger(), however, only pause_release is allowed
command after pause_push.
So, start or stop after pause in compress offload is always
returned as error if the compress offload is used with dpcm.
To fix the problem, SND_SOC_DPCM_STATE_PAUSED should be allowed
for start or stop command.
Signed-off-by: Gyeongtaek Lee <gt82.lee@samsung.com>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/004d01d607c1$7a3d5250$6eb7f6f0$@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/soc-pcm.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -2048,7 +2048,8 @@ int dpcm_be_dai_trigger(struct snd_soc_p
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_PREPARE) &&
- (be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP))
+ (be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP) &&
+ (be->dpcm[stream].state != SND_SOC_DPCM_STATE_PAUSED))
continue;
ret = dpcm_do_trigger(dpcm, be_substream, cmd);
@@ -2078,7 +2079,8 @@ int dpcm_be_dai_trigger(struct snd_soc_p
be->dpcm[stream].state = SND_SOC_DPCM_STATE_START;
break;
case SNDRV_PCM_TRIGGER_STOP:
- if (be->dpcm[stream].state != SND_SOC_DPCM_STATE_START)
+ if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_START) &&
+ (be->dpcm[stream].state != SND_SOC_DPCM_STATE_PAUSED))
continue;
if (!snd_soc_dpcm_can_be_free_stop(fe, be, stream))
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 035/199] ASoC: topology: use name_prefix for new kcontrol
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (33 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 034/199] ASoC: dpcm: allow start or stop during pause for backend Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 036/199] usb: gadget: f_fs: Fix use after free issue as part of queue failure Greg Kroah-Hartman
` (95 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Gyeongtaek Lee, Mark Brown
From: 이경택 <gt82.lee@samsung.com>
commit abca9e4a04fbe9c6df4d48ca7517e1611812af25 upstream.
Current topology doesn't add prefix of component to new kcontrol.
Signed-off-by: Gyeongtaek Lee <gt82.lee@samsung.com>
Link: https://lore.kernel.org/r/009b01d60804$ae25c2d0$0a714870$@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/soc-topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/soc/soc-topology.c
+++ b/sound/soc/soc-topology.c
@@ -421,7 +421,7 @@ static int soc_tplg_add_kcontrol(struct
struct snd_soc_component *comp = tplg->comp;
return soc_tplg_add_dcontrol(comp->card->snd_card,
- comp->dev, k, NULL, comp, kcontrol);
+ comp->dev, k, comp->name_prefix, comp, kcontrol);
}
/* remove a mixer kcontrol */
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 036/199] usb: gadget: f_fs: Fix use after free issue as part of queue failure
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (34 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 035/199] ASoC: topology: use name_prefix for new kcontrol Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 037/199] usb: gadget: composite: Inform controller driver of self-powered Greg Kroah-Hartman
` (94 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Sriharsha Allenki, Peter Chen
From: Sriharsha Allenki <sallenki@codeaurora.org>
commit f63ec55ff904b2f2e126884fcad93175f16ab4bb upstream.
In AIO case, the request is freed up if ep_queue fails.
However, io_data->req still has the reference to this freed
request. In the case of this failure if there is aio_cancel
call on this io_data it will lead to an invalid dequeue
operation and a potential use after free issue.
Fix this by setting the io_data->req to NULL when the request
is freed as part of queue failure.
Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support")
Signed-off-by: Sriharsha Allenki <sallenki@codeaurora.org>
CC: stable <stable@vger.kernel.org>
Reviewed-by: Peter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20200326115620.12571-1-sallenki@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1037,6 +1037,7 @@ static ssize_t ffs_epfile_io(struct file
ret = usb_ep_queue(ep->ep, req, GFP_ATOMIC);
if (unlikely(ret)) {
+ io_data->req = NULL;
usb_ep_free_request(ep->ep, req);
goto error_lock;
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 037/199] usb: gadget: composite: Inform controller driver of self-powered
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (35 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 036/199] usb: gadget: f_fs: Fix use after free issue as part of queue failure Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 038/199] ALSA: usb-audio: Add mixer workaround for TRX40 and co Greg Kroah-Hartman
` (93 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Thinh Nguyen, Felipe Balbi
From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
commit 5e5caf4fa8d3039140b4548b6ab23dd17fce9b2c upstream.
Different configuration/condition may draw different power. Inform the
controller driver of the change so it can respond properly (e.g.
GET_STATUS request). This fixes an issue with setting MaxPower from
configfs. The composite driver doesn't check this value when setting
self-powered.
Cc: stable@vger.kernel.org
Fixes: 88af8bbe4ef7 ("usb: gadget: the start of the configfs interface")
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/gadget/composite.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -850,6 +850,11 @@ static int set_config(struct usb_composi
else
power = min(power, 900U);
done:
+ if (power <= USB_SELF_POWER_VBUS_MAX_DRAW)
+ usb_gadget_set_selfpowered(gadget);
+ else
+ usb_gadget_clear_selfpowered(gadget);
+
usb_gadget_vbus_draw(gadget, power);
if (result >= 0 && cdev->delayed_status)
result = USB_GADGET_DELAYED_STATUS;
@@ -2281,6 +2286,7 @@ void composite_suspend(struct usb_gadget
cdev->suspended = 1;
+ usb_gadget_set_selfpowered(gadget);
usb_gadget_vbus_draw(gadget, 2);
}
@@ -2309,6 +2315,9 @@ void composite_resume(struct usb_gadget
else
maxpower = min(maxpower, 900U);
+ if (maxpower > USB_SELF_POWER_VBUS_MAX_DRAW)
+ usb_gadget_clear_selfpowered(gadget);
+
usb_gadget_vbus_draw(gadget, maxpower);
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 038/199] ALSA: usb-audio: Add mixer workaround for TRX40 and co
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (36 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 037/199] usb: gadget: composite: Inform controller driver of self-powered Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 039/199] ALSA: hda: Add driver blacklist Greg Kroah-Hartman
` (92 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 2a48218f8e23d47bd3e23cfdfb8aa9066f7dc3e6 upstream.
Some recent boards (supposedly with a new AMD platform) contain the
USB audio class 2 device that is often tied with HD-audio. The device
exposes an Input Gain Pad control (id=19, control=12) but this node
doesn't behave correctly, returning an error for each inquiry of
GET_MIN and GET_MAX that should have been mandatory.
As a workaround, simply ignore this node by adding a usbmix_name_map
table entry. The currently known devices are:
* 0414:a002 - Gigabyte TRX40 Aorus Pro WiFi
* 0b05:1916 - ASUS ROG Zenith II
* 0b05:1917 - ASUS ROG Strix
* 0db0:0d64 - MSI TRX40 Creator
* 0db0:543d - MSI TRX40
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206543
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200408140449.22319-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/usb/mixer_maps.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
--- a/sound/usb/mixer_maps.c
+++ b/sound/usb/mixer_maps.c
@@ -363,6 +363,14 @@ static const struct usbmix_name_map dell
{ 0 }
};
+/* Some mobos shipped with a dummy HD-audio show the invalid GET_MIN/GET_MAX
+ * response for Input Gain Pad (id=19, control=12). Skip it.
+ */
+static const struct usbmix_name_map asus_rog_map[] = {
+ { 19, NULL, 12 }, /* FU, Input Gain Pad */
+ {}
+};
+
/*
* Control map entries
*/
@@ -482,6 +490,26 @@ static struct usbmix_ctl_map usbmix_ctl_
.id = USB_ID(0x05a7, 0x1020),
.map = bose_companion5_map,
},
+ { /* Gigabyte TRX40 Aorus Pro WiFi */
+ .id = USB_ID(0x0414, 0xa002),
+ .map = asus_rog_map,
+ },
+ { /* ASUS ROG Zenith II */
+ .id = USB_ID(0x0b05, 0x1916),
+ .map = asus_rog_map,
+ },
+ { /* ASUS ROG Strix */
+ .id = USB_ID(0x0b05, 0x1917),
+ .map = asus_rog_map,
+ },
+ { /* MSI TRX40 Creator */
+ .id = USB_ID(0x0db0, 0x0d64),
+ .map = asus_rog_map,
+ },
+ { /* MSI TRX40 */
+ .id = USB_ID(0x0db0, 0x543d),
+ .map = asus_rog_map,
+ },
{ 0 } /* terminator */
};
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 039/199] ALSA: hda: Add driver blacklist
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (37 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 038/199] ALSA: usb-audio: Add mixer workaround for TRX40 and co Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 040/199] ALSA: hda: Fix potential access overflow in beep helper Greg Kroah-Hartman
` (91 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 3c6fd1f07ed03a04debbb9a9d782205f1ef5e2ab upstream.
The recent AMD platform exposes an HD-audio bus but without any actual
codecs, which is internally tied with a USB-audio device, supposedly.
It results in "no codecs" error of HD-audio bus driver, and it's
nothing but a waste of resources.
This patch introduces a static blacklist table for skipping such a
known bogus PCI SSID entry. As of writing this patch, the known SSIDs
are:
* 1043:874f - ASUS ROG Zenith II / Strix
* 1462:cb59 - MSI TRX40 Creator
* 1462:cb60 - MSI TRX40
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206543
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200408140449.22319-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/hda_intel.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2177,6 +2177,17 @@ static const struct hdac_io_ops pci_hda_
.dma_free_pages = dma_free_pages,
};
+/* Blacklist for skipping the whole probe:
+ * some HD-audio PCI entries are exposed without any codecs, and such devices
+ * should be ignored from the beginning.
+ */
+static const struct snd_pci_quirk driver_blacklist[] = {
+ SND_PCI_QUIRK(0x1043, 0x874f, "ASUS ROG Zenith II / Strix", 0),
+ SND_PCI_QUIRK(0x1462, 0xcb59, "MSI TRX40 Creator", 0),
+ SND_PCI_QUIRK(0x1462, 0xcb60, "MSI TRX40", 0),
+ {}
+};
+
static const struct hda_controller_ops pci_hda_ops = {
.disable_msi_reset_irq = disable_msi_reset_irq,
.substream_alloc_pages = substream_alloc_pages,
@@ -2196,6 +2207,11 @@ static int azx_probe(struct pci_dev *pci
bool schedule_probe;
int err;
+ if (snd_pci_quirk_lookup(pci, driver_blacklist)) {
+ dev_info(&pci->dev, "Skipping the blacklisted device\n");
+ return -ENODEV;
+ }
+
if (dev >= SNDRV_CARDS)
return -ENODEV;
if (!enable[dev]) {
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 040/199] ALSA: hda: Fix potential access overflow in beep helper
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (38 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 039/199] ALSA: hda: Add driver blacklist Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 041/199] ALSA: ice1724: Fix invalid access for enumerated ctl items Greg Kroah-Hartman
` (90 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jaroslav Kysela, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 0ad3f0b384d58f3bd1f4fb87d0af5b8f6866f41a upstream.
The beep control helper function blindly stores the values in two
stereo channels no matter whether the actual control is mono or
stereo. This is practically harmless, but it annoys the recently
introduced sanity check, resulting in an error when the checker is
enabled.
This patch corrects the behavior to store only on the defined array
member.
Fixes: 0401e8548eac ("ALSA: hda - Move beep helper functions to hda_beep.c")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207139
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200407084402.25589-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/hda_beep.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/sound/pci/hda/hda_beep.c
+++ b/sound/pci/hda/hda_beep.c
@@ -310,8 +310,12 @@ int snd_hda_mixer_amp_switch_get_beep(st
{
struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
struct hda_beep *beep = codec->beep;
+ int chs = get_amp_channels(kcontrol);
+
if (beep && (!beep->enabled || !ctl_has_mute(kcontrol))) {
- ucontrol->value.integer.value[0] =
+ if (chs & 1)
+ ucontrol->value.integer.value[0] = beep->enabled;
+ if (chs & 2)
ucontrol->value.integer.value[1] = beep->enabled;
return 0;
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 041/199] ALSA: ice1724: Fix invalid access for enumerated ctl items
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (39 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 040/199] ALSA: hda: Fix potential access overflow in beep helper Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 042/199] ALSA: pcm: oss: Fix regression by buffer overflow fix Greg Kroah-Hartman
` (89 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jaroslav Kysela, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit c47914c00be346bc5b48c48de7b0da5c2d1a296c upstream.
The access to Analog Capture Source control value implemented in
prodigy_hifi.c is wrong, as caught by the recently introduced sanity
check; it should be accessing value.enumerated.item[] instead of
value.integer.value[]. This patch corrects the wrong access pattern.
Fixes: 6b8d6e5518e2 ("[ALSA] ICE1724: Added support for Audiotrak Prodigy 7.1 HiFi & HD2, Hercules Fortissimo IV")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207139
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200407084402.25589-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/ice1712/prodigy_hifi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/pci/ice1712/prodigy_hifi.c
+++ b/sound/pci/ice1712/prodigy_hifi.c
@@ -569,7 +569,7 @@ static int wm_adc_mux_enum_get(struct sn
struct snd_ice1712 *ice = snd_kcontrol_chip(kcontrol);
mutex_lock(&ice->gpio_mutex);
- ucontrol->value.integer.value[0] = wm_get(ice, WM_ADC_MUX) & 0x1f;
+ ucontrol->value.enumerated.item[0] = wm_get(ice, WM_ADC_MUX) & 0x1f;
mutex_unlock(&ice->gpio_mutex);
return 0;
}
@@ -583,7 +583,7 @@ static int wm_adc_mux_enum_put(struct sn
mutex_lock(&ice->gpio_mutex);
oval = wm_get(ice, WM_ADC_MUX);
- nval = (oval & 0xe0) | ucontrol->value.integer.value[0];
+ nval = (oval & 0xe0) | ucontrol->value.enumerated.item[0];
if (nval != oval) {
wm_put(ice, WM_ADC_MUX, nval);
change = 1;
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 042/199] ALSA: pcm: oss: Fix regression by buffer overflow fix
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (40 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 041/199] ALSA: ice1724: Fix invalid access for enumerated ctl items Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 043/199] ALSA: doc: Document PC Beep Hidden Register on Realtek ALC256 Greg Kroah-Hartman
` (88 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai, Jari Ruusu
From: Takashi Iwai <tiwai@suse.de>
commit ae769d3556644888c964635179ef192995f40793 upstream.
The recent fix for the OOB access in PCM OSS plugins (commit
f2ecf903ef06: "ALSA: pcm: oss: Avoid plugin buffer overflow") caused a
regression on OSS applications. The patch introduced the size check
in client and slave size calculations to limit to each plugin's buffer
size, but I overlooked that some code paths call those without
allocating the buffer but just for estimation.
This patch fixes the bug by skipping the size check for those code
paths while keeping checking in the actual transfer calls.
Fixes: f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
Tested-and-reported-by: Jari Ruusu <jari.ruusu@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200403072515.25539-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/oss/pcm_plugin.c | 32 ++++++++++++++++++++++++--------
1 file changed, 24 insertions(+), 8 deletions(-)
--- a/sound/core/oss/pcm_plugin.c
+++ b/sound/core/oss/pcm_plugin.c
@@ -196,7 +196,9 @@ int snd_pcm_plugin_free(struct snd_pcm_p
return 0;
}
-snd_pcm_sframes_t snd_pcm_plug_client_size(struct snd_pcm_substream *plug, snd_pcm_uframes_t drv_frames)
+static snd_pcm_sframes_t plug_client_size(struct snd_pcm_substream *plug,
+ snd_pcm_uframes_t drv_frames,
+ bool check_size)
{
struct snd_pcm_plugin *plugin, *plugin_prev, *plugin_next;
int stream;
@@ -209,7 +211,7 @@ snd_pcm_sframes_t snd_pcm_plug_client_si
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
plugin = snd_pcm_plug_last(plug);
while (plugin && drv_frames > 0) {
- if (drv_frames > plugin->buf_frames)
+ if (check_size && drv_frames > plugin->buf_frames)
drv_frames = plugin->buf_frames;
plugin_prev = plugin->prev;
if (plugin->src_frames)
@@ -222,7 +224,7 @@ snd_pcm_sframes_t snd_pcm_plug_client_si
plugin_next = plugin->next;
if (plugin->dst_frames)
drv_frames = plugin->dst_frames(plugin, drv_frames);
- if (drv_frames > plugin->buf_frames)
+ if (check_size && drv_frames > plugin->buf_frames)
drv_frames = plugin->buf_frames;
plugin = plugin_next;
}
@@ -231,7 +233,9 @@ snd_pcm_sframes_t snd_pcm_plug_client_si
return drv_frames;
}
-snd_pcm_sframes_t snd_pcm_plug_slave_size(struct snd_pcm_substream *plug, snd_pcm_uframes_t clt_frames)
+static snd_pcm_sframes_t plug_slave_size(struct snd_pcm_substream *plug,
+ snd_pcm_uframes_t clt_frames,
+ bool check_size)
{
struct snd_pcm_plugin *plugin, *plugin_prev, *plugin_next;
snd_pcm_sframes_t frames;
@@ -252,14 +256,14 @@ snd_pcm_sframes_t snd_pcm_plug_slave_siz
if (frames < 0)
return frames;
}
- if (frames > plugin->buf_frames)
+ if (check_size && frames > plugin->buf_frames)
frames = plugin->buf_frames;
plugin = plugin_next;
}
} else if (stream == SNDRV_PCM_STREAM_CAPTURE) {
plugin = snd_pcm_plug_last(plug);
while (plugin) {
- if (frames > plugin->buf_frames)
+ if (check_size && frames > plugin->buf_frames)
frames = plugin->buf_frames;
plugin_prev = plugin->prev;
if (plugin->src_frames) {
@@ -274,6 +278,18 @@ snd_pcm_sframes_t snd_pcm_plug_slave_siz
return frames;
}
+snd_pcm_sframes_t snd_pcm_plug_client_size(struct snd_pcm_substream *plug,
+ snd_pcm_uframes_t drv_frames)
+{
+ return plug_client_size(plug, drv_frames, false);
+}
+
+snd_pcm_sframes_t snd_pcm_plug_slave_size(struct snd_pcm_substream *plug,
+ snd_pcm_uframes_t clt_frames)
+{
+ return plug_slave_size(plug, clt_frames, false);
+}
+
static int snd_pcm_plug_formats(const struct snd_mask *mask,
snd_pcm_format_t format)
{
@@ -629,7 +645,7 @@ snd_pcm_sframes_t snd_pcm_plug_write_tra
src_channels = dst_channels;
plugin = next;
}
- return snd_pcm_plug_client_size(plug, frames);
+ return plug_client_size(plug, frames, true);
}
snd_pcm_sframes_t snd_pcm_plug_read_transfer(struct snd_pcm_substream *plug, struct snd_pcm_plugin_channel *dst_channels_final, snd_pcm_uframes_t size)
@@ -639,7 +655,7 @@ snd_pcm_sframes_t snd_pcm_plug_read_tran
snd_pcm_sframes_t frames = size;
int err;
- frames = snd_pcm_plug_slave_size(plug, frames);
+ frames = plug_slave_size(plug, frames, true);
if (frames < 0)
return frames;
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 043/199] ALSA: doc: Document PC Beep Hidden Register on Realtek ALC256
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (41 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 042/199] ALSA: pcm: oss: Fix regression by buffer overflow fix Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 044/199] ALSA: hda/realtek - Set principled PC Beep configuration for ALC256 Greg Kroah-Hartman
` (87 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Thomas Hebb, Takashi Iwai
From: Thomas Hebb <tommyhebb@gmail.com>
commit f128090491c3f5aacef91a863f8c52abf869c436 upstream.
This codec (among others) has a hidden set of audio routes, apparently
designed to allow PC Beep output without a mixer widget on the output
path, which are controlled by an undocumented Realtek vendor register.
The default configuration of these routes means that certain inputs
aren't accessible, necessitating driver control of the register.
However, Realtek has provided no documentation of the register, instead
opting to fix issues by providing magic numbers, most of which have been
at least somewhat erroneous. These magic numbers then get copied by
others into model-specific fixups, leading to a fragmented and buggy set
of configurations.
To get out of this situation, I've reverse engineered the register by
flipping bits and observing how the codec's behavior changes. This
commit documents my findings. It does not change any code.
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Link: https://lore.kernel.org/r/bd69dfdeaf40ff31c4b7b797c829bb320031739c.1585584498.git.tommyhebb@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/sound/hd-audio/index.rst | 1
Documentation/sound/hd-audio/realtek-pc-beep.rst | 129 +++++++++++++++++++++++
2 files changed, 130 insertions(+)
--- a/Documentation/sound/hd-audio/index.rst
+++ b/Documentation/sound/hd-audio/index.rst
@@ -8,3 +8,4 @@ HD-Audio
models
controls
dp-mst
+ realtek-pc-beep
--- /dev/null
+++ b/Documentation/sound/hd-audio/realtek-pc-beep.rst
@@ -0,0 +1,129 @@
+===============================
+Realtek PC Beep Hidden Register
+===============================
+
+This file documents the "PC Beep Hidden Register", which is present in certain
+Realtek HDA codecs and controls a muxer and pair of passthrough mixers that can
+route audio between pins but aren't themselves exposed as HDA widgets. As far
+as I can tell, these hidden routes are designed to allow flexible PC Beep output
+for codecs that don't have mixer widgets in their output paths. Why it's easier
+to hide a mixer behind an undocumented vendor register than to just expose it
+as a widget, I have no idea.
+
+Register Description
+====================
+
+The register is accessed via processing coefficient 0x36 on NID 20h. Bits not
+identified below have no discernible effect on my machine, a Dell XPS 13 9350::
+
+ MSB LSB
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |h|S|L| | B |R| | Known bits
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ |0|0|1|1| 0x7 |0|0x0|1| 0x7 | Reset value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+1Ah input select (B): 2 bits
+ When zero, expose the PC Beep line (from the internal beep generator, when
+ enabled with the Set Beep Generation verb on NID 01h, or else from the
+ external PCBEEP pin) on the 1Ah pin node. When nonzero, expose the headphone
+ jack (or possibly Line In on some machines) input instead. If PC Beep is
+ selected, the 1Ah boost control has no effect.
+
+Amplify 1Ah loopback, left (L): 1 bit
+ Amplify the left channel of 1Ah before mixing it into outputs as specified
+ by h and S bits. Does not affect the level of 1Ah exposed to other widgets.
+
+Amplify 1Ah loopback, right (R): 1 bit
+ Amplify the right channel of 1Ah before mixing it into outputs as specified
+ by h and S bits. Does not affect the level of 1Ah exposed to other widgets.
+
+Loopback 1Ah to 21h [active low] (h): 1 bit
+ When zero, mix 1Ah (possibly with amplification, depending on L and R bits)
+ into 21h (headphone jack on my machine). Mixed signal respects the mute
+ setting on 21h.
+
+Loopback 1Ah to 14h (S): 1 bit
+ When one, mix 1Ah (possibly with amplification, depending on L and R bits)
+ into 14h (internal speaker on my machine). Mixed signal **ignores** the mute
+ setting on 14h and is present whenever 14h is configured as an output.
+
+Path diagrams
+=============
+
+1Ah input selection (DIV is the PC Beep divider set on NID 01h)::
+
+ <Beep generator> <PCBEEP pin> <Headphone jack>
+ | | |
+ +--DIV--+--!DIV--+ {1Ah boost control}
+ | |
+ +--(b == 0)--+--(b != 0)--+
+ |
+ >1Ah (Beep/Headphone Mic/Line In)<
+
+Loopback of 1Ah to 21h/14h::
+
+ <1Ah (Beep/Headphone Mic/Line In)>
+ |
+ {amplify if L/R}
+ |
+ +-----!h-----+-----S-----+
+ | |
+ {21h mute control} |
+ | |
+ >21h (Headphone)< >14h (Internal Speaker)<
+
+Background
+==========
+
+All Realtek HDA codecs have a vendor-defined widget with node ID 20h which
+provides access to a bank of registers that control various codec functions.
+Registers are read and written via the standard HDA processing coefficient
+verbs (Set/Get Coefficient Index, Set/Get Processing Coefficient). The node is
+named "Realtek Vendor Registers" in public datasheets' verb listings and,
+apart from that, is entirely undocumented.
+
+This particular register, exposed at coefficient 0x36 and named in commits from
+Realtek, is of note: unlike most registers, which seem to control detailed
+amplifier parameters not in scope of the HDA specification, it controls audio
+routing which could just as easily have been defined using standard HDA mixer
+and selector widgets.
+
+Specifically, it selects between two sources for the input pin widget with Node
+ID (NID) 1Ah: the widget's signal can come either from an audio jack (on my
+laptop, a Dell XPS 13 9350, it's the headphone jack, but comments in Realtek
+commits indicate that it might be a Line In on some machines) or from the PC
+Beep line (which is itself multiplexed between the codec's internal beep
+generator and external PCBEEP pin, depending on if the beep generator is
+enabled via verbs on NID 01h). Additionally, it can mix (with optional
+amplification) that signal onto the 21h and/or 14h output pins.
+
+The register's reset value is 0x3717, corresponding to PC Beep on 1Ah that is
+then amplified and mixed into both the headphones and the speakers. Not only
+does this violate the HDA specification, which says that "[a vendor defined
+beep input pin] connection may be maintained *only* while the Link reset
+(**RST#**) is asserted", it means that we cannot ignore the register if we care
+about the input that 1Ah would otherwise expose or if the PCBEEP trace is
+poorly shielded and picks up chassis noise (both of which are the case on my
+machine).
+
+Unfortunately, there are lots of ways to get this register configuration wrong.
+Linux, it seems, has gone through most of them. For one, the register resets
+after S3 suspend: judging by existing code, this isn't the case for all vendor
+registers, and it's led to some fixes that improve behavior on cold boot but
+don't last after suspend. Other fixes have successfully switched the 1Ah input
+away from PC Beep but have failed to disable both loopback paths. On my
+machine, this means that the headphone input is amplified and looped back to
+the headphone output, which uses the exact same pins! As you might expect, this
+causes terrible headphone noise, the character of which is controlled by the
+1Ah boost control. (If you've seen instructions online to fix XPS 13 headphone
+noise by changing "Headphone Mic Boost" in ALSA, now you know why.)
+
+The information here has been obtained through black-box reverse engineering of
+the ALC256 codec's behavior and is not guaranteed to be correct. It likely
+also applies for the ALC255, ALC257, ALC235, and ALC236, since those codecs
+seem to be close relatives of the ALC256. (They all share one initialization
+function.) Additionally, other codecs like the ALC225 and ALC285 also have this
+register, judging by existing fixups in ``patch_realtek.c``, but specific
+data (e.g. node IDs, bit positions, pin mappings) for those codecs may differ
+from what I've described here.
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 044/199] ALSA: hda/realtek - Set principled PC Beep configuration for ALC256
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (42 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 043/199] ALSA: doc: Document PC Beep Hidden Register on Realtek ALC256 Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 045/199] media: ti-vpe: cal: fix disable_irqs to only the intended target Greg Kroah-Hartman
` (86 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Thomas Hebb, Takashi Iwai
From: Thomas Hebb <tommyhebb@gmail.com>
commit c44737449468a0bdc50e09ec75e530f208391561 upstream.
The Realtek PC Beep Hidden Register[1] is currently set by
patch_realtek.c in two different places:
In alc_fill_eapd_coef(), it's set to the value 0x5757, corresponding to
non-beep input on 1Ah and no 1Ah loopback to either headphones or
speakers. (Although, curiously, the loopback amp is still enabled.) This
write was added fairly recently by commit e3743f431143 ("ALSA:
hda/realtek - Dell headphone has noise on unmute for ALC236") and is a
safe default. However, it happens in the wrong place:
alc_fill_eapd_coef() runs on module load and cold boot but not on S3
resume, meaning the register loses its value after suspend.
Conversely, in alc256_init(), the register is updated to unset bit 13
(disable speaker loopback) and set bit 5 (set non-beep input on 1Ah).
Although this write does run on S3 resume, it's not quite enough to fix
up the register's default value of 0x3717. What's missing is a set of
bit 14 to disable headphone loopback. Without that, we end up with a
feedback loop where the headphone jack is being driven by amplified
samples of itself[2].
This change eliminates the update in alc256_init() and replaces it with
the 0x5757 write from alc_fill_eapd_coef(). Kailang says that 0x5757 is
supposed to be the codec's default value, so using it will make
debugging easier for Realtek.
Affects the ALC255, ALC256, ALC257, ALC235, and ALC236 codecs.
[1] Newly documented in Documentation/sound/hd-audio/realtek-pc-beep.rst
[2] Setting the "Headphone Mic Boost" control from userspace changes
this feedback loop and has been a widely-shared workaround for headphone
noise on laptops like the Dell XPS 13 9350. This commit eliminates the
feedback loop and makes the workaround unnecessary.
Fixes: e1e8c1fdce8b ("ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Link: https://lore.kernel.org/r/bf22b417d1f2474b12011c2a39ed6cf8b06d3bf5.1585584498.git.tommyhebb@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -333,7 +333,9 @@ static void alc_fill_eapd_coef(struct hd
case 0x10ec0215:
case 0x10ec0233:
case 0x10ec0235:
+ case 0x10ec0236:
case 0x10ec0255:
+ case 0x10ec0256:
case 0x10ec0257:
case 0x10ec0282:
case 0x10ec0283:
@@ -345,11 +347,6 @@ static void alc_fill_eapd_coef(struct hd
case 0x10ec0300:
alc_update_coef_idx(codec, 0x10, 1<<9, 0);
break;
- case 0x10ec0236:
- case 0x10ec0256:
- alc_write_coef_idx(codec, 0x36, 0x5757);
- alc_update_coef_idx(codec, 0x10, 1<<9, 0);
- break;
case 0x10ec0275:
alc_update_coef_idx(codec, 0xe, 0, 1<<0);
break;
@@ -3122,7 +3119,13 @@ static void alc256_init(struct hda_codec
alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight power */
alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 1 << 15); /* Clear bit */
alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 0 << 15);
- alc_update_coef_idx(codec, 0x36, 1 << 13, 1 << 5); /* Switch pcbeep path to Line in path*/
+ /*
+ * Expose headphone mic (or possibly Line In on some machines) instead
+ * of PC Beep on 1Ah, and disable 1Ah loopback for all outputs. See
+ * Documentation/sound/hd-audio/realtek-pc-beep.rst for details of
+ * this register.
+ */
+ alc_write_coef_idx(codec, 0x36, 0x5757);
}
static void alc256_shutup(struct hda_codec *codec)
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 045/199] media: ti-vpe: cal: fix disable_irqs to only the intended target
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (43 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 044/199] ALSA: hda/realtek - Set principled PC Beep configuration for ALC256 Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 046/199] acpi/x86: ignore unspecified bit positions in the ACPI global lock field Greg Kroah-Hartman
` (85 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Benoit Parrot, Hans Verkuil,
Mauro Carvalho Chehab
From: Benoit Parrot <bparrot@ti.com>
commit 1db56284b9da9056093681f28db48a09a243274b upstream.
disable_irqs() was mistakenly disabling all interrupts when called.
This cause all port stream to stop even if only stopping one of them.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/platform/ti-vpe/cal.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -544,16 +544,16 @@ static void enable_irqs(struct cal_ctx *
static void disable_irqs(struct cal_ctx *ctx)
{
+ u32 val;
+
/* Disable IRQ_WDMA_END 0/1 */
- reg_write_field(ctx->dev,
- CAL_HL_IRQENABLE_CLR(2),
- CAL_HL_IRQ_CLEAR,
- CAL_HL_IRQ_MASK(ctx->csi2_port));
+ val = 0;
+ set_field(&val, CAL_HL_IRQ_CLEAR, CAL_HL_IRQ_MASK(ctx->csi2_port));
+ reg_write(ctx->dev, CAL_HL_IRQENABLE_CLR(2), val);
/* Disable IRQ_WDMA_START 0/1 */
- reg_write_field(ctx->dev,
- CAL_HL_IRQENABLE_CLR(3),
- CAL_HL_IRQ_CLEAR,
- CAL_HL_IRQ_MASK(ctx->csi2_port));
+ val = 0;
+ set_field(&val, CAL_HL_IRQ_CLEAR, CAL_HL_IRQ_MASK(ctx->csi2_port));
+ reg_write(ctx->dev, CAL_HL_IRQENABLE_CLR(3), val);
/* Todo: Add VC_IRQ and CSI2_COMPLEXIO_IRQ handling */
reg_write(ctx->dev, CAL_CSI2_VC_IRQENABLE(1), 0);
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 046/199] acpi/x86: ignore unspecified bit positions in the ACPI global lock field
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (44 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 045/199] media: ti-vpe: cal: fix disable_irqs to only the intended target Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 047/199] thermal: devfreq_cooling: inline all stubs for CONFIG_DEVFREQ_THERMAL=n Greg Kroah-Hartman
` (84 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jan Engelhardt, Rafael J. Wysocki
From: Jan Engelhardt <jengelh@inai.de>
commit ecb9c790999fd6c5af0f44783bd0217f0b89ec2b upstream.
The value in "new" is constructed from "old" such that all bits defined
as reserved by the ACPI spec[1] are left untouched. But if those bits
do not happen to be all zero, "new < 3" will not evaluate to true.
The firmware of the laptop(s) Medion MD63490 / Akoya P15648 comes with
garbage inside the "FACS" ACPI table. The starting value is
old=0x4944454d, therefore new=0x4944454e, which is >= 3. Mask off
the reserved bits.
[1] https://uefi.org/sites/default/files/resources/ACPI_6_2.pdf
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206553
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Jan Engelhardt <jengelh@inai.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/acpi/boot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1738,7 +1738,7 @@ int __acpi_acquire_global_lock(unsigned
new = (((old & ~0x3) + 2) + ((old >> 1) & 0x1));
val = cmpxchg(lock, old, new);
} while (unlikely (val != old));
- return (new < 3) ? -1 : 0;
+ return ((new & 0x3) < 3) ? -1 : 0;
}
int __acpi_release_global_lock(unsigned int *lock)
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 047/199] thermal: devfreq_cooling: inline all stubs for CONFIG_DEVFREQ_THERMAL=n
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (45 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 046/199] acpi/x86: ignore unspecified bit positions in the ACPI global lock field Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 048/199] nvme-fc: Revert "add module to ops template to allow module references" Greg Kroah-Hartman
` (83 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas Zimmermann,
Martin Blumenstingl, Daniel Lezcano
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
commit 3f5b9959041e0db6dacbea80bb833bff5900999f upstream.
When CONFIG_DEVFREQ_THERMAL is disabled all functions except
of_devfreq_cooling_register_power() were already inlined. Also inline
the last function to avoid compile errors when multiple drivers call
of_devfreq_cooling_register_power() when CONFIG_DEVFREQ_THERMAL is not
set. Compilation failed with the following message:
multiple definition of `of_devfreq_cooling_register_power'
(which then lists all usages of of_devfreq_cooling_register_power())
Thomas Zimmermann reported this problem [0] on a kernel config with
CONFIG_DRM_LIMA={m,y}, CONFIG_DRM_PANFROST={m,y} and
CONFIG_DEVFREQ_THERMAL=n after both, the lima and panfrost drivers
gained devfreq cooling support.
[0] https://www.spinics.net/lists/dri-devel/msg252825.html
Fixes: a76caf55e5b356 ("thermal: Add devfreq cooling")
Cc: stable@vger.kernel.org
Reported-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200403205133.1101808-1-martin.blumenstingl@googlemail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/devfreq_cooling.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/linux/devfreq_cooling.h
+++ b/include/linux/devfreq_cooling.h
@@ -75,7 +75,7 @@ void devfreq_cooling_unregister(struct t
#else /* !CONFIG_DEVFREQ_THERMAL */
-struct thermal_cooling_device *
+static inline struct thermal_cooling_device *
of_devfreq_cooling_register_power(struct device_node *np, struct devfreq *df,
struct devfreq_cooling_power *dfc_power)
{
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 048/199] nvme-fc: Revert "add module to ops template to allow module references"
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (46 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 047/199] thermal: devfreq_cooling: inline all stubs for CONFIG_DEVFREQ_THERMAL=n Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 049/199] PCI/ASPM: Clear the correct bits when enabling L1 substates Greg Kroah-Hartman
` (82 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, James Smart, Himanshu Madhani,
Christoph Hellwig
From: James Smart <jsmart2021@gmail.com>
commit 8c5c660529209a0e324c1c1a35ce3f83d67a2aa5 upstream.
The original patch was to resolve the lldd being able to be unloaded
while being used to talk to the boot device of the system. However, the
end result of the original patch is that any driver unload while a nvme
controller is live via the lldd is now being prohibited. Given the module
reference, the module teardown routine can't be called, thus there's no
way, other than manual actions to terminate the controllers.
Fixes: 863fbae929c7 ("nvme_fc: add module to ops template to allow module references")
Cc: <stable@vger.kernel.org> # v5.4+
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nvme/host/fc.c | 14 ++------------
drivers/nvme/target/fcloop.c | 1 -
drivers/scsi/lpfc/lpfc_nvme.c | 2 --
drivers/scsi/qla2xxx/qla_nvme.c | 1 -
include/linux/nvme-fc-driver.h | 4 ----
5 files changed, 2 insertions(+), 20 deletions(-)
--- a/drivers/nvme/host/fc.c
+++ b/drivers/nvme/host/fc.c
@@ -337,8 +337,7 @@ nvme_fc_register_localport(struct nvme_f
!template->ls_req || !template->fcp_io ||
!template->ls_abort || !template->fcp_abort ||
!template->max_hw_queues || !template->max_sgl_segments ||
- !template->max_dif_sgl_segments || !template->dma_boundary ||
- !template->module) {
+ !template->max_dif_sgl_segments || !template->dma_boundary) {
ret = -EINVAL;
goto out_reghost_failed;
}
@@ -1763,7 +1762,6 @@ nvme_fc_ctrl_free(struct kref *ref)
{
struct nvme_fc_ctrl *ctrl =
container_of(ref, struct nvme_fc_ctrl, ref);
- struct nvme_fc_lport *lport = ctrl->lport;
unsigned long flags;
if (ctrl->ctrl.tagset) {
@@ -1789,7 +1787,6 @@ nvme_fc_ctrl_free(struct kref *ref)
if (ctrl->ctrl.opts)
nvmf_free_options(ctrl->ctrl.opts);
kfree(ctrl);
- module_put(lport->ops->module);
}
static void
@@ -2768,15 +2765,10 @@ nvme_fc_init_ctrl(struct device *dev, st
goto out_fail;
}
- if (!try_module_get(lport->ops->module)) {
- ret = -EUNATCH;
- goto out_free_ctrl;
- }
-
idx = ida_simple_get(&nvme_fc_ctrl_cnt, 0, 0, GFP_KERNEL);
if (idx < 0) {
ret = -ENOSPC;
- goto out_mod_put;
+ goto out_free_ctrl;
}
ctrl->ctrl.opts = opts;
@@ -2923,8 +2915,6 @@ out_free_queues:
out_free_ida:
put_device(ctrl->dev);
ida_simple_remove(&nvme_fc_ctrl_cnt, ctrl->cnum);
-out_mod_put:
- module_put(lport->ops->module);
out_free_ctrl:
kfree(ctrl);
out_fail:
--- a/drivers/nvme/target/fcloop.c
+++ b/drivers/nvme/target/fcloop.c
@@ -693,7 +693,6 @@ fcloop_targetport_delete(struct nvmet_fc
#define FCLOOP_DMABOUND_4G 0xFFFFFFFF
static struct nvme_fc_port_template fctemplate = {
- .module = THIS_MODULE,
.localport_delete = fcloop_localport_delete,
.remoteport_delete = fcloop_remoteport_delete,
.create_queue = fcloop_create_queue,
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -1591,8 +1591,6 @@ lpfc_nvme_fcp_abort(struct nvme_fc_local
/* Declare and initialization an instance of the FC NVME template. */
static struct nvme_fc_port_template lpfc_nvme_template = {
- .module = THIS_MODULE,
-
/* initiator-based functions */
.localport_delete = lpfc_nvme_localport_delete,
.remoteport_delete = lpfc_nvme_remoteport_delete,
--- a/drivers/scsi/qla2xxx/qla_nvme.c
+++ b/drivers/scsi/qla2xxx/qla_nvme.c
@@ -578,7 +578,6 @@ static void qla_nvme_remoteport_delete(s
}
static struct nvme_fc_port_template qla_nvme_fc_transport = {
- .module = THIS_MODULE,
.localport_delete = qla_nvme_localport_delete,
.remoteport_delete = qla_nvme_remoteport_delete,
.create_queue = qla_nvme_alloc_queue,
--- a/include/linux/nvme-fc-driver.h
+++ b/include/linux/nvme-fc-driver.h
@@ -279,8 +279,6 @@ struct nvme_fc_remote_port {
*
* Host/Initiator Transport Entrypoints/Parameters:
*
- * @module: The LLDD module using the interface
- *
* @localport_delete: The LLDD initiates deletion of a localport via
* nvme_fc_deregister_localport(). However, the teardown is
* asynchronous. This routine is called upon the completion of the
@@ -394,8 +392,6 @@ struct nvme_fc_remote_port {
* Value is Mandatory. Allowed to be zero.
*/
struct nvme_fc_port_template {
- struct module *module;
-
/* initiator-based functions */
void (*localport_delete)(struct nvme_fc_local_port *);
void (*remoteport_delete)(struct nvme_fc_remote_port *);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 049/199] PCI/ASPM: Clear the correct bits when enabling L1 substates
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (47 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 048/199] nvme-fc: Revert "add module to ops template to allow module references" Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 050/199] PCI: endpoint: Fix for concurrent memory allocation in OB address region Greg Kroah-Hartman
` (81 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Yicong Yang, Bjorn Helgaas
From: Yicong Yang <yangyicong@hisilicon.com>
commit 58a3862a10a317a81097ab0c78aecebabb1704f5 upstream.
In pcie_config_aspm_l1ss(), we cleared the wrong bits when enabling ASPM L1
Substates. Instead of the L1.x enable bits (PCI_L1SS_CTL1_L1SS_MASK, 0xf), we
cleared the Link Activation Interrupt Enable bit (PCI_L1SS_CAP_L1_PM_SS,
0x10).
Clear the L1.x enable bits before writing the new L1.x configuration.
[bhelgaas: changelog]
Fixes: aeda9adebab8 ("PCI/ASPM: Configure L1 substate settings")
Link: https://lore.kernel.org/r/1584093227-1292-1-git-send-email-yangyicong@hisilicon.com
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v4.11+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/pcie/aspm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -693,9 +693,9 @@ static void pcie_config_aspm_l1ss(struct
/* Enable what we need to enable */
pci_clear_and_set_dword(parent, up_cap_ptr + PCI_L1SS_CTL1,
- PCI_L1SS_CAP_L1_PM_SS, val);
+ PCI_L1SS_CTL1_L1SS_MASK, val);
pci_clear_and_set_dword(child, dw_cap_ptr + PCI_L1SS_CTL1,
- PCI_L1SS_CAP_L1_PM_SS, val);
+ PCI_L1SS_CTL1_L1SS_MASK, val);
}
static void pcie_config_aspm_dev(struct pci_dev *pdev, u32 val)
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 050/199] PCI: endpoint: Fix for concurrent memory allocation in OB address region
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (48 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 049/199] PCI/ASPM: Clear the correct bits when enabling L1 substates Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 051/199] KEYS: reaching the keys quotas correctly Greg Kroah-Hartman
` (80 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kishon Vijay Abraham I, Lorenzo Pieralisi
From: Kishon Vijay Abraham I <kishon@ti.com>
commit 04e046ca57ebed3943422dee10eec9e73aec081e upstream.
pci-epc-mem uses a bitmap to manage the Endpoint outbound (OB) address
region. This address region will be shared by multiple endpoint
functions (in the case of multi function endpoint) and it has to be
protected from concurrent access to avoid updating an inconsistent state.
Use a mutex to protect bitmap updates to prevent the memory
allocation API from returning incorrect addresses.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/endpoint/pci-epc-mem.c | 10 ++++++++--
include/linux/pci-epc.h | 3 +++
2 files changed, 11 insertions(+), 2 deletions(-)
--- a/drivers/pci/endpoint/pci-epc-mem.c
+++ b/drivers/pci/endpoint/pci-epc-mem.c
@@ -90,6 +90,7 @@ int __pci_epc_mem_init(struct pci_epc *e
mem->page_size = page_size;
mem->pages = pages;
mem->size = size;
+ mutex_init(&mem->lock);
epc->mem = mem;
@@ -133,7 +134,7 @@ void __iomem *pci_epc_mem_alloc_addr(str
phys_addr_t *phys_addr, size_t size)
{
int pageno;
- void __iomem *virt_addr;
+ void __iomem *virt_addr = NULL;
struct pci_epc_mem *mem = epc->mem;
unsigned int page_shift = ilog2(mem->page_size);
int order;
@@ -141,15 +142,18 @@ void __iomem *pci_epc_mem_alloc_addr(str
size = ALIGN(size, mem->page_size);
order = pci_epc_mem_get_order(mem, size);
+ mutex_lock(&mem->lock);
pageno = bitmap_find_free_region(mem->bitmap, mem->pages, order);
if (pageno < 0)
- return NULL;
+ goto ret;
*phys_addr = mem->phys_base + (pageno << page_shift);
virt_addr = ioremap(*phys_addr, size);
if (!virt_addr)
bitmap_release_region(mem->bitmap, pageno, order);
+ret:
+ mutex_unlock(&mem->lock);
return virt_addr;
}
EXPORT_SYMBOL_GPL(pci_epc_mem_alloc_addr);
@@ -175,7 +179,9 @@ void pci_epc_mem_free_addr(struct pci_ep
pageno = (phys_addr - mem->phys_base) >> page_shift;
size = ALIGN(size, mem->page_size);
order = pci_epc_mem_get_order(mem, size);
+ mutex_lock(&mem->lock);
bitmap_release_region(mem->bitmap, pageno, order);
+ mutex_unlock(&mem->lock);
}
EXPORT_SYMBOL_GPL(pci_epc_mem_free_addr);
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -63,6 +63,7 @@ struct pci_epc_ops {
* @bitmap: bitmap to manage the PCI address space
* @pages: number of bits representing the address region
* @page_size: size of each page
+ * @lock: mutex to protect bitmap
*/
struct pci_epc_mem {
phys_addr_t phys_base;
@@ -70,6 +71,8 @@ struct pci_epc_mem {
unsigned long *bitmap;
size_t page_size;
int pages;
+ /* mutex to protect against concurrent access for memory allocation*/
+ struct mutex lock;
};
/**
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 051/199] KEYS: reaching the keys quotas correctly
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (49 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 050/199] PCI: endpoint: Fix for concurrent memory allocation in OB address region Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 052/199] irqchip/versatile-fpga: Apply clear-mask earlier Greg Kroah-Hartman
` (79 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Biggers, Yang Xu, Jarkko Sakkinen
From: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
commit 2e356101e72ab1361821b3af024d64877d9a798d upstream.
Currently, when we add a new user key, the calltrace as below:
add_key()
key_create_or_update()
key_alloc()
__key_instantiate_and_link
generic_key_instantiate
key_payload_reserve
......
Since commit a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly"),
we can reach max bytes/keys in key_alloc, but we forget to remove this
limit when we reserver space for payload in key_payload_reserve. So we
can only reach max keys but not max bytes when having delta between plen
and type->def_datalen. Remove this limit when instantiating the key, so we
can keep consistent with key_alloc.
Also, fix the similar problem in keyctl_chown_key().
Fixes: 0b77f5bfb45c ("keys: make the keyring quotas controllable through /proc/sys")
Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly")
Cc: stable@vger.kernel.org # 5.0.x
Cc: Eric Biggers <ebiggers@google.com>
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/keys/key.c | 2 +-
security/keys/keyctl.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -383,7 +383,7 @@ int key_payload_reserve(struct key *key,
spin_lock(&key->user->lock);
if (delta > 0 &&
- (key->user->qnbytes + delta >= maxbytes ||
+ (key->user->qnbytes + delta > maxbytes ||
key->user->qnbytes + delta < key->user->qnbytes)) {
ret = -EDQUOT;
}
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -882,8 +882,8 @@ long keyctl_chown_key(key_serial_t id, u
key_quota_root_maxbytes : key_quota_maxbytes;
spin_lock(&newowner->lock);
- if (newowner->qnkeys + 1 >= maxkeys ||
- newowner->qnbytes + key->quotalen >= maxbytes ||
+ if (newowner->qnkeys + 1 > maxkeys ||
+ newowner->qnbytes + key->quotalen > maxbytes ||
newowner->qnbytes + key->quotalen <
newowner->qnbytes)
goto quota_overrun;
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 052/199] irqchip/versatile-fpga: Apply clear-mask earlier
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (50 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 051/199] KEYS: reaching the keys quotas correctly Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 053/199] MIPS: OCTEON: irq: Fix potential NULL pointer dereference Greg Kroah-Hartman
` (78 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sungbo Eo, Marc Zyngier, Linus Walleij
From: Sungbo Eo <mans0n@gorani.run>
commit 6a214a28132f19ace3d835a6d8f6422ec80ad200 upstream.
Clear its own IRQs before the parent IRQ get enabled, so that the
remaining IRQs do not accidentally interrupt the parent IRQ controller.
This patch also fixes a reboot bug on OX820 SoC, where the remaining
rps-timer IRQ raises a GIC interrupt that is left pending. After that,
the rps-timer IRQ is cleared during driver initialization, and there's
no IRQ left in rps-irq when local_irq_enable() is called, which evokes
an error message "unexpected IRQ trap".
Fixes: bdd272cbb97a ("irqchip: versatile FPGA: support cascaded interrupts from DT")
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200321133842.2408823-1-mans0n@gorani.run
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/irq-versatile-fpga.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/irqchip/irq-versatile-fpga.c
+++ b/drivers/irqchip/irq-versatile-fpga.c
@@ -212,6 +212,9 @@ int __init fpga_irq_of_init(struct devic
if (of_property_read_u32(node, "valid-mask", &valid_mask))
valid_mask = 0;
+ writel(clear_mask, base + IRQ_ENABLE_CLEAR);
+ writel(clear_mask, base + FIQ_ENABLE_CLEAR);
+
/* Some chips are cascaded from a parent IRQ */
parent_irq = irq_of_parse_and_map(node, 0);
if (!parent_irq) {
@@ -221,9 +224,6 @@ int __init fpga_irq_of_init(struct devic
fpga_irq_init(base, node->name, 0, parent_irq, valid_mask, node);
- writel(clear_mask, base + IRQ_ENABLE_CLEAR);
- writel(clear_mask, base + FIQ_ENABLE_CLEAR);
-
/*
* On Versatile AB/PB, some secondary interrupts have a direct
* pass-thru to the primary controller for IRQs 20 and 22-31 which need
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 053/199] MIPS: OCTEON: irq: Fix potential NULL pointer dereference
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (51 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 052/199] irqchip/versatile-fpga: Apply clear-mask earlier Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 054/199] ath9k: Handle txpower changes even when TPC is disabled Greg Kroah-Hartman
` (77 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Gustavo A. R. Silva, Thomas Bogendoerfer
From: Gustavo A. R. Silva <gustavo@embeddedor.com>
commit 792a402c2840054533ef56279c212ef6da87d811 upstream.
There is a potential NULL pointer dereference in case kzalloc()
fails and returns NULL.
Fix this by adding a NULL check on *cd*
This bug was detected with the help of Coccinelle.
Fixes: 64b139f97c01 ("MIPS: OCTEON: irq: add CIB and other fixes")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/cavium-octeon/octeon-irq.c | 3 +++
1 file changed, 3 insertions(+)
--- a/arch/mips/cavium-octeon/octeon-irq.c
+++ b/arch/mips/cavium-octeon/octeon-irq.c
@@ -2199,6 +2199,9 @@ static int octeon_irq_cib_map(struct irq
}
cd = kzalloc(sizeof(*cd), GFP_KERNEL);
+ if (!cd)
+ return -ENOMEM;
+
cd->host_data = host_data;
cd->bit = hw;
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 054/199] ath9k: Handle txpower changes even when TPC is disabled
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (52 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 053/199] MIPS: OCTEON: irq: Fix potential NULL pointer dereference Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 055/199] signal: Extend exec_id to 64bits Greg Kroah-Hartman
` (76 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Remi Pommarel, Kalle Valo
From: Remi Pommarel <repk@triplefau.lt>
commit 968ae2caad0782db5dbbabb560d3cdefd2945d38 upstream.
When TPC is disabled IEEE80211_CONF_CHANGE_POWER event can be handled to
reconfigure HW's maximum txpower.
This fixes 0dBm txpower setting when user attaches to an interface for
the first time with the following scenario:
ieee80211_do_open()
ath9k_add_interface()
ath9k_set_txpower() /* Set TX power with not yet initialized
sc->hw->conf.power_level */
ieee80211_hw_config() /* Iniatilize sc->hw->conf.power_level and
raise IEEE80211_CONF_CHANGE_POWER */
ath9k_config() /* IEEE80211_CONF_CHANGE_POWER is ignored */
This issue can be reproduced with the following:
$ modprobe -r ath9k
$ modprobe ath9k
$ wpa_supplicant -i wlan0 -c /tmp/wpa.conf &
$ iw dev /* Here TX power is either 0 or 3 depending on RF chain */
$ killall wpa_supplicant
$ iw dev /* TX power goes back to calibrated value and subsequent
calls will be fine */
Fixes: 283dd11994cde ("ath9k: add per-vif TX power capability")
Cc: stable@vger.kernel.org
Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/ath9k/main.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1456,6 +1456,9 @@ static int ath9k_config(struct ieee80211
ath_chanctx_set_channel(sc, ctx, &hw->conf.chandef);
}
+ if (changed & IEEE80211_CONF_CHANGE_POWER)
+ ath9k_set_txpower(sc, NULL);
+
mutex_unlock(&sc->mutex);
ath9k_ps_restore(sc);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 055/199] signal: Extend exec_id to 64bits
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (53 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 054/199] ath9k: Handle txpower changes even when TPC is disabled Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 056/199] x86/entry/32: Add missing ASM_CLAC to general_protection entry Greg Kroah-Hartman
` (75 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Eric W. Biederman
From: Eric W. Biederman <ebiederm@xmission.com>
commit d1e7fd6462ca9fc76650fbe6ca800e35b24267da upstream.
Replace the 32bit exec_id with a 64bit exec_id to make it impossible
to wrap the exec_id counter. With care an attacker can cause exec_id
wrap and send arbitrary signals to a newly exec'd parent. This
bypasses the signal sending checks if the parent changes their
credentials during exec.
The severity of this problem can been seen that in my limited testing
of a 32bit exec_id it can take as little as 19s to exec 65536 times.
Which means that it can take as little as 14 days to wrap a 32bit
exec_id. Adam Zabrocki has succeeded wrapping the self_exe_id in 7
days. Even my slower timing is in the uptime of a typical server.
Which means self_exec_id is simply a speed bump today, and if exec
gets noticably faster self_exec_id won't even be a speed bump.
Extending self_exec_id to 64bits introduces a problem on 32bit
architectures where reading self_exec_id is no longer atomic and can
take two read instructions. Which means that is is possible to hit
a window where the read value of exec_id does not match the written
value. So with very lucky timing after this change this still
remains expoiltable.
I have updated the update of exec_id on exec to use WRITE_ONCE
and the read of exec_id in do_notify_parent to use READ_ONCE
to make it clear that there is no locking between these two
locations.
Link: https://lore.kernel.org/kernel-hardening/20200324215049.GA3710@pi3.com.pl
Fixes: 2.3.23pre2
Cc: stable@vger.kernel.org
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/exec.c | 2 +-
include/linux/sched.h | 4 ++--
kernel/signal.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1373,7 +1373,7 @@ void setup_new_exec(struct linux_binprm
/* An exec changes our domain. We are no longer part of the thread
group */
- current->self_exec_id++;
+ WRITE_ONCE(current->self_exec_id, current->self_exec_id + 1);
flush_signal_handlers(current, 0);
}
EXPORT_SYMBOL(setup_new_exec);
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -839,8 +839,8 @@ struct task_struct {
struct seccomp seccomp;
/* Thread group tracking: */
- u32 parent_exec_id;
- u32 self_exec_id;
+ u64 parent_exec_id;
+ u64 self_exec_id;
/* Protection against (de-)allocation: mm, files, fs, tty, keyrings, mems_allowed, mempolicy: */
spinlock_t alloc_lock;
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1675,7 +1675,7 @@ bool do_notify_parent(struct task_struct
* This is only possible if parent == real_parent.
* Check if it has changed security domain.
*/
- if (tsk->parent_exec_id != tsk->parent->self_exec_id)
+ if (tsk->parent_exec_id != READ_ONCE(tsk->parent->self_exec_id))
sig = SIGCHLD;
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 056/199] x86/entry/32: Add missing ASM_CLAC to general_protection entry
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (54 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 055/199] signal: Extend exec_id to 64bits Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 057/199] KVM: nVMX: Properly handle userspace interrupt window request Greg Kroah-Hartman
` (74 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas Gleixner, Frederic Weisbecker,
Alexandre Chartre, Andy Lutomirski
From: Thomas Gleixner <tglx@linutronix.de>
commit 3d51507f29f2153a658df4a0674ec5b592b62085 upstream.
All exception entry points must have ASM_CLAC right at the
beginning. The general_protection entry is missing one.
Fixes: e59d1b0a2419 ("x86-32, smap: Add STAC/CLAC instructions to 32-bit kernel entry")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20200225220216.219537887@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/entry/entry_32.S | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -1057,6 +1057,7 @@ ENTRY(int3)
END(int3)
ENTRY(general_protection)
+ ASM_CLAC
pushl $do_general_protection
jmp common_exception
END(general_protection)
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 057/199] KVM: nVMX: Properly handle userspace interrupt window request
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (55 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 056/199] x86/entry/32: Add missing ASM_CLAC to general_protection entry Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 058/199] KVM: s390: vsie: Fix region 1 ASCE sanity shadow address checks Greg Kroah-Hartman
` (73 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Liran Alon, Sean Christopherson,
Paolo Bonzini
From: Sean Christopherson <sean.j.christopherson@intel.com>
commit a1c77abb8d93381e25a8d2df3a917388244ba776 upstream.
Return true for vmx_interrupt_allowed() if the vCPU is in L2 and L1 has
external interrupt exiting enabled. IRQs are never blocked in hardware
if the CPU is in the guest (L2 from L1's perspective) when IRQs trigger
VM-Exit.
The new check percolates up to kvm_vcpu_ready_for_interrupt_injection()
and thus vcpu_run(), and so KVM will exit to userspace if userspace has
requested an interrupt window (to inject an IRQ into L1).
Remove the @external_intr param from vmx_check_nested_events(), which is
actually an indicator that userspace wants an interrupt window, e.g.
it's named @req_int_win further up the stack. Injecting a VM-Exit into
L1 to try and bounce out to L0 userspace is all kinds of broken and is
no longer necessary.
Remove the hack in nested_vmx_vmexit() that attempted to workaround the
breakage in vmx_check_nested_events() by only filling interrupt info if
there's an actual interrupt pending. The hack actually made things
worse because it caused KVM to _never_ fill interrupt info when the
LAPIC resides in userspace (kvm_cpu_has_interrupt() queries
interrupt.injected, which is always cleared by prepare_vmcs12() before
reaching the hack in nested_vmx_vmexit()).
Fixes: 6550c4df7e50 ("KVM: nVMX: Fix interrupt window request with "Acknowledge interrupt on exit"")
Cc: stable@vger.kernel.org
Cc: Liran Alon <liran.alon@oracle.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/vmx.c | 27 +++++++++++----------------
arch/x86/kvm/x86.c | 10 +++++-----
3 files changed, 17 insertions(+), 22 deletions(-)
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1032,7 +1032,7 @@ struct kvm_x86_ops {
bool (*mpx_supported)(void);
bool (*xsaves_supported)(void);
- int (*check_nested_events)(struct kvm_vcpu *vcpu, bool external_intr);
+ int (*check_nested_events)(struct kvm_vcpu *vcpu);
void (*sched_in)(struct kvm_vcpu *kvm, int cpu);
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6198,8 +6198,13 @@ static int vmx_nmi_allowed(struct kvm_vc
static int vmx_interrupt_allowed(struct kvm_vcpu *vcpu)
{
- return (!to_vmx(vcpu)->nested.nested_run_pending &&
- vmcs_readl(GUEST_RFLAGS) & X86_EFLAGS_IF) &&
+ if (to_vmx(vcpu)->nested.nested_run_pending)
+ return false;
+
+ if (is_guest_mode(vcpu) && nested_exit_on_intr(vcpu))
+ return true;
+
+ return (vmcs_readl(GUEST_RFLAGS) & X86_EFLAGS_IF) &&
!(vmcs_read32(GUEST_INTERRUPTIBILITY_INFO) &
(GUEST_INTR_STATE_STI | GUEST_INTR_STATE_MOV_SS));
}
@@ -11659,7 +11664,7 @@ static void vmcs12_save_pending_event(st
}
}
-static int vmx_check_nested_events(struct kvm_vcpu *vcpu, bool external_intr)
+static int vmx_check_nested_events(struct kvm_vcpu *vcpu)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
unsigned long exit_qual;
@@ -11697,8 +11702,7 @@ static int vmx_check_nested_events(struc
return 0;
}
- if ((kvm_cpu_has_interrupt(vcpu) || external_intr) &&
- nested_exit_on_intr(vcpu)) {
+ if (kvm_cpu_has_interrupt(vcpu) && nested_exit_on_intr(vcpu)) {
if (block_nested_events)
return -EBUSY;
nested_vmx_vmexit(vcpu, EXIT_REASON_EXTERNAL_INTERRUPT, 0, 0);
@@ -12254,17 +12258,8 @@ static void nested_vmx_vmexit(struct kvm
vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE;
if (likely(!vmx->fail)) {
- /*
- * TODO: SDM says that with acknowledge interrupt on
- * exit, bit 31 of the VM-exit interrupt information
- * (valid interrupt) is always set to 1 on
- * EXIT_REASON_EXTERNAL_INTERRUPT, so we shouldn't
- * need kvm_cpu_has_interrupt(). See the commit
- * message for details.
- */
- if (nested_exit_intr_ack_set(vcpu) &&
- exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT &&
- kvm_cpu_has_interrupt(vcpu)) {
+ if (exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT &&
+ nested_exit_intr_ack_set(vcpu)) {
int irq = kvm_cpu_get_interrupt(vcpu);
WARN_ON(irq < 0);
vmcs12->vm_exit_intr_info = irq |
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6638,7 +6638,7 @@ static void update_cr8_intercept(struct
kvm_x86_ops->update_cr8_intercept(vcpu, tpr, max_irr);
}
-static int inject_pending_event(struct kvm_vcpu *vcpu, bool req_int_win)
+static int inject_pending_event(struct kvm_vcpu *vcpu)
{
int r;
@@ -6665,7 +6665,7 @@ static int inject_pending_event(struct k
}
if (is_guest_mode(vcpu) && kvm_x86_ops->check_nested_events) {
- r = kvm_x86_ops->check_nested_events(vcpu, req_int_win);
+ r = kvm_x86_ops->check_nested_events(vcpu);
if (r != 0)
return r;
}
@@ -6706,7 +6706,7 @@ static int inject_pending_event(struct k
* KVM_REQ_EVENT only on certain events and not unconditionally?
*/
if (is_guest_mode(vcpu) && kvm_x86_ops->check_nested_events) {
- r = kvm_x86_ops->check_nested_events(vcpu, req_int_win);
+ r = kvm_x86_ops->check_nested_events(vcpu);
if (r != 0)
return r;
}
@@ -7152,7 +7152,7 @@ static int vcpu_enter_guest(struct kvm_v
goto out;
}
- if (inject_pending_event(vcpu, req_int_win) != 0)
+ if (inject_pending_event(vcpu) != 0)
req_immediate_exit = true;
else {
/* Enable NMI/IRQ window open exits if needed.
@@ -7360,7 +7360,7 @@ static inline int vcpu_block(struct kvm
static inline bool kvm_vcpu_running(struct kvm_vcpu *vcpu)
{
if (is_guest_mode(vcpu) && kvm_x86_ops->check_nested_events)
- kvm_x86_ops->check_nested_events(vcpu, false);
+ kvm_x86_ops->check_nested_events(vcpu);
return (vcpu->arch.mp_state == KVM_MP_STATE_RUNNABLE &&
!vcpu->arch.apf.halted);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 058/199] KVM: s390: vsie: Fix region 1 ASCE sanity shadow address checks
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (56 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 057/199] KVM: nVMX: Properly handle userspace interrupt window request Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 059/199] KVM: s390: vsie: Fix delivery of addressing exceptions Greg Kroah-Hartman
` (72 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Janosch Frank, David Hildenbrand,
Claudio Imbrenda, Christian Borntraeger
From: David Hildenbrand <david@redhat.com>
commit a1d032a49522cb5368e5dfb945a85899b4c74f65 upstream.
In case we have a region 1 the following calculation
(31 + ((gmap->asce & _ASCE_TYPE_MASK) >> 2)*11)
results in 64. As shifts beyond the size are undefined the compiler is
free to use instructions like sllg. sllg will only use 6 bits of the
shift value (here 64) resulting in no shift at all. That means that ALL
addresses will be rejected.
The can result in endless loops, e.g. when prefix cannot get mapped.
Fixes: 4be130a08420 ("s390/mm: add shadow gmap support")
Tested-by: Janosch Frank <frankja@linux.ibm.com>
Reported-by: Janosch Frank <frankja@linux.ibm.com>
Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: David Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20200403153050.20569-2-david@redhat.com
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
[borntraeger@de.ibm.com: fix patch description, remove WARN_ON_ONCE]
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/s390/mm/gmap.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/arch/s390/mm/gmap.c
+++ b/arch/s390/mm/gmap.c
@@ -762,14 +762,18 @@ static void gmap_call_notifier(struct gm
static inline unsigned long *gmap_table_walk(struct gmap *gmap,
unsigned long gaddr, int level)
{
+ const int asce_type = gmap->asce & _ASCE_TYPE_MASK;
unsigned long *table;
if ((gmap->asce & _ASCE_TYPE_MASK) + 4 < (level * 4))
return NULL;
if (gmap_is_shadow(gmap) && gmap->removed)
return NULL;
- if (gaddr & (-1UL << (31 + ((gmap->asce & _ASCE_TYPE_MASK) >> 2)*11)))
+
+ if (asce_type != _ASCE_TYPE_REGION1 &&
+ gaddr & (-1UL << (31 + (asce_type >> 2) * 11)))
return NULL;
+
table = gmap->table;
switch (gmap->asce & _ASCE_TYPE_MASK) {
case _ASCE_TYPE_REGION1:
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 059/199] KVM: s390: vsie: Fix delivery of addressing exceptions
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (57 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 058/199] KVM: s390: vsie: Fix region 1 ASCE sanity shadow address checks Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 060/199] KVM: x86: Allocate new rmap and large page tracking when moving memslot Greg Kroah-Hartman
` (71 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Hildenbrand, Claudio Imbrenda,
Christian Borntraeger
From: David Hildenbrand <david@redhat.com>
commit 4d4cee96fb7a3cc53702a9be8299bf525be4ee98 upstream.
Whenever we get an -EFAULT, we failed to read in guest 2 physical
address space. Such addressing exceptions are reported via a program
intercept to the nested hypervisor.
We faked the intercept, we have to return to guest 2. Instead, right
now we would be returning -EFAULT from the intercept handler, eventually
crashing the VM.
the correct thing to do is to return 1 as rc == 1 is the internal
representation of "we have to go back into g2".
Addressing exceptions can only happen if the g2->g3 page tables
reference invalid g2 addresses (say, either a table or the final page is
not accessible - so something that basically never happens in sane
environments.
Identified by manual code inspection.
Fixes: a3508fbe9dc6 ("KVM: s390: vsie: initial support for nested virtualization")
Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: David Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20200403153050.20569-3-david@redhat.com
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
[borntraeger@de.ibm.com: fix patch description]
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/s390/kvm/vsie.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/s390/kvm/vsie.c
+++ b/arch/s390/kvm/vsie.c
@@ -1027,6 +1027,7 @@ static int vsie_run(struct kvm_vcpu *vcp
scb_s->iprcc = PGM_ADDRESSING;
scb_s->pgmilc = 4;
scb_s->gpsw.addr = __rewind_psw(scb_s->gpsw, 4);
+ rc = 1;
}
return rc;
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 060/199] KVM: x86: Allocate new rmap and large page tracking when moving memslot
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (58 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 059/199] KVM: s390: vsie: Fix delivery of addressing exceptions Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 061/199] KVM: VMX: Always VMCLEAR in-use VMCSes during crash with kexec support Greg Kroah-Hartman
` (70 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sean Christopherson, Peter Xu, Paolo Bonzini
From: Sean Christopherson <sean.j.christopherson@intel.com>
commit edd4fa37baa6ee8e44dc65523b27bd6fe44c94de upstream.
Reallocate a rmap array and recalcuate large page compatibility when
moving an existing memslot to correctly handle the alignment properties
of the new memslot. The number of rmap entries required at each level
is dependent on the alignment of the memslot's base gfn with respect to
that level, e.g. moving a large-page aligned memslot so that it becomes
unaligned will increase the number of rmap entries needed at the now
unaligned level.
Not updating the rmap array is the most obvious bug, as KVM accesses
garbage data beyond the end of the rmap. KVM interprets the bad data as
pointers, leading to non-canonical #GPs, unexpected #PFs, etc...
general protection fault: 0000 [#1] SMP
CPU: 0 PID: 1909 Comm: move_memory_reg Not tainted 5.4.0-rc7+ #139
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:rmap_get_first+0x37/0x50 [kvm]
Code: <48> 8b 3b 48 85 ff 74 ec e8 6c f4 ff ff 85 c0 74 e3 48 89 d8 5b c3
RSP: 0018:ffffc9000021bbc8 EFLAGS: 00010246
RAX: ffff00617461642e RBX: ffff00617461642e RCX: 0000000000000012
RDX: ffff88827400f568 RSI: ffffc9000021bbe0 RDI: ffff88827400f570
RBP: 0010000000000000 R08: ffffc9000021bd00 R09: ffffc9000021bda8
R10: ffffc9000021bc48 R11: 0000000000000000 R12: 0030000000000000
R13: 0000000000000000 R14: ffff88827427d700 R15: ffffc9000021bce8
FS: 00007f7eda014700(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7ed9216ff8 CR3: 0000000274391003 CR4: 0000000000162eb0
Call Trace:
kvm_mmu_slot_set_dirty+0xa1/0x150 [kvm]
__kvm_set_memory_region.part.64+0x559/0x960 [kvm]
kvm_set_memory_region+0x45/0x60 [kvm]
kvm_vm_ioctl+0x30f/0x920 [kvm]
do_vfs_ioctl+0xa1/0x620
ksys_ioctl+0x66/0x70
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x4c/0x170
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f7ed9911f47
Code: <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 21 6f 2c 00 f7 d8 64 89 01 48
RSP: 002b:00007ffc00937498 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000001ab0010 RCX: 00007f7ed9911f47
RDX: 0000000001ab1350 RSI: 000000004020ae46 RDI: 0000000000000004
RBP: 000000000000000a R08: 0000000000000000 R09: 00007f7ed9214700
R10: 00007f7ed92149d0 R11: 0000000000000246 R12: 00000000bffff000
R13: 0000000000000003 R14: 00007f7ed9215000 R15: 0000000000000000
Modules linked in: kvm_intel kvm irqbypass
---[ end trace 0c5f570b3358ca89 ]---
The disallow_lpage tracking is more subtle. Failure to update results
in KVM creating large pages when it shouldn't, either due to stale data
or again due to indexing beyond the end of the metadata arrays, which
can lead to memory corruption and/or leaking data to guest/userspace.
Note, the arrays for the old memslot are freed by the unconditional call
to kvm_free_memslot() in __kvm_set_memory_region().
Fixes: 05da45583de9b ("KVM: MMU: large page support")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/x86.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8584,6 +8584,13 @@ int kvm_arch_create_memslot(struct kvm *
{
int i;
+ /*
+ * Clear out the previous array pointers for the KVM_MR_MOVE case. The
+ * old arrays will be freed by __kvm_set_memory_region() if installing
+ * the new memslot is successful.
+ */
+ memset(&slot->arch, 0, sizeof(slot->arch));
+
for (i = 0; i < KVM_NR_PAGE_SIZES; ++i) {
struct kvm_lpage_info *linfo;
unsigned long ugfn;
@@ -8657,6 +8664,10 @@ int kvm_arch_prepare_memory_region(struc
const struct kvm_userspace_memory_region *mem,
enum kvm_mr_change change)
{
+ if (change == KVM_MR_MOVE)
+ return kvm_arch_create_memslot(kvm, memslot,
+ mem->memory_size >> PAGE_SHIFT);
+
return 0;
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 061/199] KVM: VMX: Always VMCLEAR in-use VMCSes during crash with kexec support
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (59 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 060/199] KVM: x86: Allocate new rmap and large page tracking when moving memslot Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 062/199] KVM: VMX: fix crash cleanup when KVM wasnt used Greg Kroah-Hartman
` (69 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sean Christopherson,
Vitaly Kuznetsov, Paolo Bonzini
From: Sean Christopherson <sean.j.christopherson@intel.com>
commit 31603d4fc2bb4f0815245d496cb970b27b4f636a upstream.
VMCLEAR all in-use VMCSes during a crash, even if kdump's NMI shootdown
interrupted a KVM update of the percpu in-use VMCS list.
Because NMIs are not blocked by disabling IRQs, it's possible that
crash_vmclear_local_loaded_vmcss() could be called while the percpu list
of VMCSes is being modified, e.g. in the middle of list_add() in
vmx_vcpu_load_vmcs(). This potential corner case was called out in the
original commit[*], but the analysis of its impact was wrong.
Skipping the VMCLEARs is wrong because it all but guarantees that a
loaded, and therefore cached, VMCS will live across kexec and corrupt
memory in the new kernel. Corruption will occur because the CPU's VMCS
cache is non-coherent, i.e. not snooped, and so the writeback of VMCS
memory on its eviction will overwrite random memory in the new kernel.
The VMCS will live because the NMI shootdown also disables VMX, i.e. the
in-progress VMCLEAR will #UD, and existing Intel CPUs do not flush the
VMCS cache on VMXOFF.
Furthermore, interrupting list_add() and list_del() is safe due to
crash_vmclear_local_loaded_vmcss() using forward iteration. list_add()
ensures the new entry is not visible to forward iteration unless the
entire add completes, via WRITE_ONCE(prev->next, new). A bad "prev"
pointer could be observed if the NMI shootdown interrupted list_del() or
list_add(), but list_for_each_entry() does not consume ->prev.
In addition to removing the temporary disabling of VMCLEAR, open code
loaded_vmcs_init() in __loaded_vmcs_clear() and reorder VMCLEAR so that
the VMCS is deleted from the list only after it's been VMCLEAR'd.
Deleting the VMCS before VMCLEAR would allow a race where the NMI
shootdown could arrive between list_del() and vmcs_clear() and thus
neither flow would execute a successful VMCLEAR. Alternatively, more
code could be moved into loaded_vmcs_init(), but that gets rather silly
as the only other user, alloc_loaded_vmcs(), doesn't need the smp_wmb()
and would need to work around the list_del().
Update the smp_*() comments related to the list manipulation, and
opportunistically reword them to improve clarity.
[*] https://patchwork.kernel.org/patch/1675731/#3720461
Fixes: 8f536b7697a0 ("KVM: VMX: provide the vmclear function and a bitmap to support VMCLEAR in kdump")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Message-Id: <20200321193751.24985-2-sean.j.christopherson@intel.com>
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 67 ++++++++++++-----------------------------------------
1 file changed, 16 insertions(+), 51 deletions(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1674,43 +1674,15 @@ static void vmcs_load(struct vmcs *vmcs)
}
#ifdef CONFIG_KEXEC_CORE
-/*
- * This bitmap is used to indicate whether the vmclear
- * operation is enabled on all cpus. All disabled by
- * default.
- */
-static cpumask_t crash_vmclear_enabled_bitmap = CPU_MASK_NONE;
-
-static inline void crash_enable_local_vmclear(int cpu)
-{
- cpumask_set_cpu(cpu, &crash_vmclear_enabled_bitmap);
-}
-
-static inline void crash_disable_local_vmclear(int cpu)
-{
- cpumask_clear_cpu(cpu, &crash_vmclear_enabled_bitmap);
-}
-
-static inline int crash_local_vmclear_enabled(int cpu)
-{
- return cpumask_test_cpu(cpu, &crash_vmclear_enabled_bitmap);
-}
-
static void crash_vmclear_local_loaded_vmcss(void)
{
int cpu = raw_smp_processor_id();
struct loaded_vmcs *v;
- if (!crash_local_vmclear_enabled(cpu))
- return;
-
list_for_each_entry(v, &per_cpu(loaded_vmcss_on_cpu, cpu),
loaded_vmcss_on_cpu_link)
vmcs_clear(v->vmcs);
}
-#else
-static inline void crash_enable_local_vmclear(int cpu) { }
-static inline void crash_disable_local_vmclear(int cpu) { }
#endif /* CONFIG_KEXEC_CORE */
static void __loaded_vmcs_clear(void *arg)
@@ -1722,19 +1694,24 @@ static void __loaded_vmcs_clear(void *ar
return; /* vcpu migration can race with cpu offline */
if (per_cpu(current_vmcs, cpu) == loaded_vmcs->vmcs)
per_cpu(current_vmcs, cpu) = NULL;
- crash_disable_local_vmclear(cpu);
+
+ vmcs_clear(loaded_vmcs->vmcs);
+ if (loaded_vmcs->shadow_vmcs && loaded_vmcs->launched)
+ vmcs_clear(loaded_vmcs->shadow_vmcs);
+
list_del(&loaded_vmcs->loaded_vmcss_on_cpu_link);
/*
- * we should ensure updating loaded_vmcs->loaded_vmcss_on_cpu_link
- * is before setting loaded_vmcs->vcpu to -1 which is done in
- * loaded_vmcs_init. Otherwise, other cpu can see vcpu = -1 fist
- * then adds the vmcs into percpu list before it is deleted.
+ * Ensure all writes to loaded_vmcs, including deleting it from its
+ * current percpu list, complete before setting loaded_vmcs->vcpu to
+ * -1, otherwise a different cpu can see vcpu == -1 first and add
+ * loaded_vmcs to its percpu list before it's deleted from this cpu's
+ * list. Pairs with the smp_rmb() in vmx_vcpu_load_vmcs().
*/
smp_wmb();
- loaded_vmcs_init(loaded_vmcs);
- crash_enable_local_vmclear(cpu);
+ loaded_vmcs->cpu = -1;
+ loaded_vmcs->launched = 0;
}
static void loaded_vmcs_clear(struct loaded_vmcs *loaded_vmcs)
@@ -2497,18 +2474,17 @@ static void vmx_vcpu_load(struct kvm_vcp
if (!already_loaded) {
loaded_vmcs_clear(vmx->loaded_vmcs);
local_irq_disable();
- crash_disable_local_vmclear(cpu);
/*
- * Read loaded_vmcs->cpu should be before fetching
- * loaded_vmcs->loaded_vmcss_on_cpu_link.
- * See the comments in __loaded_vmcs_clear().
+ * Ensure loaded_vmcs->cpu is read before adding loaded_vmcs to
+ * this cpu's percpu list, otherwise it may not yet be deleted
+ * from its previous cpu's percpu list. Pairs with the
+ * smb_wmb() in __loaded_vmcs_clear().
*/
smp_rmb();
list_add(&vmx->loaded_vmcs->loaded_vmcss_on_cpu_link,
&per_cpu(loaded_vmcss_on_cpu, cpu));
- crash_enable_local_vmclear(cpu);
local_irq_enable();
}
@@ -3804,17 +3780,6 @@ static int hardware_enable(void)
INIT_LIST_HEAD(&per_cpu(blocked_vcpu_on_cpu, cpu));
spin_lock_init(&per_cpu(blocked_vcpu_on_cpu_lock, cpu));
- /*
- * Now we can enable the vmclear operation in kdump
- * since the loaded_vmcss_on_cpu list on this cpu
- * has been initialized.
- *
- * Though the cpu is not in VMX operation now, there
- * is no problem to enable the vmclear operation
- * for the loaded_vmcss_on_cpu list is empty!
- */
- crash_enable_local_vmclear(cpu);
-
rdmsrl(MSR_IA32_FEATURE_CONTROL, old);
test_bits = FEATURE_CONTROL_LOCKED;
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 062/199] KVM: VMX: fix crash cleanup when KVM wasnt used
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (60 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 061/199] KVM: VMX: Always VMCLEAR in-use VMCSes during crash with kexec support Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 063/199] CIFS: Fix bug which the return value by asynchronous read is error Greg Kroah-Hartman
` (68 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vitaly Kuznetsov,
Sean Christopherson, Paolo Bonzini
From: Vitaly Kuznetsov <vkuznets@redhat.com>
commit dbef2808af6c594922fe32833b30f55f35e9da6d upstream.
If KVM wasn't used at all before we crash the cleanup procedure fails with
BUG: unable to handle page fault for address: ffffffffffffffc8
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 23215067 P4D 23215067 PUD 23217067 PMD 0
Oops: 0000 [#8] SMP PTI
CPU: 0 PID: 3542 Comm: bash Kdump: loaded Tainted: G D 5.6.0-rc2+ #823
RIP: 0010:crash_vmclear_local_loaded_vmcss.cold+0x19/0x51 [kvm_intel]
The root cause is that loaded_vmcss_on_cpu list is not yet initialized,
we initialize it in hardware_enable() but this only happens when we start
a VM.
Previously, we used to have a bitmap with enabled CPUs and that was
preventing [masking] the issue.
Initialized loaded_vmcss_on_cpu list earlier, right before we assign
crash_vmclear_loaded_vmcss pointer. blocked_vcpu_on_cpu list and
blocked_vcpu_on_cpu_lock are moved altogether for consistency.
Fixes: 31603d4fc2bb ("KVM: VMX: Always VMCLEAR in-use VMCSes during crash with kexec support")
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20200401081348.1345307-1-vkuznets@redhat.com>
Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3776,10 +3776,6 @@ static int hardware_enable(void)
if (cr4_read_shadow() & X86_CR4_VMXE)
return -EBUSY;
- INIT_LIST_HEAD(&per_cpu(loaded_vmcss_on_cpu, cpu));
- INIT_LIST_HEAD(&per_cpu(blocked_vcpu_on_cpu, cpu));
- spin_lock_init(&per_cpu(blocked_vcpu_on_cpu_lock, cpu));
-
rdmsrl(MSR_IA32_FEATURE_CONTROL, old);
test_bits = FEATURE_CONTROL_LOCKED;
@@ -12900,7 +12896,7 @@ module_exit(vmx_exit)
static int __init vmx_init(void)
{
- int r;
+ int r, cpu;
r = kvm_init(&vmx_x86_ops, sizeof(struct vcpu_vmx),
__alignof__(struct vcpu_vmx), THIS_MODULE);
@@ -12922,6 +12918,12 @@ static int __init vmx_init(void)
}
}
+ for_each_possible_cpu(cpu) {
+ INIT_LIST_HEAD(&per_cpu(loaded_vmcss_on_cpu, cpu));
+ INIT_LIST_HEAD(&per_cpu(blocked_vcpu_on_cpu, cpu));
+ spin_lock_init(&per_cpu(blocked_vcpu_on_cpu_lock, cpu));
+ }
+
#ifdef CONFIG_KEXEC_CORE
rcu_assign_pointer(crash_vmclear_loaded_vmcss,
crash_vmclear_local_loaded_vmcss);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 063/199] CIFS: Fix bug which the return value by asynchronous read is error
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (61 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 062/199] KVM: VMX: fix crash cleanup when KVM wasnt used Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 064/199] btrfs: drop block from cache on error in relocation Greg Kroah-Hartman
` (67 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yilu Lin, Steve French, Ronnie Sahlberg
From: Yilu Lin <linyilu@huawei.com>
commit 97adda8b3ab703de8e4c8d27646ddd54fe22879c upstream.
This patch is used to fix the bug in collect_uncached_read_data()
that rc is automatically converted from a signed number to an
unsigned number when the CIFS asynchronous read fails.
It will cause ctx->rc is error.
Example:
Share a directory and create a file on the Windows OS.
Mount the directory to the Linux OS using CIFS.
On the CIFS client of the Linux OS, invoke the pread interface to
deliver the read request.
The size of the read length plus offset of the read request is greater
than the maximum file size.
In this case, the CIFS server on the Windows OS returns a failure
message (for example, the return value of
smb2.nt_status is STATUS_INVALID_PARAMETER).
After receiving the response message, the CIFS client parses
smb2.nt_status to STATUS_INVALID_PARAMETER
and converts it to the Linux error code (rdata->result=-22).
Then the CIFS client invokes the collect_uncached_read_data function to
assign the value of rdata->result to rc, that is, rc=rdata->result=-22.
The type of the ctx->total_len variable is unsigned integer,
the type of the rc variable is integer, and the type of
the ctx->rc variable is ssize_t.
Therefore, during the ternary operation, the value of rc is
automatically converted to an unsigned number. The final result is
ctx->rc=4294967274. However, the expected result is ctx->rc=-22.
Signed-off-by: Yilu Lin <linyilu@huawei.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
CC: Stable <stable@vger.kernel.org>
Acked-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -3303,7 +3303,7 @@ again:
if (rc == -ENODATA)
rc = 0;
- ctx->rc = (rc == 0) ? ctx->total_len : rc;
+ ctx->rc = (rc == 0) ? (ssize_t)ctx->total_len : rc;
mutex_unlock(&ctx->aio_mutex);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 064/199] btrfs: drop block from cache on error in relocation
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (62 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 063/199] CIFS: Fix bug which the return value by asynchronous read is error Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 065/199] crypto: mxs-dcp - fix scatterlist linearization for hash Greg Kroah-Hartman
` (66 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Qu Wenruo, Josef Bacik, David Sterba
From: Josef Bacik <josef@toxicpanda.com>
commit 8e19c9732ad1d127b5575a10f4fbcacf740500ff upstream.
If we have an error while building the backref tree in relocation we'll
process all the pending edges and then free the node. However if we
integrated some edges into the cache we'll lose our link to those edges
by simply freeing this node, which means we'll leak memory and
references to any roots that we've found.
Instead we need to use remove_backref_node(), which walks through all of
the edges that are still linked to this node and free's them up and
drops any root references we may be holding.
CC: stable@vger.kernel.org # 4.9+
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/relocation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1194,7 +1194,7 @@ out:
free_backref_node(cache, lower);
}
- free_backref_node(cache, node);
+ remove_backref_node(cache, node);
return ERR_PTR(err);
}
ASSERT(!node || !node->detached);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 065/199] crypto: mxs-dcp - fix scatterlist linearization for hash
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (63 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 064/199] btrfs: drop block from cache on error in relocation Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 066/199] ALSA: hda: Initialize power_state field properly Greg Kroah-Hartman
` (65 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rosioru Dragos, Horia Geantă,
Herbert Xu
From: Rosioru Dragos <dragos.rosioru@nxp.com>
commit fa03481b6e2e82355c46644147b614f18c7a8161 upstream.
The incorrect traversal of the scatterlist, during the linearization phase
lead to computing the hash value of the wrong input buffer.
New implementation uses scatterwalk_map_and_copy()
to address this issue.
Cc: <stable@vger.kernel.org>
Fixes: 15b59e7c3733 ("crypto: mxs - Add Freescale MXS DCP driver")
Signed-off-by: Rosioru Dragos <dragos.rosioru@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/crypto/mxs-dcp.c | 54 ++++++++++++++++++++++-------------------------
1 file changed, 26 insertions(+), 28 deletions(-)
--- a/drivers/crypto/mxs-dcp.c
+++ b/drivers/crypto/mxs-dcp.c
@@ -25,6 +25,7 @@
#include <crypto/sha.h>
#include <crypto/internal/hash.h>
#include <crypto/internal/skcipher.h>
+#include <crypto/scatterwalk.h>
#define DCP_MAX_CHANS 4
#define DCP_BUF_SZ PAGE_SIZE
@@ -621,49 +622,46 @@ static int dcp_sha_req_to_buf(struct cry
struct dcp_async_ctx *actx = crypto_ahash_ctx(tfm);
struct dcp_sha_req_ctx *rctx = ahash_request_ctx(req);
struct hash_alg_common *halg = crypto_hash_alg_common(tfm);
- const int nents = sg_nents(req->src);
uint8_t *in_buf = sdcp->coh->sha_in_buf;
uint8_t *out_buf = sdcp->coh->sha_out_buf;
- uint8_t *src_buf;
-
struct scatterlist *src;
- unsigned int i, len, clen;
+ unsigned int i, len, clen, oft = 0;
int ret;
int fin = rctx->fini;
if (fin)
rctx->fini = 0;
- for_each_sg(req->src, src, nents, i) {
- src_buf = sg_virt(src);
- len = sg_dma_len(src);
+ src = req->src;
+ len = req->nbytes;
- do {
- if (actx->fill + len > DCP_BUF_SZ)
- clen = DCP_BUF_SZ - actx->fill;
- else
- clen = len;
+ while (len) {
+ if (actx->fill + len > DCP_BUF_SZ)
+ clen = DCP_BUF_SZ - actx->fill;
+ else
+ clen = len;
- memcpy(in_buf + actx->fill, src_buf, clen);
- len -= clen;
- src_buf += clen;
- actx->fill += clen;
+ scatterwalk_map_and_copy(in_buf + actx->fill, src, oft, clen,
+ 0);
- /*
- * If we filled the buffer and still have some
- * more data, submit the buffer.
- */
- if (len && actx->fill == DCP_BUF_SZ) {
- ret = mxs_dcp_run_sha(req);
- if (ret)
- return ret;
- actx->fill = 0;
- rctx->init = 0;
- }
- } while (len);
+ len -= clen;
+ oft += clen;
+ actx->fill += clen;
+
+ /*
+ * If we filled the buffer and still have some
+ * more data, submit the buffer.
+ */
+ if (len && actx->fill == DCP_BUF_SZ) {
+ ret = mxs_dcp_run_sha(req);
+ if (ret)
+ return ret;
+ actx->fill = 0;
+ rctx->init = 0;
+ }
}
if (fin) {
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 066/199] ALSA: hda: Initialize power_state field properly
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (64 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 065/199] crypto: mxs-dcp - fix scatterlist linearization for hash Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 067/199] net: rtnl_configure_link: fix dev flags changes arg to __dev_notify_flags Greg Kroah-Hartman
` (64 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai, Guenter Roeck
From: Takashi Iwai <tiwai@suse.de>
commit 183ab39eb0ea9879bb68422a83e65f750f3192f0 upstream.
The recent commit 98081ca62cba ("ALSA: hda - Record the current power
state before suspend/resume calls") made the HD-audio driver to store
the PM state in power_state field. This forgot, however, the
initialization at power up. Although the codec drivers usually don't
need to refer to this field in the normal operation, let's initialize
it properly for consistency.
Fixes: 98081ca62cba ("ALSA: hda - Record the current power state before suspend/resume calls")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/hda_codec.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -942,6 +942,7 @@ int snd_hda_codec_new(struct hda_bus *bu
/* power-up all before initialization */
hda_set_power_state(codec, AC_PWRST_D0);
+ codec->core.dev.power.power_state = PMSG_ON;
snd_hda_codec_proc_new(codec);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 067/199] net: rtnl_configure_link: fix dev flags changes arg to __dev_notify_flags
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (65 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 066/199] ALSA: hda: Initialize power_state field properly Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 068/199] powerpc/pseries: Drop pointless static qualifier in vpa_debugfs_init() Greg Kroah-Hartman
` (63 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Liam mcbirnie, Roopa Prabhu,
David S. Miller, Guenter Roeck
From: Roopa Prabhu <roopa@cumulusnetworks.com>
commit 56a49d7048703f5ffdb84d3a0ee034108fba6850 upstream.
This fix addresses https://bugzilla.kernel.org/show_bug.cgi?id=201071
Commit 5025f7f7d506 wrongly relied on __dev_change_flags to notify users of
dev flag changes in the case when dev->rtnl_link_state = RTNL_LINK_INITIALIZED.
Fix it by indicating flag changes explicitly to __dev_notify_flags.
Fixes: 5025f7f7d506 ("rtnetlink: add rtnl_link_state check in rtnl_configure_link")
Reported-By: Liam mcbirnie <liam.mcbirnie@boeing.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/rtnetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2424,7 +2424,7 @@ int rtnl_configure_link(struct net_devic
}
if (dev->rtnl_link_state == RTNL_LINK_INITIALIZED) {
- __dev_notify_flags(dev, old_flags, 0U);
+ __dev_notify_flags(dev, old_flags, (old_flags ^ dev->flags));
} else {
dev->rtnl_link_state = RTNL_LINK_INITIALIZED;
__dev_notify_flags(dev, old_flags, ~0U);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 068/199] powerpc/pseries: Drop pointless static qualifier in vpa_debugfs_init()
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (66 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 067/199] net: rtnl_configure_link: fix dev flags changes arg to __dev_notify_flags Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 069/199] x86/speculation: Remove redundant arch_smt_update() invocation Greg Kroah-Hartman
` (62 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, YueHaibing, Daniel Axtens,
Michael Ellerman, Guenter Roeck
From: YueHaibing <yuehaibing@huawei.com>
commit 11dd34f3eae5a468013bb161a1dcf1fecd2ca321 upstream.
There is no need to have the 'struct dentry *vpa_dir' variable static
since new value always be assigned before use it.
Fixes: c6c26fb55e8e ("powerpc/pseries: Export raw per-CPU VPA data via debugfs")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190218125644.87448-1-yuehaibing@huawei.com
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/platforms/pseries/lpar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -1060,7 +1060,7 @@ static int __init vpa_debugfs_init(void)
{
char name[16];
long i;
- static struct dentry *vpa_dir;
+ struct dentry *vpa_dir;
if (!firmware_has_feature(FW_FEATURE_SPLPAR))
return 0;
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 069/199] x86/speculation: Remove redundant arch_smt_update() invocation
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (67 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 068/199] powerpc/pseries: Drop pointless static qualifier in vpa_debugfs_init() Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 070/199] tools: gpio: Fix out-of-tree build regression Greg Kroah-Hartman
` (61 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Zhenzhong Duan, Thomas Gleixner,
konrad.wilk, dwmw, bp, srinivas.eeda, peterz, hpa, Guenter Roeck
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
commit 34d66caf251df91ff27b24a3a786810d29989eca upstream.
With commit a74cfffb03b7 ("x86/speculation: Rework SMT state change"),
arch_smt_update() is invoked from each individual CPU hotplug function.
Therefore the extra arch_smt_update() call in the sysfs SMT control is
redundant.
Fixes: a74cfffb03b7 ("x86/speculation: Rework SMT state change")
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: <konrad.wilk@oracle.com>
Cc: <dwmw@amazon.co.uk>
Cc: <bp@suse.de>
Cc: <srinivas.eeda@oracle.com>
Cc: <peterz@infradead.org>
Cc: <hpa@zytor.com>
Link: https://lkml.kernel.org/r/e2e064f2-e8ef-42ca-bf4f-76b612964752@default
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/cpu.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2089,10 +2089,8 @@ int cpuhp_smt_disable(enum cpuhp_smt_con
*/
cpuhp_offline_cpu_device(cpu);
}
- if (!ret) {
+ if (!ret)
cpu_smt_control = ctrlval;
- arch_smt_update();
- }
cpu_maps_update_done();
return ret;
}
@@ -2103,7 +2101,6 @@ int cpuhp_smt_enable(void)
cpu_maps_update_begin();
cpu_smt_control = CPU_SMT_ENABLED;
- arch_smt_update();
for_each_present_cpu(cpu) {
/* Skip online CPUs and CPUs on offline nodes */
if (cpu_online(cpu) || !node_online(cpu_to_node(cpu)))
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 070/199] tools: gpio: Fix out-of-tree build regression
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (68 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 069/199] x86/speculation: Remove redundant arch_smt_update() invocation Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 071/199] mm: Use fixed constant in page_frag_alloc instead of size + 1 Greg Kroah-Hartman
` (60 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Laura Abbott, Anssi Hannula,
Bartosz Golaszewski, Linus Walleij
From: Anssi Hannula <anssi.hannula@bitwise.fi>
commit 82f04bfe2aff428b063eefd234679b2d693228ed upstream.
Commit 0161a94e2d1c7 ("tools: gpio: Correctly add make dependencies for
gpio_utils") added a make rule for gpio-utils-in.o but used $(output)
instead of the correct $(OUTPUT) for the output directory, breaking
out-of-tree build (O=xx) with the following error:
No rule to make target 'out/tools/gpio/gpio-utils-in.o', needed by 'out/tools/gpio/lsgpio-in.o'. Stop.
Fix that.
Fixes: 0161a94e2d1c ("tools: gpio: Correctly add make dependencies for gpio_utils")
Cc: <stable@vger.kernel.org>
Cc: Laura Abbott <labbott@redhat.com>
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Link: https://lore.kernel.org/r/20200325103154.32235-1-anssi.hannula@bitwise.fi
Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/gpio/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/gpio/Makefile
+++ b/tools/gpio/Makefile
@@ -35,7 +35,7 @@ $(OUTPUT)include/linux/gpio.h: ../../inc
prepare: $(OUTPUT)include/linux/gpio.h
-GPIO_UTILS_IN := $(output)gpio-utils-in.o
+GPIO_UTILS_IN := $(OUTPUT)gpio-utils-in.o
$(GPIO_UTILS_IN): prepare FORCE
$(Q)$(MAKE) $(build)=gpio-utils
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 071/199] mm: Use fixed constant in page_frag_alloc instead of size + 1
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (69 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 070/199] tools: gpio: Fix out-of-tree build regression Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 072/199] dm verity fec: fix memory leak in verity_fec_dtr Greg Kroah-Hartman
` (59 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexander Duyck, David S. Miller,
Guenter Roeck
From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
commit 8644772637deb121f7ac2df690cbf83fa63d3b70 upstream.
This patch replaces the size + 1 value introduced with the recent fix for 1
byte allocs with a constant value.
The idea here is to reduce code overhead as the previous logic would have
to read size into a register, then increment it, and write it back to
whatever field was being used. By using a constant we can avoid those
memory reads and arithmetic operations in favor of just encoding the
maximum value into the operation itself.
Fixes: 2c2ade81741c ("mm: page_alloc: fix ref bias in page_frag_alloc() for 1-byte allocs")
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/page_alloc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4325,11 +4325,11 @@ refill:
/* Even if we own the page, we do not use atomic_set().
* This would break get_page_unless_zero() users.
*/
- page_ref_add(page, size);
+ page_ref_add(page, PAGE_FRAG_CACHE_MAX_SIZE);
/* reset page count bias and offset to start of new frag */
nc->pfmemalloc = page_is_pfmemalloc(page);
- nc->pagecnt_bias = size + 1;
+ nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
nc->offset = size;
}
@@ -4345,10 +4345,10 @@ refill:
size = nc->size;
#endif
/* OK, page count is 0, we can safely set it */
- set_page_count(page, size + 1);
+ set_page_count(page, PAGE_FRAG_CACHE_MAX_SIZE + 1);
/* reset page count bias and offset to start of new frag */
- nc->pagecnt_bias = size + 1;
+ nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
offset = size - fragsz;
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 072/199] dm verity fec: fix memory leak in verity_fec_dtr
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (70 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 071/199] mm: Use fixed constant in page_frag_alloc instead of size + 1 Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 073/199] scsi: zfcp: fix missing erp_lock in port recovery trigger for point-to-point Greg Kroah-Hartman
` (58 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Harshini Shetty, Mike Snitzer
From: Shetty, Harshini X (EXT-Sony Mobile) <Harshini.X.Shetty@sony.com>
commit 75fa601934fda23d2f15bf44b09c2401942d8e15 upstream.
Fix below kmemleak detected in verity_fec_ctr. output_pool is
allocated for each dm-verity-fec device. But it is not freed when
dm-table for the verity target is removed. Hence free the output
mempool in destructor function verity_fec_dtr.
unreferenced object 0xffffffffa574d000 (size 4096):
comm "init", pid 1667, jiffies 4294894890 (age 307.168s)
hex dump (first 32 bytes):
8e 36 00 98 66 a8 0b 9b 00 00 00 00 00 00 00 00 .6..f...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000060e82407>] __kmalloc+0x2b4/0x340
[<00000000dd99488f>] mempool_kmalloc+0x18/0x20
[<000000002560172b>] mempool_init_node+0x98/0x118
[<000000006c3574d2>] mempool_init+0x14/0x20
[<0000000008cb266e>] verity_fec_ctr+0x388/0x3b0
[<000000000887261b>] verity_ctr+0x87c/0x8d0
[<000000002b1e1c62>] dm_table_add_target+0x174/0x348
[<000000002ad89eda>] table_load+0xe4/0x328
[<000000001f06f5e9>] dm_ctl_ioctl+0x3b4/0x5a0
[<00000000bee5fbb7>] do_vfs_ioctl+0x5dc/0x928
[<00000000b475b8f5>] __arm64_sys_ioctl+0x70/0x98
[<000000005361e2e8>] el0_svc_common+0xa0/0x158
[<000000001374818f>] el0_svc_handler+0x6c/0x88
[<000000003364e9f4>] el0_svc+0x8/0xc
[<000000009d84cec9>] 0xffffffffffffffff
Fixes: a739ff3f543af ("dm verity: add support for forward error correction")
Depends-on: 6f1c819c219f7 ("dm: convert to bioset_init()/mempool_init()")
Cc: stable@vger.kernel.org
Signed-off-by: Harshini Shetty <harshini.x.shetty@sony.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-verity-fec.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/md/dm-verity-fec.c
+++ b/drivers/md/dm-verity-fec.c
@@ -552,6 +552,7 @@ void verity_fec_dtr(struct dm_verity *v)
mempool_destroy(f->rs_pool);
mempool_destroy(f->prealloc_pool);
mempool_destroy(f->extra_pool);
+ mempool_destroy(f->output_pool);
kmem_cache_destroy(f->cache);
if (f->data_bufio)
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 073/199] scsi: zfcp: fix missing erp_lock in port recovery trigger for point-to-point
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (71 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 072/199] dm verity fec: fix memory leak in verity_fec_dtr Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 074/199] arm64: armv8_deprecated: Fix undef_hook mask for thumb setend Greg Kroah-Hartman
` (57 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jens Remus, Benjamin Block,
Steffen Maier, Martin K. Petersen
From: Steffen Maier <maier@linux.ibm.com>
commit 819732be9fea728623e1ed84eba28def7384ad1f upstream.
v2.6.27 commit cc8c282963bd ("[SCSI] zfcp: Automatically attach remote
ports") introduced zfcp automatic port scan.
Before that, the user had to use the sysfs attribute "port_add" of an FCP
device (adapter) to add and open remote (target) ports, even for the remote
peer port in point-to-point topology. That code path did a proper port open
recovery trigger taking the erp_lock.
Since above commit, a new helper function zfcp_erp_open_ptp_port()
performed an UNlocked port open recovery trigger. This can race with other
parallel recovery triggers. In zfcp_erp_action_enqueue() this could corrupt
e.g. adapter->erp_total_count or adapter->erp_ready_head.
As already found for fabric topology in v4.17 commit fa89adba1941 ("scsi:
zfcp: fix infinite iteration on ERP ready list"), there was an endless loop
during tracing of rport (un)block. A subsequent v4.18 commit 9e156c54ace3
("scsi: zfcp: assert that the ERP lock is held when tracing a recovery
trigger") introduced a lockdep assertion for that case.
As a side effect, that lockdep assertion now uncovered the unlocked code
path for PtP. It is from within an adapter ERP action:
zfcp_erp_strategy[1479] intentionally DROPs erp lock around
zfcp_erp_strategy_do_action()
zfcp_erp_strategy_do_action[1441] NO erp lock
zfcp_erp_adapter_strategy[876] NO erp lock
zfcp_erp_adapter_strategy_open[855] NO erp lock
zfcp_erp_adapter_strategy_open_fsf[806]NO erp lock
zfcp_erp_adapter_strat_fsf_xconf[772] erp lock only around
zfcp_erp_action_to_running(),
BUT *_not_* around
zfcp_erp_enqueue_ptp_port()
zfcp_erp_enqueue_ptp_port[728] BUG: *_not_* taking erp lock
_zfcp_erp_port_reopen[432] assumes to be called with erp lock
zfcp_erp_action_enqueue[314] assumes to be called with erp lock
zfcp_dbf_rec_trig[288] _checks_ to be called with erp lock:
lockdep_assert_held(&adapter->erp_lock);
It causes the following lockdep warning:
WARNING: CPU: 2 PID: 775 at drivers/s390/scsi/zfcp_dbf.c:288
zfcp_dbf_rec_trig+0x16a/0x188
no locks held by zfcperp0.0.17c0/775.
Fix this by using the proper locked recovery trigger helper function.
Link: https://lore.kernel.org/r/20200312174505.51294-2-maier@linux.ibm.com
Fixes: cc8c282963bd ("[SCSI] zfcp: Automatically attach remote ports")
Cc: <stable@vger.kernel.org> #v2.6.27+
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/s390/scsi/zfcp_erp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/s390/scsi/zfcp_erp.c
+++ b/drivers/s390/scsi/zfcp_erp.c
@@ -747,7 +747,7 @@ static void zfcp_erp_enqueue_ptp_port(st
adapter->peer_d_id);
if (IS_ERR(port)) /* error or port already attached */
return;
- _zfcp_erp_port_reopen(port, 0, "ereptp1");
+ zfcp_erp_port_reopen(port, 0, "ereptp1");
}
static int zfcp_erp_adapter_strat_fsf_xconf(struct zfcp_erp_action *erp_action)
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 074/199] arm64: armv8_deprecated: Fix undef_hook mask for thumb setend
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (72 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 073/199] scsi: zfcp: fix missing erp_lock in port recovery trigger for point-to-point Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 075/199] rtc: omap: Use define directive for PIN_CONFIG_ACTIVE_HIGH Greg Kroah-Hartman
` (56 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Suzuki K Poulose, Fredrik Strupe,
Catalin Marinas
From: Fredrik Strupe <fredrik@strupe.net>
commit fc2266011accd5aeb8ebc335c381991f20e26e33 upstream.
For thumb instructions, call_undef_hook() in traps.c first reads a u16,
and if the u16 indicates a T32 instruction (u16 >= 0xe800), a second
u16 is read, which then makes up the the lower half-word of a T32
instruction. For T16 instructions, the second u16 is not read,
which makes the resulting u32 opcode always have the upper half set to
0.
However, having the upper half of instr_mask in the undef_hook set to 0
masks out the upper half of all thumb instructions - both T16 and T32.
This results in trapped T32 instructions with the lower half-word equal
to the T16 encoding of setend (b650) being matched, even though the upper
half-word is not 0000 and thus indicates a T32 opcode.
An example of such a T32 instruction is eaa0b650, which should raise a
SIGILL since T32 instructions with an eaa prefix are unallocated as per
Arm ARM, but instead works as a SETEND because the second half-word is set
to b650.
This patch fixes the issue by extending instr_mask to include the
upper u32 half, which will still match T16 instructions where the upper
half is 0, but not T32 instructions.
Fixes: 2d888f48e056 ("arm64: Emulate SETEND for AArch32 tasks")
Cc: <stable@vger.kernel.org> # 4.0.x-
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Fredrik Strupe <fredrik@strupe.net>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/kernel/armv8_deprecated.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -607,7 +607,7 @@ static struct undef_hook setend_hooks[]
},
{
/* Thumb mode */
- .instr_mask = 0x0000fff7,
+ .instr_mask = 0xfffffff7,
.instr_val = 0x0000b650,
.pstate_mask = (COMPAT_PSR_T_BIT | COMPAT_PSR_MODE_MASK),
.pstate_val = (COMPAT_PSR_T_BIT | COMPAT_PSR_MODE_USR),
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 075/199] rtc: omap: Use define directive for PIN_CONFIG_ACTIVE_HIGH
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (73 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 074/199] arm64: armv8_deprecated: Fix undef_hook mask for thumb setend Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 076/199] NFS: Fix a page leak in nfs_destroy_unlinked_subrequests() Greg Kroah-Hartman
` (55 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nathan Chancellor, Alexandre Belloni
From: Nathan Chancellor <natechancellor@gmail.com>
commit c50156526a2f7176b50134e3e5fb108ba09791b2 upstream.
Clang warns when one enumerated type is implicitly converted to another:
drivers/rtc/rtc-omap.c:574:21: warning: implicit conversion from
enumeration type 'enum rtc_pin_config_param' to different enumeration
type 'enum pin_config_param' [-Wenum-conversion]
{"ti,active-high", PIN_CONFIG_ACTIVE_HIGH, 0},
~ ^~~~~~~~~~~~~~~~~~~~~~
drivers/rtc/rtc-omap.c:579:12: warning: implicit conversion from
enumeration type 'enum rtc_pin_config_param' to different enumeration
type 'enum pin_config_param' [-Wenum-conversion]
PCONFDUMP(PIN_CONFIG_ACTIVE_HIGH, "input active high", NULL, false),
~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded from
macro 'PCONFDUMP'
.param = a, .display = b, .format = c, .has_arg = d \
^
2 warnings generated.
It is expected that pinctrl drivers can extend pin_config_param because
of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
isn't an issue. Most drivers that take advantage of this define the
PIN_CONFIG variables as constants, rather than enumerated values. Do the
same thing here so that Clang no longer warns.
Link: https://github.com/ClangBuiltLinux/linux/issues/144
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/rtc/rtc-omap.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -559,9 +559,7 @@ static const struct pinctrl_ops rtc_pinc
.dt_free_map = pinconf_generic_dt_free_map,
};
-enum rtc_pin_config_param {
- PIN_CONFIG_ACTIVE_HIGH = PIN_CONFIG_END + 1,
-};
+#define PIN_CONFIG_ACTIVE_HIGH (PIN_CONFIG_END + 1)
static const struct pinconf_generic_params rtc_params[] = {
{"ti,active-high", PIN_CONFIG_ACTIVE_HIGH, 0},
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 076/199] NFS: Fix a page leak in nfs_destroy_unlinked_subrequests()
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (74 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 075/199] rtc: omap: Use define directive for PIN_CONFIG_ACTIVE_HIGH Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 077/199] ext4: fix a data race at inode->i_blocks Greg Kroah-Hartman
` (54 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Trond Myklebust
From: Trond Myklebust <trond.myklebust@hammerspace.com>
commit add42de31721fa29ed77a7ce388674d69f9d31a4 upstream.
When we detach a subrequest from the list, we must also release the
reference it holds to the parent.
Fixes: 5b2b5187fa85 ("NFS: Fix nfs_page_group_destroy() and nfs_lock_and_join_requests() race cases")
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfs/write.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -422,6 +422,7 @@ nfs_destroy_unlinked_subrequests(struct
}
subreq->wb_head = subreq;
+ nfs_release_request(old_head);
if (test_and_clear_bit(PG_INODE_REF, &subreq->wb_flags)) {
nfs_release_request(subreq);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 077/199] ext4: fix a data race at inode->i_blocks
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (75 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 076/199] NFS: Fix a page leak in nfs_destroy_unlinked_subrequests() Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 078/199] fs/filesystems.c: downgrade user-reachable WARN_ONCE() to pr_warn_once() Greg Kroah-Hartman
` (53 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Qian Cai, Theodore Tso, stable
From: Qian Cai <cai@lca.pw>
commit 28936b62e71e41600bab319f262ea9f9b1027629 upstream.
inode->i_blocks could be accessed concurrently as noticed by KCSAN,
BUG: KCSAN: data-race in ext4_do_update_inode [ext4] / inode_add_bytes
write to 0xffff9a00d4b982d0 of 8 bytes by task 22100 on cpu 118:
inode_add_bytes+0x65/0xf0
__inode_add_bytes at fs/stat.c:689
(inlined by) inode_add_bytes at fs/stat.c:702
ext4_mb_new_blocks+0x418/0xca0 [ext4]
ext4_ext_map_blocks+0x1a6b/0x27b0 [ext4]
ext4_map_blocks+0x1a9/0x950 [ext4]
_ext4_get_block+0xfc/0x270 [ext4]
ext4_get_block_unwritten+0x33/0x50 [ext4]
__block_write_begin_int+0x22e/0xae0
__block_write_begin+0x39/0x50
ext4_write_begin+0x388/0xb50 [ext4]
ext4_da_write_begin+0x35f/0x8f0 [ext4]
generic_perform_write+0x15d/0x290
ext4_buffered_write_iter+0x11f/0x210 [ext4]
ext4_file_write_iter+0xce/0x9e0 [ext4]
new_sync_write+0x29c/0x3b0
__vfs_write+0x92/0xa0
vfs_write+0x103/0x260
ksys_write+0x9d/0x130
__x64_sys_write+0x4c/0x60
do_syscall_64+0x91/0xb05
entry_SYSCALL_64_after_hwframe+0x49/0xbe
read to 0xffff9a00d4b982d0 of 8 bytes by task 8 on cpu 65:
ext4_do_update_inode+0x4a0/0xf60 [ext4]
ext4_inode_blocks_set at fs/ext4/inode.c:4815
ext4_mark_iloc_dirty+0xaf/0x160 [ext4]
ext4_mark_inode_dirty+0x129/0x3e0 [ext4]
ext4_convert_unwritten_extents+0x253/0x2d0 [ext4]
ext4_convert_unwritten_io_end_vec+0xc5/0x150 [ext4]
ext4_end_io_rsv_work+0x22c/0x350 [ext4]
process_one_work+0x54f/0xb90
worker_thread+0x80/0x5f0
kthread+0x1cd/0x1f0
ret_from_fork+0x27/0x50
4 locks held by kworker/u256:0/8:
#0: ffff9a025abc4328 ((wq_completion)ext4-rsv-conversion){+.+.}, at: process_one_work+0x443/0xb90
#1: ffffab5a862dbe20 ((work_completion)(&ei->i_rsv_conversion_work)){+.+.}, at: process_one_work+0x443/0xb90
#2: ffff9a025a9d0f58 (jbd2_handle){++++}, at: start_this_handle+0x1c1/0x9d0 [jbd2]
#3: ffff9a00d4b985d8 (&(&ei->i_raw_lock)->rlock){+.+.}, at: ext4_do_update_inode+0xaa/0xf60 [ext4]
irq event stamp: 3009267
hardirqs last enabled at (3009267): [<ffffffff980da9b7>] __find_get_block+0x107/0x790
hardirqs last disabled at (3009266): [<ffffffff980da8f9>] __find_get_block+0x49/0x790
softirqs last enabled at (3009230): [<ffffffff98a0034c>] __do_softirq+0x34c/0x57c
softirqs last disabled at (3009223): [<ffffffff97cc67a2>] irq_exit+0xa2/0xc0
Reported by Kernel Concurrency Sanitizer on:
CPU: 65 PID: 8 Comm: kworker/u256:0 Tainted: G L 5.6.0-rc2-next-20200221+ #7
Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
Workqueue: ext4-rsv-conversion ext4_end_io_rsv_work [ext4]
The plain read is outside of inode->i_lock critical section which
results in a data race. Fix it by adding READ_ONCE() there.
Link: https://lore.kernel.org/r/20200222043258.2279-1-cai@lca.pw
Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4981,7 +4981,7 @@ static int ext4_inode_blocks_set(handle_
struct ext4_inode_info *ei)
{
struct inode *inode = &(ei->vfs_inode);
- u64 i_blocks = inode->i_blocks;
+ u64 i_blocks = READ_ONCE(inode->i_blocks);
struct super_block *sb = inode->i_sb;
if (i_blocks <= ~0U) {
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 078/199] fs/filesystems.c: downgrade user-reachable WARN_ONCE() to pr_warn_once()
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (76 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 077/199] ext4: fix a data race at inode->i_blocks Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 079/199] ocfs2: no need try to truncate file beyond i_size Greg Kroah-Hartman
` (52 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Biggers, Andrew Morton,
Jessica Yu, Alexei Starovoitov, Jeff Vander Stoep, Kees Cook,
Luis Chamberlain, NeilBrown, Linus Torvalds
From: Eric Biggers <ebiggers@google.com>
commit 26c5d78c976ca298e59a56f6101a97b618ba3539 upstream.
After request_module(), nothing is stopping the module from being
unloaded until someone takes a reference to it via try_get_module().
The WARN_ONCE() in get_fs_type() is thus user-reachable, via userspace
running 'rmmod' concurrently.
Since WARN_ONCE() is for kernel bugs only, not for user-reachable
situations, downgrade this warning to pr_warn_once().
Keep it printed once only, since the intent of this warning is to detect
a bug in modprobe at boot time. Printing the warning more than once
wouldn't really provide any useful extra information.
Fixes: 41124db869b7 ("fs: warn in case userspace lied about modprobe return")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Jessica Yu <jeyu@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jeff Vander Stoep <jeffv@google.com>
Cc: Jessica Yu <jeyu@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: NeilBrown <neilb@suse.com>
Cc: <stable@vger.kernel.org> [4.13+]
Link: http://lkml.kernel.org/r/20200312202552.241885-3-ebiggers@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/filesystems.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/filesystems.c
+++ b/fs/filesystems.c
@@ -279,7 +279,9 @@ struct file_system_type *get_fs_type(con
fs = __get_fs_type(name, len);
if (!fs && (request_module("fs-%.*s", len, name) == 0)) {
fs = __get_fs_type(name, len);
- WARN_ONCE(!fs, "request_module fs-%.*s succeeded, but still no fs?\n", len, name);
+ if (!fs)
+ pr_warn_once("request_module fs-%.*s succeeded, but still no fs?\n",
+ len, name);
}
if (dot && fs && !(fs->fs_flags & FS_HAS_SUBTYPE)) {
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 079/199] ocfs2: no need try to truncate file beyond i_size
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (77 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 078/199] fs/filesystems.c: downgrade user-reachable WARN_ONCE() to pr_warn_once() Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 080/199] perf tools: Support Python 3.8+ in Makefile Greg Kroah-Hartman
` (51 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Changwei Ge, Andrew Morton,
Joseph Qi, Mark Fasheh, Joel Becker, Junxiao Bi, Changwei Ge,
Gang He, Jun Piao, Linus Torvalds
From: Changwei Ge <chge@linux.alibaba.com>
commit 783fda856e1034dee90a873f7654c418212d12d7 upstream.
Linux fallocate(2) with FALLOC_FL_PUNCH_HOLE mode set, its offset can
exceed the inode size. Ocfs2 now doesn't allow that offset beyond inode
size. This restriction is not necessary and violates fallocate(2)
semantics.
If fallocate(2) offset is beyond inode size, just return success and do
nothing further.
Otherwise, ocfs2 will crash the kernel.
kernel BUG at fs/ocfs2//alloc.c:7264!
ocfs2_truncate_inline+0x20f/0x360 [ocfs2]
ocfs2_remove_inode_range+0x23c/0xcb0 [ocfs2]
__ocfs2_change_file_space+0x4a5/0x650 [ocfs2]
ocfs2_fallocate+0x83/0xa0 [ocfs2]
vfs_fallocate+0x148/0x230
SyS_fallocate+0x48/0x80
do_syscall_64+0x79/0x170
Signed-off-by: Changwei Ge <chge@linux.alibaba.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Gang He <ghe@suse.com>
Cc: Jun Piao <piaojun@huawei.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200407082754.17565-1-chge@linux.alibaba.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ocfs2/alloc.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/fs/ocfs2/alloc.c
+++ b/fs/ocfs2/alloc.c
@@ -7240,6 +7240,10 @@ int ocfs2_truncate_inline(struct inode *
struct ocfs2_dinode *di = (struct ocfs2_dinode *)di_bh->b_data;
struct ocfs2_inline_data *idata = &di->id2.i_data;
+ /* No need to punch hole beyond i_size. */
+ if (start >= i_size_read(inode))
+ return 0;
+
if (end > i_size_read(inode))
end = i_size_read(inode);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 080/199] perf tools: Support Python 3.8+ in Makefile
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (78 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 079/199] ocfs2: no need try to truncate file beyond i_size Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 081/199] s390/diag: fix display of diagnose call statistics Greg Kroah-Hartman
` (50 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sam Lunt, He Zhe, Jiri Olsa,
Alexander Shishkin, Mark Rutland, Namhyung Kim, Peter Zijlstra,
trivial, stable, Arnaldo Carvalho de Melo
From: Sam Lunt <samueljlunt@gmail.com>
commit b9c9ce4e598e012ca7c1813fae2f4d02395807de upstream.
Python 3.8 changed the output of 'python-config --ldflags' to no longer
include the '-lpythonX.Y' flag (this apparently fixed an issue loading
modules with a statically linked Python executable). The libpython
feature check in linux/build/feature fails if the Python library is not
included in FEATURE_CHECK_LDFLAGS-libpython variable.
This adds a check in the Makefile to determine if PYTHON_CONFIG accepts
the '--embed' flag and passes that flag alongside '--ldflags' if so.
tools/perf is the only place the libpython feature check is used.
Signed-off-by: Sam Lunt <samuel.j.lunt@gmail.com>
Tested-by: He Zhe <zhe.he@windriver.com>
Link: http://lore.kernel.org/lkml/c56be2e1-8111-9dfe-8298-f7d0f9ab7431@windriver.com
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: trivial@kernel.org
Cc: stable@kernel.org
Link: http://lore.kernel.org/lkml/20200131181123.tmamivhq4b7uqasr@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/Makefile.config | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -179,8 +179,17 @@ strip-libs = $(filter-out -l%,$(1))
PYTHON_CONFIG_SQ := $(call shell-sq,$(PYTHON_CONFIG))
+# Python 3.8 changed the output of `python-config --ldflags` to not include the
+# '-lpythonX.Y' flag unless '--embed' is also passed. The feature check for
+# libpython fails if that flag is not included in LDFLAGS
+ifeq ($(shell $(PYTHON_CONFIG_SQ) --ldflags --embed 2>&1 1>/dev/null; echo $$?), 0)
+ PYTHON_CONFIG_LDFLAGS := --ldflags --embed
+else
+ PYTHON_CONFIG_LDFLAGS := --ldflags
+endif
+
ifdef PYTHON_CONFIG
- PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
+ PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) $(PYTHON_CONFIG_LDFLAGS) 2>/dev/null)
PYTHON_EMBED_LDFLAGS := $(call strip-libs,$(PYTHON_EMBED_LDOPTS))
PYTHON_EMBED_LIBADD := $(call grep-libs,$(PYTHON_EMBED_LDOPTS)) -lutil
PYTHON_EMBED_CCOPTS := $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 081/199] s390/diag: fix display of diagnose call statistics
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (79 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 080/199] perf tools: Support Python 3.8+ in Makefile Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 082/199] Input: i8042 - add Acer Aspire 5738z to nomux list Greg Kroah-Hartman
` (49 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michael Mueller, Heiko Carstens,
Vasily Gorbik
From: Michael Mueller <mimu@linux.ibm.com>
commit 6c7c851f1b666a8a455678a0b480b9162de86052 upstream.
Show the full diag statistic table and not just parts of it.
The issue surfaced in a KVM guest with a number of vcpus
defined smaller than NR_DIAG_STAT.
Fixes: 1ec2772e0c3c ("s390/diag: add a statistic for diagnose calls")
Cc: stable@vger.kernel.org
Signed-off-by: Michael Mueller <mimu@linux.ibm.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/s390/kernel/diag.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/s390/kernel/diag.c
+++ b/arch/s390/kernel/diag.c
@@ -79,7 +79,7 @@ static int show_diag_stat(struct seq_fil
static void *show_diag_stat_start(struct seq_file *m, loff_t *pos)
{
- return *pos <= nr_cpu_ids ? (void *)((unsigned long) *pos + 1) : NULL;
+ return *pos <= NR_DIAG_STAT ? (void *)((unsigned long) *pos + 1) : NULL;
}
static void *show_diag_stat_next(struct seq_file *m, void *v, loff_t *pos)
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 082/199] Input: i8042 - add Acer Aspire 5738z to nomux list
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (80 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 081/199] s390/diag: fix display of diagnose call statistics Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 083/199] kmod: make request_module() return an error when autoloading is disabled Greg Kroah-Hartman
` (48 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hans de Goede, Dmitry Torokhov
From: Hans de Goede <hdegoede@redhat.com>
commit ebc68cedec4aead47d8d11623d013cca9bf8e825 upstream.
The Acer Aspire 5738z has a button to disable (and re-enable) the
touchpad next to the touchpad.
When this button is pressed a LED underneath indicates that the touchpad
is disabled (and an event is send to userspace and GNOME shows its
touchpad enabled / disable OSD thingie).
So far so good, but after re-enabling the touchpad it no longer works.
The laptop does not have an external ps2 port, so mux mode is not needed
and disabling mux mode fixes the touchpad no longer working after toggling
it off and back on again, so lets add this laptop model to the nomux list.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200331123947.318908-1-hdegoede@redhat.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/serio/i8042-x86ia64io.h | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -534,6 +534,17 @@ static const struct dmi_system_id __init
DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo LaVie Z"),
},
},
+ {
+ /*
+ * Acer Aspire 5738z
+ * Touchpad stops working in mux mode when dis- + re-enabled
+ * with the touchpad enable/disable toggle hotkey
+ */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5738"),
+ },
+ },
{ }
};
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 083/199] kmod: make request_module() return an error when autoloading is disabled
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (81 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 082/199] Input: i8042 - add Acer Aspire 5738z to nomux list Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 084/199] cpufreq: powernv: Fix use-after-free Greg Kroah-Hartman
` (47 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Biggers, Andrew Morton,
Kees Cook, Jessica Yu, Luis Chamberlain, Alexei Starovoitov,
Jeff Vander Stoep, Ben Hutchings, Josh Triplett, Linus Torvalds
From: Eric Biggers <ebiggers@google.com>
commit d7d27cfc5cf0766a26a8f56868c5ad5434735126 upstream.
Patch series "module autoloading fixes and cleanups", v5.
This series fixes a bug where request_module() was reporting success to
kernel code when module autoloading had been completely disabled via
'echo > /proc/sys/kernel/modprobe'.
It also addresses the issues raised on the original thread
(https://lkml.kernel.org/lkml/20200310223731.126894-1-ebiggers@kernel.org/T/#u)
bydocumenting the modprobe sysctl, adding a self-test for the empty path
case, and downgrading a user-reachable WARN_ONCE().
This patch (of 4):
It's long been possible to disable kernel module autoloading completely
(while still allowing manual module insertion) by setting
/proc/sys/kernel/modprobe to the empty string.
This can be preferable to setting it to a nonexistent file since it
avoids the overhead of an attempted execve(), avoids potential
deadlocks, and avoids the call to security_kernel_module_request() and
thus on SELinux-based systems eliminates the need to write SELinux rules
to dontaudit module_request.
However, when module autoloading is disabled in this way,
request_module() returns 0. This is broken because callers expect 0 to
mean that the module was successfully loaded.
Apparently this was never noticed because this method of disabling
module autoloading isn't used much, and also most callers don't use the
return value of request_module() since it's always necessary to check
whether the module registered its functionality or not anyway.
But improperly returning 0 can indeed confuse a few callers, for example
get_fs_type() in fs/filesystems.c where it causes a WARNING to be hit:
if (!fs && (request_module("fs-%.*s", len, name) == 0)) {
fs = __get_fs_type(name, len);
WARN_ONCE(!fs, "request_module fs-%.*s succeeded, but still no fs?\n", len, name);
}
This is easily reproduced with:
echo > /proc/sys/kernel/modprobe
mount -t NONEXISTENT none /
It causes:
request_module fs-NONEXISTENT succeeded, but still no fs?
WARNING: CPU: 1 PID: 1106 at fs/filesystems.c:275 get_fs_type+0xd6/0xf0
[...]
This should actually use pr_warn_once() rather than WARN_ONCE(), since
it's also user-reachable if userspace immediately unloads the module.
Regardless, request_module() should correctly return an error when it
fails. So let's make it return -ENOENT, which matches the error when
the modprobe binary doesn't exist.
I've also sent patches to document and test this case.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Jessica Yu <jeyu@kernel.org>
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jeff Vander Stoep <jeffv@google.com>
Cc: Ben Hutchings <benh@debian.org>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200310223731.126894-1-ebiggers@kernel.org
Link: http://lkml.kernel.org/r/20200312202552.241885-1-ebiggers@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/kmod.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -120,7 +120,7 @@ out:
* invoke it.
*
* If module auto-loading support is disabled then this function
- * becomes a no-operation.
+ * simply returns -ENOENT.
*/
int __request_module(bool wait, const char *fmt, ...)
{
@@ -137,7 +137,7 @@ int __request_module(bool wait, const ch
WARN_ON_ONCE(wait && current_is_async());
if (!modprobe_path[0])
- return 0;
+ return -ENOENT;
va_start(args, fmt);
ret = vsnprintf(module_name, MODULE_NAME_LEN, fmt, args);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 084/199] cpufreq: powernv: Fix use-after-free
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (82 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 083/199] kmod: make request_module() return an error when autoloading is disabled Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 085/199] hfsplus: fix crash and filesystem corruption when deleting files Greg Kroah-Hartman
` (46 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Oliver OHalloran, Gautham R. Shenoy,
Michael Ellerman
From: Oliver O'Halloran <oohall@gmail.com>
commit d0a72efac89d1c35ac55197895201b7b94c5e6ef upstream.
The cpufreq driver has a use-after-free that we can hit if:
a) There's an OCC message pending when the notifier is registered, and
b) The cpufreq driver fails to register with the core.
When a) occurs the notifier schedules a workqueue item to handle the
message. The backing work_struct is located on chips[].throttle and
when b) happens we clean up by freeing the array. Once we get to
the (now free) queued item and the kernel crashes.
Fixes: c5e29ea7ac14 ("cpufreq: powernv: Fix bugs in powernv_cpufreq_{init/exit}")
Cc: stable@vger.kernel.org # v4.6+
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200206062622.28235-1-oohall@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/cpufreq/powernv-cpufreq.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -1041,6 +1041,12 @@ free_and_return:
static inline void clean_chip_info(void)
{
+ int i;
+
+ /* flush any pending work items */
+ if (chips)
+ for (i = 0; i < nr_chips; i++)
+ cancel_work_sync(&chips[i].throttle);
kfree(chips);
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 085/199] hfsplus: fix crash and filesystem corruption when deleting files
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (83 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 084/199] cpufreq: powernv: Fix use-after-free Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 086/199] libata: Return correct status in sata_pmp_eh_recover_pm() when ATA_DFLAG_DETACH is set Greg Kroah-Hartman
` (45 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Simon Gander, Andrew Morton,
Anton Altaparmakov, Linus Torvalds
From: Simon Gander <simon@tuxera.com>
commit 25efb2ffdf991177e740b2f63e92b4ec7d310a92 upstream.
When removing files containing extended attributes, the hfsplus driver may
remove the wrong entries from the attributes b-tree, causing major
filesystem damage and in some cases even kernel crashes.
To remove a file, all its extended attributes have to be removed as well.
The driver does this by looking up all keys in the attributes b-tree with
the cnid of the file. Each of these entries then gets deleted using the
key used for searching, which doesn't contain the attribute's name when it
should. Since the key doesn't contain the name, the deletion routine will
not find the correct entry and instead remove the one in front of it. If
parent nodes have to be modified, these become corrupt as well. This
causes invalid links and unsorted entries that not even macOS's fsck_hfs
is able to fix.
To fix this, modify the search key before an entry is deleted from the
attributes b-tree by copying the found entry's key into the search key,
therefore ensuring that the correct entry gets removed from the tree.
Signed-off-by: Simon Gander <simon@tuxera.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Anton Altaparmakov <anton@tuxera.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200327155541.1521-1-simon@tuxera.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/hfsplus/attributes.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/fs/hfsplus/attributes.c
+++ b/fs/hfsplus/attributes.c
@@ -292,6 +292,10 @@ static int __hfsplus_delete_attr(struct
return -ENOENT;
}
+ /* Avoid btree corruption */
+ hfs_bnode_read(fd->bnode, fd->search_key,
+ fd->keyoffset, fd->keylength);
+
err = hfs_brec_remove(fd);
if (err)
return err;
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 086/199] libata: Return correct status in sata_pmp_eh_recover_pm() when ATA_DFLAG_DETACH is set
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (84 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 085/199] hfsplus: fix crash and filesystem corruption when deleting files Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 087/199] powerpc/powernv/idle: Restore AMR/UAMOR/AMOR after idle Greg Kroah-Hartman
` (44 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Kai-Heng Feng, Jens Axboe
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
commit 8305f72f952cff21ce8109dc1ea4b321c8efc5af upstream.
During system resume from suspend, this can be observed on ASM1062 PMP
controller:
ata10.01: SATA link down (SStatus 0 SControl 330)
ata10.02: hard resetting link
ata10.02: SATA link down (SStatus 0 SControl 330)
ata10.00: configured for UDMA/133
Kernel panic - not syncing: stack-protector: Kernel
in: sata_pmp_eh_recover+0xa2b/0xa40
CPU: 2 PID: 230 Comm: scsi_eh_9 Tainted: P OE
#49-Ubuntu
Hardware name: System manufacturer System Product
1001 12/10/2017
Call Trace:
dump_stack+0x63/0x8b
panic+0xe4/0x244
? sata_pmp_eh_recover+0xa2b/0xa40
__stack_chk_fail+0x19/0x20
sata_pmp_eh_recover+0xa2b/0xa40
? ahci_do_softreset+0x260/0x260 [libahci]
? ahci_do_hardreset+0x140/0x140 [libahci]
? ata_phys_link_offline+0x60/0x60
? ahci_stop_engine+0xc0/0xc0 [libahci]
sata_pmp_error_handler+0x22/0x30
ahci_error_handler+0x45/0x80 [libahci]
ata_scsi_port_error_handler+0x29b/0x770
? ata_scsi_cmd_error_handler+0x101/0x140
ata_scsi_error+0x95/0xd0
? scsi_try_target_reset+0x90/0x90
scsi_error_handler+0xd0/0x5b0
kthread+0x121/0x140
? scsi_eh_get_sense+0x200/0x200
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x22/0x40
Kernel Offset: 0xcc00000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
Since sata_pmp_eh_recover_pmp() doens't set rc when ATA_DFLAG_DETACH is
set, sata_pmp_eh_recover() continues to run. During retry it triggers
the stack protector.
Set correct rc in sata_pmp_eh_recover_pmp() to let sata_pmp_eh_recover()
jump to pmp_fail directly.
BugLink: https://bugs.launchpad.net/bugs/1821434
Cc: stable@vger.kernel.org
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/libata-pmp.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/ata/libata-pmp.c
+++ b/drivers/ata/libata-pmp.c
@@ -764,6 +764,7 @@ static int sata_pmp_eh_recover_pmp(struc
if (dev->flags & ATA_DFLAG_DETACH) {
detach = 1;
+ rc = -ENODEV;
goto fail;
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 087/199] powerpc/powernv/idle: Restore AMR/UAMOR/AMOR after idle
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (85 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 086/199] libata: Return correct status in sata_pmp_eh_recover_pm() when ATA_DFLAG_DETACH is set Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 088/199] powerpc/64/tm: Dont let userspace set regs->trap via sigreturn Greg Kroah-Hartman
` (43 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michael Ellerman, Andrew Donnellan
From: Michael Ellerman <mpe@ellerman.id.au>
commit 53a712bae5dd919521a58d7bad773b949358add0 upstream.
In order to implement KUAP (Kernel Userspace Access Protection) on
Power9 we will be using the AMR, and therefore indirectly the
UAMOR/AMOR.
So save/restore these regs in the idle code.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[ajd: Backport to 4.14 tree, CVE-2020-11669]
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/idle_book3s.S | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -163,8 +163,11 @@ core_idle_lock_held:
bne- core_idle_lock_held
blr
-/* Reuse an unused pt_regs slot for IAMR */
+/* Reuse some unused pt_regs slots for AMR/IAMR/UAMOR/UAMOR */
+#define PNV_POWERSAVE_AMR _TRAP
#define PNV_POWERSAVE_IAMR _DAR
+#define PNV_POWERSAVE_UAMOR _DSISR
+#define PNV_POWERSAVE_AMOR RESULT
/*
* Pass requested state in r3:
@@ -198,8 +201,16 @@ pnv_powersave_common:
SAVE_NVGPRS(r1)
BEGIN_FTR_SECTION
+ mfspr r4, SPRN_AMR
mfspr r5, SPRN_IAMR
+ mfspr r6, SPRN_UAMOR
+ std r4, PNV_POWERSAVE_AMR(r1)
std r5, PNV_POWERSAVE_IAMR(r1)
+ std r6, PNV_POWERSAVE_UAMOR(r1)
+BEGIN_FTR_SECTION_NESTED(42)
+ mfspr r7, SPRN_AMOR
+ std r7, PNV_POWERSAVE_AMOR(r1)
+END_FTR_SECTION_NESTED_IFSET(CPU_FTR_HVMODE, 42)
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
mfcr r5
@@ -951,12 +962,20 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
REST_GPR(2, r1)
BEGIN_FTR_SECTION
- /* IAMR was saved in pnv_powersave_common() */
+ /* These regs were saved in pnv_powersave_common() */
+ ld r4, PNV_POWERSAVE_AMR(r1)
ld r5, PNV_POWERSAVE_IAMR(r1)
+ ld r6, PNV_POWERSAVE_UAMOR(r1)
+ mtspr SPRN_AMR, r4
mtspr SPRN_IAMR, r5
+ mtspr SPRN_UAMOR, r6
+BEGIN_FTR_SECTION_NESTED(42)
+ ld r7, PNV_POWERSAVE_AMOR(r1)
+ mtspr SPRN_AMOR, r7
+END_FTR_SECTION_NESTED_IFSET(CPU_FTR_HVMODE, 42)
/*
- * We don't need an isync here because the upcoming mtmsrd is
- * execution synchronizing.
+ * We don't need an isync here after restoring IAMR because the upcoming
+ * mtmsrd is execution synchronizing.
*/
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 088/199] powerpc/64/tm: Dont let userspace set regs->trap via sigreturn
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (86 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 087/199] powerpc/powernv/idle: Restore AMR/UAMOR/AMOR after idle Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 089/199] powerpc/hash64/devmap: Use H_PAGE_THP_HUGE when setting up huge devmap PTE entries Greg Kroah-Hartman
` (42 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Michael Ellerman
From: Michael Ellerman <mpe@ellerman.id.au>
commit c7def7fbdeaa25feaa19caf4a27c5d10bd8789e4 upstream.
In restore_tm_sigcontexts() we take the trap value directly from the
user sigcontext with no checking:
err |= __get_user(regs->trap, &sc->gp_regs[PT_TRAP]);
This means we can be in the kernel with an arbitrary regs->trap value.
Although that's not immediately problematic, there is a risk we could
trigger one of the uses of CHECK_FULL_REGS():
#define CHECK_FULL_REGS(regs) BUG_ON(regs->trap & 1)
It can also cause us to unnecessarily save non-volatile GPRs again in
save_nvgprs(), which shouldn't be problematic but is still wrong.
It's also possible it could trick the syscall restart machinery, which
relies on regs->trap not being == 0xc00 (see 9a81c16b5275 ("powerpc:
fix double syscall restarts")), though I haven't been able to make
that happen.
Finally it doesn't match the behaviour of the non-TM case, in
restore_sigcontext() which zeroes regs->trap.
So change restore_tm_sigcontexts() to zero regs->trap.
This was discovered while testing Nick's upcoming rewrite of the
syscall entry path. In that series the call to save_nvgprs() prior to
signal handling (do_notify_resume()) is removed, which leaves the
low-bit of regs->trap uncleared which can then trigger the FULL_REGS()
WARNs in setup_tm_sigcontexts().
Fixes: 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal context")
Cc: stable@vger.kernel.org # v3.9+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200401023836.3286664-1-mpe@ellerman.id.au
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/signal_64.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -469,8 +469,10 @@ static long restore_tm_sigcontexts(struc
err |= __get_user(tsk->thread.ckpt_regs.ccr,
&sc->gp_regs[PT_CCR]);
+ /* Don't allow userspace to set the trap value */
+ regs->trap = 0;
+
/* These regs are not checkpointed; they can go in 'regs'. */
- err |= __get_user(regs->trap, &sc->gp_regs[PT_TRAP]);
err |= __get_user(regs->dar, &sc->gp_regs[PT_DAR]);
err |= __get_user(regs->dsisr, &sc->gp_regs[PT_DSISR]);
err |= __get_user(regs->result, &sc->gp_regs[PT_RESULT]);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 089/199] powerpc/hash64/devmap: Use H_PAGE_THP_HUGE when setting up huge devmap PTE entries
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (87 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 088/199] powerpc/64/tm: Dont let userspace set regs->trap via sigreturn Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 090/199] powerpc/xive: Use XIVE_BAD_IRQ instead of zero to catch non configured IPIs Greg Kroah-Hartman
` (41 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Aneesh Kumar K.V, Michael Ellerman
From: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
commit 36b78402d97a3b9aeab136feb9b00d8647ec2c20 upstream.
H_PAGE_THP_HUGE is used to differentiate between a THP hugepage and
hugetlb hugepage entries. The difference is WRT how we handle hash
fault on these address. THP address enables MPSS in segments. We want
to manage devmap hugepage entries similar to THP pt entries. Hence use
H_PAGE_THP_HUGE for devmap huge PTE entries.
With current code while handling hash PTE fault, we do set is_thp =
true when finding devmap PTE huge PTE entries.
Current code also does the below sequence we setting up huge devmap
entries.
entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));
if (pfn_t_devmap(pfn))
entry = pmd_mkdevmap(entry);
In that case we would find both H_PAGE_THP_HUGE and PAGE_DEVMAP set
for huge devmap PTE entries. This results in false positive error like
below.
kernel BUG at /home/kvaneesh/src/linux/mm/memory.c:4321!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 56 PID: 67996 Comm: t_mmap_dio Not tainted 5.6.0-rc4-59640-g371c804dedbc #128
....
NIP [c00000000044c9e4] __follow_pte_pmd+0x264/0x900
LR [c0000000005d45f8] dax_writeback_one+0x1a8/0x740
Call Trace:
str_spec.74809+0x22ffb4/0x2d116c (unreliable)
dax_writeback_one+0x1a8/0x740
dax_writeback_mapping_range+0x26c/0x700
ext4_dax_writepages+0x150/0x5a0
do_writepages+0x68/0x180
__filemap_fdatawrite_range+0x138/0x180
file_write_and_wait_range+0xa4/0x110
ext4_sync_file+0x370/0x6e0
vfs_fsync_range+0x70/0xf0
sys_msync+0x220/0x2e0
system_call+0x5c/0x68
This is because our pmd_trans_huge check doesn't exclude _PAGE_DEVMAP.
To make this all consistent, update pmd_mkdevmap to set
H_PAGE_THP_HUGE and pmd_trans_huge check now excludes _PAGE_DEVMAP
correctly.
Fixes: ebd31197931d ("powerpc/mm: Add devmap support for ppc64")
Cc: stable@vger.kernel.org # v4.13+
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200313094842.351830-1-aneesh.kumar@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/include/asm/book3s/64/hash-4k.h | 6 ++++++
arch/powerpc/include/asm/book3s/64/hash-64k.h | 8 +++++++-
arch/powerpc/include/asm/book3s/64/pgtable.h | 4 +++-
arch/powerpc/include/asm/book3s/64/radix.h | 5 +++++
4 files changed, 21 insertions(+), 2 deletions(-)
--- a/arch/powerpc/include/asm/book3s/64/hash-4k.h
+++ b/arch/powerpc/include/asm/book3s/64/hash-4k.h
@@ -108,6 +108,12 @@ extern pmd_t hash__pmdp_huge_get_and_cle
extern int hash__has_transparent_hugepage(void);
#endif
+static inline pmd_t hash__pmd_mkdevmap(pmd_t pmd)
+{
+ BUG();
+ return pmd;
+}
+
#endif /* !__ASSEMBLY__ */
#endif /* _ASM_POWERPC_BOOK3S_64_HASH_4K_H */
--- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
+++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
@@ -181,7 +181,7 @@ static inline void mark_hpte_slot_valid(
*/
static inline int hash__pmd_trans_huge(pmd_t pmd)
{
- return !!((pmd_val(pmd) & (_PAGE_PTE | H_PAGE_THP_HUGE)) ==
+ return !!((pmd_val(pmd) & (_PAGE_PTE | H_PAGE_THP_HUGE | _PAGE_DEVMAP)) ==
(_PAGE_PTE | H_PAGE_THP_HUGE));
}
@@ -209,6 +209,12 @@ extern pmd_t hash__pmdp_huge_get_and_cle
unsigned long addr, pmd_t *pmdp);
extern int hash__has_transparent_hugepage(void);
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+
+static inline pmd_t hash__pmd_mkdevmap(pmd_t pmd)
+{
+ return __pmd(pmd_val(pmd) | (_PAGE_PTE | H_PAGE_THP_HUGE | _PAGE_DEVMAP));
+}
+
#endif /* __ASSEMBLY__ */
#endif /* _ASM_POWERPC_BOOK3S_64_HASH_64K_H */
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -1179,7 +1179,9 @@ extern void serialize_against_pte_lookup
static inline pmd_t pmd_mkdevmap(pmd_t pmd)
{
- return __pmd(pmd_val(pmd) | (_PAGE_PTE | _PAGE_DEVMAP));
+ if (radix_enabled())
+ return radix__pmd_mkdevmap(pmd);
+ return hash__pmd_mkdevmap(pmd);
}
static inline int pmd_devmap(pmd_t pmd)
--- a/arch/powerpc/include/asm/book3s/64/radix.h
+++ b/arch/powerpc/include/asm/book3s/64/radix.h
@@ -289,6 +289,11 @@ extern pmd_t radix__pmdp_huge_get_and_cl
extern int radix__has_transparent_hugepage(void);
#endif
+static inline pmd_t radix__pmd_mkdevmap(pmd_t pmd)
+{
+ return __pmd(pmd_val(pmd) | (_PAGE_PTE | _PAGE_DEVMAP));
+}
+
extern int __meminit radix__vmemmap_create_mapping(unsigned long start,
unsigned long page_size,
unsigned long phys);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 090/199] powerpc/xive: Use XIVE_BAD_IRQ instead of zero to catch non configured IPIs
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (88 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 089/199] powerpc/hash64/devmap: Use H_PAGE_THP_HUGE when setting up huge devmap PTE entries Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 091/199] powerpc/kprobes: Ignore traps that happened in real mode Greg Kroah-Hartman
` (40 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Gibson, Cédric Le Goater,
Michael Ellerman
From: Cédric Le Goater <clg@kaod.org>
commit b1a504a6500df50e83b701b7946b34fce27ad8a3 upstream.
When a CPU is brought up, an IPI number is allocated and recorded
under the XIVE CPU structure. Invalid IPI numbers are tracked with
interrupt number 0x0.
On the PowerNV platform, the interrupt number space starts at 0x10 and
this works fine. However, on the sPAPR platform, it is possible to
allocate the interrupt number 0x0 and this raises an issue when CPU 0
is unplugged. The XIVE spapr driver tracks allocated interrupt numbers
in a bitmask and it is not correctly updated when interrupt number 0x0
is freed. It stays allocated and it is then impossible to reallocate.
Fix by using the XIVE_BAD_IRQ value instead of zero on both platforms.
Reported-by: David Gibson <david@gibson.dropbear.id.au>
Fixes: eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt controller")
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200306150143.5551-2-clg@kaod.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/sysdev/xive/common.c | 12 +++---------
arch/powerpc/sysdev/xive/native.c | 4 ++--
arch/powerpc/sysdev/xive/spapr.c | 4 ++--
arch/powerpc/sysdev/xive/xive-internal.h | 7 +++++++
4 files changed, 14 insertions(+), 13 deletions(-)
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -72,13 +72,6 @@ static u32 xive_ipi_irq;
/* Xive state for each CPU */
static DEFINE_PER_CPU(struct xive_cpu *, xive_cpu);
-/*
- * A "disabled" interrupt should never fire, to catch problems
- * we set its logical number to this
- */
-#define XIVE_BAD_IRQ 0x7fffffff
-#define XIVE_MAX_IRQ (XIVE_BAD_IRQ - 1)
-
/* An invalid CPU target */
#define XIVE_INVALID_TARGET (-1)
@@ -1073,7 +1066,7 @@ static int xive_setup_cpu_ipi(unsigned i
xc = per_cpu(xive_cpu, cpu);
/* Check if we are already setup */
- if (xc->hw_ipi != 0)
+ if (xc->hw_ipi != XIVE_BAD_IRQ)
return 0;
/* Grab an IPI from the backend, this will populate xc->hw_ipi */
@@ -1110,7 +1103,7 @@ static void xive_cleanup_cpu_ipi(unsigne
/* Disable the IPI and free the IRQ data */
/* Already cleaned up ? */
- if (xc->hw_ipi == 0)
+ if (xc->hw_ipi == XIVE_BAD_IRQ)
return;
/* Mask the IPI */
@@ -1266,6 +1259,7 @@ static int xive_prepare_cpu(unsigned int
if (np)
xc->chip_id = of_get_ibm_chip_id(np);
of_node_put(np);
+ xc->hw_ipi = XIVE_BAD_IRQ;
per_cpu(xive_cpu, cpu) = xc;
}
--- a/arch/powerpc/sysdev/xive/native.c
+++ b/arch/powerpc/sysdev/xive/native.c
@@ -310,7 +310,7 @@ static void xive_native_put_ipi(unsigned
s64 rc;
/* Free the IPI */
- if (!xc->hw_ipi)
+ if (xc->hw_ipi == XIVE_BAD_IRQ)
return;
for (;;) {
rc = opal_xive_free_irq(xc->hw_ipi);
@@ -318,7 +318,7 @@ static void xive_native_put_ipi(unsigned
msleep(1);
continue;
}
- xc->hw_ipi = 0;
+ xc->hw_ipi = XIVE_BAD_IRQ;
break;
}
}
--- a/arch/powerpc/sysdev/xive/spapr.c
+++ b/arch/powerpc/sysdev/xive/spapr.c
@@ -443,11 +443,11 @@ static int xive_spapr_get_ipi(unsigned i
static void xive_spapr_put_ipi(unsigned int cpu, struct xive_cpu *xc)
{
- if (!xc->hw_ipi)
+ if (xc->hw_ipi == XIVE_BAD_IRQ)
return;
xive_irq_bitmap_free(xc->hw_ipi);
- xc->hw_ipi = 0;
+ xc->hw_ipi = XIVE_BAD_IRQ;
}
#endif /* CONFIG_SMP */
--- a/arch/powerpc/sysdev/xive/xive-internal.h
+++ b/arch/powerpc/sysdev/xive/xive-internal.h
@@ -9,6 +9,13 @@
#ifndef __XIVE_INTERNAL_H
#define __XIVE_INTERNAL_H
+/*
+ * A "disabled" interrupt should never fire, to catch problems
+ * we set its logical number to this
+ */
+#define XIVE_BAD_IRQ 0x7fffffff
+#define XIVE_MAX_IRQ (XIVE_BAD_IRQ - 1)
+
/* Each CPU carry one of these with various per-CPU state */
struct xive_cpu {
#ifdef CONFIG_SMP
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 091/199] powerpc/kprobes: Ignore traps that happened in real mode
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (89 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 090/199] powerpc/xive: Use XIVE_BAD_IRQ instead of zero to catch non configured IPIs Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 092/199] scsi: mpt3sas: Fix kernel panic observed on soft HBA unplug Greg Kroah-Hartman
` (39 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Larry Finger, Christophe Leroy,
Masami Hiramatsu, Naveen N. Rao, Michael Ellerman
From: Christophe Leroy <christophe.leroy@c-s.fr>
commit 21f8b2fa3ca5b01f7a2b51b89ce97a3705a15aa0 upstream.
When a program check exception happens while MMU translation is
disabled, following Oops happens in kprobe_handler() in the following
code:
} else if (*addr != BREAKPOINT_INSTRUCTION) {
BUG: Unable to handle kernel data access on read at 0x0000e268
Faulting instruction address: 0xc000ec34
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=16K PREEMPT CMPC885
Modules linked in:
CPU: 0 PID: 429 Comm: cat Not tainted 5.6.0-rc1-s3k-dev-00824-g84195dc6c58a #3267
NIP: c000ec34 LR: c000ecd8 CTR: c019cab8
REGS: ca4d3b58 TRAP: 0300 Not tainted (5.6.0-rc1-s3k-dev-00824-g84195dc6c58a)
MSR: 00001032 <ME,IR,DR,RI> CR: 2a4d3c52 XER: 00000000
DAR: 0000e268 DSISR: c0000000
GPR00: c000b09c ca4d3c10 c66d0620 00000000 ca4d3c60 00000000 00009032 00000000
GPR08: 00020000 00000000 c087de44 c000afe0 c66d0ad0 100d3dd6 fffffff3 00000000
GPR16: 00000000 00000041 00000000 ca4d3d70 00000000 00000000 0000416d 00000000
GPR24: 00000004 c53b6128 00000000 0000e268 00000000 c07c0000 c07bb6fc ca4d3c60
NIP [c000ec34] kprobe_handler+0x128/0x290
LR [c000ecd8] kprobe_handler+0x1cc/0x290
Call Trace:
[ca4d3c30] [c000b09c] program_check_exception+0xbc/0x6fc
[ca4d3c50] [c000e43c] ret_from_except_full+0x0/0x4
--- interrupt: 700 at 0xe268
Instruction dump:
913e0008 81220000 38600001 3929ffff 91220000 80010024 bb410008 7c0803a6
38210020 4e800020 38600000 4e800020 <813b0000> 6d2a7fe0 2f8a0008 419e0154
---[ end trace 5b9152d4cdadd06d ]---
kprobe is not prepared to handle events in real mode and functions
running in real mode should have been blacklisted, so kprobe_handler()
can safely bail out telling 'this trap is not mine' for any trap that
happened while in real-mode.
If the trap happened with MSR_IR or MSR_DR cleared, return 0
immediately.
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Fixes: 6cc89bad60a6 ("powerpc/kprobes: Invoke handlers directly")
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/424331e2006e7291a1bfe40e7f3fa58825f565e1.1582054578.git.christophe.leroy@c-s.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/kprobes.c | 3 +++
1 file changed, 3 insertions(+)
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -279,6 +279,9 @@ int kprobe_handler(struct pt_regs *regs)
if (user_mode(regs))
return 0;
+ if (!(regs->msr & MSR_IR) || !(regs->msr & MSR_DR))
+ return 0;
+
/*
* We don't want to be preempted for the entire
* duration of kprobe processing
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 092/199] scsi: mpt3sas: Fix kernel panic observed on soft HBA unplug
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (90 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 091/199] powerpc/kprobes: Ignore traps that happened in real mode Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:56 ` [PATCH 4.14 093/199] powerpc: Add attributes for setjmp/longjmp Greg Kroah-Hartman
` (38 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sreekanth Reddy, Martin K. Petersen
From: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
commit cc41f11a21a51d6869d71e525a7264c748d7c0d7 upstream.
Generic protection fault type kernel panic is observed when user performs
soft (ordered) HBA unplug operation while IOs are running on drives
connected to HBA.
When user performs ordered HBA removal operation, the kernel calls PCI
device's .remove() call back function where driver is flushing out all the
outstanding SCSI IO commands with DID_NO_CONNECT host byte and also unmaps
sg buffers allocated for these IO commands.
However, in the ordered HBA removal case (unlike of real HBA hot removal),
HBA device is still alive and hence HBA hardware is performing the DMA
operations to those buffers on the system memory which are already unmapped
while flushing out the outstanding SCSI IO commands and this leads to
kernel panic.
Don't flush out the outstanding IOs from .remove() path in case of ordered
removal since HBA will be still alive in this case and it can complete the
outstanding IOs. Flush out the outstanding IOs only in case of 'physical
HBA hot unplug' where there won't be any communication with the HBA.
During shutdown also it is possible that HBA hardware can perform DMA
operations on those outstanding IO buffers which are completed with
DID_NO_CONNECT by the driver from .shutdown(). So same above fix is applied
in shutdown path as well.
It is safe to drop the outstanding commands when HBA is inaccessible such
as when permanent PCI failure happens, when HBA is in non-operational
state, or when someone does a real HBA hot unplug operation. Since driver
knows that HBA is inaccessible during these cases, it is safe to drop the
outstanding commands instead of waiting for SCSI error recovery to kick in
and clear these outstanding commands.
Link: https://lore.kernel.org/r/1585302763-23007-1-git-send-email-sreekanth.reddy@broadcom.com
Fixes: c666d3be99c0 ("scsi: mpt3sas: wait for and flush running commands on shutdown/unload")
Cc: stable@vger.kernel.org #v4.14.174+
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -8280,8 +8280,8 @@ static void scsih_remove(struct pci_dev
ioc->remove_host = 1;
- mpt3sas_wait_for_commands_to_complete(ioc);
- _scsih_flush_running_cmds(ioc);
+ if (!pci_device_is_present(pdev))
+ _scsih_flush_running_cmds(ioc);
_scsih_fw_event_cleanup_queue(ioc);
@@ -8354,8 +8354,8 @@ scsih_shutdown(struct pci_dev *pdev)
ioc->remove_host = 1;
- mpt3sas_wait_for_commands_to_complete(ioc);
- _scsih_flush_running_cmds(ioc);
+ if (!pci_device_is_present(pdev))
+ _scsih_flush_running_cmds(ioc);
_scsih_fw_event_cleanup_queue(ioc);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 093/199] powerpc: Add attributes for setjmp/longjmp
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (91 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 092/199] scsi: mpt3sas: Fix kernel panic observed on soft HBA unplug Greg Kroah-Hartman
@ 2020-04-22 9:56 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 094/199] powerpc: Make setjmp/longjmp signature standard Greg Kroah-Hartman
` (37 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Segher Boessenkool, Michael Ellerman,
Nathan Chancellor
From: Segher Boessenkool <segher@kernel.crashing.org>
commit aa497d4352414aad22e792b35d0aaaa12bbc37c5 upstream.
The setjmp function should be declared as "returns_twice", or bad
things can happen[1]. This does not actually change generated code in
my testing.
The longjmp function should be declared as "noreturn", so that the
compiler can optimise calls to it better. This makes the generated
code a little shorter.
1: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-returns_005ftwice-function-attribute
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/c02ce4a573f3bac907e2c70957a2d1275f910013.1567605586.git.segher@kernel.crashing.org
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/include/asm/setjmp.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/powerpc/include/asm/setjmp.h
+++ b/arch/powerpc/include/asm/setjmp.h
@@ -12,7 +12,7 @@
#define JMP_BUF_LEN 23
-extern long setjmp(long *);
-extern void longjmp(long *, long);
+extern long setjmp(long *) __attribute__((returns_twice));
+extern void longjmp(long *, long) __attribute__((noreturn));
#endif /* _ASM_POWERPC_SETJMP_H */
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 094/199] powerpc: Make setjmp/longjmp signature standard
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (92 preceding siblings ...)
2020-04-22 9:56 ` [PATCH 4.14 093/199] powerpc: Add attributes for setjmp/longjmp Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 095/199] Btrfs: fix crash during unmount due to race with delayed inode workers Greg Kroah-Hartman
` (36 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Clement Courbet, Nathan Chancellor,
Michael Ellerman
From: Clement Courbet <courbet@google.com>
commit c17eb4dca5a353a9dbbb8ad6934fe57af7165e91 upstream.
Declaring setjmp()/longjmp() as taking longs makes the signature
non-standard, and makes clang complain. In the past, this has been
worked around by adding -ffreestanding to the compile flags.
The implementation looks like it only ever propagates the value
(in longjmp) or sets it to 1 (in setjmp), and we only call longjmp
with integer parameters.
This allows removing -ffreestanding from the compilation flags.
Fixes: c9029ef9c957 ("powerpc: Avoid clang warnings around setjmp and longjmp")
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Clement Courbet <courbet@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200330080400.124803-1-courbet@google.com
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/include/asm/setjmp.h | 6 ++++--
arch/powerpc/kernel/Makefile | 3 ---
arch/powerpc/xmon/Makefile | 3 ---
3 files changed, 4 insertions(+), 8 deletions(-)
--- a/arch/powerpc/include/asm/setjmp.h
+++ b/arch/powerpc/include/asm/setjmp.h
@@ -12,7 +12,9 @@
#define JMP_BUF_LEN 23
-extern long setjmp(long *) __attribute__((returns_twice));
-extern void longjmp(long *, long) __attribute__((noreturn));
+typedef long jmp_buf[JMP_BUF_LEN];
+
+extern int setjmp(jmp_buf env) __attribute__((returns_twice));
+extern void longjmp(jmp_buf env, int val) __attribute__((noreturn));
#endif /* _ASM_POWERPC_SETJMP_H */
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -5,9 +5,6 @@
CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"'
-# Avoid clang warnings around longjmp/setjmp declarations
-CFLAGS_crash.o += -ffreestanding
-
subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
ifeq ($(CONFIG_PPC64),y)
--- a/arch/powerpc/xmon/Makefile
+++ b/arch/powerpc/xmon/Makefile
@@ -1,9 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
# Makefile for xmon
-# Avoid clang warnings around longjmp/setjmp declarations
-subdir-ccflags-y := -ffreestanding
-
subdir-ccflags-$(CONFIG_PPC_WERROR) += -Werror
GCOV_PROFILE := n
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 095/199] Btrfs: fix crash during unmount due to race with delayed inode workers
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (93 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 094/199] powerpc: Make setjmp/longjmp signature standard Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 096/199] btrfs: use nofs allocations for running delayed items Greg Kroah-Hartman
` (35 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Filipe Manana, David Sterba, Sasha Levin
From: Filipe Manana <fdmanana@suse.com>
[ Upstream commit f0cc2cd70164efe8f75c5d99560f0f69969c72e4 ]
During unmount we can have a job from the delayed inode items work queue
still running, that can lead to at least two bad things:
1) A crash, because the worker can try to create a transaction just
after the fs roots were freed;
2) A transaction leak, because the worker can create a transaction
before the fs roots are freed and just after we committed the last
transaction and after we stopped the transaction kthread.
A stack trace example of the crash:
[79011.691214] kernel BUG at lib/radix-tree.c:982!
[79011.692056] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
[79011.693180] CPU: 3 PID: 1394 Comm: kworker/u8:2 Tainted: G W 5.6.0-rc2-btrfs-next-54 #2
(...)
[79011.696789] Workqueue: btrfs-delayed-meta btrfs_work_helper [btrfs]
[79011.697904] RIP: 0010:radix_tree_tag_set+0xe7/0x170
(...)
[79011.702014] RSP: 0018:ffffb3c84a317ca0 EFLAGS: 00010293
[79011.702949] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[79011.704202] RDX: ffffb3c84a317cb0 RSI: ffffb3c84a317ca8 RDI: ffff8db3931340a0
[79011.705463] RBP: 0000000000000005 R08: 0000000000000005 R09: ffffffff974629d0
[79011.706756] R10: ffffb3c84a317bc0 R11: 0000000000000001 R12: ffff8db393134000
[79011.708010] R13: ffff8db3931340a0 R14: ffff8db393134068 R15: 0000000000000001
[79011.709270] FS: 0000000000000000(0000) GS:ffff8db3b6a00000(0000) knlGS:0000000000000000
[79011.710699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[79011.711710] CR2: 00007f22c2a0a000 CR3: 0000000232ad4005 CR4: 00000000003606e0
[79011.712958] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[79011.714205] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[79011.715448] Call Trace:
[79011.715925] record_root_in_trans+0x72/0xf0 [btrfs]
[79011.716819] btrfs_record_root_in_trans+0x4b/0x70 [btrfs]
[79011.717925] start_transaction+0xdd/0x5c0 [btrfs]
[79011.718829] btrfs_async_run_delayed_root+0x17e/0x2b0 [btrfs]
[79011.719915] btrfs_work_helper+0xaa/0x720 [btrfs]
[79011.720773] process_one_work+0x26d/0x6a0
[79011.721497] worker_thread+0x4f/0x3e0
[79011.722153] ? process_one_work+0x6a0/0x6a0
[79011.722901] kthread+0x103/0x140
[79011.723481] ? kthread_create_worker_on_cpu+0x70/0x70
[79011.724379] ret_from_fork+0x3a/0x50
(...)
The following diagram shows a sequence of steps that lead to the crash
during ummount of the filesystem:
CPU 1 CPU 2 CPU 3
btrfs_punch_hole()
btrfs_btree_balance_dirty()
btrfs_balance_delayed_items()
--> sees
fs_info->delayed_root->items
with value 200, which is greater
than
BTRFS_DELAYED_BACKGROUND (128)
and smaller than
BTRFS_DELAYED_WRITEBACK (512)
btrfs_wq_run_delayed_node()
--> queues a job for
fs_info->delayed_workers to run
btrfs_async_run_delayed_root()
btrfs_async_run_delayed_root()
--> job queued by CPU 1
--> starts picking and running
delayed nodes from the
prepare_list list
close_ctree()
btrfs_delete_unused_bgs()
btrfs_commit_super()
btrfs_join_transaction()
--> gets transaction N
btrfs_commit_transaction(N)
--> set transaction state
to TRANTS_STATE_COMMIT_START
btrfs_first_prepared_delayed_node()
--> picks delayed node X through
the prepared_list list
btrfs_run_delayed_items()
btrfs_first_delayed_node()
--> also picks delayed node X
but through the node_list
list
__btrfs_commit_inode_delayed_items()
--> runs all delayed items from
this node and drops the
node's item count to 0
through call to
btrfs_release_delayed_inode()
--> finishes running any remaining
delayed nodes
--> finishes transaction commit
--> stops cleaner and transaction threads
btrfs_free_fs_roots()
--> frees all roots and removes them
from the radix tree
fs_info->fs_roots_radix
btrfs_join_transaction()
start_transaction()
btrfs_record_root_in_trans()
record_root_in_trans()
radix_tree_tag_set()
--> crashes because
the root is not in
the radix tree
anymore
If the worker is able to call btrfs_join_transaction() before the unmount
task frees the fs roots, we end up leaking a transaction and all its
resources, since after the call to btrfs_commit_super() and stopping the
transaction kthread, we don't expect to have any transaction open anymore.
When this situation happens the worker has a delayed node that has no
more items to run, since the task calling btrfs_run_delayed_items(),
which is doing a transaction commit, picks the same node and runs all
its items first.
We can not wait for the worker to complete when running delayed items
through btrfs_run_delayed_items(), because we call that function in
several phases of a transaction commit, and that could cause a deadlock
because the worker calls btrfs_join_transaction() and the task doing the
transaction commit may have already set the transaction state to
TRANS_STATE_COMMIT_DOING.
Also it's not possible to get into a situation where only some of the
items of a delayed node are added to the fs/subvolume tree in the current
transaction and the remaining ones in the next transaction, because when
running the items of a delayed inode we lock its mutex, effectively
waiting for the worker if the worker is running the items of the delayed
node already.
Since this can only cause issues when unmounting a filesystem, fix it in
a simple way by waiting for any jobs on the delayed workers queue before
calling btrfs_commit_supper() at close_ctree(). This works because at this
point no one can call btrfs_btree_balance_dirty() or
btrfs_balance_delayed_items(), and if we end up waiting for any worker to
complete, btrfs_commit_super() will commit the transaction created by the
worker.
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/async-thread.c | 8 ++++++++
fs/btrfs/async-thread.h | 2 ++
fs/btrfs/disk-io.c | 13 +++++++++++++
3 files changed, 23 insertions(+)
diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c
index 72d7589072f52..92615badc1734 100644
--- a/fs/btrfs/async-thread.c
+++ b/fs/btrfs/async-thread.c
@@ -447,3 +447,11 @@ void btrfs_set_work_high_priority(struct btrfs_work *work)
{
set_bit(WORK_HIGH_PRIO_BIT, &work->flags);
}
+
+void btrfs_flush_workqueue(struct btrfs_workqueue *wq)
+{
+ if (wq->high)
+ flush_workqueue(wq->high->normal_wq);
+
+ flush_workqueue(wq->normal->normal_wq);
+}
diff --git a/fs/btrfs/async-thread.h b/fs/btrfs/async-thread.h
index fc957e00cef14..2a25aef6ef2a5 100644
--- a/fs/btrfs/async-thread.h
+++ b/fs/btrfs/async-thread.h
@@ -85,4 +85,6 @@ void btrfs_set_work_high_priority(struct btrfs_work *work);
struct btrfs_fs_info *btrfs_work_owner(const struct btrfs_work *work);
struct btrfs_fs_info *btrfs_workqueue_owner(const struct __btrfs_workqueue *wq);
bool btrfs_workqueue_normal_congested(const struct btrfs_workqueue *wq);
+void btrfs_flush_workqueue(struct btrfs_workqueue *wq);
+
#endif
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 6b4fee5c79f9d..096c015b22a46 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3725,6 +3725,19 @@ void close_ctree(struct btrfs_fs_info *fs_info)
*/
btrfs_delete_unused_bgs(fs_info);
+ /*
+ * There might be existing delayed inode workers still running
+ * and holding an empty delayed inode item. We must wait for
+ * them to complete first because they can create a transaction.
+ * This happens when someone calls btrfs_balance_delayed_items()
+ * and then a transaction commit runs the same delayed nodes
+ * before any delayed worker has done something with the nodes.
+ * We must wait for any worker here and not at transaction
+ * commit time since that could cause a deadlock.
+ * This is a very rare case.
+ */
+ btrfs_flush_workqueue(fs_info->delayed_workers);
+
ret = btrfs_commit_super(fs_info);
if (ret)
btrfs_err(fs_info, "commit super ret %d", ret);
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 096/199] btrfs: use nofs allocations for running delayed items
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (94 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 095/199] Btrfs: fix crash during unmount due to race with delayed inode workers Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 097/199] dm zoned: remove duplicate nr_rnd_zones increase in dmz_init_zone() Greg Kroah-Hartman
` (34 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Josef Bacik, David Sterba, Sasha Levin
From: Josef Bacik <josef@toxicpanda.com>
[ Upstream commit 351cbf6e4410e7ece05e35d0a07320538f2418b4 ]
Zygo reported the following lockdep splat while testing the balance
patches
======================================================
WARNING: possible circular locking dependency detected
5.6.0-c6f0579d496a+ #53 Not tainted
------------------------------------------------------
kswapd0/1133 is trying to acquire lock:
ffff888092f622c0 (&delayed_node->mutex){+.+.}, at: __btrfs_release_delayed_node+0x7c/0x5b0
but task is already holding lock:
ffffffff8fc5f860 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x5/0x30
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (fs_reclaim){+.+.}:
fs_reclaim_acquire.part.91+0x29/0x30
fs_reclaim_acquire+0x19/0x20
kmem_cache_alloc_trace+0x32/0x740
add_block_entry+0x45/0x260
btrfs_ref_tree_mod+0x6e2/0x8b0
btrfs_alloc_tree_block+0x789/0x880
alloc_tree_block_no_bg_flush+0xc6/0xf0
__btrfs_cow_block+0x270/0x940
btrfs_cow_block+0x1ba/0x3a0
btrfs_search_slot+0x999/0x1030
btrfs_insert_empty_items+0x81/0xe0
btrfs_insert_delayed_items+0x128/0x7d0
__btrfs_run_delayed_items+0xf4/0x2a0
btrfs_run_delayed_items+0x13/0x20
btrfs_commit_transaction+0x5cc/0x1390
insert_balance_item.isra.39+0x6b2/0x6e0
btrfs_balance+0x72d/0x18d0
btrfs_ioctl_balance+0x3de/0x4c0
btrfs_ioctl+0x30ab/0x44a0
ksys_ioctl+0xa1/0xe0
__x64_sys_ioctl+0x43/0x50
do_syscall_64+0x77/0x2c0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (&delayed_node->mutex){+.+.}:
__lock_acquire+0x197e/0x2550
lock_acquire+0x103/0x220
__mutex_lock+0x13d/0xce0
mutex_lock_nested+0x1b/0x20
__btrfs_release_delayed_node+0x7c/0x5b0
btrfs_remove_delayed_node+0x49/0x50
btrfs_evict_inode+0x6fc/0x900
evict+0x19a/0x2c0
dispose_list+0xa0/0xe0
prune_icache_sb+0xbd/0xf0
super_cache_scan+0x1b5/0x250
do_shrink_slab+0x1f6/0x530
shrink_slab+0x32e/0x410
shrink_node+0x2a5/0xba0
balance_pgdat+0x4bd/0x8a0
kswapd+0x35a/0x800
kthread+0x1e9/0x210
ret_from_fork+0x3a/0x50
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(&delayed_node->mutex);
lock(fs_reclaim);
lock(&delayed_node->mutex);
*** DEADLOCK ***
3 locks held by kswapd0/1133:
#0: ffffffff8fc5f860 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x5/0x30
#1: ffffffff8fc380d8 (shrinker_rwsem){++++}, at: shrink_slab+0x1e8/0x410
#2: ffff8881e0e6c0e8 (&type->s_umount_key#42){++++}, at: trylock_super+0x1b/0x70
stack backtrace:
CPU: 2 PID: 1133 Comm: kswapd0 Not tainted 5.6.0-c6f0579d496a+ #53
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
Call Trace:
dump_stack+0xc1/0x11a
print_circular_bug.isra.38.cold.57+0x145/0x14a
check_noncircular+0x2a9/0x2f0
? print_circular_bug.isra.38+0x130/0x130
? stack_trace_consume_entry+0x90/0x90
? save_trace+0x3cc/0x420
__lock_acquire+0x197e/0x2550
? btrfs_inode_clear_file_extent_range+0x9b/0xb0
? register_lock_class+0x960/0x960
lock_acquire+0x103/0x220
? __btrfs_release_delayed_node+0x7c/0x5b0
__mutex_lock+0x13d/0xce0
? __btrfs_release_delayed_node+0x7c/0x5b0
? __asan_loadN+0xf/0x20
? pvclock_clocksource_read+0xeb/0x190
? __btrfs_release_delayed_node+0x7c/0x5b0
? mutex_lock_io_nested+0xc20/0xc20
? __kasan_check_read+0x11/0x20
? check_chain_key+0x1e6/0x2e0
mutex_lock_nested+0x1b/0x20
? mutex_lock_nested+0x1b/0x20
__btrfs_release_delayed_node+0x7c/0x5b0
btrfs_remove_delayed_node+0x49/0x50
btrfs_evict_inode+0x6fc/0x900
? btrfs_setattr+0x840/0x840
? do_raw_spin_unlock+0xa8/0x140
evict+0x19a/0x2c0
dispose_list+0xa0/0xe0
prune_icache_sb+0xbd/0xf0
? invalidate_inodes+0x310/0x310
super_cache_scan+0x1b5/0x250
do_shrink_slab+0x1f6/0x530
shrink_slab+0x32e/0x410
? do_shrink_slab+0x530/0x530
? do_shrink_slab+0x530/0x530
? __kasan_check_read+0x11/0x20
? mem_cgroup_protected+0x13d/0x260
shrink_node+0x2a5/0xba0
balance_pgdat+0x4bd/0x8a0
? mem_cgroup_shrink_node+0x490/0x490
? _raw_spin_unlock_irq+0x27/0x40
? finish_task_switch+0xce/0x390
? rcu_read_lock_bh_held+0xb0/0xb0
kswapd+0x35a/0x800
? _raw_spin_unlock_irqrestore+0x4c/0x60
? balance_pgdat+0x8a0/0x8a0
? finish_wait+0x110/0x110
? __kasan_check_read+0x11/0x20
? __kthread_parkme+0xc6/0xe0
? balance_pgdat+0x8a0/0x8a0
kthread+0x1e9/0x210
? kthread_create_worker_on_cpu+0xc0/0xc0
ret_from_fork+0x3a/0x50
This is because we hold that delayed node's mutex while doing tree
operations. Fix this by just wrapping the searches in nofs.
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/delayed-inode.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 87414fc9e268f..416fb50a5378c 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -18,6 +18,7 @@
*/
#include <linux/slab.h>
+#include <linux/sched/mm.h>
#include "delayed-inode.h"
#include "disk-io.h"
#include "transaction.h"
@@ -833,11 +834,14 @@ static int btrfs_insert_delayed_item(struct btrfs_trans_handle *trans,
{
struct btrfs_fs_info *fs_info = root->fs_info;
struct extent_buffer *leaf;
+ unsigned int nofs_flag;
char *ptr;
int ret;
+ nofs_flag = memalloc_nofs_save();
ret = btrfs_insert_empty_item(trans, root, path, &delayed_item->key,
delayed_item->data_len);
+ memalloc_nofs_restore(nofs_flag);
if (ret < 0 && ret != -EEXIST)
return ret;
@@ -966,6 +970,7 @@ static int btrfs_delete_delayed_items(struct btrfs_trans_handle *trans,
struct btrfs_delayed_node *node)
{
struct btrfs_delayed_item *curr, *prev;
+ unsigned int nofs_flag;
int ret = 0;
do_again:
@@ -974,7 +979,9 @@ static int btrfs_delete_delayed_items(struct btrfs_trans_handle *trans,
if (!curr)
goto delete_fail;
+ nofs_flag = memalloc_nofs_save();
ret = btrfs_search_slot(trans, root, &curr->key, path, -1, 1);
+ memalloc_nofs_restore(nofs_flag);
if (ret < 0)
goto delete_fail;
else if (ret > 0) {
@@ -1041,6 +1048,7 @@ static int __btrfs_update_delayed_inode(struct btrfs_trans_handle *trans,
struct btrfs_key key;
struct btrfs_inode_item *inode_item;
struct extent_buffer *leaf;
+ unsigned int nofs_flag;
int mod;
int ret;
@@ -1053,7 +1061,9 @@ static int __btrfs_update_delayed_inode(struct btrfs_trans_handle *trans,
else
mod = 1;
+ nofs_flag = memalloc_nofs_save();
ret = btrfs_lookup_inode(trans, root, path, &key, mod);
+ memalloc_nofs_restore(nofs_flag);
if (ret > 0) {
btrfs_release_path(path);
return -ENOENT;
@@ -1104,7 +1114,10 @@ static int __btrfs_update_delayed_inode(struct btrfs_trans_handle *trans,
key.type = BTRFS_INODE_EXTREF_KEY;
key.offset = -1;
+
+ nofs_flag = memalloc_nofs_save();
ret = btrfs_search_slot(trans, root, &key, path, -1, 1);
+ memalloc_nofs_restore(nofs_flag);
if (ret < 0)
goto err_out;
ASSERT(ret);
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 097/199] dm zoned: remove duplicate nr_rnd_zones increase in dmz_init_zone()
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (95 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 096/199] btrfs: use nofs allocations for running delayed items Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 098/199] crypto: caam - update xts sector size for large input length Greg Kroah-Hartman
` (33 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bob Liu, Damien Le Moal,
Mike Snitzer, Sasha Levin
From: Bob Liu <bob.liu@oracle.com>
[ Upstream commit b8fdd090376a7a46d17db316638fe54b965c2fb0 ]
zmd->nr_rnd_zones was increased twice by mistake. The other place it
is increased in dmz_init_zone() is the only one needed:
1131 zmd->nr_useable_zones++;
1132 if (dmz_is_rnd(zone)) {
1133 zmd->nr_rnd_zones++;
^^^
Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target")
Cc: stable@vger.kernel.org
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/md/dm-zoned-metadata.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/md/dm-zoned-metadata.c b/drivers/md/dm-zoned-metadata.c
index e3b67b145027b..4d658a0c60258 100644
--- a/drivers/md/dm-zoned-metadata.c
+++ b/drivers/md/dm-zoned-metadata.c
@@ -1105,7 +1105,6 @@ static int dmz_init_zone(struct dmz_metadata *zmd, struct dm_zone *zone,
if (blkz->type == BLK_ZONE_TYPE_CONVENTIONAL) {
set_bit(DMZ_RND, &zone->flags);
- zmd->nr_rnd_zones++;
} else if (blkz->type == BLK_ZONE_TYPE_SEQWRITE_REQ ||
blkz->type == BLK_ZONE_TYPE_SEQWRITE_PREF) {
set_bit(DMZ_SEQ, &zone->flags);
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 098/199] crypto: caam - update xts sector size for large input length
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (96 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 097/199] dm zoned: remove duplicate nr_rnd_zones increase in dmz_init_zone() Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 099/199] drm/dp_mst: Fix clearing payload state on topology disable Greg Kroah-Hartman
` (32 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andrei Botila, Horia Geantă,
Herbert Xu, Sasha Levin
From: Andrei Botila <andrei.botila@nxp.com>
[ Upstream commit 3f142b6a7b573bde6cff926f246da05652c61eb4 ]
Since in the software implementation of XTS-AES there is
no notion of sector every input length is processed the same way.
CAAM implementation has the notion of sector which causes different
results between the software implementation and the one in CAAM
for input lengths bigger than 512 bytes.
Increase sector size to maximum value on 16 bits.
Fixes: c6415a6016bf ("crypto: caam - add support for acipher xts(aes)")
Cc: <stable@vger.kernel.org> # v4.12+
Signed-off-by: Andrei Botila <andrei.botila@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/crypto/caam/caamalg_desc.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/caam/caamalg_desc.c b/drivers/crypto/caam/caamalg_desc.c
index b23c7b72525c0..a3d507fb9ea5a 100644
--- a/drivers/crypto/caam/caamalg_desc.c
+++ b/drivers/crypto/caam/caamalg_desc.c
@@ -1280,7 +1280,13 @@ EXPORT_SYMBOL(cnstr_shdsc_ablkcipher_givencap);
*/
void cnstr_shdsc_xts_ablkcipher_encap(u32 * const desc, struct alginfo *cdata)
{
- __be64 sector_size = cpu_to_be64(512);
+ /*
+ * Set sector size to a big value, practically disabling
+ * sector size segmentation in xts implementation. We cannot
+ * take full advantage of this HW feature with existing
+ * crypto API / dm-crypt SW architecture.
+ */
+ __be64 sector_size = cpu_to_be64(BIT(15));
u32 *key_jump_cmd;
init_sh_desc(desc, HDR_SHARE_SERIAL | HDR_SAVECTX);
@@ -1332,7 +1338,13 @@ EXPORT_SYMBOL(cnstr_shdsc_xts_ablkcipher_encap);
*/
void cnstr_shdsc_xts_ablkcipher_decap(u32 * const desc, struct alginfo *cdata)
{
- __be64 sector_size = cpu_to_be64(512);
+ /*
+ * Set sector size to a big value, practically disabling
+ * sector size segmentation in xts implementation. We cannot
+ * take full advantage of this HW feature with existing
+ * crypto API / dm-crypt SW architecture.
+ */
+ __be64 sector_size = cpu_to_be64(BIT(15));
u32 *key_jump_cmd;
init_sh_desc(desc, HDR_SHARE_SERIAL | HDR_SAVECTX);
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 099/199] drm/dp_mst: Fix clearing payload state on topology disable
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (97 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 098/199] crypto: caam - update xts sector size for large input length Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 100/199] drm: Remove PageReserved manipulation from drm_pci_alloc Greg Kroah-Hartman
` (31 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sean Paul, Wayne Lin,
Ville Syrjälä,
Lyude Paul, Sasha Levin
From: Lyude Paul <lyude@redhat.com>
[ Upstream commit 8732fe46b20c951493bfc4dba0ad08efdf41de81 ]
The issues caused by:
commit 64e62bdf04ab ("drm/dp_mst: Remove VCPI while disabling topology
mgr")
Prompted me to take a closer look at how we clear the payload state in
general when disabling the topology, and it turns out there's actually
two subtle issues here.
The first is that we're not grabbing &mgr.payload_lock when clearing the
payloads in drm_dp_mst_topology_mgr_set_mst(). Seeing as the canonical
lock order is &mgr.payload_lock -> &mgr.lock (because we always want
&mgr.lock to be the inner-most lock so topology validation always
works), this makes perfect sense. It also means that -technically- there
could be racing between someone calling
drm_dp_mst_topology_mgr_set_mst() to disable the topology, along with a
modeset occurring that's modifying the payload state at the same time.
The second is the more obvious issue that Wayne Lin discovered, that
we're not clearing proposed_payloads when disabling the topology.
I actually can't see any obvious places where the racing caused by the
first issue would break something, and it could be that some of our
higher-level locks already prevent this by happenstance, but better safe
then sorry. So, let's make it so that drm_dp_mst_topology_mgr_set_mst()
first grabs &mgr.payload_lock followed by &mgr.lock so that we never
race when modifying the payload state. Then, we also clear
proposed_payloads to fix the original issue of enabling a new topology
with a dirty payload state. This doesn't clear any of the drm_dp_vcpi
structures, but those are getting destroyed along with the ports anyway.
Changes since v1:
* Use sizeof(mgr->payloads[0])/sizeof(mgr->proposed_vcpis[0]) instead -
vsyrjala
Cc: Sean Paul <sean@poorly.run>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200122194321.14953-1-lyude@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
index f0d819fc16cd7..db0e9ce57e29a 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2038,6 +2038,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool ms
int ret = 0;
struct drm_dp_mst_branch *mstb = NULL;
+ mutex_lock(&mgr->payload_lock);
mutex_lock(&mgr->lock);
if (mst_state == mgr->mst_state)
goto out_unlock;
@@ -2096,7 +2097,10 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool ms
/* this can fail if the device is gone */
drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL, 0);
ret = 0;
- memset(mgr->payloads, 0, mgr->max_payloads * sizeof(struct drm_dp_payload));
+ memset(mgr->payloads, 0,
+ mgr->max_payloads * sizeof(mgr->payloads[0]));
+ memset(mgr->proposed_vcpis, 0,
+ mgr->max_payloads * sizeof(mgr->proposed_vcpis[0]));
mgr->payload_mask = 0;
set_bit(0, &mgr->payload_mask);
mgr->vcpi_mask = 0;
@@ -2104,6 +2108,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool ms
out_unlock:
mutex_unlock(&mgr->lock);
+ mutex_unlock(&mgr->payload_lock);
if (mstb)
drm_dp_put_mst_branch_device(mstb);
return ret;
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 100/199] drm: Remove PageReserved manipulation from drm_pci_alloc
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (98 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 099/199] drm/dp_mst: Fix clearing payload state on topology disable Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 101/199] ftrace/kprobe: Show the maxactive number on kprobe_events Greg Kroah-Hartman
` (30 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chris Wilson, Alex Deucher, Sasha Levin
From: Chris Wilson <chris@chris-wilson.co.uk>
[ Upstream commit ea36ec8623f56791c6ff6738d0509b7920f85220 ]
drm_pci_alloc/drm_pci_free are very thin wrappers around the core dma
facilities, and we have no special reason within the drm layer to behave
differently. In particular, since
commit de09d31dd38a50fdce106c15abd68432eebbd014
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date: Fri Jan 15 16:51:42 2016 -0800
page-flags: define PG_reserved behavior on compound pages
As far as I can see there's no users of PG_reserved on compound pages.
Let's use PF_NO_COMPOUND here.
it has been illegal to combine GFP_COMP with SetPageReserved, so lets
stop doing both and leave the dma layer to its own devices.
Reported-by: Taketo Kabe
Bug: https://gitlab.freedesktop.org/drm/intel/issues/1027
Fixes: de09d31dd38a ("page-flags: define PG_reserved behavior on compound pages")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v4.5+
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200202171635.4039044-1-chris@chris-wilson.co.uk
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/drm_pci.c | 25 ++-----------------------
1 file changed, 2 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 1235c9877d6f1..2078d7706a67b 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -46,8 +46,6 @@
drm_dma_handle_t *drm_pci_alloc(struct drm_device * dev, size_t size, size_t align)
{
drm_dma_handle_t *dmah;
- unsigned long addr;
- size_t sz;
/* pci_alloc_consistent only guarantees alignment to the smallest
* PAGE_SIZE order which is greater than or equal to the requested size.
@@ -61,22 +59,13 @@ drm_dma_handle_t *drm_pci_alloc(struct drm_device * dev, size_t size, size_t ali
return NULL;
dmah->size = size;
- dmah->vaddr = dma_alloc_coherent(&dev->pdev->dev, size, &dmah->busaddr, GFP_KERNEL | __GFP_COMP);
+ dmah->vaddr = dma_alloc_coherent(&dev->pdev->dev, size, &dmah->busaddr, GFP_KERNEL);
if (dmah->vaddr == NULL) {
kfree(dmah);
return NULL;
}
- memset(dmah->vaddr, 0, size);
-
- /* XXX - Is virt_to_page() legal for consistent mem? */
- /* Reserve */
- for (addr = (unsigned long)dmah->vaddr, sz = size;
- sz > 0; addr += PAGE_SIZE, sz -= PAGE_SIZE) {
- SetPageReserved(virt_to_page((void *)addr));
- }
-
return dmah;
}
@@ -89,19 +78,9 @@ EXPORT_SYMBOL(drm_pci_alloc);
*/
void __drm_legacy_pci_free(struct drm_device * dev, drm_dma_handle_t * dmah)
{
- unsigned long addr;
- size_t sz;
-
- if (dmah->vaddr) {
- /* XXX - Is virt_to_page() legal for consistent mem? */
- /* Unreserve */
- for (addr = (unsigned long)dmah->vaddr, sz = dmah->size;
- sz > 0; addr += PAGE_SIZE, sz -= PAGE_SIZE) {
- ClearPageReserved(virt_to_page((void *)addr));
- }
+ if (dmah->vaddr)
dma_free_coherent(&dev->pdev->dev, dmah->size, dmah->vaddr,
dmah->busaddr);
- }
}
/**
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 101/199] ftrace/kprobe: Show the maxactive number on kprobe_events
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (99 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 100/199] drm: Remove PageReserved manipulation from drm_pci_alloc Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 102/199] ipmi: fix hung processes in __get_guid() Greg Kroah-Hartman
` (29 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Taeung Song, Masami Hiramatsu,
Steven Rostedt (VMware),
Sasha Levin
From: Masami Hiramatsu <mhiramat@kernel.org>
[ Upstream commit 6a13a0d7b4d1171ef9b80ad69abc37e1daa941b3 ]
Show maxactive parameter on kprobe_events.
This allows user to save the current configuration and
restore it without losing maxactive parameter.
Link: http://lkml.kernel.org/r/4762764a-6df7-bc93-ed60-e336146dce1f@gmail.com
Link: http://lkml.kernel.org/r/158503528846.22706.5549974121212526020.stgit@devnote2
Cc: stable@vger.kernel.org
Fixes: 696ced4fb1d76 ("tracing/kprobes: expose maxactive for kretprobe in kprobe_events")
Reported-by: Taeung Song <treeze.taeung@gmail.com>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/trace/trace_kprobe.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index ea20274a105ae..d66aed6e9c75f 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -877,6 +877,8 @@ static int probes_seq_show(struct seq_file *m, void *v)
int i;
seq_putc(m, trace_kprobe_is_return(tk) ? 'r' : 'p');
+ if (trace_kprobe_is_return(tk) && tk->rp.maxactive)
+ seq_printf(m, "%d", tk->rp.maxactive);
seq_printf(m, ":%s/%s", tk->tp.call.class->system,
trace_event_name(&tk->tp.call));
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 102/199] ipmi: fix hung processes in __get_guid()
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (100 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 101/199] ftrace/kprobe: Show the maxactive number on kprobe_events Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 103/199] powerpc/fsl_booke: Avoid creating duplicate tlb1 entry Greg Kroah-Hartman
` (28 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Wen Yang, Corey Minyard,
Arnd Bergmann, openipmi-developer, Corey Minyard, Sasha Levin
From: Wen Yang <wenyang@linux.alibaba.com>
[ Upstream commit 32830a0534700f86366f371b150b17f0f0d140d7 ]
The wait_event() function is used to detect command completion.
When send_guid_cmd() returns an error, smi_send() has not been
called to send data. Therefore, wait_event() should not be used
on the error path, otherwise it will cause the following warning:
[ 1361.588808] systemd-udevd D 0 1501 1436 0x00000004
[ 1361.588813] ffff883f4b1298c0 0000000000000000 ffff883f4b188000 ffff887f7e3d9f40
[ 1361.677952] ffff887f64bd4280 ffffc90037297a68 ffffffff8173ca3b ffffc90000000010
[ 1361.767077] 00ffc90037297ad0 ffff887f7e3d9f40 0000000000000286 ffff883f4b188000
[ 1361.856199] Call Trace:
[ 1361.885578] [<ffffffff8173ca3b>] ? __schedule+0x23b/0x780
[ 1361.951406] [<ffffffff8173cfb6>] schedule+0x36/0x80
[ 1362.010979] [<ffffffffa071f178>] get_guid+0x118/0x150 [ipmi_msghandler]
[ 1362.091281] [<ffffffff810d5350>] ? prepare_to_wait_event+0x100/0x100
[ 1362.168533] [<ffffffffa071f755>] ipmi_register_smi+0x405/0x940 [ipmi_msghandler]
[ 1362.258337] [<ffffffffa0230ae9>] try_smi_init+0x529/0x950 [ipmi_si]
[ 1362.334521] [<ffffffffa022f350>] ? std_irq_setup+0xd0/0xd0 [ipmi_si]
[ 1362.411701] [<ffffffffa0232bd2>] init_ipmi_si+0x492/0x9e0 [ipmi_si]
[ 1362.487917] [<ffffffffa0232740>] ? ipmi_pci_probe+0x280/0x280 [ipmi_si]
[ 1362.568219] [<ffffffff810021a0>] do_one_initcall+0x50/0x180
[ 1362.636109] [<ffffffff812231b2>] ? kmem_cache_alloc_trace+0x142/0x190
[ 1362.714330] [<ffffffff811b2ae1>] do_init_module+0x5f/0x200
[ 1362.781208] [<ffffffff81123ca8>] load_module+0x1898/0x1de0
[ 1362.848069] [<ffffffff811202e0>] ? __symbol_put+0x60/0x60
[ 1362.913886] [<ffffffff8130696b>] ? security_kernel_post_read_file+0x6b/0x80
[ 1362.998514] [<ffffffff81124465>] SYSC_finit_module+0xe5/0x120
[ 1363.068463] [<ffffffff81124465>] ? SYSC_finit_module+0xe5/0x120
[ 1363.140513] [<ffffffff811244be>] SyS_finit_module+0xe/0x10
[ 1363.207364] [<ffffffff81003c04>] do_syscall_64+0x74/0x180
Fixes: 50c812b2b951 ("[PATCH] ipmi: add full sysfs support")
Signed-off-by: Wen Yang <wenyang@linux.alibaba.com>
Cc: Corey Minyard <minyard@acm.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: openipmi-developer@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # 2.6.17-
Message-Id: <20200403090408.58745-1-wenyang@linux.alibaba.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/char/ipmi/ipmi_msghandler.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c
index c82d9fd2f05af..f72a272eeb9b2 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -2647,7 +2647,9 @@ get_guid(ipmi_smi_t intf)
if (rv)
/* Send failed, no GUID available. */
intf->bmc->guid_set = 0;
- wait_event(intf->waitq, intf->bmc->guid_set != 2);
+ else
+ wait_event(intf->waitq, intf->bmc->guid_set != 2);
+
intf->null_user_handler = NULL;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 103/199] powerpc/fsl_booke: Avoid creating duplicate tlb1 entry
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (101 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 102/199] ipmi: fix hung processes in __get_guid() Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 104/199] misc: echo: Remove unnecessary parentheses and simplify check for zero Greg Kroah-Hartman
` (27 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Laurentiu Tudor, Scott Wood,
Michael Ellerman, Sasha Levin
From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
[ Upstream commit aa4113340ae6c2811e046f08c2bc21011d20a072 ]
In the current implementation, the call to loadcam_multi() is wrapped
between switch_to_as1() and restore_to_as0() calls so, when it tries
to create its own temporary AS=1 TLB1 entry, it ends up duplicating
the existing one created by switch_to_as1(). Add a check to skip
creating the temporary entry if already running in AS=1.
Fixes: d9e1831a4202 ("powerpc/85xx: Load all early TLB entries at once")
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Acked-by: Scott Wood <oss@buserror.net>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200123111914.2565-1-laurentiu.tudor@nxp.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/mm/tlb_nohash_low.S | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/tlb_nohash_low.S b/arch/powerpc/mm/tlb_nohash_low.S
index 048b8e9f44928..63964af9a162e 100644
--- a/arch/powerpc/mm/tlb_nohash_low.S
+++ b/arch/powerpc/mm/tlb_nohash_low.S
@@ -400,7 +400,7 @@ _GLOBAL(set_context)
* extern void loadcam_entry(unsigned int index)
*
* Load TLBCAM[index] entry in to the L2 CAM MMU
- * Must preserve r7, r8, r9, and r10
+ * Must preserve r7, r8, r9, r10 and r11
*/
_GLOBAL(loadcam_entry)
mflr r5
@@ -436,6 +436,10 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
*/
_GLOBAL(loadcam_multi)
mflr r8
+ /* Don't switch to AS=1 if already there */
+ mfmsr r11
+ andi. r11,r11,MSR_IS
+ bne 10f
/*
* Set up temporary TLB entry that is the same as what we're
@@ -461,6 +465,7 @@ _GLOBAL(loadcam_multi)
mtmsr r6
isync
+10:
mr r9,r3
add r10,r3,r4
2: bl loadcam_entry
@@ -469,6 +474,10 @@ _GLOBAL(loadcam_multi)
mr r3,r9
blt 2b
+ /* Don't return to AS=0 if we were in AS=1 at function start */
+ andi. r11,r11,MSR_IS
+ bne 3f
+
/* Return to AS=0 and clear the temporary entry */
mfmsr r6
rlwinm. r6,r6,0,~(MSR_IS|MSR_DS)
@@ -484,6 +493,7 @@ _GLOBAL(loadcam_multi)
tlbwe
isync
+3:
mtlr r8
blr
#endif
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 104/199] misc: echo: Remove unnecessary parentheses and simplify check for zero
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (102 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 103/199] powerpc/fsl_booke: Avoid creating duplicate tlb1 entry Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 105/199] mfd: dln2: Fix sanity checking for endpoints Greg Kroah-Hartman
` (26 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nick Desaulniers, Nathan Chancellor,
Sasha Levin
From: Nathan Chancellor <natechancellor@gmail.com>
[ Upstream commit 85dc2c65e6c975baaf36ea30f2ccc0a36a8c8add ]
Clang warns when multiple pairs of parentheses are used for a single
conditional statement.
drivers/misc/echo/echo.c:384:27: warning: equality comparison with
extraneous parentheses [-Wparentheses-equality]
if ((ec->nonupdate_dwell == 0)) {
~~~~~~~~~~~~~~~~~~~~^~~~
drivers/misc/echo/echo.c:384:27: note: remove extraneous parentheses
around the comparison to silence this warning
if ((ec->nonupdate_dwell == 0)) {
~ ^ ~
drivers/misc/echo/echo.c:384:27: note: use '=' to turn this equality
comparison into an assignment
if ((ec->nonupdate_dwell == 0)) {
^~
=
1 warning generated.
Remove them and while we're at it, simplify the zero check as '!var' is
used more than 'var == 0'.
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/misc/echo/echo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/echo/echo.c b/drivers/misc/echo/echo.c
index 9597e9523cac4..fff13176f9b8b 100644
--- a/drivers/misc/echo/echo.c
+++ b/drivers/misc/echo/echo.c
@@ -454,7 +454,7 @@ int16_t oslec_update(struct oslec_state *ec, int16_t tx, int16_t rx)
*/
ec->factor = 0;
ec->shift = 0;
- if ((ec->nonupdate_dwell == 0)) {
+ if (!ec->nonupdate_dwell) {
int p, logp, shift;
/* Determine:
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 105/199] mfd: dln2: Fix sanity checking for endpoints
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (103 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 104/199] misc: echo: Remove unnecessary parentheses and simplify check for zero Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 106/199] amd-xgbe: Use __napi_schedule() in BH context Greg Kroah-Hartman
` (25 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Oliver Neukum, Andy Shevchenko,
Lee Jones, Sasha Levin
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[ Upstream commit fb945c95a482200876993977008b67ea658bd938 ]
While the commit 2b8bd606b1e6 ("mfd: dln2: More sanity checking for endpoints")
tries to harden the sanity checks it made at the same time a regression,
i.e. mixed in and out endpoints. Obviously it should have been not tested on
real hardware at that time, but unluckily it didn't happen.
So, fix above mentioned typo and make device being enumerated again.
While here, introduce an enumerator for magic values to prevent similar issue
to happen in the future.
Fixes: 2b8bd606b1e6 ("mfd: dln2: More sanity checking for endpoints")
Cc: Oliver Neukum <oneukum@suse.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/mfd/dln2.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
index 95d0f2df0ad42..672831d5ee32e 100644
--- a/drivers/mfd/dln2.c
+++ b/drivers/mfd/dln2.c
@@ -93,6 +93,11 @@ struct dln2_mod_rx_slots {
spinlock_t lock;
};
+enum dln2_endpoint {
+ DLN2_EP_OUT = 0,
+ DLN2_EP_IN = 1,
+};
+
struct dln2_dev {
struct usb_device *usb_dev;
struct usb_interface *interface;
@@ -740,10 +745,10 @@ static int dln2_probe(struct usb_interface *interface,
hostif->desc.bNumEndpoints < 2)
return -ENODEV;
- epin = &hostif->endpoint[0].desc;
- epout = &hostif->endpoint[1].desc;
+ epout = &hostif->endpoint[DLN2_EP_OUT].desc;
if (!usb_endpoint_is_bulk_out(epout))
return -ENODEV;
+ epin = &hostif->endpoint[DLN2_EP_IN].desc;
if (!usb_endpoint_is_bulk_in(epin))
return -ENODEV;
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 106/199] amd-xgbe: Use __napi_schedule() in BH context
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (104 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 105/199] mfd: dln2: Fix sanity checking for endpoints Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 107/199] hsr: check protocol version in hsr_newlink() Greg Kroah-Hartman
` (24 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sebastian Andrzej Siewior,
Tom Lendacky, David S. Miller
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
[ Upstream commit d518691cbd3be3dae218e05cca3f3fc9b2f1aa77 ]
The driver uses __napi_schedule_irqoff() which is fine as long as it is
invoked with disabled interrupts by everybody. Since the commit
mentioned below the driver may invoke xgbe_isr_task() in tasklet/softirq
context. This may lead to list corruption if another driver uses
__napi_schedule_irqoff() in IRQ context.
Use __napi_schedule() which safe to use from IRQ and softirq context.
Fixes: 85b85c853401d ("amd-xgbe: Re-issue interrupt if interrupt status not cleared")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -515,7 +515,7 @@ static void xgbe_isr_task(unsigned long
xgbe_disable_rx_tx_ints(pdata);
/* Turn on polling */
- __napi_schedule_irqoff(&pdata->napi);
+ __napi_schedule(&pdata->napi);
}
} else {
/* Don't clear Rx/Tx status if doing per channel DMA
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 107/199] hsr: check protocol version in hsr_newlink()
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (105 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 106/199] amd-xgbe: Use __napi_schedule() in BH context Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 108/199] net: ipv4: devinet: Fix crash when add/del multicast IP with autojoin Greg Kroah-Hartman
` (23 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Taehee Yoo, David S. Miller
From: Taehee Yoo <ap420073@gmail.com>
[ Upstream commit 4faab8c446def7667adf1f722456c2f4c304069c ]
In the current hsr code, only 0 and 1 protocol versions are valid.
But current hsr code doesn't check the version, which is received by
userspace.
Test commands:
ip link add dummy0 type dummy
ip link add dummy1 type dummy
ip link add hsr0 type hsr slave1 dummy0 slave2 dummy1 version 4
In the test commands, version 4 is invalid.
So, the command should be failed.
After this patch, following error will occur.
"Error: hsr: Only versions 0..1 are supported."
Fixes: ee1c27977284 ("net/hsr: Added support for HSR v1")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/hsr/hsr_netlink.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/net/hsr/hsr_netlink.c
+++ b/net/hsr/hsr_netlink.c
@@ -64,10 +64,16 @@ static int hsr_newlink(struct net *src_n
else
multicast_spec = nla_get_u8(data[IFLA_HSR_MULTICAST_SPEC]);
- if (!data[IFLA_HSR_VERSION])
+ if (!data[IFLA_HSR_VERSION]) {
hsr_version = 0;
- else
+ } else {
hsr_version = nla_get_u8(data[IFLA_HSR_VERSION]);
+ if (hsr_version > 1) {
+ NL_SET_ERR_MSG_MOD(extack,
+ "Only versions 0..1 are supported");
+ return -EINVAL;
+ }
+ }
return hsr_dev_finalize(dev, link, multicast_spec, hsr_version);
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 108/199] net: ipv4: devinet: Fix crash when add/del multicast IP with autojoin
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (106 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 107/199] hsr: check protocol version in hsr_newlink() Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 109/199] net: ipv6: do not consider routes via gateways for anycast address check Greg Kroah-Hartman
` (22 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Taras Chornyi, Vadym Kochan, David S. Miller
From: Taras Chornyi <taras.chornyi@plvision.eu>
[ Upstream commit 690cc86321eb9bcee371710252742fb16fe96824 ]
When CONFIG_IP_MULTICAST is not set and multicast ip is added to the device
with autojoin flag or when multicast ip is deleted kernel will crash.
steps to reproduce:
ip addr add 224.0.0.0/32 dev eth0
ip addr del 224.0.0.0/32 dev eth0
or
ip addr add 224.0.0.0/32 dev eth0 autojoin
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088
pc : _raw_write_lock_irqsave+0x1e0/0x2ac
lr : lock_sock_nested+0x1c/0x60
Call trace:
_raw_write_lock_irqsave+0x1e0/0x2ac
lock_sock_nested+0x1c/0x60
ip_mc_config.isra.28+0x50/0xe0
inet_rtm_deladdr+0x1a8/0x1f0
rtnetlink_rcv_msg+0x120/0x350
netlink_rcv_skb+0x58/0x120
rtnetlink_rcv+0x14/0x20
netlink_unicast+0x1b8/0x270
netlink_sendmsg+0x1a0/0x3b0
____sys_sendmsg+0x248/0x290
___sys_sendmsg+0x80/0xc0
__sys_sendmsg+0x68/0xc0
__arm64_sys_sendmsg+0x20/0x30
el0_svc_common.constprop.2+0x88/0x150
do_el0_svc+0x20/0x80
el0_sync_handler+0x118/0x190
el0_sync+0x140/0x180
Fixes: 93a714d6b53d ("multicast: Extend ip address command to enable multicast group join/leave on")
Signed-off-by: Taras Chornyi <taras.chornyi@plvision.eu>
Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/devinet.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -579,12 +579,15 @@ struct in_ifaddr *inet_ifa_byprefix(stru
return NULL;
}
-static int ip_mc_config(struct sock *sk, bool join, const struct in_ifaddr *ifa)
+static int ip_mc_autojoin_config(struct net *net, bool join,
+ const struct in_ifaddr *ifa)
{
+#if defined(CONFIG_IP_MULTICAST)
struct ip_mreqn mreq = {
.imr_multiaddr.s_addr = ifa->ifa_address,
.imr_ifindex = ifa->ifa_dev->dev->ifindex,
};
+ struct sock *sk = net->ipv4.mc_autojoin_sk;
int ret;
ASSERT_RTNL();
@@ -597,6 +600,9 @@ static int ip_mc_config(struct sock *sk,
release_sock(sk);
return ret;
+#else
+ return -EOPNOTSUPP;
+#endif
}
static int inet_rtm_deladdr(struct sk_buff *skb, struct nlmsghdr *nlh,
@@ -638,7 +644,7 @@ static int inet_rtm_deladdr(struct sk_bu
continue;
if (ipv4_is_multicast(ifa->ifa_address))
- ip_mc_config(net->ipv4.mc_autojoin_sk, false, ifa);
+ ip_mc_autojoin_config(net, false, ifa);
__inet_del_ifa(in_dev, ifap, 1, nlh, NETLINK_CB(skb).portid);
return 0;
}
@@ -896,8 +902,7 @@ static int inet_rtm_newaddr(struct sk_bu
*/
set_ifa_lifetime(ifa, valid_lft, prefered_lft);
if (ifa->ifa_flags & IFA_F_MCAUTOJOIN) {
- int ret = ip_mc_config(net->ipv4.mc_autojoin_sk,
- true, ifa);
+ int ret = ip_mc_autojoin_config(net, true, ifa);
if (ret < 0) {
inet_free_ifa(ifa);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 109/199] net: ipv6: do not consider routes via gateways for anycast address check
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (107 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 108/199] net: ipv4: devinet: Fix crash when add/del multicast IP with autojoin Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 110/199] net: qrtr: send msgs from local of same id as broadcast Greg Kroah-Hartman
` (21 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Tim Stallard, David S. Miller
From: Tim Stallard <code@timstallard.me.uk>
[ Upstream commit 03e2a984b6165621f287fadf5f4b5cd8b58dcaba ]
The behaviour for what is considered an anycast address changed in
commit 45e4fd26683c ("ipv6: Only create RTF_CACHE routes after
encountering pmtu exception"). This now considers the first
address in a subnet where there is a route via a gateway
to be an anycast address.
This breaks path MTU discovery and traceroutes when a host in a
remote network uses the address at the start of a prefix
(eg 2600:: advertised as 2600::/48 in the DFZ) as ICMP errors
will not be sent to anycast addresses.
This patch excludes any routes with a gateway, or via point to
point links, like the behaviour previously from
rt6_is_gw_or_nonexthop in net/ipv6/route.c.
This can be tested with:
ip link add v1 type veth peer name v2
ip netns add test
ip netns exec test ip link set lo up
ip link set v2 netns test
ip link set v1 up
ip netns exec test ip link set v2 up
ip addr add 2001:db8::1/64 dev v1 nodad
ip addr add 2001:db8:100:: dev lo nodad
ip netns exec test ip addr add 2001:db8::2/64 dev v2 nodad
ip netns exec test ip route add unreachable 2001:db8:1::1
ip netns exec test ip route add 2001:db8:100::/64 via 2001:db8::1
ip netns exec test sysctl net.ipv6.conf.all.forwarding=1
ip route add 2001:db8:1::1 via 2001:db8::2
ping -I 2001:db8::1 2001:db8:1::1 -c1
ping -I 2001:db8:100:: 2001:db8:1::1 -c1
ip addr delete 2001:db8:100:: dev lo
ip netns delete test
Currently the first ping will get back a destination unreachable ICMP
error, but the second will never get a response, with "icmp6_send:
acast source" logged. After this patch, both get destination
unreachable ICMP replies.
Fixes: 45e4fd26683c ("ipv6: Only create RTF_CACHE routes after encountering pmtu exception")
Signed-off-by: Tim Stallard <code@timstallard.me.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/ip6_route.h | 1 +
1 file changed, 1 insertion(+)
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -207,6 +207,7 @@ static inline bool ipv6_anycast_destinat
return rt->rt6i_flags & RTF_ANYCAST ||
(rt->rt6i_dst.plen < 127 &&
+ !(rt->rt6i_flags & (RTF_GATEWAY | RTF_NONEXTHOP)) &&
ipv6_addr_equal(&rt->rt6i_dst.addr, daddr));
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 110/199] net: qrtr: send msgs from local of same id as broadcast
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (108 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 109/199] net: ipv6: do not consider routes via gateways for anycast address check Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 111/199] net: revert default NAPI poll timeout to 2 jiffies Greg Kroah-Hartman
` (20 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Wang Wenhu, David S. Miller
From: Wang Wenhu <wenhu.wang@vivo.com>
[ Upstream commit 6dbf02acef69b0742c238574583b3068afbd227c ]
If the local node id(qrtr_local_nid) is not modified after its
initialization, it equals to the broadcast node id(QRTR_NODE_BCAST).
So the messages from local node should not be taken as broadcast
and keep the process going to send them out anyway.
The definitions are as follow:
static unsigned int qrtr_local_nid = NUMA_NO_NODE;
Fixes: fdf5fd397566 ("net: qrtr: Broadcast messages only from control port")
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/qrtr/qrtr.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
@@ -710,20 +710,21 @@ static int qrtr_sendmsg(struct socket *s
node = NULL;
if (addr->sq_node == QRTR_NODE_BCAST) {
- enqueue_fn = qrtr_bcast_enqueue;
- if (addr->sq_port != QRTR_PORT_CTRL) {
+ if (addr->sq_port != QRTR_PORT_CTRL &&
+ qrtr_local_nid != QRTR_NODE_BCAST) {
release_sock(sk);
return -ENOTCONN;
}
+ enqueue_fn = qrtr_bcast_enqueue;
} else if (addr->sq_node == ipc->us.sq_node) {
enqueue_fn = qrtr_local_enqueue;
} else {
- enqueue_fn = qrtr_node_enqueue;
node = qrtr_node_lookup(addr->sq_node);
if (!node) {
release_sock(sk);
return -ECONNRESET;
}
+ enqueue_fn = qrtr_node_enqueue;
}
plen = (len + 3) & ~3;
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 111/199] net: revert default NAPI poll timeout to 2 jiffies
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (109 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 110/199] net: qrtr: send msgs from local of same id as broadcast Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 112/199] net: stmmac: dwmac-sunxi: Provide TX and RX fifo sizes Greg Kroah-Hartman
` (19 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dmitry Yakunin,
Konstantin Khlebnikov, David S. Miller
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
[ Upstream commit a4837980fd9fa4c70a821d11831698901baef56b ]
For HZ < 1000 timeout 2000us rounds up to 1 jiffy but expires randomly
because next timer interrupt could come shortly after starting softirq.
For commonly used CONFIG_HZ=1000 nothing changes.
Fixes: 7acf8a1e8a28 ("Replace 2 jiffies with sysctl netdev_budget_usecs to enable softirq tuning")
Reported-by: Dmitry Yakunin <zeil@yandex-team.ru>
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/dev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3575,7 +3575,8 @@ EXPORT_SYMBOL(netdev_max_backlog);
int netdev_tstamp_prequeue __read_mostly = 1;
int netdev_budget __read_mostly = 300;
-unsigned int __read_mostly netdev_budget_usecs = 2000;
+/* Must be at least 2 jiffes to guarantee 1 jiffy timeout */
+unsigned int __read_mostly netdev_budget_usecs = 2 * USEC_PER_SEC / HZ;
int weight_p __read_mostly = 64; /* old backlog weight */
int dev_weight_rx_bias __read_mostly = 1; /* bias for backlog weight */
int dev_weight_tx_bias __read_mostly = 1; /* bias for output_queue quota */
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 112/199] net: stmmac: dwmac-sunxi: Provide TX and RX fifo sizes
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (110 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 111/199] net: revert default NAPI poll timeout to 2 jiffies Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 113/199] scsi: ufs: Fix ufshcd_hold() caused scheduling while atomic Greg Kroah-Hartman
` (18 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chen-Yu Tsai, Florian Fainelli,
David S. Miller
From: Florian Fainelli <f.fainelli@gmail.com>
[ Upstream commit 806fd188ce2a4f8b587e83e73c478e6484fbfa55 ]
After commit bfcb813203e619a8960a819bf533ad2a108d8105 ("net: dsa:
configure the MTU for switch ports") my Lamobo R1 platform which uses
an allwinner,sun7i-a20-gmac compatible Ethernet MAC started to fail
by rejecting a MTU of 1536. The reason for that is that the DMA
capabilities are not readable on this version of the IP, and there
is also no 'tx-fifo-depth' property being provided in Device Tree. The
property is documented as optional, and is not provided.
Chen-Yu indicated that the FIFO sizes are 4KB for TX and 16KB for RX, so
provide these values through platform data as an immediate fix until
various Device Tree sources get updated accordingly.
Fixes: eaf4fac47807 ("net: stmmac: Do not accept invalid MTU values")
Suggested-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
@@ -155,6 +155,8 @@ static int sun7i_gmac_probe(struct platf
plat_dat->init = sun7i_gmac_init;
plat_dat->exit = sun7i_gmac_exit;
plat_dat->fix_mac_speed = sun7i_fix_speed;
+ plat_dat->tx_fifo_size = 4096;
+ plat_dat->rx_fifo_size = 16384;
ret = sun7i_gmac_init(pdev, plat_dat->bsp_priv);
if (ret)
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 113/199] scsi: ufs: Fix ufshcd_hold() caused scheduling while atomic
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (111 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 112/199] net: stmmac: dwmac-sunxi: Provide TX and RX fifo sizes Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 114/199] jbd2: improve comments about freeing data buffers whose page mapping is NULL Greg Kroah-Hartman
` (17 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hongwu Su, Asutosh Das, Bean Huo,
Stanley Chu, Can Guo, Martin K. Petersen
From: Can Guo <cang@codeaurora.org>
commit c63d6099a7959ecc919b2549dc6b71f53521f819 upstream.
The async version of ufshcd_hold(async == true), which is only called in
queuecommand path as for now, is expected to work in atomic context, thus
it should not sleep or schedule out. When it runs into the condition that
clocks are ON but link is still in hibern8 state, it should bail out
without flushing the clock ungate work.
Fixes: f2a785ac2312 ("scsi: ufshcd: Fix race between clk scaling and ungate work")
Link: https://lore.kernel.org/r/1581392451-28743-6-git-send-email-cang@codeaurora.org
Reviewed-by: Hongwu Su <hongwus@codeaurora.org>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/ufs/ufshcd.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1448,6 +1448,11 @@ start:
*/
if (ufshcd_can_hibern8_during_gating(hba) &&
ufshcd_is_link_hibern8(hba)) {
+ if (async) {
+ rc = -EAGAIN;
+ hba->clk_gating.active_reqs--;
+ break;
+ }
spin_unlock_irqrestore(hba->host->host_lock, flags);
flush_work(&hba->clk_gating.ungate_work);
spin_lock_irqsave(hba->host->host_lock, flags);
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 114/199] jbd2: improve comments about freeing data buffers whose page mapping is NULL
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (112 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 113/199] scsi: ufs: Fix ufshcd_hold() caused scheduling while atomic Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 115/199] pwm: pca9685: Fix PWM/GPIO inter-operation Greg Kroah-Hartman
` (16 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jan Kara, zhangyi (F), Theodore Tso
From: zhangyi (F) <yi.zhang@huawei.com>
commit 780f66e59231fcf882f36c63f287252ee47cc75a upstream.
Improve comments in jbd2_journal_commit_transaction() to describe why
we don't need to clear the buffer_mapped bit for freeing file mapping
buffers whose page mapping is NULL.
Link: https://lore.kernel.org/r/20200217112706.20085-1-yi.zhang@huawei.com
Fixes: c96dceeabf76 ("jbd2: do not clear the BH_Mapped flag when forgetting a metadata buffer")
Suggested-by: Jan Kara <jack@suse.cz>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/jbd2/commit.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/fs/jbd2/commit.c
+++ b/fs/jbd2/commit.c
@@ -994,9 +994,10 @@ restart_loop:
* journalled data) we need to unmap buffer and clear
* more bits. We also need to be careful about the check
* because the data page mapping can get cleared under
- * out hands, which alse need not to clear more bits
- * because the page and buffers will be freed and can
- * never be reused once we are done with them.
+ * our hands. Note that if mapping == NULL, we don't
+ * need to make buffer unmapped because the page is
+ * already detached from the mapping and buffers cannot
+ * get reused.
*/
mapping = READ_ONCE(bh->b_page->mapping);
if (mapping && !sb_is_blkdev_sb(mapping->host->i_sb)) {
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 115/199] pwm: pca9685: Fix PWM/GPIO inter-operation
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (113 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 114/199] jbd2: improve comments about freeing data buffers whose page mapping is NULL Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 116/199] ext4: fix incorrect group count in ext4_fill_super error message Greg Kroah-Hartman
` (15 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, YueHaibing, Mika Westerberg,
Uwe Kleine-König, Sven Van Asbroeck, Clemens Gruber,
Thierry Reding
From: Sven Van Asbroeck <TheSven73@gmail.com>
commit 9cc5f232a4b6a0ef6e9b57876d61b88f61bdd7c2 upstream.
This driver allows pwms to be requested as gpios via gpiolib. Obviously,
it should not be allowed to request a GPIO when its corresponding PWM is
already requested (and vice versa). So it requires some exclusion code.
Given that the PWMm and GPIO cores are not synchronized with respect to
each other, this exclusion code will also require proper
synchronization.
Such a mechanism was in place, but was inadvertently removed by Uwe's
clean-up in commit e926b12c611c ("pwm: Clear chip_data in pwm_put()").
Upon revisiting the synchronization mechanism, we found that
theoretically, it could allow two threads to successfully request
conflicting PWMs/GPIOs.
Replace with a bitmap which tracks PWMs in-use, plus a mutex. As long as
PWM and GPIO's respective request/free functions modify the in-use
bitmap while holding the mutex, proper synchronization will be
guaranteed.
Reported-by: YueHaibing <yuehaibing@huawei.com>
Fixes: e926b12c611c ("pwm: Clear chip_data in pwm_put()")
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: YueHaibing <yuehaibing@huawei.com>
Link: https://lkml.org/lkml/2019/5/31/963
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
[cg: Tested on an i.MX6Q board with two NXP PCA9685 chips]
Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Reviewed-by: Sven Van Asbroeck <TheSven73@gmail.com> # cg's rebase
Link: https://lore.kernel.org/lkml/20200330160238.GD2817345@ulmo/
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pwm/pwm-pca9685.c | 85 +++++++++++++++++++++++++---------------------
1 file changed, 48 insertions(+), 37 deletions(-)
--- a/drivers/pwm/pwm-pca9685.c
+++ b/drivers/pwm/pwm-pca9685.c
@@ -31,6 +31,7 @@
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/pm_runtime.h>
+#include <linux/bitmap.h>
/*
* Because the PCA9685 has only one prescaler per chip, changing the period of
@@ -85,6 +86,7 @@ struct pca9685 {
#if IS_ENABLED(CONFIG_GPIOLIB)
struct mutex lock;
struct gpio_chip gpio;
+ DECLARE_BITMAP(pwms_inuse, PCA9685_MAXCHAN + 1);
#endif
};
@@ -94,51 +96,51 @@ static inline struct pca9685 *to_pca(str
}
#if IS_ENABLED(CONFIG_GPIOLIB)
-static int pca9685_pwm_gpio_request(struct gpio_chip *gpio, unsigned int offset)
+static bool pca9685_pwm_test_and_set_inuse(struct pca9685 *pca, int pwm_idx)
{
- struct pca9685 *pca = gpiochip_get_data(gpio);
- struct pwm_device *pwm;
+ bool is_inuse;
mutex_lock(&pca->lock);
-
- pwm = &pca->chip.pwms[offset];
-
- if (pwm->flags & (PWMF_REQUESTED | PWMF_EXPORTED)) {
- mutex_unlock(&pca->lock);
- return -EBUSY;
+ if (pwm_idx >= PCA9685_MAXCHAN) {
+ /*
+ * "all LEDs" channel:
+ * pretend already in use if any of the PWMs are requested
+ */
+ if (!bitmap_empty(pca->pwms_inuse, PCA9685_MAXCHAN)) {
+ is_inuse = true;
+ goto out;
+ }
+ } else {
+ /*
+ * regular channel:
+ * pretend already in use if the "all LEDs" channel is requested
+ */
+ if (test_bit(PCA9685_MAXCHAN, pca->pwms_inuse)) {
+ is_inuse = true;
+ goto out;
+ }
}
-
- pwm_set_chip_data(pwm, (void *)1);
-
+ is_inuse = test_and_set_bit(pwm_idx, pca->pwms_inuse);
+out:
mutex_unlock(&pca->lock);
- pm_runtime_get_sync(pca->chip.dev);
- return 0;
+ return is_inuse;
}
-static bool pca9685_pwm_is_gpio(struct pca9685 *pca, struct pwm_device *pwm)
+static void pca9685_pwm_clear_inuse(struct pca9685 *pca, int pwm_idx)
{
- bool is_gpio = false;
-
mutex_lock(&pca->lock);
+ clear_bit(pwm_idx, pca->pwms_inuse);
+ mutex_unlock(&pca->lock);
+}
- if (pwm->hwpwm >= PCA9685_MAXCHAN) {
- unsigned int i;
-
- /*
- * Check if any of the GPIOs are requested and in that case
- * prevent using the "all LEDs" channel.
- */
- for (i = 0; i < pca->gpio.ngpio; i++)
- if (gpiochip_is_requested(&pca->gpio, i)) {
- is_gpio = true;
- break;
- }
- } else if (pwm_get_chip_data(pwm)) {
- is_gpio = true;
- }
+static int pca9685_pwm_gpio_request(struct gpio_chip *gpio, unsigned int offset)
+{
+ struct pca9685 *pca = gpiochip_get_data(gpio);
- mutex_unlock(&pca->lock);
- return is_gpio;
+ if (pca9685_pwm_test_and_set_inuse(pca, offset))
+ return -EBUSY;
+ pm_runtime_get_sync(pca->chip.dev);
+ return 0;
}
static int pca9685_pwm_gpio_get(struct gpio_chip *gpio, unsigned int offset)
@@ -173,6 +175,7 @@ static void pca9685_pwm_gpio_free(struct
pca9685_pwm_gpio_set(gpio, offset, 0);
pm_runtime_put(pca->chip.dev);
+ pca9685_pwm_clear_inuse(pca, offset);
}
static int pca9685_pwm_gpio_get_direction(struct gpio_chip *chip,
@@ -224,12 +227,17 @@ static int pca9685_pwm_gpio_probe(struct
return devm_gpiochip_add_data(dev, &pca->gpio, pca);
}
#else
-static inline bool pca9685_pwm_is_gpio(struct pca9685 *pca,
- struct pwm_device *pwm)
+static inline bool pca9685_pwm_test_and_set_inuse(struct pca9685 *pca,
+ int pwm_idx)
{
return false;
}
+static inline void
+pca9685_pwm_clear_inuse(struct pca9685 *pca, int pwm_idx)
+{
+}
+
static inline int pca9685_pwm_gpio_probe(struct pca9685 *pca)
{
return 0;
@@ -413,7 +421,7 @@ static int pca9685_pwm_request(struct pw
{
struct pca9685 *pca = to_pca(chip);
- if (pca9685_pwm_is_gpio(pca, pwm))
+ if (pca9685_pwm_test_and_set_inuse(pca, pwm->hwpwm))
return -EBUSY;
pm_runtime_get_sync(chip->dev);
@@ -422,8 +430,11 @@ static int pca9685_pwm_request(struct pw
static void pca9685_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
{
+ struct pca9685 *pca = to_pca(chip);
+
pca9685_pwm_disable(chip, pwm);
pm_runtime_put(chip->dev);
+ pca9685_pwm_clear_inuse(pca, pwm->hwpwm);
}
static const struct pwm_ops pca9685_pwm_ops = {
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 116/199] ext4: fix incorrect group count in ext4_fill_super error message
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (114 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 115/199] pwm: pca9685: Fix PWM/GPIO inter-operation Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 117/199] ext4: fix incorrect inodes per group in " Greg Kroah-Hartman
` (14 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Josh Triplett, Theodore Tso
From: Josh Triplett <josh@joshtriplett.org>
commit df41460a21b06a76437af040d90ccee03888e8e5 upstream.
ext4_fill_super doublechecks the number of groups before mounting; if
that check fails, the resulting error message prints the group count
from the ext4_sb_info sbi, which hasn't been set yet. Print the freshly
computed group count instead (which at that point has just been computed
in "blocks_count").
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Fixes: 4ec1102813798 ("ext4: Add sanity checks for the superblock before mounting the filesystem")
Link: https://lore.kernel.org/r/8b957cd1513fcc4550fe675c10bcce2175c33a49.1585431964.git.josh@joshtriplett.org
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/super.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4100,9 +4100,9 @@ static int ext4_fill_super(struct super_
EXT4_BLOCKS_PER_GROUP(sb) - 1);
do_div(blocks_count, EXT4_BLOCKS_PER_GROUP(sb));
if (blocks_count > ((uint64_t)1<<32) - EXT4_DESC_PER_BLOCK(sb)) {
- ext4_msg(sb, KERN_WARNING, "groups count too large: %u "
+ ext4_msg(sb, KERN_WARNING, "groups count too large: %llu "
"(block count %llu, first data block %u, "
- "blocks per group %lu)", sbi->s_groups_count,
+ "blocks per group %lu)", blocks_count,
ext4_blocks_count(es),
le32_to_cpu(es->s_first_data_block),
EXT4_BLOCKS_PER_GROUP(sb));
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 117/199] ext4: fix incorrect inodes per group in error message
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (115 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 116/199] ext4: fix incorrect group count in ext4_fill_super error message Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 118/199] ASoC: Intel: mrfld: fix incorrect check on p->sink Greg Kroah-Hartman
` (13 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andreas Dilger, Josh Triplett, Theodore Tso
From: Josh Triplett <josh@joshtriplett.org>
commit b9c538da4e52a7b79dfcf4cfa487c46125066dfb upstream.
If ext4_fill_super detects an invalid number of inodes per group, the
resulting error message printed the number of blocks per group, rather
than the number of inodes per group. Fix it to print the correct value.
Fixes: cd6bb35bf7f6d ("ext4: use more strict checks for inodes_per_block on mount")
Link: https://lore.kernel.org/r/8be03355983a08e5d4eed480944613454d7e2550.1585434649.git.josh@joshtriplett.org
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3969,7 +3969,7 @@ static int ext4_fill_super(struct super_
if (sbi->s_inodes_per_group < sbi->s_inodes_per_block ||
sbi->s_inodes_per_group > blocksize * 8) {
ext4_msg(sb, KERN_ERR, "invalid inodes per group: %lu\n",
- sbi->s_blocks_per_group);
+ sbi->s_inodes_per_group);
goto failed_mount;
}
sbi->s_itb_per_group = sbi->s_inodes_per_group /
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 118/199] ASoC: Intel: mrfld: fix incorrect check on p->sink
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (116 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 117/199] ext4: fix incorrect inodes per group in " Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 119/199] ASoC: Intel: mrfld: return error codes when an error occurs Greg Kroah-Hartman
` (12 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Colin Ian King, Mark Brown
From: Colin Ian King <colin.king@canonical.com>
commit f5e056e1e46fcbb5f74ce560792aeb7d57ce79e6 upstream.
The check on p->sink looks bogus, I believe it should be p->source
since the following code blocks are related to p->source. Fix
this by replacing p->sink with p->source.
Fixes: 24c8d14192cc ("ASoC: Intel: mrfld: add DSP core controls")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Addresses-Coverity: ("Copy-paste error")
Link: https://lore.kernel.org/r/20191119113640.166940-1-colin.king@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/intel/atom/sst-atom-controls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/soc/intel/atom/sst-atom-controls.c
+++ b/sound/soc/intel/atom/sst-atom-controls.c
@@ -1341,7 +1341,7 @@ int sst_send_pipe_gains(struct snd_soc_d
dai->capture_widget->name);
w = dai->capture_widget;
snd_soc_dapm_widget_for_each_source_path(w, p) {
- if (p->connected && !p->connected(w, p->sink))
+ if (p->connected && !p->connected(w, p->source))
continue;
if (p->connect && p->source->power &&
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 119/199] ASoC: Intel: mrfld: return error codes when an error occurs
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (117 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 118/199] ASoC: Intel: mrfld: fix incorrect check on p->sink Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 120/199] ALSA: usb-audio: Dont override ignore_ctl_error value from the map Greg Kroah-Hartman
` (11 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Colin Ian King, Cezary Rojewski,
Pierre-Louis Bossart, Mark Brown
From: Colin Ian King <colin.king@canonical.com>
commit 3025571edd9df653e1ad649f0638368a39d1bbb5 upstream.
Currently function sst_platform_get_resources always returns zero and
error return codes set by the function are never returned. Fix this
by returning the error return code in variable ret rather than the
hard coded zero.
Addresses-Coverity: ("Unused value")
Fixes: f533a035e4da ("ASoC: Intel: mrfld - create separate module for pci part")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200208220720.36657-1-colin.king@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/intel/atom/sst/sst_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/soc/intel/atom/sst/sst_pci.c
+++ b/sound/soc/intel/atom/sst/sst_pci.c
@@ -107,7 +107,7 @@ static int sst_platform_get_resources(st
dev_dbg(ctx->dev, "DRAM Ptr %p\n", ctx->dram);
do_release_regions:
pci_release_regions(pci);
- return 0;
+ return ret;
}
/*
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 120/199] ALSA: usb-audio: Dont override ignore_ctl_error value from the map
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (118 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 119/199] ASoC: Intel: mrfld: return error codes when an error occurs Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 121/199] tracing: Fix the race between registering snapshot event trigger and triggering snapshot operation Greg Kroah-Hartman
` (10 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 3507245b82b4362dc9721cbc328644905a3efa22 upstream.
The mapping table may contain also ignore_ctl_error flag for devices
that are known to behave wild. Since this flag always writes the
card's own ignore_ctl_error flag, it overrides the value already set
by the module option, so it doesn't follow user's expectation.
Let's fix the code not to clear the flag that has been set by user.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200412081331.4742-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/usb/mixer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -2342,7 +2342,7 @@ static int snd_usb_mixer_controls(struct
if (map->id == state.chip->usb_id) {
state.map = map->map;
state.selector_map = map->selector_map;
- mixer->ignore_ctl_error = map->ignore_ctl_error;
+ mixer->ignore_ctl_error |= map->ignore_ctl_error;
break;
}
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 121/199] tracing: Fix the race between registering snapshot event trigger and triggering snapshot operation
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (119 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 120/199] ALSA: usb-audio: Dont override ignore_ctl_error value from the map Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 122/199] btrfs: check commit root generation in should_ignore_root Greg Kroah-Hartman
` (9 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Xiao Yang, Steven Rostedt (VMware)
From: Xiao Yang <yangx.jy@cn.fujitsu.com>
commit 0bbe7f719985efd9adb3454679ecef0984cb6800 upstream.
Traced event can trigger 'snapshot' operation(i.e. calls snapshot_trigger()
or snapshot_count_trigger()) when register_snapshot_trigger() has completed
registration but doesn't allocate buffer for 'snapshot' event trigger. In
the rare case, 'snapshot' operation always detects the lack of allocated
buffer so make register_snapshot_trigger() allocate buffer first.
trigger-snapshot.tc in kselftest reproduces the issue on slow vm:
-----------------------------------------------------------
cat trace
...
ftracetest-3028 [002] .... 236.784290: sched_process_fork: comm=ftracetest pid=3028 child_comm=ftracetest child_pid=3036
<...>-2875 [003] .... 240.460335: tracing_snapshot_instance_cond: *** SNAPSHOT NOT ALLOCATED ***
<...>-2875 [003] .... 240.460338: tracing_snapshot_instance_cond: *** stopping trace here! ***
-----------------------------------------------------------
Link: http://lkml.kernel.org/r/20200414015145.66236-1-yangx.jy@cn.fujitsu.com
Cc: stable@vger.kernel.org
Fixes: 93e31ffbf417a ("tracing: Add 'snapshot' event trigger command")
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/trace/trace_events_trigger.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -1075,14 +1075,10 @@ register_snapshot_trigger(char *glob, st
struct event_trigger_data *data,
struct trace_event_file *file)
{
- int ret = register_trigger(glob, ops, data, file);
+ if (tracing_alloc_snapshot_instance(file->tr) != 0)
+ return 0;
- if (ret > 0 && tracing_alloc_snapshot_instance(file->tr) != 0) {
- unregister_trigger(glob, ops, data, file);
- ret = 0;
- }
-
- return ret;
+ return register_trigger(glob, ops, data, file);
}
static int
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 122/199] btrfs: check commit root generation in should_ignore_root
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (120 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 121/199] tracing: Fix the race between registering snapshot event trigger and triggering snapshot operation Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 123/199] mac80211_hwsim: Use kstrndup() in place of kasprintf() Greg Kroah-Hartman
` (8 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Filipe Manana, Josef Bacik, David Sterba
From: Josef Bacik <josef@toxicpanda.com>
commit 4d4225fc228e46948486d8b8207955f0c031b92e upstream.
Previously we would set the reloc root's last snapshot to transid - 1.
However there was a problem with doing this, and we changed it to
setting the last snapshot to the generation of the commit node of the fs
root.
This however broke should_ignore_root(). The assumption is that if we
are in a generation newer than when the reloc root was created, then we
would find the reloc root through normal backref lookups, and thus can
ignore any fs roots we find with an old enough reloc root.
Now that the last snapshot could be considerably further in the past
than before, we'd end up incorrectly ignoring an fs root. Thus we'd
find no nodes for the bytenr we were searching for, and we'd fail to
relocate anything. We'd loop through the relocate code again and see
that there were still used space in that block group, attempt to
relocate those bytenr's again, fail in the same way, and just loop like
this forever. This is tricky in that we have to not modify the fs root
at all during this time, so we need to have a block group that has data
in this fs root that is not shared by any other root, which is why this
has been difficult to reproduce.
Fixes: 054570a1dc94 ("Btrfs: fix relocation incorrectly dropping data references")
CC: stable@vger.kernel.org # 4.9+
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/relocation.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -538,8 +538,8 @@ static int should_ignore_root(struct btr
if (!reloc_root)
return 0;
- if (btrfs_root_last_snapshot(&reloc_root->root_item) ==
- root->fs_info->running_transaction->transid - 1)
+ if (btrfs_header_generation(reloc_root->commit_root) ==
+ root->fs_info->running_transaction->transid)
return 0;
/*
* if there is reloc tree and it was created in previous
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 123/199] mac80211_hwsim: Use kstrndup() in place of kasprintf()
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (121 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 122/199] btrfs: check commit root generation in should_ignore_root Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 124/199] ext4: do not zeroout extents beyond i_disksize Greg Kroah-Hartman
` (7 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+6693adf1698864d21734,
syzbot+a4aee3f42d7584d76761, stable, Tuomas Tynkkynen,
Johannes Berg
From: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
commit 7ea862048317aa76d0f22334202779a25530980c upstream.
syzbot reports a warning:
precision 33020 too large
WARNING: CPU: 0 PID: 9618 at lib/vsprintf.c:2471 set_precision+0x150/0x180 lib/vsprintf.c:2471
vsnprintf+0xa7b/0x19a0 lib/vsprintf.c:2547
kvasprintf+0xb2/0x170 lib/kasprintf.c:22
kasprintf+0xbb/0xf0 lib/kasprintf.c:59
hwsim_del_radio_nl+0x63a/0x7e0 drivers/net/wireless/mac80211_hwsim.c:3625
genl_family_rcv_msg_doit net/netlink/genetlink.c:672 [inline]
...
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Thus it seems that kasprintf() with "%.*s" format can not be used for
duplicating a string with arbitrary length. Replace it with kstrndup().
Note that later this string is limited to NL80211_WIPHY_NAME_MAXLEN == 64,
but the code is simpler this way.
Reported-by: syzbot+6693adf1698864d21734@syzkaller.appspotmail.com
Reported-by: syzbot+a4aee3f42d7584d76761@syzkaller.appspotmail.com
Cc: stable@kernel.org
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Link: https://lore.kernel.org/r/20200410123257.14559-1-tuomas.tynkkynen@iki.fi
[johannes: add note about length limit]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/mac80211_hwsim.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3134,9 +3134,9 @@ static int hwsim_new_radio_nl(struct sk_
param.no_vif = true;
if (info->attrs[HWSIM_ATTR_RADIO_NAME]) {
- hwname = kasprintf(GFP_KERNEL, "%.*s",
- nla_len(info->attrs[HWSIM_ATTR_RADIO_NAME]),
- (char *)nla_data(info->attrs[HWSIM_ATTR_RADIO_NAME]));
+ hwname = kstrndup((char *)nla_data(info->attrs[HWSIM_ATTR_RADIO_NAME]),
+ nla_len(info->attrs[HWSIM_ATTR_RADIO_NAME]),
+ GFP_KERNEL);
if (!hwname)
return -ENOMEM;
param.hwname = hwname;
@@ -3175,9 +3175,9 @@ static int hwsim_del_radio_nl(struct sk_
if (info->attrs[HWSIM_ATTR_RADIO_ID]) {
idx = nla_get_u32(info->attrs[HWSIM_ATTR_RADIO_ID]);
} else if (info->attrs[HWSIM_ATTR_RADIO_NAME]) {
- hwname = kasprintf(GFP_KERNEL, "%.*s",
- nla_len(info->attrs[HWSIM_ATTR_RADIO_NAME]),
- (char *)nla_data(info->attrs[HWSIM_ATTR_RADIO_NAME]));
+ hwname = kstrndup((char *)nla_data(info->attrs[HWSIM_ATTR_RADIO_NAME]),
+ nla_len(info->attrs[HWSIM_ATTR_RADIO_NAME]),
+ GFP_KERNEL);
if (!hwname)
return -ENOMEM;
} else
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 124/199] ext4: do not zeroout extents beyond i_disksize
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (122 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 123/199] mac80211_hwsim: Use kstrndup() in place of kasprintf() Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 125/199] dm flakey: check for null arg_name in parse_features() Greg Kroah-Hartman
` (6 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lukas Czerner, Jan Kara, Theodore Tso
From: Jan Kara <jack@suse.cz>
commit 801674f34ecfed033b062a0f217506b93c8d5e8a upstream.
We do not want to create initialized extents beyond end of file because
for e2fsck it is impossible to distinguish them from a case of corrupted
file size / extent tree and so it complains like:
Inode 12, i_size is 147456, should be 163840. Fix? no
Code in ext4_ext_convert_to_initialized() and
ext4_split_convert_extents() try to make sure it does not create
initialized extents beyond inode size however they check against
inode->i_size which is wrong. They should instead check against
EXT4_I(inode)->i_disksize which is the current inode size on disk.
That's what e2fsck is going to see in case of crash before all dirty
data is written. This bug manifests as generic/456 test failure (with
recent enough fstests where fsx got fixed to properly pass
FALLOC_KEEP_SIZE_FL flags to the kernel) when run with dioread_lock
mount option.
CC: stable@vger.kernel.org
Fixes: 21ca087a3891 ("ext4: Do not zero out uninitialized extents beyond i_size")
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Link: https://lore.kernel.org/r/20200331105016.8674-1-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/extents.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -3446,8 +3446,8 @@ static int ext4_ext_convert_to_initializ
(unsigned long long)map->m_lblk, map_len);
sbi = EXT4_SB(inode->i_sb);
- eof_block = (inode->i_size + inode->i_sb->s_blocksize - 1) >>
- inode->i_sb->s_blocksize_bits;
+ eof_block = (EXT4_I(inode)->i_disksize + inode->i_sb->s_blocksize - 1)
+ >> inode->i_sb->s_blocksize_bits;
if (eof_block < map->m_lblk + map_len)
eof_block = map->m_lblk + map_len;
@@ -3702,8 +3702,8 @@ static int ext4_split_convert_extents(ha
__func__, inode->i_ino,
(unsigned long long)map->m_lblk, map->m_len);
- eof_block = (inode->i_size + inode->i_sb->s_blocksize - 1) >>
- inode->i_sb->s_blocksize_bits;
+ eof_block = (EXT4_I(inode)->i_disksize + inode->i_sb->s_blocksize - 1)
+ >> inode->i_sb->s_blocksize_bits;
if (eof_block < map->m_lblk + map->m_len)
eof_block = map->m_lblk + map->m_len;
/*
^ permalink raw reply [flat|nested] 132+ messages in thread* [PATCH 4.14 125/199] dm flakey: check for null arg_name in parse_features()
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (123 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 124/199] ext4: do not zeroout extents beyond i_disksize Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 126/199] kvm: x86: Host feature SSBD doesnt imply guest feature SPEC_CTRL_SSBD Greg Kroah-Hartman
` (5 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Goldwyn Rodrigues, Mike Snitzer, Sasha Levin
From: Goldwyn Rodrigues <rgoldwyn@suse.com>
[ Upstream commit 7690e25302dc7d0cd42b349e746fe44b44a94f2b ]
One can crash dm-flakey by specifying more feature arguments than the
number of features supplied. Checking for null in arg_name avoids
this.
dmsetup create flakey-test --table "0 66076080 flakey /dev/sdb9 0 0 180 2 drop_writes"
Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/md/dm-flakey.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/md/dm-flakey.c b/drivers/md/dm-flakey.c
index b1b68e01b889c..53cd31199f212 100644
--- a/drivers/md/dm-flakey.c
+++ b/drivers/md/dm-flakey.c
@@ -70,6 +70,11 @@ static int parse_features(struct dm_arg_set *as, struct flakey_c *fc,
arg_name = dm_shift_arg(as);
argc--;
+ if (!arg_name) {
+ ti->error = "Insufficient feature arguments";
+ return -EINVAL;
+ }
+
/*
* drop_writes
*/
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 126/199] kvm: x86: Host feature SSBD doesnt imply guest feature SPEC_CTRL_SSBD
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (124 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 125/199] dm flakey: check for null arg_name in parse_features() Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 127/199] scsi: target: remove boilerplate code Greg Kroah-Hartman
` (4 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jim Mattson, Jacob Xu, Peter Shier,
Paolo Bonzini, Eric Biggers, Ben Hutchings, Sasha Levin
From: Jim Mattson <jmattson@google.com>
commit 396d2e878f92ec108e4293f1c77ea3bc90b414ff upstream.
The host reports support for the synthetic feature X86_FEATURE_SSBD
when any of the three following hardware features are set:
CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31]
CPUID.80000008H:EBX.AMD_SSBD[bit 24]
CPUID.80000008H:EBX.VIRT_SSBD[bit 25]
Either of the first two hardware features implies the existence of the
IA32_SPEC_CTRL MSR, but CPUID.80000008H:EBX.VIRT_SSBD[bit 25] does
not. Therefore, CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] should only be
set in the guest if CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] or
CPUID.80000008H:EBX.AMD_SSBD[bit 24] is set on the host.
Fixes: 0c54914d0c52a ("KVM: x86: use Intel speculation bugs and features as derived in generic x86 code")
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Jacob Xu <jacobhxu@google.com>
Reviewed-by: Peter Shier <pshier@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Reported-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[bwh: Backported to 4.x: adjust indentation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/kvm/cpuid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 1152afad524fe..6ec1cfd0addd8 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -494,7 +494,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
entry->edx |= F(SPEC_CTRL);
if (boot_cpu_has(X86_FEATURE_STIBP))
entry->edx |= F(INTEL_STIBP);
- if (boot_cpu_has(X86_FEATURE_SSBD))
+ if (boot_cpu_has(X86_FEATURE_SPEC_CTRL_SSBD) ||
+ boot_cpu_has(X86_FEATURE_AMD_SSBD))
entry->edx |= F(SPEC_CTRL_SSBD);
/*
* We emulate ARCH_CAPABILITIES in software even
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 127/199] scsi: target: remove boilerplate code
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (125 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 126/199] kvm: x86: Host feature SSBD doesnt imply guest feature SPEC_CTRL_SSBD Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 128/199] scsi: target: fix hang when multiple threads try to destroy the same iscsi session Greg Kroah-Hartman
` (3 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rahul Kundu, Maurizio Lombardi,
Martin K. Petersen, Sasha Levin
From: Maurizio Lombardi <mlombard@redhat.com>
[ Upstream commit e49a7d994379278d3353d7ffc7994672752fb0ad ]
iscsit_free_session() is equivalent to iscsit_stop_session() followed by a
call to iscsit_close_session().
Link: https://lore.kernel.org/r/20200313170656.9716-2-mlombard@redhat.com
Tested-by: Rahul Kundu <rahul.kundu@chelsio.com>
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/target/iscsi/iscsi_target.c | 46 ++---------------------------
drivers/target/iscsi/iscsi_target.h | 1 -
2 files changed, 2 insertions(+), 45 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target.c b/drivers/target/iscsi/iscsi_target.c
index fb7bd422e2e1f..40993c575017f 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -4583,49 +4583,6 @@ void iscsit_fail_session(struct iscsi_session *sess)
sess->session_state = TARG_SESS_STATE_FAILED;
}
-int iscsit_free_session(struct iscsi_session *sess)
-{
- u16 conn_count = atomic_read(&sess->nconn);
- struct iscsi_conn *conn, *conn_tmp = NULL;
- int is_last;
-
- spin_lock_bh(&sess->conn_lock);
- atomic_set(&sess->sleep_on_sess_wait_comp, 1);
-
- list_for_each_entry_safe(conn, conn_tmp, &sess->sess_conn_list,
- conn_list) {
- if (conn_count == 0)
- break;
-
- if (list_is_last(&conn->conn_list, &sess->sess_conn_list)) {
- is_last = 1;
- } else {
- iscsit_inc_conn_usage_count(conn_tmp);
- is_last = 0;
- }
- iscsit_inc_conn_usage_count(conn);
-
- spin_unlock_bh(&sess->conn_lock);
- iscsit_cause_connection_reinstatement(conn, 1);
- spin_lock_bh(&sess->conn_lock);
-
- iscsit_dec_conn_usage_count(conn);
- if (is_last == 0)
- iscsit_dec_conn_usage_count(conn_tmp);
-
- conn_count--;
- }
-
- if (atomic_read(&sess->nconn)) {
- spin_unlock_bh(&sess->conn_lock);
- wait_for_completion(&sess->session_wait_comp);
- } else
- spin_unlock_bh(&sess->conn_lock);
-
- iscsit_close_session(sess);
- return 0;
-}
-
void iscsit_stop_session(
struct iscsi_session *sess,
int session_sleep,
@@ -4710,7 +4667,8 @@ int iscsit_release_sessions_for_tpg(struct iscsi_portal_group *tpg, int force)
list_for_each_entry_safe(se_sess, se_sess_tmp, &free_list, sess_list) {
sess = (struct iscsi_session *)se_sess->fabric_sess_ptr;
- iscsit_free_session(sess);
+ iscsit_stop_session(sess, 1, 1);
+ iscsit_close_session(sess);
session_count++;
}
diff --git a/drivers/target/iscsi/iscsi_target.h b/drivers/target/iscsi/iscsi_target.h
index 42de1843aa40d..f0d2cbf594c92 100644
--- a/drivers/target/iscsi/iscsi_target.h
+++ b/drivers/target/iscsi/iscsi_target.h
@@ -43,7 +43,6 @@ extern int iscsi_target_rx_thread(void *);
extern int iscsit_close_connection(struct iscsi_conn *);
extern int iscsit_close_session(struct iscsi_session *);
extern void iscsit_fail_session(struct iscsi_session *);
-extern int iscsit_free_session(struct iscsi_session *);
extern void iscsit_stop_session(struct iscsi_session *, int, int);
extern int iscsit_release_sessions_for_tpg(struct iscsi_portal_group *, int);
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 128/199] scsi: target: fix hang when multiple threads try to destroy the same iscsi session
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (126 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 127/199] scsi: target: remove boilerplate code Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-22 9:57 ` [PATCH 4.14 129/199] x86/microcode/AMD: Increase microcode PATCH_MAX_SIZE Greg Kroah-Hartman
` (2 subsequent siblings)
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matt Coleman, Rahul Kundu,
Maurizio Lombardi, Martin K. Petersen, Sasha Levin
From: Maurizio Lombardi <mlombard@redhat.com>
[ Upstream commit 57c46e9f33da530a2485fa01aa27b6d18c28c796 ]
A number of hangs have been reported against the target driver; they are
due to the fact that multiple threads may try to destroy the iscsi session
at the same time. This may be reproduced for example when a "targetcli
iscsi/iqn.../tpg1 disable" command is executed while a logout operation is
underway.
When this happens, two or more threads may end up sleeping and waiting for
iscsit_close_connection() to execute "complete(session_wait_comp)". Only
one of the threads will wake up and proceed to destroy the session
structure, the remaining threads will hang forever.
Note that if the blocked threads are somehow forced to wake up with
complete_all(), they will try to free the same iscsi session structure
destroyed by the first thread, causing double frees, memory corruptions
etc...
With this patch, the threads that want to destroy the iscsi session will
increase the session refcount and will set the "session_close" flag to 1;
then they wait for the driver to close the remaining active connections.
When the last connection is closed, iscsit_close_connection() will wake up
all the threads and will wait for the session's refcount to reach zero;
when this happens, iscsit_close_connection() will destroy the session
structure because no one is referencing it anymore.
INFO: task targetcli:5971 blocked for more than 120 seconds.
Tainted: P OE 4.15.0-72-generic #81~16.04.1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
targetcli D 0 5971 1 0x00000080
Call Trace:
__schedule+0x3d6/0x8b0
? vprintk_func+0x44/0xe0
schedule+0x36/0x80
schedule_timeout+0x1db/0x370
? __dynamic_pr_debug+0x8a/0xb0
wait_for_completion+0xb4/0x140
? wake_up_q+0x70/0x70
iscsit_free_session+0x13d/0x1a0 [iscsi_target_mod]
iscsit_release_sessions_for_tpg+0x16b/0x1e0 [iscsi_target_mod]
iscsit_tpg_disable_portal_group+0xca/0x1c0 [iscsi_target_mod]
lio_target_tpg_enable_store+0x66/0xe0 [iscsi_target_mod]
configfs_write_file+0xb9/0x120
__vfs_write+0x1b/0x40
vfs_write+0xb8/0x1b0
SyS_write+0x5c/0xe0
do_syscall_64+0x73/0x130
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Link: https://lore.kernel.org/r/20200313170656.9716-3-mlombard@redhat.com
Reported-by: Matt Coleman <mcoleman@datto.com>
Tested-by: Matt Coleman <mcoleman@datto.com>
Tested-by: Rahul Kundu <rahul.kundu@chelsio.com>
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/target/iscsi/iscsi_target.c | 35 ++++++++++++--------
drivers/target/iscsi/iscsi_target_configfs.c | 5 ++-
drivers/target/iscsi/iscsi_target_login.c | 5 +--
include/target/iscsi/iscsi_target_core.h | 2 +-
4 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target.c b/drivers/target/iscsi/iscsi_target.c
index 40993c575017f..ee49b227dc12b 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -4314,30 +4314,37 @@ int iscsit_close_connection(
if (!atomic_read(&sess->session_reinstatement) &&
atomic_read(&sess->session_fall_back_to_erl0)) {
spin_unlock_bh(&sess->conn_lock);
+ complete_all(&sess->session_wait_comp);
iscsit_close_session(sess);
return 0;
} else if (atomic_read(&sess->session_logout)) {
pr_debug("Moving to TARG_SESS_STATE_FREE.\n");
sess->session_state = TARG_SESS_STATE_FREE;
- spin_unlock_bh(&sess->conn_lock);
- if (atomic_read(&sess->sleep_on_sess_wait_comp))
- complete(&sess->session_wait_comp);
+ if (atomic_read(&sess->session_close)) {
+ spin_unlock_bh(&sess->conn_lock);
+ complete_all(&sess->session_wait_comp);
+ iscsit_close_session(sess);
+ } else {
+ spin_unlock_bh(&sess->conn_lock);
+ }
return 0;
} else {
pr_debug("Moving to TARG_SESS_STATE_FAILED.\n");
sess->session_state = TARG_SESS_STATE_FAILED;
- if (!atomic_read(&sess->session_continuation)) {
- spin_unlock_bh(&sess->conn_lock);
+ if (!atomic_read(&sess->session_continuation))
iscsit_start_time2retain_handler(sess);
- } else
- spin_unlock_bh(&sess->conn_lock);
- if (atomic_read(&sess->sleep_on_sess_wait_comp))
- complete(&sess->session_wait_comp);
+ if (atomic_read(&sess->session_close)) {
+ spin_unlock_bh(&sess->conn_lock);
+ complete_all(&sess->session_wait_comp);
+ iscsit_close_session(sess);
+ } else {
+ spin_unlock_bh(&sess->conn_lock);
+ }
return 0;
}
@@ -4446,9 +4453,9 @@ static void iscsit_logout_post_handler_closesession(
complete(&conn->conn_logout_comp);
iscsit_dec_conn_usage_count(conn);
+ atomic_set(&sess->session_close, 1);
iscsit_stop_session(sess, sleep, sleep);
iscsit_dec_session_usage_count(sess);
- iscsit_close_session(sess);
}
static void iscsit_logout_post_handler_samecid(
@@ -4593,8 +4600,6 @@ void iscsit_stop_session(
int is_last;
spin_lock_bh(&sess->conn_lock);
- if (session_sleep)
- atomic_set(&sess->sleep_on_sess_wait_comp, 1);
if (connection_sleep) {
list_for_each_entry_safe(conn, conn_tmp, &sess->sess_conn_list,
@@ -4652,12 +4657,15 @@ int iscsit_release_sessions_for_tpg(struct iscsi_portal_group *tpg, int force)
spin_lock(&sess->conn_lock);
if (atomic_read(&sess->session_fall_back_to_erl0) ||
atomic_read(&sess->session_logout) ||
+ atomic_read(&sess->session_close) ||
(sess->time2retain_timer_flags & ISCSI_TF_EXPIRED)) {
spin_unlock(&sess->conn_lock);
continue;
}
+ iscsit_inc_session_usage_count(sess);
atomic_set(&sess->session_reinstatement, 1);
atomic_set(&sess->session_fall_back_to_erl0, 1);
+ atomic_set(&sess->session_close, 1);
spin_unlock(&sess->conn_lock);
list_move_tail(&se_sess->sess_list, &free_list);
@@ -4667,8 +4675,9 @@ int iscsit_release_sessions_for_tpg(struct iscsi_portal_group *tpg, int force)
list_for_each_entry_safe(se_sess, se_sess_tmp, &free_list, sess_list) {
sess = (struct iscsi_session *)se_sess->fabric_sess_ptr;
+ list_del_init(&se_sess->sess_list);
iscsit_stop_session(sess, 1, 1);
- iscsit_close_session(sess);
+ iscsit_dec_session_usage_count(sess);
session_count++;
}
diff --git a/drivers/target/iscsi/iscsi_target_configfs.c b/drivers/target/iscsi/iscsi_target_configfs.c
index 0ebc4818e132a..4191e4a8a9ed6 100644
--- a/drivers/target/iscsi/iscsi_target_configfs.c
+++ b/drivers/target/iscsi/iscsi_target_configfs.c
@@ -1503,20 +1503,23 @@ static void lio_tpg_close_session(struct se_session *se_sess)
spin_lock(&sess->conn_lock);
if (atomic_read(&sess->session_fall_back_to_erl0) ||
atomic_read(&sess->session_logout) ||
+ atomic_read(&sess->session_close) ||
(sess->time2retain_timer_flags & ISCSI_TF_EXPIRED)) {
spin_unlock(&sess->conn_lock);
spin_unlock_bh(&se_tpg->session_lock);
return;
}
+ iscsit_inc_session_usage_count(sess);
atomic_set(&sess->session_reinstatement, 1);
atomic_set(&sess->session_fall_back_to_erl0, 1);
+ atomic_set(&sess->session_close, 1);
spin_unlock(&sess->conn_lock);
iscsit_stop_time2retain_timer(sess);
spin_unlock_bh(&se_tpg->session_lock);
iscsit_stop_session(sess, 1, 1);
- iscsit_close_session(sess);
+ iscsit_dec_session_usage_count(sess);
}
static u32 lio_tpg_get_inst_index(struct se_portal_group *se_tpg)
diff --git a/drivers/target/iscsi/iscsi_target_login.c b/drivers/target/iscsi/iscsi_target_login.c
index 27893d90c4efa..55df6f99e6691 100644
--- a/drivers/target/iscsi/iscsi_target_login.c
+++ b/drivers/target/iscsi/iscsi_target_login.c
@@ -199,6 +199,7 @@ int iscsi_check_for_session_reinstatement(struct iscsi_conn *conn)
spin_lock(&sess_p->conn_lock);
if (atomic_read(&sess_p->session_fall_back_to_erl0) ||
atomic_read(&sess_p->session_logout) ||
+ atomic_read(&sess_p->session_close) ||
(sess_p->time2retain_timer_flags & ISCSI_TF_EXPIRED)) {
spin_unlock(&sess_p->conn_lock);
continue;
@@ -209,6 +210,7 @@ int iscsi_check_for_session_reinstatement(struct iscsi_conn *conn)
(sess_p->sess_ops->SessionType == sessiontype))) {
atomic_set(&sess_p->session_reinstatement, 1);
atomic_set(&sess_p->session_fall_back_to_erl0, 1);
+ atomic_set(&sess_p->session_close, 1);
spin_unlock(&sess_p->conn_lock);
iscsit_inc_session_usage_count(sess_p);
iscsit_stop_time2retain_timer(sess_p);
@@ -233,7 +235,6 @@ int iscsi_check_for_session_reinstatement(struct iscsi_conn *conn)
if (sess->session_state == TARG_SESS_STATE_FAILED) {
spin_unlock_bh(&sess->conn_lock);
iscsit_dec_session_usage_count(sess);
- iscsit_close_session(sess);
return 0;
}
spin_unlock_bh(&sess->conn_lock);
@@ -241,7 +242,6 @@ int iscsi_check_for_session_reinstatement(struct iscsi_conn *conn)
iscsit_stop_session(sess, 1, 1);
iscsit_dec_session_usage_count(sess);
- iscsit_close_session(sess);
return 0;
}
@@ -534,6 +534,7 @@ static int iscsi_login_non_zero_tsih_s2(
sess_p = (struct iscsi_session *)se_sess->fabric_sess_ptr;
if (atomic_read(&sess_p->session_fall_back_to_erl0) ||
atomic_read(&sess_p->session_logout) ||
+ atomic_read(&sess_p->session_close) ||
(sess_p->time2retain_timer_flags & ISCSI_TF_EXPIRED))
continue;
if (!memcmp(sess_p->isid, pdu->isid, 6) &&
diff --git a/include/target/iscsi/iscsi_target_core.h b/include/target/iscsi/iscsi_target_core.h
index cf5f3fff1f1a7..fd7e4d1df9a15 100644
--- a/include/target/iscsi/iscsi_target_core.h
+++ b/include/target/iscsi/iscsi_target_core.h
@@ -673,7 +673,7 @@ struct iscsi_session {
atomic_t session_logout;
atomic_t session_reinstatement;
atomic_t session_stop_active;
- atomic_t sleep_on_sess_wait_comp;
+ atomic_t session_close;
/* connection list */
struct list_head sess_conn_list;
struct list_head cr_active_list;
--
2.20.1
^ permalink raw reply related [flat|nested] 132+ messages in thread* [PATCH 4.14 129/199] x86/microcode/AMD: Increase microcode PATCH_MAX_SIZE
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (127 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 128/199] scsi: target: fix hang when multiple threads try to destroy the same iscsi session Greg Kroah-Hartman
@ 2020-04-22 9:57 ` Greg Kroah-Hartman
2020-04-23 10:20 ` [PATCH 4.14 000/199] 4.14.177-rc1 review Jon Hunter
2020-04-23 11:28 ` Naresh Kamboju
130 siblings, 0 replies; 132+ messages in thread
From: Greg Kroah-Hartman @ 2020-04-22 9:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, John Allen, Borislav Petkov
From: John Allen <john.allen@amd.com>
commit bdf89df3c54518eed879d8fac7577fcfb220c67e upstream.
Future AMD CPUs will have microcode patches that exceed the default 4K
patch size. Raise our limit.
Signed-off-by: John Allen <john.allen@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: stable@vger.kernel.org # v4.14..
Link: https://lkml.kernel.org/r/20200409152931.GA685273@mojo.amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/microcode_amd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/microcode_amd.h
+++ b/arch/x86/include/asm/microcode_amd.h
@@ -41,7 +41,7 @@ struct microcode_amd {
unsigned int mpb[0];
};
-#define PATCH_MAX_SIZE PAGE_SIZE
+#define PATCH_MAX_SIZE (3 * PAGE_SIZE)
#ifdef CONFIG_MICROCODE_AMD
extern void __init load_ucode_amd_bsp(unsigned int family);
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [PATCH 4.14 000/199] 4.14.177-rc1 review
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (128 preceding siblings ...)
2020-04-22 9:57 ` [PATCH 4.14 129/199] x86/microcode/AMD: Increase microcode PATCH_MAX_SIZE Greg Kroah-Hartman
@ 2020-04-23 10:20 ` Jon Hunter
2020-04-23 11:28 ` Naresh Kamboju
130 siblings, 0 replies; 132+ messages in thread
From: Jon Hunter @ 2020-04-23 10:20 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, ben.hutchings,
lkft-triage, stable, linux-tegra
On 22/04/2020 10:55, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.177 release.
> There are 199 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 Fri, 24 Apr 2020 09:48:23 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.177-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
All tests are passing for Tegra
Test results for stable-v4.14:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
24 tests: 24 pass, 0 fail
Linux version: 4.14.177-rc1-gcebd79de8787
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [PATCH 4.14 000/199] 4.14.177-rc1 review
2020-04-22 9:55 [PATCH 4.14 000/199] 4.14.177-rc1 review Greg Kroah-Hartman
` (129 preceding siblings ...)
2020-04-23 10:20 ` [PATCH 4.14 000/199] 4.14.177-rc1 review Jon Hunter
@ 2020-04-23 11:28 ` Naresh Kamboju
130 siblings, 0 replies; 132+ messages in thread
From: Naresh Kamboju @ 2020-04-23 11:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Shuah Khan, patches, lkft-triage, Ben Hutchings,
linux- stable, Andrew Morton, Linus Torvalds, Guenter Roeck,
Arnd Bergmann, John Stultz, Rob Clark
On Wed, 22 Apr 2020 at 15:42, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.14.177 release.
> There are 199 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 Fri, 24 Apr 2020 09:48:23 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.177-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
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
NOTE:
The platform specific issue on arm64 qualcomm dragonboard 410c and
hi6220-hikey have been reported.
stable-rc 4.14: Internal error: Oops: 96000004 - pc : __pi_strcmp+0x18/0x154
https://lore.kernel.org/stable/CA+G9fYtoYzRbrUVhboUgOOqEC2xt_i4ZmYb9yq33fRmf653_pQ@mail.gmail.com/T/#u
WARNING: drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h:178 mdp5_bind
https://lore.kernel.org/stable/CA+G9fYtcjK8MrygHu686rV4i+bYO2CR==OFNrXNSM_HzWEhNFA@mail.gmail.com/T/#t
WARNING: net/sched/sch_generic.c:320 dev_watchdog on arm64 hi6220-hikey
https://lore.kernel.org/stable/CA+G9fYtR4cvY9N0NLYDOByHsDyQJwpaYuV8qss6s-D+_DS9x_A@mail.gmail.com/T/#u
Summary
------------------------------------------------------------------------
kernel: 4.14.177-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: cebd79de87875c1f054d7e674a496868b78e637f
git describe: v4.14.176-200-gcebd79de8787
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.176-200-gcebd79de8787
No regressions (compared to build v4.14.176)
No fixes (compared to build v4.14.176)
Ran 44120 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* install-android-platform-tools-r2800
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* kselftest/networking
* libhugetlbfs
* linux-log-parser
* ltp-commands-tests
* ltp-containers-tests
* ltp-dio-tests
* ltp-fs-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-sched-tests
* ltp-syscalls-tests
* perf
* v4l2-compliance
* kvm-unit-tests
* ltp-cap_bounds-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* network-basic-tests
* ltp-open-posix-tests
* spectre-meltdown-checker-test
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-native/networking
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
* kselftest-vsyscall-mode-none/networking
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 132+ messages in thread