- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch "test_firmware: fix missing unlock on error in config_num_requests_store()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled test_firmware: fix missing unlock on error in config_num_requests_store() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: test_firmware-fix-missing-unlock-on-error-in-config_num_requests_store.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a5e1923356505e46476c2fb518559b7a4d9d25b1 Mon Sep 17 00:00:00 2001 From: Wei Yongjun <weiyongjun1(a)huawei.com> Date: Thu, 11 Jan 2018 11:12:55 +0000 Subject: test_firmware: fix missing unlock on error in config_num_requests_store() From: Wei Yongjun <weiyongjun1(a)huawei.com> commit a5e1923356505e46476c2fb518559b7a4d9d25b1 upstream. Add the missing unlock before return from function config_num_requests_store() in the error handling case. Fixes: c92316bf8e94 ("test_firmware: add batched firmware tests") Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- lib/test_firmware.c | 1 + 1 file changed, 1 insertion(+) --- a/lib/test_firmware.c +++ b/lib/test_firmware.c @@ -371,6 +371,7 @@ static ssize_t config_num_requests_store if (test_fw_config->reqs) { pr_err("Must call release_all_firmware prior to changing config\n"); rc = -EINVAL; + mutex_unlock(&test_fw_mutex); goto out; } mutex_unlock(&test_fw_mutex); Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are queue-4.14/test_firmware-fix-missing-unlock-on-error-in-config_num_requests_store.patch queue-4.14/serial-8250_uniphier-fix-error-return-code-in-uniphier_uart_probe.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: lustre: separate a connection destroy from free struct kib_conn" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: lustre: separate a connection destroy from free struct kib_conn to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-lustre-separate-a-connection-destroy-from-free-struct-kib_conn.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 9b046013e5837f8a58453d1e9f8e01d03adb7fe7 Mon Sep 17 00:00:00 2001 From: Dmitry Eremin <dmitry.eremin(a)intel.com> Date: Thu, 25 Jan 2018 16:51:04 +0300 Subject: staging: lustre: separate a connection destroy from free struct kib_conn From: Dmitry Eremin <dmitry.eremin(a)intel.com> commit 9b046013e5837f8a58453d1e9f8e01d03adb7fe7 upstream. The logic of the original commit 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for ko2iblnd") was assumed conditional free of struct kib_conn if the second argument free_conn in function kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn) is true. But this hunk of code was dropped from original commit. As result the logic works wrong and current code use struct kib_conn after free. > drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c > 3317 kiblnd_destroy_conn(conn, !peer); > ^^^^ Freed always (but should be conditionally) > 3318 > 3319 spin_lock_irqsave(lock, flags); > 3320 if (!peer) > 3321 continue; > 3322 > 3323 conn->ibc_peer = peer; > ^^^^^^^^^^^^^^ Use after free > 3324 if (peer->ibp_reconnected < KIB_RECONN_HIGH_RACE) > 3325 list_add_tail(&conn->ibc_list, > ^^^^^^^^^^^^^^ Use after free > 3326 &kiblnd_data.kib_reconn_list); > 3327 else > 3328 list_add_tail(&conn->ibc_list, > ^^^^^^^^^^^^^^ Use after free > 3329 &kiblnd_data.kib_reconn_wait); To avoid confusion this fix moved the freeing a struct kib_conn outside of the function kiblnd_destroy_conn() and free as it was intended in original commit. Fixes: 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for ko2iblnd") Signed-off-by: Dmitry Eremin <Dmitry.Eremin(a)intel.com> Reviewed-by: Andreas Dilger <andreas.dilger(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 7 +++---- drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h | 2 +- drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 6 ++++-- 3 files changed, 8 insertions(+), 7 deletions(-) --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c @@ -825,14 +825,15 @@ struct kib_conn *kiblnd_create_conn(stru return conn; failed_2: - kiblnd_destroy_conn(conn, true); + kiblnd_destroy_conn(conn); + LIBCFS_FREE(conn, sizeof(*conn)); failed_1: LIBCFS_FREE(init_qp_attr, sizeof(*init_qp_attr)); failed_0: return NULL; } -void kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn) +void kiblnd_destroy_conn(struct kib_conn *conn) { struct rdma_cm_id *cmid = conn->ibc_cmid; struct kib_peer *peer = conn->ibc_peer; @@ -895,8 +896,6 @@ void kiblnd_destroy_conn(struct kib_conn rdma_destroy_id(cmid); atomic_dec(&net->ibn_nconns); } - - LIBCFS_FREE(conn, sizeof(*conn)); } int kiblnd_close_peer_conns_locked(struct kib_peer *peer, int why) --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h @@ -1015,7 +1015,7 @@ int kiblnd_close_peer_conns_locked(stru struct kib_conn *kiblnd_create_conn(struct kib_peer *peer, struct rdma_cm_id *cmid, int state, int version); -void kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn); +void kiblnd_destroy_conn(struct kib_conn *conn); void kiblnd_close_conn(struct kib_conn *conn, int error); void kiblnd_close_conn_locked(struct kib_conn *conn, int error); --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c @@ -3313,11 +3313,13 @@ kiblnd_connd(void *arg) spin_unlock_irqrestore(lock, flags); dropped_lock = 1; - kiblnd_destroy_conn(conn, !peer); + kiblnd_destroy_conn(conn); spin_lock_irqsave(lock, flags); - if (!peer) + if (!peer) { + kfree(conn); continue; + } conn->ibc_peer = peer; if (peer->ibp_reconnected < KIB_RECONN_HIGH_RACE) Patches currently in stable-queue which might be from dmitry.eremin(a)intel.com are queue-4.14/staging-lustre-separate-a-connection-destroy-from-free-struct-kib_conn.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: ccree: NULLify backup_info when unused" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: ccree: NULLify backup_info when unused to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-ccree-nullify-backup_info-when-unused.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 46df8824982e4fb0198776078d4a8c3e2d531464 Mon Sep 17 00:00:00 2001 From: Gilad Ben-Yossef <gilad(a)benyossef.com> Date: Sun, 3 Dec 2017 13:58:19 +0000 Subject: staging: ccree: NULLify backup_info when unused From: Gilad Ben-Yossef <gilad(a)benyossef.com> commit 46df8824982e4fb0198776078d4a8c3e2d531464 upstream. backup_info field is only allocated for decrypt code path. The field was not nullified when not used causing a kfree in an error handling path to attempt to free random addresses as uncovered in stress testing. Fixes: 737aed947f9b ("staging: ccree: save ciphertext for CTS IV") Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/ccree/ssi_cipher.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/staging/ccree/ssi_cipher.c +++ b/drivers/staging/ccree/ssi_cipher.c @@ -904,6 +904,7 @@ static int ssi_ablkcipher_decrypt(struct scatterwalk_map_and_copy(req_ctx->backup_info, req->src, (req->nbytes - ivsize), ivsize, 0); req_ctx->is_giv = false; + req_ctx->backup_info = NULL; return ssi_blkcipher_process(tfm, req_ctx, req->dst, req->src, req->nbytes, req->info, ivsize, (void *)req, DRV_CRYPTO_DIRECTION_DECRYPT); } Patches currently in stable-queue which might be from gilad(a)benyossef.com are queue-4.14/staging-ccree-fix-fips-event-irq-handling-build.patch queue-4.14/staging-ccree-nullify-backup_info-when-unused.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: ccree: fix fips event irq handling build" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: ccree: fix fips event irq handling build to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-ccree-fix-fips-event-irq-handling-build.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From dc5591dc9c03e4cd22d3f0c3659196cc34668452 Mon Sep 17 00:00:00 2001 From: Gilad Ben-Yossef <gilad(a)benyossef.com> Date: Thu, 14 Dec 2017 14:02:46 +0000 Subject: staging: ccree: fix fips event irq handling build From: Gilad Ben-Yossef <gilad(a)benyossef.com> commit dc5591dc9c03e4cd22d3f0c3659196cc34668452 upstream. When moving from internal for kernel FIPS infrastructure the FIPS event irq handling code was left with the old ifdef by mistake. Fix it. Fixes: b7e607bf33a2 ("staging: ccree: move FIPS support to kernel infrastructure") Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/ccree/ssi_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/staging/ccree/ssi_driver.c +++ b/drivers/staging/ccree/ssi_driver.c @@ -141,7 +141,7 @@ static irqreturn_t cc_isr(int irq, void irr &= ~SSI_COMP_IRQ_MASK; complete_request(drvdata); } -#ifdef CC_SUPPORT_FIPS +#ifdef CONFIG_CRYPTO_FIPS /* TEE FIPS interrupt */ if (likely((irr & SSI_GPR0_IRQ_MASK) != 0)) { /* Mask interrupt - will be unmasked in Deferred service handler */ Patches currently in stable-queue which might be from gilad(a)benyossef.com are queue-4.14/staging-ccree-fix-fips-event-irq-handling-build.patch queue-4.14/staging-ccree-nullify-backup_info-when-unused.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "spi: imx: do not access registers while clocks disabled" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled spi: imx: do not access registers while clocks disabled to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: spi-imx-do-not-access-registers-while-clocks-disabled.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d593574aff0ab846136190b1729c151c736727ec Mon Sep 17 00:00:00 2001 From: Stefan Agner <stefan(a)agner.ch> Date: Sun, 7 Jan 2018 15:05:49 +0100 Subject: spi: imx: do not access registers while clocks disabled From: Stefan Agner <stefan(a)agner.ch> commit d593574aff0ab846136190b1729c151c736727ec upstream. Since clocks are disabled except during message transfer clocks are also disabled when spi_imx_remove gets called. Accessing registers leads to a freeeze at least on a i.MX 6ULL. Enable clocks before disabling accessing the MXC_CSPICTRL register. Fixes: 9e556dcc55774 ("spi: spi-imx: only enable the clocks when we start to transfer a message") Signed-off-by: Stefan Agner <stefan(a)agner.ch> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/spi/spi-imx.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) --- a/drivers/spi/spi-imx.c +++ b/drivers/spi/spi-imx.c @@ -1496,12 +1496,23 @@ static int spi_imx_remove(struct platfor { struct spi_master *master = platform_get_drvdata(pdev); struct spi_imx_data *spi_imx = spi_master_get_devdata(master); + int ret; spi_bitbang_stop(&spi_imx->bitbang); + ret = clk_enable(spi_imx->clk_per); + if (ret) + return ret; + + ret = clk_enable(spi_imx->clk_ipg); + if (ret) { + clk_disable(spi_imx->clk_per); + return ret; + } + writel(0, spi_imx->base + MXC_CSPICTRL); - clk_unprepare(spi_imx->clk_ipg); - clk_unprepare(spi_imx->clk_per); + clk_disable_unprepare(spi_imx->clk_ipg); + clk_disable_unprepare(spi_imx->clk_per); spi_imx_sdma_exit(spi_imx); spi_master_put(master); Patches currently in stable-queue which might be from stefan(a)agner.ch are queue-4.14/spi-imx-do-not-access-registers-while-clocks-disabled.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTS" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTS to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-imx-only-wakeup-via-rtsden-bit-if-the-system-has-rts-cts.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 38b1f0fb42f772b8c9aac53593883a18ff5eb9d7 Mon Sep 17 00:00:00 2001 From: Fabio Estevam <fabio.estevam(a)nxp.com> Date: Thu, 4 Jan 2018 15:58:34 -0200 Subject: serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTS From: Fabio Estevam <fabio.estevam(a)nxp.com> commit 38b1f0fb42f772b8c9aac53593883a18ff5eb9d7 upstream. The wakeup mechanism via RTSDEN bit relies on the system using the RTS/CTS lines, so only allow such wakeup method when the system actually has RTS/CTS support. Fixes: bc85734b126f ("serial: imx: allow waking up on RTSD") Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com> Reviewed-by: Martin Kaiser <martin(a)kaiser.cx> Acked-by: Fugang Duan <fugang.duan(a)nxp.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/imx.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -2275,12 +2275,14 @@ static void serial_imx_enable_wakeup(str val &= ~UCR3_AWAKEN; writel(val, sport->port.membase + UCR3); - val = readl(sport->port.membase + UCR1); - if (on) - val |= UCR1_RTSDEN; - else - val &= ~UCR1_RTSDEN; - writel(val, sport->port.membase + UCR1); + if (sport->have_rtscts) { + val = readl(sport->port.membase + UCR1); + if (on) + val |= UCR1_RTSDEN; + else + val &= ~UCR1_RTSDEN; + writel(val, sport->port.membase + UCR1); + } } static int imx_serial_port_suspend_noirq(struct device *dev) Patches currently in stable-queue which might be from fabio.estevam(a)nxp.com are queue-4.14/serial-imx-only-wakeup-via-rtsden-bit-if-the-system-has-rts-cts.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "serial: 8250_uniphier: fix error return code in uniphier_uart_probe()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: 8250_uniphier: fix error return code in uniphier_uart_probe() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-8250_uniphier-fix-error-return-code-in-uniphier_uart_probe.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7defa77d2baca4d6eb85234f10f38ab618332e75 Mon Sep 17 00:00:00 2001 From: Wei Yongjun <weiyongjun1(a)huawei.com> Date: Thu, 4 Jan 2018 07:42:15 +0000 Subject: serial: 8250_uniphier: fix error return code in uniphier_uart_probe() From: Wei Yongjun <weiyongjun1(a)huawei.com> commit 7defa77d2baca4d6eb85234f10f38ab618332e75 upstream. Fix to return a negative error code from the port register error handling case instead of 0, as done elsewhere in this function. Fixes: 39be40ce066d ("serial: 8250_uniphier: fix serial port index in private data") Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Acked-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_uniphier.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/tty/serial/8250/8250_uniphier.c +++ b/drivers/tty/serial/8250/8250_uniphier.c @@ -259,12 +259,13 @@ static int uniphier_uart_probe(struct pl up.dl_read = uniphier_serial_dl_read; up.dl_write = uniphier_serial_dl_write; - priv->line = serial8250_register_8250_port(&up); - if (priv->line < 0) { + ret = serial8250_register_8250_port(&up); + if (ret < 0) { dev_err(dev, "failed to register 8250 port\n"); clk_disable_unprepare(priv->clk); return ret; } + priv->line = ret; platform_set_drvdata(pdev, priv); Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are queue-4.14/test_firmware-fix-missing-unlock-on-error-in-config_num_requests_store.patch queue-4.14/serial-8250_uniphier-fix-error-return-code-in-uniphier_uart_probe.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "serial: 8250_of: fix return code when probe function fails to get reset" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: 8250_of: fix return code when probe function fails to get reset to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-8250_of-fix-return-code-when-probe-function-fails-to-get-reset.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b9820a31691b771db37afe2054dd3d3a680c1eed Mon Sep 17 00:00:00 2001 From: Masahiro Yamada <yamada.masahiro(a)socionext.com> Date: Wed, 27 Dec 2017 14:21:05 +0900 Subject: serial: 8250_of: fix return code when probe function fails to get reset From: Masahiro Yamada <yamada.masahiro(a)socionext.com> commit b9820a31691b771db37afe2054dd3d3a680c1eed upstream. The error pointer from devm_reset_control_get_optional_shared() is not propagated. One of the most common problem scenarios is it returns -EPROBE_DEFER when the reset controller has not probed yet. In this case, the probe of the reset consumer should be deferred. Fixes: e2860e1f62f2 ("serial: 8250_of: Add reset support") Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Reviewed-by: Philipp Zabel <p.zabel(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_of.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/tty/serial/8250/8250_of.c +++ b/drivers/tty/serial/8250/8250_of.c @@ -141,8 +141,11 @@ static int of_platform_serial_setup(stru } info->rst = devm_reset_control_get_optional_shared(&ofdev->dev, NULL); - if (IS_ERR(info->rst)) + if (IS_ERR(info->rst)) { + ret = PTR_ERR(info->rst); goto err_dispose; + } + ret = reset_control_deassert(info->rst); if (ret) goto err_dispose; Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are queue-4.14/serial-8250_of-fix-return-code-when-probe-function-fails-to-get-reset.patch queue-4.14/mtd-nand-denali_pci-add-missing-module_description-author-license.patch queue-4.14/serial-8250_uniphier-fix-error-return-code-in-uniphier_uart_probe.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "mei: me: allow runtime pm for platform with D0i3" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mei: me: allow runtime pm for platform with D0i3 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mei-me-allow-runtime-pm-for-platform-with-d0i3.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From cc365dcf0e56271bedf3de95f88922abe248e951 Mon Sep 17 00:00:00 2001 From: Tomas Winkler <tomas.winkler(a)intel.com> Date: Tue, 2 Jan 2018 12:01:41 +0200 Subject: mei: me: allow runtime pm for platform with D0i3 From: Tomas Winkler <tomas.winkler(a)intel.com> commit cc365dcf0e56271bedf3de95f88922abe248e951 upstream. >From the pci power documentation: "The driver itself should not call pm_runtime_allow(), though. Instead, it should let user space or some platform-specific code do that (user space can do it via sysfs as stated above)..." However, the S0ix residency cannot be reached without MEI device getting into low power state. Hence, for mei devices that support D0i3, it's better to make runtime power management mandatory and not rely on the system integration such as udev rules. This policy cannot be applied globally as some older platforms were found to have broken power management. Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com> Reviewed-by: Alexander Usyskin <alexander.usyskin(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/mei/pci-me.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/misc/mei/pci-me.c +++ b/drivers/misc/mei/pci-me.c @@ -238,8 +238,11 @@ static int mei_me_probe(struct pci_dev * */ mei_me_set_pm_domain(dev); - if (mei_pg_is_enabled(dev)) + if (mei_pg_is_enabled(dev)) { pm_runtime_put_noidle(&pdev->dev); + if (hw->d0i3_supported) + pm_runtime_allow(&pdev->dev); + } dev_dbg(&pdev->dev, "initialization successful.\n"); Patches currently in stable-queue which might be from tomas.winkler(a)intel.com are queue-4.14/mei-me-allow-runtime-pm-for-platform-with-d0i3.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "Input: synaptics-rmi4 - unmask F03 interrupts when port is opened" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: synaptics-rmi4 - unmask F03 interrupts when port is opened to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: input-synaptics-rmi4-unmask-f03-interrupts-when-port-is-opened.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6abe534f0776d2437c8302f58d8eb5abd483e926 Mon Sep 17 00:00:00 2001 From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Date: Wed, 17 Jan 2018 15:46:18 -0800 Subject: Input: synaptics-rmi4 - unmask F03 interrupts when port is opened From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> commit 6abe534f0776d2437c8302f58d8eb5abd483e926 upstream. Currently we register the pass-through serio port when we probe the F03 RMI function, and then, in sensor configure phase, we unmask interrupts. Unfortunately this is too late, as other drivers are free probe devices attached to the serio port as soon as it is probed. Because interrupts are masked, the IO times out, which may result in not being able to detect trackpoints on the pass-through port. To fix the issue we implement open() and close() methods for the pass-through serio port and unmask interrupts from there. We also move creation of the pass-through port form probe to configure stage, as RMI driver does not enable transport interrupt until all functions are probed (we should change this, but this is a separate topic). We also try to clear the pending data before unmasking interrupts, because some devices like to spam the system with multiple 0xaa 0x00 announcements, which may interfere with us trying to query ID of the device. Fixes: c5e8848fc98e ("Input: synaptics-rmi4 - add support for F03") Reviewed-by: Lyude Paul <lyude(a)redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/rmi4/rmi_f03.c | 64 ++++++++++++++++++++++++++++++++++++------- 1 file changed, 54 insertions(+), 10 deletions(-) --- a/drivers/input/rmi4/rmi_f03.c +++ b/drivers/input/rmi4/rmi_f03.c @@ -32,6 +32,7 @@ struct f03_data { struct rmi_function *fn; struct serio *serio; + bool serio_registered; unsigned int overwrite_buttons; @@ -138,6 +139,37 @@ static int rmi_f03_initialize(struct f03 return 0; } +static int rmi_f03_pt_open(struct serio *serio) +{ + struct f03_data *f03 = serio->port_data; + struct rmi_function *fn = f03->fn; + const u8 ob_len = f03->rx_queue_length * RMI_F03_OB_SIZE; + const u16 data_addr = fn->fd.data_base_addr + RMI_F03_OB_OFFSET; + u8 obs[RMI_F03_QUEUE_LENGTH * RMI_F03_OB_SIZE]; + int error; + + /* + * Consume any pending data. Some devices like to spam with + * 0xaa 0x00 announcements which may confuse us as we try to + * probe the device. + */ + error = rmi_read_block(fn->rmi_dev, data_addr, &obs, ob_len); + if (!error) + rmi_dbg(RMI_DEBUG_FN, &fn->dev, + "%s: Consumed %*ph (%d) from PS2 guest\n", + __func__, ob_len, obs, ob_len); + + return fn->rmi_dev->driver->set_irq_bits(fn->rmi_dev, fn->irq_mask); +} + +static void rmi_f03_pt_close(struct serio *serio) +{ + struct f03_data *f03 = serio->port_data; + struct rmi_function *fn = f03->fn; + + fn->rmi_dev->driver->clear_irq_bits(fn->rmi_dev, fn->irq_mask); +} + static int rmi_f03_register_pt(struct f03_data *f03) { struct serio *serio; @@ -148,6 +180,8 @@ static int rmi_f03_register_pt(struct f0 serio->id.type = SERIO_PS_PSTHRU; serio->write = rmi_f03_pt_write; + serio->open = rmi_f03_pt_open; + serio->close = rmi_f03_pt_close; serio->port_data = f03; strlcpy(serio->name, "Synaptics RMI4 PS/2 pass-through", @@ -184,17 +218,27 @@ static int rmi_f03_probe(struct rmi_func f03->device_count); dev_set_drvdata(dev, f03); - - error = rmi_f03_register_pt(f03); - if (error) - return error; - return 0; } static int rmi_f03_config(struct rmi_function *fn) { - fn->rmi_dev->driver->set_irq_bits(fn->rmi_dev, fn->irq_mask); + struct f03_data *f03 = dev_get_drvdata(&fn->dev); + int error; + + if (!f03->serio_registered) { + error = rmi_f03_register_pt(f03); + if (error) + return error; + + f03->serio_registered = true; + } else { + /* + * We must be re-configuring the sensor, just enable + * interrupts for this function. + */ + fn->rmi_dev->driver->set_irq_bits(fn->rmi_dev, fn->irq_mask); + } return 0; } @@ -204,7 +248,7 @@ static int rmi_f03_attention(struct rmi_ struct rmi_device *rmi_dev = fn->rmi_dev; struct rmi_driver_data *drvdata = dev_get_drvdata(&rmi_dev->dev); struct f03_data *f03 = dev_get_drvdata(&fn->dev); - u16 data_addr = fn->fd.data_base_addr; + const u16 data_addr = fn->fd.data_base_addr + RMI_F03_OB_OFFSET; const u8 ob_len = f03->rx_queue_length * RMI_F03_OB_SIZE; u8 obs[RMI_F03_QUEUE_LENGTH * RMI_F03_OB_SIZE]; u8 ob_status; @@ -226,8 +270,7 @@ static int rmi_f03_attention(struct rmi_ drvdata->attn_data.size -= ob_len; } else { /* Grab all of the data registers, and check them for data */ - error = rmi_read_block(fn->rmi_dev, data_addr + RMI_F03_OB_OFFSET, - &obs, ob_len); + error = rmi_read_block(fn->rmi_dev, data_addr, &obs, ob_len); if (error) { dev_err(&fn->dev, "%s: Failed to read F03 output buffers: %d\n", @@ -266,7 +309,8 @@ static void rmi_f03_remove(struct rmi_fu { struct f03_data *f03 = dev_get_drvdata(&fn->dev); - serio_unregister_port(f03->serio); + if (f03->serio_registered) + serio_unregister_port(f03->serio); } struct rmi_function_handler rmi_f03_handler = { Patches currently in stable-queue which might be from dmitry.torokhov(a)gmail.com are queue-4.14/input-synaptics-rmi4-do-not-delete-interrupt-memory-too-early.patch queue-4.14/input-synaptics-rmi4-unmask-f03-interrupts-when-port-is-opened.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "Input: synaptics-rmi4 - do not delete interrupt memory too early" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: synaptics-rmi4 - do not delete interrupt memory too early to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: input-synaptics-rmi4-do-not-delete-interrupt-memory-too-early.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a1ab69021a584d952e6548a44b93760547b1b6b5 Mon Sep 17 00:00:00 2001 From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Date: Wed, 17 Jan 2018 16:18:27 -0800 Subject: Input: synaptics-rmi4 - do not delete interrupt memory too early From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> commit a1ab69021a584d952e6548a44b93760547b1b6b5 upstream. We want to free memory reserved for interrupt mask handling only after we free functions, as function drivers might want to mask interrupts. This is needed for the followup patch to the F03 that would implement unmasking and masking interrupts from the serio pass-through port open() and close() methods. Reviewed-by: Lyude Paul <lyude(a)redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/rmi4/rmi_driver.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) --- a/drivers/input/rmi4/rmi_driver.c +++ b/drivers/input/rmi4/rmi_driver.c @@ -41,6 +41,13 @@ void rmi_free_function_list(struct rmi_d rmi_dbg(RMI_DEBUG_CORE, &rmi_dev->dev, "Freeing function list\n"); + /* Doing it in the reverse order so F01 will be removed last */ + list_for_each_entry_safe_reverse(fn, tmp, + &data->function_list, node) { + list_del(&fn->node); + rmi_unregister_function(fn); + } + devm_kfree(&rmi_dev->dev, data->irq_memory); data->irq_memory = NULL; data->irq_status = NULL; @@ -50,13 +57,6 @@ void rmi_free_function_list(struct rmi_d data->f01_container = NULL; data->f34_container = NULL; - - /* Doing it in the reverse order so F01 will be removed last */ - list_for_each_entry_safe_reverse(fn, tmp, - &data->function_list, node) { - list_del(&fn->node); - rmi_unregister_function(fn); - } } static int reset_one_function(struct rmi_function *fn) Patches currently in stable-queue which might be from dmitry.torokhov(a)gmail.com are queue-4.14/input-synaptics-rmi4-do-not-delete-interrupt-memory-too-early.patch queue-4.14/input-synaptics-rmi4-unmask-f03-interrupts-when-port-is-opened.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "iio: chemical: ccs811: Fix output of IIO_CONCENTRATION channels" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: chemical: ccs811: Fix output of IIO_CONCENTRATION channels to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iio-chemical-ccs811-fix-output-of-iio_concentration-channels.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8f114acd4e1a9cfa05b70bcc4219bc88197b5c9b Mon Sep 17 00:00:00 2001 From: Narcisa Ana Maria Vasile <narcisaanamaria12(a)gmail.com> Date: Wed, 6 Dec 2017 18:57:58 +0200 Subject: iio: chemical: ccs811: Fix output of IIO_CONCENTRATION channels From: Narcisa Ana Maria Vasile <narcisaanamaria12(a)gmail.com> commit 8f114acd4e1a9cfa05b70bcc4219bc88197b5c9b upstream. in_concentration_raw should report, according to sysfs-bus-iio documentation, a "Raw (unscaled no offset etc.) percentage reading of a substance." Modify scale to convert from ppm/ppb to percentage: 1 ppm = 0.0001% 1 ppb = 0.0000001% There is no offset needed to convert the ppm/ppb to percentage, so remove offset from IIO_CONCENTRATION (IIO_MOD_CO2) channel. Cc'd stable to reduce chance of userspace breakage in the long run as we fix this wrong bit of ABI usage. Signed-off-by: Narcisa Ana Maria Vasile <narcisaanamaria12(a)gmail.com> Reviewed-by: Matt Ranostay <matt.ranostay(a)konsulko.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/chemical/ccs811.c | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-) --- a/drivers/iio/chemical/ccs811.c +++ b/drivers/iio/chemical/ccs811.c @@ -91,7 +91,6 @@ static const struct iio_chan_spec ccs811 .channel2 = IIO_MOD_CO2, .modified = 1, .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | - BIT(IIO_CHAN_INFO_OFFSET) | BIT(IIO_CHAN_INFO_SCALE), .scan_index = 0, .scan_type = { @@ -245,24 +244,18 @@ static int ccs811_read_raw(struct iio_de switch (chan->channel2) { case IIO_MOD_CO2: *val = 0; - *val2 = 12834; + *val2 = 100; return IIO_VAL_INT_PLUS_MICRO; case IIO_MOD_VOC: *val = 0; - *val2 = 84246; - return IIO_VAL_INT_PLUS_MICRO; + *val2 = 100; + return IIO_VAL_INT_PLUS_NANO; default: return -EINVAL; } default: return -EINVAL; } - case IIO_CHAN_INFO_OFFSET: - if (!(chan->type == IIO_CONCENTRATION && - chan->channel2 == IIO_MOD_CO2)) - return -EINVAL; - *val = -400; - return IIO_VAL_INT; default: return -EINVAL; } Patches currently in stable-queue which might be from narcisaanamaria12(a)gmail.com are queue-4.14/iio-chemical-ccs811-fix-output-of-iio_concentration-channels.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "iio: adc: stm32: fix scan of multiple channels with DMA" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: stm32: fix scan of multiple channels with DMA to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iio-adc-stm32-fix-scan-of-multiple-channels-with-dma.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 04e491ca9df60ffe8637d00d68e5ab8bc73b30d5 Mon Sep 17 00:00:00 2001 From: Fabrice Gasnier <fabrice.gasnier(a)st.com> Date: Fri, 5 Jan 2018 15:34:54 +0100 Subject: iio: adc: stm32: fix scan of multiple channels with DMA From: Fabrice Gasnier <fabrice.gasnier(a)st.com> commit 04e491ca9df60ffe8637d00d68e5ab8bc73b30d5 upstream. By default, watermark is set to '1'. Watermark is used to fine tune cyclic dma buffer period. In case watermark is left untouched (e.g. 1) and several channels are being scanned, buffer period is wrongly set (e.g. to 1 sample). As a consequence, data is never pushed to upper layer. Fix buffer period size, by taking scan channels number into account. Fixes: 2763ea0585c9 ("iio: adc: stm32: add optional dma support") Signed-off-by: Fabrice Gasnier <fabrice.gasnier(a)st.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/adc/stm32-adc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/iio/adc/stm32-adc.c +++ b/drivers/iio/adc/stm32-adc.c @@ -1314,6 +1314,7 @@ static int stm32_adc_set_watermark(struc { struct stm32_adc *adc = iio_priv(indio_dev); unsigned int watermark = STM32_DMA_BUFFER_SIZE / 2; + unsigned int rx_buf_sz = STM32_DMA_BUFFER_SIZE; /* * dma cyclic transfers are used, buffer is split into two periods. @@ -1322,7 +1323,7 @@ static int stm32_adc_set_watermark(struc * - one buffer (period) driver can push with iio_trigger_poll(). */ watermark = min(watermark, val * (unsigned)(sizeof(u16))); - adc->rx_buf_sz = watermark * 2; + adc->rx_buf_sz = min(rx_buf_sz, watermark * 2 * adc->num_conv); return 0; } Patches currently in stable-queue which might be from fabrice.gasnier(a)st.com are queue-4.14/iio-adc-stm32-fix-scan-of-multiple-channels-with-dma.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "CDC-ACM: apply quirk for card reader" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled CDC-ACM: apply quirk for card reader to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cdc-acm-apply-quirk-for-card-reader.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From df1cc78a52491f71d8170d513d0f6f114faa1bda Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Thu, 18 Jan 2018 12:13:45 +0100 Subject: CDC-ACM: apply quirk for card reader From: Oliver Neukum <oneukum(a)suse.com> commit df1cc78a52491f71d8170d513d0f6f114faa1bda upstream. This devices drops random bytes from messages if you talk to it too fast. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/class/cdc-acm.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -1765,6 +1765,9 @@ static const struct usb_device_id acm_id { USB_DEVICE(0x0ace, 0x1611), /* ZyDAS 56K USB MODEM - new version */ .driver_info = SINGLE_RX_URB, /* firmware bug */ }, + { USB_DEVICE(0x11ca, 0x0201), /* VeriFone Mx870 Gadget Serial */ + .driver_info = SINGLE_RX_URB, + }, { USB_DEVICE(0x22b8, 0x7000), /* Motorola Q Phone */ .driver_info = NO_UNION_NORMAL, /* has no union descriptor */ }, Patches currently in stable-queue which might be from oneukum(a)suse.com are queue-4.14/usb-uas-unconditionally-bring-back-host-after-reset.patch queue-4.14/cdc-acm-apply-quirk-for-card-reader.patch queue-4.14/usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "android: binder: use VM_ALLOC to get vm area" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled android: binder: use VM_ALLOC to get vm area to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: android-binder-use-vm_alloc-to-get-vm-area.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From aac6830ec1cb681544212838911cdc57f2638216 Mon Sep 17 00:00:00 2001 From: Ganesh Mahendran <opensource.ganesh(a)gmail.com> Date: Wed, 10 Jan 2018 10:49:05 +0800 Subject: android: binder: use VM_ALLOC to get vm area From: Ganesh Mahendran <opensource.ganesh(a)gmail.com> commit aac6830ec1cb681544212838911cdc57f2638216 upstream. VM_IOREMAP is used to access hardware through a mechanism called I/O mapped memory. Android binder is a IPC machanism which will not access I/O memory. And VM_IOREMAP has alignment requiement which may not needed in binder. __get_vm_area_node() { ... if (flags & VM_IOREMAP) align = 1ul << clamp_t(int, fls_long(size), PAGE_SHIFT, IOREMAP_MAX_ORDER); ... } This patch will save some kernel vm area, especially for 32bit os. In 32bit OS, kernel vm area is only 240MB. We may got below error when launching a app: <3>[ 4482.440053] binder_alloc: binder_alloc_mmap_handler: 15728 8ce67000-8cf65000 get_vm_area failed -12 <3>[ 4483.218817] binder_alloc: binder_alloc_mmap_handler: 15745 8ce67000-8cf65000 get_vm_area failed -12 Signed-off-by: Ganesh Mahendran <opensource.ganesh(a)gmail.com> Acked-by: Martijn Coenen <maco(a)android.com> Acked-by: Todd Kjos <tkjos(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/android/binder_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/android/binder_alloc.c +++ b/drivers/android/binder_alloc.c @@ -668,7 +668,7 @@ int binder_alloc_mmap_handler(struct bin goto err_already_mapped; } - area = get_vm_area(vma->vm_end - vma->vm_start, VM_IOREMAP); + area = get_vm_area(vma->vm_end - vma->vm_start, VM_ALLOC); if (area == NULL) { ret = -ENOMEM; failure_string = "get_vm_area"; Patches currently in stable-queue which might be from opensource.ganesh(a)gmail.com are queue-4.14/android-binder-use-vm_alloc-to-get-vm-area.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "ANDROID: binder: remove waitqueue when thread exits." has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ANDROID: binder: remove waitqueue when thread exits. to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: android-binder-remove-waitqueue-when-thread-exits.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f5cb779ba16334b45ba8946d6bfa6d9834d1527f Mon Sep 17 00:00:00 2001 From: Martijn Coenen <maco(a)android.com> Date: Fri, 5 Jan 2018 11:27:07 +0100 Subject: ANDROID: binder: remove waitqueue when thread exits. From: Martijn Coenen <maco(a)android.com> commit f5cb779ba16334b45ba8946d6bfa6d9834d1527f upstream. binder_poll() passes the thread->wait waitqueue that can be slept on for work. When a thread that uses epoll explicitly exits using BINDER_THREAD_EXIT, the waitqueue is freed, but it is never removed from the corresponding epoll data structure. When the process subsequently exits, the epoll cleanup code tries to access the waitlist, which results in a use-after-free. Prevent this by using POLLFREE when the thread exits. Signed-off-by: Martijn Coenen <maco(a)android.com> Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/android/binder.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/drivers/android/binder.c +++ b/drivers/android/binder.c @@ -4302,6 +4302,18 @@ static int binder_thread_release(struct if (t) spin_lock(&t->lock); } + + /* + * If this thread used poll, make sure we remove the waitqueue + * from any epoll data structures holding it with POLLFREE. + * waitqueue_active() is safe to use here because we're holding + * the inner lock. + */ + if ((thread->looper & BINDER_LOOPER_STATE_POLL) && + waitqueue_active(&thread->wait)) { + wake_up_poll(&thread->wait, POLLHUP | POLLFREE); + } + binder_inner_proc_unlock(thread->proc); if (send_reply) Patches currently in stable-queue which might be from maco(a)android.com are queue-4.14/android-binder-remove-waitqueue-when-thread-exits.patch queue-4.14/android-binder-use-vm_alloc-to-get-vm-area.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] [PATCH 4.9] usbip: vhci_hcd: clear just the USB_PORT_STAT_POWER bit

by Shuah Khan

Upstream commit 1c9de5bf4286 ("usbip: vhci-hcd: Add USB3 SuperSpeed support") vhci_hcd clears all the bits port_status bits instead of clearing just the USB_PORT_STAT_POWER bit when it handles ClearPortFeature: USB_PORT_FEAT_POWER. This causes vhci_hcd attach to fail in a bad state, leaving device unusable by the client. The device is still attached and however client can't use it. The problem was fixed as part of larger change to add USB3 Super Speed support. This patch backports just the change to clear the USB_PORT_STAT_POWER. Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> --- drivers/usb/usbip/vhci_hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c index 7f161b095176..dbe615ba07c9 100644 --- a/drivers/usb/usbip/vhci_hcd.c +++ b/drivers/usb/usbip/vhci_hcd.c @@ -300,7 +300,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue, case USB_PORT_FEAT_POWER: usbip_dbg_vhci_rh( " ClearPortFeature: USB_PORT_FEAT_POWER\n"); - dum->port_status[rhport] = 0; + dum->port_status[rhport] &= ~USB_PORT_STAT_POWER; dum->resuming = 0; break; case USB_PORT_FEAT_C_RESET: -- 2.14.1

7 years, 4 months

3
4
0 0

[Linux-stable-mirror] Patch "usbip: prevent bind loops on devices attached to vhci_hcd" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usbip: prevent bind loops on devices attached to vhci_hcd to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usbip-prevent-bind-loops-on-devices-attached-to-vhci_hcd.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ef54cf0c600fb8f5737fb001a9e357edda1a1de8 Mon Sep 17 00:00:00 2001 From: Shuah Khan <shuahkh(a)osg.samsung.com> Date: Wed, 17 Jan 2018 12:07:30 -0700 Subject: usbip: prevent bind loops on devices attached to vhci_hcd From: Shuah Khan <shuahkh(a)osg.samsung.com> commit ef54cf0c600fb8f5737fb001a9e357edda1a1de8 upstream. usbip host binds to devices attached to vhci_hcd on the same server when user does attach over localhost or specifies the server as the remote. usbip attach -r localhost -b busid or usbip attach -r servername (or server IP) Unbind followed by bind works, however device is left in a bad state with accesses via the attached busid result in errors and system hangs during shutdown. Fix it to check and bail out if the device is already attached to vhci_hcd. Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/usb/usbip/src/usbip_bind.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/tools/usb/usbip/src/usbip_bind.c +++ b/tools/usb/usbip/src/usbip_bind.c @@ -144,6 +144,7 @@ static int bind_device(char *busid) int rc; struct udev *udev; struct udev_device *dev; + const char *devpath; /* Check whether the device with this bus ID exists. */ udev = udev_new(); @@ -152,8 +153,16 @@ static int bind_device(char *busid) err("device with the specified bus ID does not exist"); return -1; } + devpath = udev_device_get_devpath(dev); udev_unref(udev); + /* If the device is already attached to vhci_hcd - bail out */ + if (strstr(devpath, USBIP_VHCI_DRV_NAME)) { + err("bind loop detected: device: %s is attached to %s\n", + devpath, USBIP_VHCI_DRV_NAME); + return -1; + } + rc = unbind_other(busid); if (rc == UNBIND_ST_FAILED) { err("could not unbind driver from device on busid %s", busid); Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are queue-4.9/usbip-list-don-t-list-devices-attached-to-vhci_hcd.patch queue-4.9/usbip-prevent-bind-loops-on-devices-attached-to-vhci_hcd.patch queue-4.9/cpupowerutils-bench-fix-cpu-online-check.patch queue-4.9/usbip-vhci_hcd-clear-just-the-usb_port_stat_power-bit.patch queue-4.9/cpupower-fix-cpupower-working-when-cpu0-is-offline.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usbip: list: don't list devices attached to vhci_hcd" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usbip: list: don't list devices attached to vhci_hcd to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usbip-list-don-t-list-devices-attached-to-vhci_hcd.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ef824501f50846589f02173d73ce3fe6021a9d2a Mon Sep 17 00:00:00 2001 From: Shuah Khan <shuahkh(a)osg.samsung.com> Date: Wed, 17 Jan 2018 12:08:03 -0700 Subject: usbip: list: don't list devices attached to vhci_hcd From: Shuah Khan <shuahkh(a)osg.samsung.com> commit ef824501f50846589f02173d73ce3fe6021a9d2a upstream. usbip host lists devices attached to vhci_hcd on the same server when user does attach over localhost or specifies the server as the remote. usbip attach -r localhost -b busid or usbip attach -r servername (or server IP) Fix it to check and not list devices that are attached to vhci_hcd. Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/usb/usbip/src/usbip_list.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/tools/usb/usbip/src/usbip_list.c +++ b/tools/usb/usbip/src/usbip_list.c @@ -187,6 +187,7 @@ static int list_devices(bool parsable) const char *busid; char product_name[128]; int ret = -1; + const char *devpath; /* Create libudev context. */ udev = udev_new(); @@ -209,6 +210,14 @@ static int list_devices(bool parsable) path = udev_list_entry_get_name(dev_list_entry); dev = udev_device_new_from_syspath(udev, path); + /* Ignore devices attached to vhci_hcd */ + devpath = udev_device_get_devpath(dev); + if (strstr(devpath, USBIP_VHCI_DRV_NAME)) { + dbg("Skip the device %s already attached to %s\n", + devpath, USBIP_VHCI_DRV_NAME); + continue; + } + /* Get device information. */ idVendor = udev_device_get_sysattr_value(dev, "idVendor"); idProduct = udev_device_get_sysattr_value(dev, "idProduct"); Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are queue-4.9/usbip-list-don-t-list-devices-attached-to-vhci_hcd.patch queue-4.9/usbip-prevent-bind-loops-on-devices-attached-to-vhci_hcd.patch queue-4.9/cpupowerutils-bench-fix-cpu-online-check.patch queue-4.9/usbip-vhci_hcd-clear-just-the-usb_port_stat_power-bit.patch queue-4.9/cpupower-fix-cpupower-working-when-cpu0-is-offline.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: uas: unconditionally bring back host after reset" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: uas: unconditionally bring back host after reset to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-uas-unconditionally-bring-back-host-after-reset.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From cbeef22fd611c4f47c494b821b2b105b8af970bb Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Thu, 11 Jan 2018 13:10:16 +0100 Subject: usb: uas: unconditionally bring back host after reset From: Oliver Neukum <oneukum(a)suse.com> commit cbeef22fd611c4f47c494b821b2b105b8af970bb upstream. Quoting Hans: If we return 1 from our post_reset handler, then our disconnect handler will be called immediately afterwards. Since pre_reset blocks all scsi requests our disconnect handler will then hang in the scsi_remove_host call. This is esp. bad because our disconnect handler hanging for ever also stops the USB subsys from enumerating any new USB devices, causes commands like lsusb to hang, etc. In practice this happens when unplugging some uas devices because the hub code may see the device as needing a warm-reset and calls usb_reset_device before seeing the disconnect. In this case uas_configure_endpoints fails with -ENODEV. We do not want to print an error for this, so this commit also silences the shost_printk for -ENODEV. ENDQUOTE However, if we do that we better drop any unconditional execution and report to the SCSI subsystem that we have undergone a reset but we are not operational now. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Reported-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/storage/uas.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- a/drivers/usb/storage/uas.c +++ b/drivers/usb/storage/uas.c @@ -1076,20 +1076,19 @@ static int uas_post_reset(struct usb_int return 0; err = uas_configure_endpoints(devinfo); - if (err) { + if (err && err != ENODEV) shost_printk(KERN_ERR, shost, "%s: alloc streams error %d after reset", __func__, err); - return 1; - } + /* we must unblock the host in every case lest we deadlock */ spin_lock_irqsave(shost->host_lock, flags); scsi_report_bus_reset(shost, 0); spin_unlock_irqrestore(shost->host_lock, flags); scsi_unblock_requests(shost); - return 0; + return err ? 1 : 0; } static int uas_suspend(struct usb_interface *intf, pm_message_t message) Patches currently in stable-queue which might be from oneukum(a)suse.com are queue-4.9/usb-uas-unconditionally-bring-back-host-after-reset.patch queue-4.9/cdc-acm-apply-quirk-for-card-reader.patch queue-4.9/usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: simple: add Motorola Tetra driver" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: simple: add Motorola Tetra driver to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-serial-simple-add-motorola-tetra-driver.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 46fe895e22ab3845515ec06b01eaf1282b342e29 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Thu, 18 Jan 2018 14:46:41 +1100 Subject: USB: serial: simple: add Motorola Tetra driver From: Johan Hovold <johan(a)kernel.org> commit 46fe895e22ab3845515ec06b01eaf1282b342e29 upstream. Add new Motorola Tetra (simple) driver for Motorola Solutions TETRA PEI devices. D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0cad ProdID=9011 Rev=24.16 S: Manufacturer=Motorola Solutions Inc. S: Product=Motorola Solutions TETRA PEI interface C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) Note that these devices do not support the CDC SET_CONTROL_LINE_STATE request (for any interface). Reported-by: Max Schulze <max.schulze(a)posteo.de> Tested-by: Max Schulze <max.schulze(a)posteo.de> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/Kconfig | 1 + drivers/usb/serial/usb-serial-simple.c | 7 +++++++ 2 files changed, 8 insertions(+) --- a/drivers/usb/serial/Kconfig +++ b/drivers/usb/serial/Kconfig @@ -63,6 +63,7 @@ config USB_SERIAL_SIMPLE - Google USB serial devices - HP4x calculators - a number of Motorola phones + - Motorola Tetra devices - Novatel Wireless GPS receivers - Siemens USB/MPI adapter. - ViVOtech ViVOpay USB device. --- a/drivers/usb/serial/usb-serial-simple.c +++ b/drivers/usb/serial/usb-serial-simple.c @@ -80,6 +80,11 @@ DEVICE(vivopay, VIVOPAY_IDS); { USB_DEVICE(0x22b8, 0x2c64) } /* Motorola V950 phone */ DEVICE(moto_modem, MOTO_IDS); +/* Motorola Tetra driver */ +#define MOTOROLA_TETRA_IDS() \ + { USB_DEVICE(0x0cad, 0x9011) } /* Motorola Solutions TETRA PEI */ +DEVICE(motorola_tetra, MOTOROLA_TETRA_IDS); + /* Novatel Wireless GPS driver */ #define NOVATEL_IDS() \ { USB_DEVICE(0x09d7, 0x0100) } /* NovAtel FlexPack GPS */ @@ -110,6 +115,7 @@ static struct usb_serial_driver * const &google_device, &vivopay_device, &moto_modem_device, + &motorola_tetra_device, &novatel_gps_device, &hp4x_device, &suunto_device, @@ -125,6 +131,7 @@ static const struct usb_device_id id_tab GOOGLE_IDS(), VIVOPAY_IDS(), MOTO_IDS(), + MOTOROLA_TETRA_IDS(), NOVATEL_IDS(), HP4X_IDS(), SUUNTO_IDS(), Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.9/usb-serial-pl2303-new-device-id-for-chilitag.patch queue-4.9/usb-serial-simple-add-motorola-tetra-driver.patch queue-4.9/usb-serial-io_edgeport-fix-possible-sleep-in-atomic.patch queue-4.9/usb-option-add-support-for-fs040u-modem.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: pl2303: new device id for Chilitag" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: pl2303: new device id for Chilitag to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-serial-pl2303-new-device-id-for-chilitag.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d08dd3f3dd2ae351b793fc5b76abdbf0fd317b12 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Date: Thu, 25 Jan 2018 09:48:55 +0100 Subject: USB: serial: pl2303: new device id for Chilitag MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> commit d08dd3f3dd2ae351b793fc5b76abdbf0fd317b12 upstream. This adds a new device id for Chilitag devices to the pl2303 driver. Reported-by: "Chu.Mike [朱堅宜]" <Mike-Chu(a)prolific.com.tw> Acked-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/pl2303.c | 1 + drivers/usb/serial/pl2303.h | 1 + 2 files changed, 2 insertions(+) --- a/drivers/usb/serial/pl2303.c +++ b/drivers/usb/serial/pl2303.c @@ -39,6 +39,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ2) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_DCU11) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ3) }, + { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_CHILITAG) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_PHAROS) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_ALDIGA) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_MMX) }, --- a/drivers/usb/serial/pl2303.h +++ b/drivers/usb/serial/pl2303.h @@ -17,6 +17,7 @@ #define PL2303_PRODUCT_ID_DCU11 0x1234 #define PL2303_PRODUCT_ID_PHAROS 0xaaa0 #define PL2303_PRODUCT_ID_RSAQ3 0xaaa2 +#define PL2303_PRODUCT_ID_CHILITAG 0xaaa8 #define PL2303_PRODUCT_ID_ALDIGA 0x0611 #define PL2303_PRODUCT_ID_MMX 0x0612 #define PL2303_PRODUCT_ID_GPRS 0x0609 Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are queue-4.9/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.9/drm-bridge-tc358767-fix-timing-calculations.patch queue-4.9/lockd-fix-list_add-double-add-caused-by-legacy-signal-interface.patch queue-4.9/xfs-always-free-inline-data-before-resetting-inode-fork-during-ifree.patch queue-4.9/crypto-ecdh-fix-typo-in-kpp-dependency-of-crypto_ecdh.patch queue-4.9/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.9/nfsd-ensure-we-check-stateid-validity-in-the-seqid-operation-checks.patch queue-4.9/hid-wacom-ekr-ensure-devres-groups-at-higher-indexes-are-released.patch queue-4.9/staging-lustre-separate-a-connection-destroy-from-free-struct-kib_conn.patch queue-4.9/drm-amdgpu-don-t-try-to-move-pinned-bos.patch queue-4.9/sunrpc-allow-connect-to-return-ehostunreach.patch queue-4.9/tty-fix-data-race-between-tty_init_dev-and-flush-of-buf.patch queue-4.9/drm-bridge-tc358767-fix-auxdatan-registers-access.patch queue-4.9/nfsd-check-for-use-of-the-closed-special-stateid.patch queue-4.9/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch queue-4.9/bcache-check-return-value-of-register_shrinker.patch queue-4.9/nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch queue-4.9/crypto-af_alg-whitelist-mask-and-type.patch queue-4.9/quota-check-for-register_shrinker-failure.patch queue-4.9/mac80211-fix-the-update-of-path-metric-for-rann-frame.patch queue-4.9/xen-netfront-remove-warning-when-unloading-module.patch queue-4.9/net-mlx5-define-interface-bits-for-fencing-umr-wqe.patch queue-4.9/kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch queue-4.9/crypto-aesni-handle-zero-length-dst-buffer.patch queue-4.9/kmemleak-add-scheduling-point-to-kmemleak_scan.patch queue-4.9/net-ethernet-xilinx-mark-xilinx_ll_temac-broken-on-64-bit.patch queue-4.9/bnxt_en-fix-an-error-handling-path-in-bnxt_get_module_eeprom.patch queue-4.9/drm-amdkfd-fix-sdma-oversubsription-handling.patch queue-4.9/grace-replace-bug_on-by-warn_once-in-exit_net-hook.patch queue-4.9/xfs-ubsan-fixes.patch queue-4.9/gpio-iop-add-missing-module_description-author-license.patch queue-4.9/arm-dts-nsp-fix-ppi-interrupt-types.patch queue-4.9/xfs-fortify-xfs_alloc_buftarg-error-handling.patch queue-4.9/usbip-list-don-t-list-devices-attached-to-vhci_hcd.patch queue-4.9/scsi-ufs-ufshcd-fix-potential-null-pointer-dereference-in-ufshcd_config_vreg.patch queue-4.9/kvm-x86-fix-operand-address-size-during-instruction-decoding.patch queue-4.9/usb-uas-unconditionally-bring-back-host-after-reset.patch queue-4.9/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.9/usb-gadget-fix-high-bandwidth-check-in-usb_gadget_ep_match_desc.patch queue-4.9/usbip-prevent-bind-loops-on-devices-attached-to-vhci_hcd.patch queue-4.9/btrfs-fix-deadlock-when-writing-out-space-cache.patch queue-4.9/drm-amdkfd-fix-sdma-ring-buffer-size-calculation.patch queue-4.9/scsi-aacraid-prevent-crash-in-case-of-free-interrupt-during-scsi-eh-path.patch queue-4.9/iwlwifi-mvm-fix-the-tx-queue-hang-timeout-for-monitor-vif-type.patch queue-4.9/drm-bridge-tc358767-filter-out-too-high-modes.patch queue-4.9/kvm-x86-fix-softlockup-when-get-the-current-kvmclock.patch queue-4.9/spi-imx-do-not-access-registers-while-clocks-disabled.patch queue-4.9/cdc-acm-apply-quirk-for-card-reader.patch queue-4.9/rdma-mlx5-set-umr-wqe-fence-according-to-hca-cap.patch queue-4.9/staging-rtl8188eu-fix-incorrect-response-to-siocgiwessid.patch queue-4.9/serial-imx-only-wakeup-via-rtsden-bit-if-the-system-has-rts-cts.patch queue-4.9/xfs-properly-retry-failed-dquot-items-in-case-of-error-during-buffer-writeback.patch queue-4.9/cpupowerutils-bench-fix-cpu-online-check.patch queue-4.9/drm-bridge-tc358767-fix-1-lane-behavior.patch queue-4.9/drm-amdgpu-fix-sdma-load-unload-sequence-on-hws-disabled-mode.patch queue-4.9/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch queue-4.9/usbip-vhci_hcd-clear-just-the-usb_port_stat_power-bit.patch queue-4.9/cpufreq-add-loongson-machine-dependencies.patch queue-4.9/power-reset-zx-reboot-add-missing-module_description-author-license.patch queue-4.9/igb-free-irqs-when-device-is-hotplugged.patch queue-4.9/acpi-bus-leave-modalias-empty-for-devices-which-are-not-present.patch queue-4.9/tools-gpio-fix-build-error-with-musl-libc.patch queue-4.9/drm-bridge-tc358767-fix-dp0_misc-register-set.patch queue-4.9/drm-vc4-move-irq-enable-to-pm-path.patch queue-4.9/usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch queue-4.9/gpio-fix-kernel-stack-leak-to-userspace.patch queue-4.9/gpio-ath79-add-missing-module_description-license.patch queue-4.9/drm-omap-fix-error-handling-path-in-omap_dmm_probe.patch queue-4.9/loop-fix-concurrent-lo_open-lo_release.patch queue-4.9/media-usbtv-add-a-new-usbid.patch queue-4.9/drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch queue-4.9/usb-serial-pl2303-new-device-id-for-chilitag.patch queue-4.9/usb-serial-simple-add-motorola-tetra-driver.patch queue-4.9/usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch queue-4.9/cpupower-fix-cpupower-working-when-cpu0-is-offline.patch queue-4.9/auxdisplay-img-ascii-lcd-only-build-on-archs-that-have-iomem.patch queue-4.9/usb-serial-io_edgeport-fix-possible-sleep-in-atomic.patch queue-4.9/usb-option-add-support-for-fs040u-modem.patch queue-4.9/usb-f_fs-prevent-gadget-unbind-if-it-is-already-unbound.patch queue-4.9/crypto-sha3-generic-fixes-for-alignment-and-big-endian-operation.patch queue-4.9/hwmon-pmbus-use-64bit-math-for-direct-format-values.patch queue-4.9/reiserfs-remove-unneeded-i_version-bump.patch queue-4.9/openvswitch-fix-the-incorrect-flow-action-alloc-size.patch queue-4.9/gpio-stmpe-i2c-transfer-are-forbiden-in-atomic-context.patch queue-4.9/mtd-nand-denali_pci-add-missing-module_description-author-license.patch queue-4.9/drm-vc4-account-for-interrupts-in-flight.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: io_edgeport: fix possible sleep-in-atomic" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: io_edgeport: fix possible sleep-in-atomic to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-serial-io_edgeport-fix-possible-sleep-in-atomic.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c7b8f77872c73f69a16528a9eb87afefcccdc18b Mon Sep 17 00:00:00 2001 From: Jia-Ju Bai <baijiaju1990(a)gmail.com> Date: Wed, 13 Dec 2017 20:34:36 +0800 Subject: USB: serial: io_edgeport: fix possible sleep-in-atomic From: Jia-Ju Bai <baijiaju1990(a)gmail.com> commit c7b8f77872c73f69a16528a9eb87afefcccdc18b upstream. According to drivers/usb/serial/io_edgeport.c, the driver may sleep under a spinlock. The function call path is: edge_bulk_in_callback (acquire the spinlock) process_rcvd_data process_rcvd_status change_port_settings send_iosp_ext_cmd write_cmd_usb usb_kill_urb --> may sleep To fix it, the redundant usb_kill_urb() is removed from the error path after usb_submit_urb() fails. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai <baijiaju1990(a)gmail.com> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/io_edgeport.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/usb/serial/io_edgeport.c +++ b/drivers/usb/serial/io_edgeport.c @@ -2215,7 +2215,6 @@ static int write_cmd_usb(struct edgeport /* something went wrong */ dev_err(dev, "%s - usb_submit_urb(write command) failed, status = %d\n", __func__, status); - usb_kill_urb(urb); usb_free_urb(urb); atomic_dec(&CmdUrbs); return status; Patches currently in stable-queue which might be from baijiaju1990(a)gmail.com are queue-4.9/usb-serial-io_edgeport-fix-possible-sleep-in-atomic.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: option: Add support for FS040U modem" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: option: Add support for FS040U modem to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-option-add-support-for-fs040u-modem.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 69341bd15018da0a662847e210f9b2380c71e623 Mon Sep 17 00:00:00 2001 From: OKAMOTO Yoshiaki <yokamoto(a)allied-telesis.co.jp> Date: Tue, 16 Jan 2018 09:51:17 +0000 Subject: usb: option: Add support for FS040U modem From: OKAMOTO Yoshiaki <yokamoto(a)allied-telesis.co.jp> commit 69341bd15018da0a662847e210f9b2380c71e623 upstream. FS040U modem is manufactured by omega, and sold by Fujisoft. This patch adds ID of the modem to use option1 driver. Interface 3 is used as qmi_wwan, so the interface is ignored. Signed-off-by: Yoshiaki Okamoto <yokamoto(a)allied-telesis.co.jp> Signed-off-by: Hiroyuki Yamamoto <hyamamo(a)allied-telesis.co.jp> Acked-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/option.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -383,6 +383,9 @@ static void option_instat_callback(struc #define FOUR_G_SYSTEMS_PRODUCT_W14 0x9603 #define FOUR_G_SYSTEMS_PRODUCT_W100 0x9b01 +/* Fujisoft products */ +#define FUJISOFT_PRODUCT_FS040U 0x9b02 + /* iBall 3.5G connect wireless modem */ #define IBALL_3_5G_CONNECT 0x9605 @@ -1897,6 +1900,8 @@ static const struct usb_device_id option { USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W100), .driver_info = (kernel_ulong_t)&four_g_w100_blacklist }, + {USB_DEVICE(LONGCHEER_VENDOR_ID, FUJISOFT_PRODUCT_FS040U), + .driver_info = (kernel_ulong_t)&net_intf3_blacklist}, { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, SPEEDUP_PRODUCT_SU9800, 0xff) }, { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 0x9801, 0xff), .driver_info = (kernel_ulong_t)&net_intf3_blacklist }, Patches currently in stable-queue which might be from yokamoto(a)allied-telesis.co.jp are queue-4.9/usb-option-add-support-for-fs040u-modem.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usb/gadget: Fix "high bandwidth" check in usb_gadget_ep_match_desc()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb/gadget: Fix "high bandwidth" check in usb_gadget_ep_match_desc() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-fix-high-bandwidth-check-in-usb_gadget_ep_match_desc.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 11fb37998759c48e4e4c200c974593cbeab25d3e Mon Sep 17 00:00:00 2001 From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Date: Fri, 12 Jan 2018 17:50:02 +1100 Subject: usb/gadget: Fix "high bandwidth" check in usb_gadget_ep_match_desc() From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> commit 11fb37998759c48e4e4c200c974593cbeab25d3e upstream. The current code tries to test for bits that are masked out by usb_endpoint_maxp(). Instead, use the proper accessor to access the new high bandwidth bits. Signed-off-by: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/udc/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/usb/gadget/udc/core.c +++ b/drivers/usb/gadget/udc/core.c @@ -913,7 +913,7 @@ int usb_gadget_ep_match_desc(struct usb_ return 0; /* "high bandwidth" works only at high speed */ - if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp(desc) & (3<<11)) + if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp_mult(desc) > 1) return 0; switch (type) { Patches currently in stable-queue which might be from benh(a)kernel.crashing.org are queue-4.9/usb-gadget-fix-high-bandwidth-check-in-usb_gadget_ep_match_desc.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: f_fs: Prevent gadget unbind if it is already unbound" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: f_fs: Prevent gadget unbind if it is already unbound to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-f_fs-prevent-gadget-unbind-if-it-is-already-unbound.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ce5bf9a50daf2d9078b505aca1cea22e88ecb94a Mon Sep 17 00:00:00 2001 From: Hemant Kumar <hemantk(a)codeaurora.org> Date: Tue, 9 Jan 2018 12:30:53 +0530 Subject: usb: f_fs: Prevent gadget unbind if it is already unbound From: Hemant Kumar <hemantk(a)codeaurora.org> commit ce5bf9a50daf2d9078b505aca1cea22e88ecb94a upstream. Upon usb composition switch there is possibility of ep0 file release happening after gadget driver bind. In case of composition switch from adb to a non-adb composition gadget will never gets bound again resulting into failure of usb device enumeration. Fix this issue by checking FFS_FL_BOUND flag and avoid extra gadget driver unbind if it is already done as part of composition switch. This fixes adb reconnection error reported on Android running v4.4 and above kernel versions. Verified on Hikey running vanilla v4.15-rc7 + few out of tree Mali patches. Reviewed-at: https://android-review.googlesource.com/#/c/582632/ Cc: Felipe Balbi <balbi(a)kernel.org> Cc: Greg KH <gregkh(a)linux-foundation.org> Cc: Michal Nazarewicz <mina86(a)mina86.com> Cc: John Stultz <john.stultz(a)linaro.org> Cc: Dmitry Shmidt <dimitrysh(a)google.com> Cc: Badhri <badhri(a)google.com> Cc: Android Kernel Team <kernel-team(a)android.com> Signed-off-by: Hemant Kumar <hemantk(a)codeaurora.org> [AmitP: Cherry-picked it from android-4.14 and updated the commit log] Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/function/f_fs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -3725,7 +3725,8 @@ static void ffs_closed(struct ffs_data * ci = opts->func_inst.group.cg_item.ci_parent->ci_parent; ffs_dev_unlock(); - unregister_gadget_item(ci); + if (test_bit(FFS_FL_BOUND, &ffs->flags)) + unregister_gadget_item(ci); return; done: ffs_dev_unlock(); Patches currently in stable-queue which might be from hemantk(a)codeaurora.org are queue-4.9/usb-f_fs-prevent-gadget-unbind-if-it-is-already-unbound.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: cdc-acm: Do not log urb submission errors on disconnect" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: cdc-acm: Do not log urb submission errors on disconnect to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f0386c083c2ce85284dc0b419d7b89c8e567c09f Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Sun, 14 Jan 2018 16:09:00 +0100 Subject: USB: cdc-acm: Do not log urb submission errors on disconnect From: Hans de Goede <hdegoede(a)redhat.com> commit f0386c083c2ce85284dc0b419d7b89c8e567c09f upstream. When disconnected sometimes the cdc-acm driver logs errors like these: [20278.039417] cdc_acm 2-2:2.1: urb 9 failed submission with -19 [20278.042924] cdc_acm 2-2:2.1: urb 10 failed submission with -19 [20278.046449] cdc_acm 2-2:2.1: urb 11 failed submission with -19 [20278.049920] cdc_acm 2-2:2.1: urb 12 failed submission with -19 [20278.053442] cdc_acm 2-2:2.1: urb 13 failed submission with -19 [20278.056915] cdc_acm 2-2:2.1: urb 14 failed submission with -19 [20278.060418] cdc_acm 2-2:2.1: urb 15 failed submission with -19 Silence these by not logging errors when the result is -ENODEV. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Acked-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/class/cdc-acm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -375,7 +375,7 @@ static int acm_submit_read_urb(struct ac res = usb_submit_urb(acm->read_urbs[index], mem_flags); if (res) { - if (res != -EPERM) { + if (res != -EPERM && res != -ENODEV) { dev_err(&acm->data->dev, "urb %d failed submission with %d\n", index, res); Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.9/usb-uas-unconditionally-bring-back-host-after-reset.patch queue-4.9/acpi-bus-leave-modalias-empty-for-devices-which-are-not-present.patch queue-4.9/usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "tty: fix data race between tty_init_dev and flush of buf" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty: fix data race between tty_init_dev and flush of buf to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tty-fix-data-race-between-tty_init_dev-and-flush-of-buf.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b027e2298bd588d6fa36ed2eda97447fb3eac078 Mon Sep 17 00:00:00 2001 From: Gaurav Kohli <gkohli(a)codeaurora.org> Date: Tue, 23 Jan 2018 13:16:34 +0530 Subject: tty: fix data race between tty_init_dev and flush of buf From: Gaurav Kohli <gkohli(a)codeaurora.org> commit b027e2298bd588d6fa36ed2eda97447fb3eac078 upstream. There can be a race, if receive_buf call comes before tty initialization completes in n_tty_open and tty->disc_data may be NULL. CPU0 CPU1 ---- ---- 000|n_tty_receive_buf_common() n_tty_open() -001|n_tty_receive_buf2() tty_ldisc_open.isra.3() -002|tty_ldisc_receive_buf(inline) tty_ldisc_setup() Using ldisc semaphore lock in tty_init_dev till disc_data initializes completely. Signed-off-by: Gaurav Kohli <gkohli(a)codeaurora.org> Reviewed-by: Alan Cox <alan(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/tty_io.c | 8 +++++++- drivers/tty/tty_ldisc.c | 4 ++-- include/linux/tty.h | 2 ++ 3 files changed, 11 insertions(+), 3 deletions(-) --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -1543,6 +1543,9 @@ struct tty_struct *tty_init_dev(struct t "%s: %s driver does not set tty->port. This will crash the kernel later. Fix the driver!\n", __func__, tty->driver->name); + retval = tty_ldisc_lock(tty, 5 * HZ); + if (retval) + goto err_release_lock; tty->port->itty = tty; /* @@ -1553,6 +1556,7 @@ struct tty_struct *tty_init_dev(struct t retval = tty_ldisc_setup(tty, tty->link); if (retval) goto err_release_tty; + tty_ldisc_unlock(tty); /* Return the tty locked so that it cannot vanish under the caller */ return tty; @@ -1565,9 +1569,11 @@ err_module_put: /* call the tty release_tty routine to clean out this slot */ err_release_tty: - tty_unlock(tty); + tty_ldisc_unlock(tty); tty_info_ratelimited(tty, "ldisc open failed (%d), clearing slot %d\n", retval, idx); +err_release_lock: + tty_unlock(tty); release_tty(tty, idx); return ERR_PTR(retval); } --- a/drivers/tty/tty_ldisc.c +++ b/drivers/tty/tty_ldisc.c @@ -336,7 +336,7 @@ static inline void __tty_ldisc_unlock(st ldsem_up_write(&tty->ldisc_sem); } -static int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout) +int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout) { int ret; @@ -347,7 +347,7 @@ static int tty_ldisc_lock(struct tty_str return 0; } -static void tty_ldisc_unlock(struct tty_struct *tty) +void tty_ldisc_unlock(struct tty_struct *tty) { clear_bit(TTY_LDISC_HALTED, &tty->flags); __tty_ldisc_unlock(tty); --- a/include/linux/tty.h +++ b/include/linux/tty.h @@ -394,6 +394,8 @@ extern struct tty_struct *get_current_tt /* tty_io.c */ extern int __init tty_init(void); extern const char *tty_name(const struct tty_struct *tty); +extern int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout); +extern void tty_ldisc_unlock(struct tty_struct *tty); #else static inline void console_init(void) { } Patches currently in stable-queue which might be from gkohli(a)codeaurora.org are queue-4.9/tty-fix-data-race-between-tty_init_dev-and-flush-of-buf.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: lustre: separate a connection destroy from free struct kib_conn" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: lustre: separate a connection destroy from free struct kib_conn to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-lustre-separate-a-connection-destroy-from-free-struct-kib_conn.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 9b046013e5837f8a58453d1e9f8e01d03adb7fe7 Mon Sep 17 00:00:00 2001 From: Dmitry Eremin <dmitry.eremin(a)intel.com> Date: Thu, 25 Jan 2018 16:51:04 +0300 Subject: staging: lustre: separate a connection destroy from free struct kib_conn From: Dmitry Eremin <dmitry.eremin(a)intel.com> commit 9b046013e5837f8a58453d1e9f8e01d03adb7fe7 upstream. The logic of the original commit 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for ko2iblnd") was assumed conditional free of struct kib_conn if the second argument free_conn in function kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn) is true. But this hunk of code was dropped from original commit. As result the logic works wrong and current code use struct kib_conn after free. > drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c > 3317 kiblnd_destroy_conn(conn, !peer); > ^^^^ Freed always (but should be conditionally) > 3318 > 3319 spin_lock_irqsave(lock, flags); > 3320 if (!peer) > 3321 continue; > 3322 > 3323 conn->ibc_peer = peer; > ^^^^^^^^^^^^^^ Use after free > 3324 if (peer->ibp_reconnected < KIB_RECONN_HIGH_RACE) > 3325 list_add_tail(&conn->ibc_list, > ^^^^^^^^^^^^^^ Use after free > 3326 &kiblnd_data.kib_reconn_list); > 3327 else > 3328 list_add_tail(&conn->ibc_list, > ^^^^^^^^^^^^^^ Use after free > 3329 &kiblnd_data.kib_reconn_wait); To avoid confusion this fix moved the freeing a struct kib_conn outside of the function kiblnd_destroy_conn() and free as it was intended in original commit. Fixes: 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for ko2iblnd") Signed-off-by: Dmitry Eremin <Dmitry.Eremin(a)intel.com> Reviewed-by: Andreas Dilger <andreas.dilger(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 7 +++---- drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h | 2 +- drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 6 ++++-- 3 files changed, 8 insertions(+), 7 deletions(-) --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c @@ -824,14 +824,15 @@ struct kib_conn *kiblnd_create_conn(stru return conn; failed_2: - kiblnd_destroy_conn(conn, true); + kiblnd_destroy_conn(conn); + LIBCFS_FREE(conn, sizeof(*conn)); failed_1: LIBCFS_FREE(init_qp_attr, sizeof(*init_qp_attr)); failed_0: return NULL; } -void kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn) +void kiblnd_destroy_conn(struct kib_conn *conn) { struct rdma_cm_id *cmid = conn->ibc_cmid; struct kib_peer *peer = conn->ibc_peer; @@ -894,8 +895,6 @@ void kiblnd_destroy_conn(struct kib_conn rdma_destroy_id(cmid); atomic_dec(&net->ibn_nconns); } - - LIBCFS_FREE(conn, sizeof(*conn)); } int kiblnd_close_peer_conns_locked(struct kib_peer *peer, int why) --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h @@ -1018,7 +1018,7 @@ int kiblnd_close_peer_conns_locked(stru struct kib_conn *kiblnd_create_conn(struct kib_peer *peer, struct rdma_cm_id *cmid, int state, int version); -void kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn); +void kiblnd_destroy_conn(struct kib_conn *conn); void kiblnd_close_conn(struct kib_conn *conn, int error); void kiblnd_close_conn_locked(struct kib_conn *conn, int error); --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c @@ -3323,11 +3323,13 @@ kiblnd_connd(void *arg) spin_unlock_irqrestore(lock, flags); dropped_lock = 1; - kiblnd_destroy_conn(conn, !peer); + kiblnd_destroy_conn(conn); spin_lock_irqsave(lock, flags); - if (!peer) + if (!peer) { + kfree(conn); continue; + } conn->ibc_peer = peer; if (peer->ibp_reconnected < KIB_RECONN_HIGH_RACE) Patches currently in stable-queue which might be from dmitry.eremin(a)intel.com are queue-4.9/staging-lustre-separate-a-connection-destroy-from-free-struct-kib_conn.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "spi: imx: do not access registers while clocks disabled" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled spi: imx: do not access registers while clocks disabled to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: spi-imx-do-not-access-registers-while-clocks-disabled.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d593574aff0ab846136190b1729c151c736727ec Mon Sep 17 00:00:00 2001 From: Stefan Agner <stefan(a)agner.ch> Date: Sun, 7 Jan 2018 15:05:49 +0100 Subject: spi: imx: do not access registers while clocks disabled From: Stefan Agner <stefan(a)agner.ch> commit d593574aff0ab846136190b1729c151c736727ec upstream. Since clocks are disabled except during message transfer clocks are also disabled when spi_imx_remove gets called. Accessing registers leads to a freeeze at least on a i.MX 6ULL. Enable clocks before disabling accessing the MXC_CSPICTRL register. Fixes: 9e556dcc55774 ("spi: spi-imx: only enable the clocks when we start to transfer a message") Signed-off-by: Stefan Agner <stefan(a)agner.ch> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/spi/spi-imx.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) --- a/drivers/spi/spi-imx.c +++ b/drivers/spi/spi-imx.c @@ -1307,12 +1307,23 @@ static int spi_imx_remove(struct platfor { struct spi_master *master = platform_get_drvdata(pdev); struct spi_imx_data *spi_imx = spi_master_get_devdata(master); + int ret; spi_bitbang_stop(&spi_imx->bitbang); + ret = clk_enable(spi_imx->clk_per); + if (ret) + return ret; + + ret = clk_enable(spi_imx->clk_ipg); + if (ret) { + clk_disable(spi_imx->clk_per); + return ret; + } + writel(0, spi_imx->base + MXC_CSPICTRL); - clk_unprepare(spi_imx->clk_ipg); - clk_unprepare(spi_imx->clk_per); + clk_disable_unprepare(spi_imx->clk_ipg); + clk_disable_unprepare(spi_imx->clk_per); spi_imx_sdma_exit(spi_imx); spi_master_put(master); Patches currently in stable-queue which might be from stefan(a)agner.ch are queue-4.9/spi-imx-do-not-access-registers-while-clocks-disabled.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTS" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTS to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-imx-only-wakeup-via-rtsden-bit-if-the-system-has-rts-cts.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 38b1f0fb42f772b8c9aac53593883a18ff5eb9d7 Mon Sep 17 00:00:00 2001 From: Fabio Estevam <fabio.estevam(a)nxp.com> Date: Thu, 4 Jan 2018 15:58:34 -0200 Subject: serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTS From: Fabio Estevam <fabio.estevam(a)nxp.com> commit 38b1f0fb42f772b8c9aac53593883a18ff5eb9d7 upstream. The wakeup mechanism via RTSDEN bit relies on the system using the RTS/CTS lines, so only allow such wakeup method when the system actually has RTS/CTS support. Fixes: bc85734b126f ("serial: imx: allow waking up on RTSD") Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com> Reviewed-by: Martin Kaiser <martin(a)kaiser.cx> Acked-by: Fugang Duan <fugang.duan(a)nxp.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/imx.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -2239,12 +2239,14 @@ static void serial_imx_enable_wakeup(str val &= ~UCR3_AWAKEN; writel(val, sport->port.membase + UCR3); - val = readl(sport->port.membase + UCR1); - if (on) - val |= UCR1_RTSDEN; - else - val &= ~UCR1_RTSDEN; - writel(val, sport->port.membase + UCR1); + if (sport->have_rtscts) { + val = readl(sport->port.membase + UCR1); + if (on) + val |= UCR1_RTSDEN; + else + val &= ~UCR1_RTSDEN; + writel(val, sport->port.membase + UCR1); + } } static int imx_serial_port_suspend_noirq(struct device *dev) Patches currently in stable-queue which might be from fabio.estevam(a)nxp.com are queue-4.9/serial-imx-only-wakeup-via-rtsden-bit-if-the-system-has-rts-cts.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "CDC-ACM: apply quirk for card reader" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled CDC-ACM: apply quirk for card reader to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cdc-acm-apply-quirk-for-card-reader.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From df1cc78a52491f71d8170d513d0f6f114faa1bda Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Thu, 18 Jan 2018 12:13:45 +0100 Subject: CDC-ACM: apply quirk for card reader From: Oliver Neukum <oneukum(a)suse.com> commit df1cc78a52491f71d8170d513d0f6f114faa1bda upstream. This devices drops random bytes from messages if you talk to it too fast. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/class/cdc-acm.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -1706,6 +1706,9 @@ static const struct usb_device_id acm_id { USB_DEVICE(0x0ace, 0x1611), /* ZyDAS 56K USB MODEM - new version */ .driver_info = SINGLE_RX_URB, /* firmware bug */ }, + { USB_DEVICE(0x11ca, 0x0201), /* VeriFone Mx870 Gadget Serial */ + .driver_info = SINGLE_RX_URB, + }, { USB_DEVICE(0x22b8, 0x7000), /* Motorola Q Phone */ .driver_info = NO_UNION_NORMAL, /* has no union descriptor */ }, Patches currently in stable-queue which might be from oneukum(a)suse.com are queue-4.9/usb-uas-unconditionally-bring-back-host-after-reset.patch queue-4.9/cdc-acm-apply-quirk-for-card-reader.patch queue-4.9/usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usbip: list: don't list devices attached to vhci_hcd" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usbip: list: don't list devices attached to vhci_hcd to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usbip-list-don-t-list-devices-attached-to-vhci_hcd.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ef824501f50846589f02173d73ce3fe6021a9d2a Mon Sep 17 00:00:00 2001 From: Shuah Khan <shuahkh(a)osg.samsung.com> Date: Wed, 17 Jan 2018 12:08:03 -0700 Subject: usbip: list: don't list devices attached to vhci_hcd From: Shuah Khan <shuahkh(a)osg.samsung.com> commit ef824501f50846589f02173d73ce3fe6021a9d2a upstream. usbip host lists devices attached to vhci_hcd on the same server when user does attach over localhost or specifies the server as the remote. usbip attach -r localhost -b busid or usbip attach -r servername (or server IP) Fix it to check and not list devices that are attached to vhci_hcd. Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/usb/usbip/src/usbip_list.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/tools/usb/usbip/src/usbip_list.c +++ b/tools/usb/usbip/src/usbip_list.c @@ -180,6 +180,7 @@ static int list_devices(bool parsable) const char *busid; char product_name[128]; int ret = -1; + const char *devpath; /* Create libudev context. */ udev = udev_new(); @@ -202,6 +203,14 @@ static int list_devices(bool parsable) path = udev_list_entry_get_name(dev_list_entry); dev = udev_device_new_from_syspath(udev, path); + /* Ignore devices attached to vhci_hcd */ + devpath = udev_device_get_devpath(dev); + if (strstr(devpath, USBIP_VHCI_DRV_NAME)) { + dbg("Skip the device %s already attached to %s\n", + devpath, USBIP_VHCI_DRV_NAME); + continue; + } + /* Get device information. */ idVendor = udev_device_get_sysattr_value(dev, "idVendor"); idProduct = udev_device_get_sysattr_value(dev, "idProduct"); Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are queue-4.4/usbip-list-don-t-list-devices-attached-to-vhci_hcd.patch queue-4.4/usbip-prevent-bind-loops-on-devices-attached-to-vhci_hcd.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usbip: prevent bind loops on devices attached to vhci_hcd" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usbip: prevent bind loops on devices attached to vhci_hcd to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usbip-prevent-bind-loops-on-devices-attached-to-vhci_hcd.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ef54cf0c600fb8f5737fb001a9e357edda1a1de8 Mon Sep 17 00:00:00 2001 From: Shuah Khan <shuahkh(a)osg.samsung.com> Date: Wed, 17 Jan 2018 12:07:30 -0700 Subject: usbip: prevent bind loops on devices attached to vhci_hcd From: Shuah Khan <shuahkh(a)osg.samsung.com> commit ef54cf0c600fb8f5737fb001a9e357edda1a1de8 upstream. usbip host binds to devices attached to vhci_hcd on the same server when user does attach over localhost or specifies the server as the remote. usbip attach -r localhost -b busid or usbip attach -r servername (or server IP) Unbind followed by bind works, however device is left in a bad state with accesses via the attached busid result in errors and system hangs during shutdown. Fix it to check and bail out if the device is already attached to vhci_hcd. Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/usb/usbip/src/usbip_bind.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/tools/usb/usbip/src/usbip_bind.c +++ b/tools/usb/usbip/src/usbip_bind.c @@ -144,6 +144,7 @@ static int bind_device(char *busid) int rc; struct udev *udev; struct udev_device *dev; + const char *devpath; /* Check whether the device with this bus ID exists. */ udev = udev_new(); @@ -152,8 +153,16 @@ static int bind_device(char *busid) err("device with the specified bus ID does not exist"); return -1; } + devpath = udev_device_get_devpath(dev); udev_unref(udev); + /* If the device is already attached to vhci_hcd - bail out */ + if (strstr(devpath, USBIP_VHCI_DRV_NAME)) { + err("bind loop detected: device: %s is attached to %s\n", + devpath, USBIP_VHCI_DRV_NAME); + return -1; + } + rc = unbind_other(busid); if (rc == UNBIND_ST_FAILED) { err("could not unbind driver from device on busid %s", busid); Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are queue-4.4/usbip-list-don-t-list-devices-attached-to-vhci_hcd.patch queue-4.4/usbip-prevent-bind-loops-on-devices-attached-to-vhci_hcd.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: uas: unconditionally bring back host after reset" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: uas: unconditionally bring back host after reset to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-uas-unconditionally-bring-back-host-after-reset.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From cbeef22fd611c4f47c494b821b2b105b8af970bb Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Thu, 11 Jan 2018 13:10:16 +0100 Subject: usb: uas: unconditionally bring back host after reset From: Oliver Neukum <oneukum(a)suse.com> commit cbeef22fd611c4f47c494b821b2b105b8af970bb upstream. Quoting Hans: If we return 1 from our post_reset handler, then our disconnect handler will be called immediately afterwards. Since pre_reset blocks all scsi requests our disconnect handler will then hang in the scsi_remove_host call. This is esp. bad because our disconnect handler hanging for ever also stops the USB subsys from enumerating any new USB devices, causes commands like lsusb to hang, etc. In practice this happens when unplugging some uas devices because the hub code may see the device as needing a warm-reset and calls usb_reset_device before seeing the disconnect. In this case uas_configure_endpoints fails with -ENODEV. We do not want to print an error for this, so this commit also silences the shost_printk for -ENODEV. ENDQUOTE However, if we do that we better drop any unconditional execution and report to the SCSI subsystem that we have undergone a reset but we are not operational now. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Reported-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/storage/uas.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- a/drivers/usb/storage/uas.c +++ b/drivers/usb/storage/uas.c @@ -1052,20 +1052,19 @@ static int uas_post_reset(struct usb_int return 0; err = uas_configure_endpoints(devinfo); - if (err) { + if (err && err != ENODEV) shost_printk(KERN_ERR, shost, "%s: alloc streams error %d after reset", __func__, err); - return 1; - } + /* we must unblock the host in every case lest we deadlock */ spin_lock_irqsave(shost->host_lock, flags); scsi_report_bus_reset(shost, 0); spin_unlock_irqrestore(shost->host_lock, flags); scsi_unblock_requests(shost); - return 0; + return err ? 1 : 0; } static int uas_suspend(struct usb_interface *intf, pm_message_t message) Patches currently in stable-queue which might be from oneukum(a)suse.com are queue-4.4/usb-uas-unconditionally-bring-back-host-after-reset.patch queue-4.4/cdc-acm-apply-quirk-for-card-reader.patch queue-4.4/usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: pl2303: new device id for Chilitag" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: pl2303: new device id for Chilitag to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-serial-pl2303-new-device-id-for-chilitag.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d08dd3f3dd2ae351b793fc5b76abdbf0fd317b12 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Date: Thu, 25 Jan 2018 09:48:55 +0100 Subject: USB: serial: pl2303: new device id for Chilitag MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> commit d08dd3f3dd2ae351b793fc5b76abdbf0fd317b12 upstream. This adds a new device id for Chilitag devices to the pl2303 driver. Reported-by: "Chu.Mike [朱堅宜]" <Mike-Chu(a)prolific.com.tw> Acked-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/pl2303.c | 1 + drivers/usb/serial/pl2303.h | 1 + 2 files changed, 2 insertions(+) --- a/drivers/usb/serial/pl2303.c +++ b/drivers/usb/serial/pl2303.c @@ -39,6 +39,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ2) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_DCU11) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ3) }, + { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_CHILITAG) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_PHAROS) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_ALDIGA) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_MMX) }, --- a/drivers/usb/serial/pl2303.h +++ b/drivers/usb/serial/pl2303.h @@ -17,6 +17,7 @@ #define PL2303_PRODUCT_ID_DCU11 0x1234 #define PL2303_PRODUCT_ID_PHAROS 0xaaa0 #define PL2303_PRODUCT_ID_RSAQ3 0xaaa2 +#define PL2303_PRODUCT_ID_CHILITAG 0xaaa8 #define PL2303_PRODUCT_ID_ALDIGA 0x0611 #define PL2303_PRODUCT_ID_MMX 0x0612 #define PL2303_PRODUCT_ID_GPRS 0x0609 Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are queue-4.4/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.4/lockd-fix-list_add-double-add-caused-by-legacy-signal-interface.patch queue-4.4/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.4/nfsd-ensure-we-check-stateid-validity-in-the-seqid-operation-checks.patch queue-4.4/sunrpc-allow-connect-to-return-ehostunreach.patch queue-4.4/bpf-fix-branch-pruning-logic.patch queue-4.4/nfsd-check-for-use-of-the-closed-special-stateid.patch queue-4.4/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch queue-4.4/bcache-check-return-value-of-register_shrinker.patch queue-4.4/nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch queue-4.4/crypto-af_alg-whitelist-mask-and-type.patch queue-4.4/quota-check-for-register_shrinker-failure.patch queue-4.4/mac80211-fix-the-update-of-path-metric-for-rann-frame.patch queue-4.4/xen-netfront-remove-warning-when-unloading-module.patch queue-4.4/kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch queue-4.4/crypto-aesni-handle-zero-length-dst-buffer.patch queue-4.4/kmemleak-add-scheduling-point-to-kmemleak_scan.patch queue-4.4/net-ethernet-xilinx-mark-xilinx_ll_temac-broken-on-64-bit.patch queue-4.4/drm-amdkfd-fix-sdma-oversubsription-handling.patch queue-4.4/grace-replace-bug_on-by-warn_once-in-exit_net-hook.patch queue-4.4/xfs-ubsan-fixes.patch queue-4.4/gpio-iop-add-missing-module_description-author-license.patch queue-4.4/bpf-avoid-false-sharing-of-map-refcount-with-max_entries.patch queue-4.4/usbip-list-don-t-list-devices-attached-to-vhci_hcd.patch queue-4.4/scsi-ufs-ufshcd-fix-potential-null-pointer-dereference-in-ufshcd_config_vreg.patch queue-4.4/kvm-x86-fix-operand-address-size-during-instruction-decoding.patch queue-4.4/usb-uas-unconditionally-bring-back-host-after-reset.patch queue-4.4/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.4/usbip-prevent-bind-loops-on-devices-attached-to-vhci_hcd.patch queue-4.4/btrfs-fix-deadlock-when-writing-out-space-cache.patch queue-4.4/drm-amdkfd-fix-sdma-ring-buffer-size-calculation.patch queue-4.4/scsi-aacraid-prevent-crash-in-case-of-free-interrupt-during-scsi-eh-path.patch queue-4.4/x86-bpf_jit-small-optimization-in-emit_bpf_tail_call.patch queue-4.4/spi-imx-do-not-access-registers-while-clocks-disabled.patch queue-4.4/cdc-acm-apply-quirk-for-card-reader.patch queue-4.4/staging-rtl8188eu-fix-incorrect-response-to-siocgiwessid.patch queue-4.4/serial-imx-only-wakeup-via-rtsden-bit-if-the-system-has-rts-cts.patch queue-4.4/bpf-reject-stores-into-ctx-via-st-and-xadd.patch queue-4.4/drm-amdgpu-fix-sdma-load-unload-sequence-on-hws-disabled-mode.patch queue-4.4/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch queue-4.4/bpf-fix-32-bit-divide-by-zero.patch queue-4.4/cpufreq-add-loongson-machine-dependencies.patch queue-4.4/power-reset-zx-reboot-add-missing-module_description-author-license.patch queue-4.4/igb-free-irqs-when-device-is-hotplugged.patch queue-4.4/acpi-bus-leave-modalias-empty-for-devices-which-are-not-present.patch queue-4.4/bpf-fix-bpf_tail_call-x64-jit.patch queue-4.4/x86-pti-make-unpoison-of-pgd-for-trusted-boot-work-for-real.patch queue-4.4/bpf-arsh-is-not-supported-in-32-bit-alu-thus-reject-it.patch queue-4.4/kaiser-fix-intel_bts-perf-crashes.patch queue-4.4/usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch queue-4.4/bpf-fix-divides-by-zero.patch queue-4.4/gpio-ath79-add-missing-module_description-license.patch queue-4.4/drm-omap-fix-error-handling-path-in-omap_dmm_probe.patch queue-4.4/loop-fix-concurrent-lo_open-lo_release.patch queue-4.4/media-usbtv-add-a-new-usbid.patch queue-4.4/usb-serial-pl2303-new-device-id-for-chilitag.patch queue-4.4/usb-serial-simple-add-motorola-tetra-driver.patch queue-4.4/usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch queue-4.4/usb-serial-io_edgeport-fix-possible-sleep-in-atomic.patch queue-4.4/usb-option-add-support-for-fs040u-modem.patch queue-4.4/usb-f_fs-prevent-gadget-unbind-if-it-is-already-unbound.patch queue-4.4/alsa-seq-make-ioctls-race-free.patch queue-4.4/hwmon-pmbus-use-64bit-math-for-direct-format-values.patch queue-4.4/selinux-general-protection-fault-in-sock_has_perm.patch queue-4.4/openvswitch-fix-the-incorrect-flow-action-alloc-size.patch queue-4.4/mtd-nand-denali_pci-add-missing-module_description-author-license.patch queue-4.4/bpf-introduce-bpf_jit_always_on-config.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: simple: add Motorola Tetra driver" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: simple: add Motorola Tetra driver to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-serial-simple-add-motorola-tetra-driver.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 46fe895e22ab3845515ec06b01eaf1282b342e29 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Thu, 18 Jan 2018 14:46:41 +1100 Subject: USB: serial: simple: add Motorola Tetra driver From: Johan Hovold <johan(a)kernel.org> commit 46fe895e22ab3845515ec06b01eaf1282b342e29 upstream. Add new Motorola Tetra (simple) driver for Motorola Solutions TETRA PEI devices. D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0cad ProdID=9011 Rev=24.16 S: Manufacturer=Motorola Solutions Inc. S: Product=Motorola Solutions TETRA PEI interface C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) Note that these devices do not support the CDC SET_CONTROL_LINE_STATE request (for any interface). Reported-by: Max Schulze <max.schulze(a)posteo.de> Tested-by: Max Schulze <max.schulze(a)posteo.de> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/Kconfig | 1 + drivers/usb/serial/usb-serial-simple.c | 7 +++++++ 2 files changed, 8 insertions(+) --- a/drivers/usb/serial/Kconfig +++ b/drivers/usb/serial/Kconfig @@ -63,6 +63,7 @@ config USB_SERIAL_SIMPLE - Google USB serial devices - HP4x calculators - a number of Motorola phones + - Motorola Tetra devices - Novatel Wireless GPS receivers - Siemens USB/MPI adapter. - ViVOtech ViVOpay USB device. --- a/drivers/usb/serial/usb-serial-simple.c +++ b/drivers/usb/serial/usb-serial-simple.c @@ -80,6 +80,11 @@ DEVICE(vivopay, VIVOPAY_IDS); { USB_DEVICE(0x22b8, 0x2c64) } /* Motorola V950 phone */ DEVICE(moto_modem, MOTO_IDS); +/* Motorola Tetra driver */ +#define MOTOROLA_TETRA_IDS() \ + { USB_DEVICE(0x0cad, 0x9011) } /* Motorola Solutions TETRA PEI */ +DEVICE(motorola_tetra, MOTOROLA_TETRA_IDS); + /* Novatel Wireless GPS driver */ #define NOVATEL_IDS() \ { USB_DEVICE(0x09d7, 0x0100) } /* NovAtel FlexPack GPS */ @@ -110,6 +115,7 @@ static struct usb_serial_driver * const &google_device, &vivopay_device, &moto_modem_device, + &motorola_tetra_device, &novatel_gps_device, &hp4x_device, &suunto_device, @@ -125,6 +131,7 @@ static const struct usb_device_id id_tab GOOGLE_IDS(), VIVOPAY_IDS(), MOTO_IDS(), + MOTOROLA_TETRA_IDS(), NOVATEL_IDS(), HP4X_IDS(), SUUNTO_IDS(), Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.4/usb-serial-pl2303-new-device-id-for-chilitag.patch queue-4.4/usb-serial-simple-add-motorola-tetra-driver.patch queue-4.4/usb-serial-io_edgeport-fix-possible-sleep-in-atomic.patch queue-4.4/usb-option-add-support-for-fs040u-modem.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: option: Add support for FS040U modem" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: option: Add support for FS040U modem to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-option-add-support-for-fs040u-modem.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 69341bd15018da0a662847e210f9b2380c71e623 Mon Sep 17 00:00:00 2001 From: OKAMOTO Yoshiaki <yokamoto(a)allied-telesis.co.jp> Date: Tue, 16 Jan 2018 09:51:17 +0000 Subject: usb: option: Add support for FS040U modem From: OKAMOTO Yoshiaki <yokamoto(a)allied-telesis.co.jp> commit 69341bd15018da0a662847e210f9b2380c71e623 upstream. FS040U modem is manufactured by omega, and sold by Fujisoft. This patch adds ID of the modem to use option1 driver. Interface 3 is used as qmi_wwan, so the interface is ignored. Signed-off-by: Yoshiaki Okamoto <yokamoto(a)allied-telesis.co.jp> Signed-off-by: Hiroyuki Yamamoto <hyamamo(a)allied-telesis.co.jp> Acked-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/option.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -383,6 +383,9 @@ static void option_instat_callback(struc #define FOUR_G_SYSTEMS_PRODUCT_W14 0x9603 #define FOUR_G_SYSTEMS_PRODUCT_W100 0x9b01 +/* Fujisoft products */ +#define FUJISOFT_PRODUCT_FS040U 0x9b02 + /* iBall 3.5G connect wireless modem */ #define IBALL_3_5G_CONNECT 0x9605 @@ -1897,6 +1900,8 @@ static const struct usb_device_id option { USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W100), .driver_info = (kernel_ulong_t)&four_g_w100_blacklist }, + {USB_DEVICE(LONGCHEER_VENDOR_ID, FUJISOFT_PRODUCT_FS040U), + .driver_info = (kernel_ulong_t)&net_intf3_blacklist}, { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, SPEEDUP_PRODUCT_SU9800, 0xff) }, { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 0x9801, 0xff), .driver_info = (kernel_ulong_t)&net_intf3_blacklist }, Patches currently in stable-queue which might be from yokamoto(a)allied-telesis.co.jp are queue-4.4/usb-option-add-support-for-fs040u-modem.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: f_fs: Prevent gadget unbind if it is already unbound" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: f_fs: Prevent gadget unbind if it is already unbound to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-f_fs-prevent-gadget-unbind-if-it-is-already-unbound.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ce5bf9a50daf2d9078b505aca1cea22e88ecb94a Mon Sep 17 00:00:00 2001 From: Hemant Kumar <hemantk(a)codeaurora.org> Date: Tue, 9 Jan 2018 12:30:53 +0530 Subject: usb: f_fs: Prevent gadget unbind if it is already unbound From: Hemant Kumar <hemantk(a)codeaurora.org> commit ce5bf9a50daf2d9078b505aca1cea22e88ecb94a upstream. Upon usb composition switch there is possibility of ep0 file release happening after gadget driver bind. In case of composition switch from adb to a non-adb composition gadget will never gets bound again resulting into failure of usb device enumeration. Fix this issue by checking FFS_FL_BOUND flag and avoid extra gadget driver unbind if it is already done as part of composition switch. This fixes adb reconnection error reported on Android running v4.4 and above kernel versions. Verified on Hikey running vanilla v4.15-rc7 + few out of tree Mali patches. Reviewed-at: https://android-review.googlesource.com/#/c/582632/ Cc: Felipe Balbi <balbi(a)kernel.org> Cc: Greg KH <gregkh(a)linux-foundation.org> Cc: Michal Nazarewicz <mina86(a)mina86.com> Cc: John Stultz <john.stultz(a)linaro.org> Cc: Dmitry Shmidt <dimitrysh(a)google.com> Cc: Badhri <badhri(a)google.com> Cc: Android Kernel Team <kernel-team(a)android.com> Signed-off-by: Hemant Kumar <hemantk(a)codeaurora.org> [AmitP: Cherry-picked it from android-4.14 and updated the commit log] Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/function/f_fs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -3490,7 +3490,8 @@ static void ffs_closed(struct ffs_data * ci = opts->func_inst.group.cg_item.ci_parent->ci_parent; ffs_dev_unlock(); - unregister_gadget_item(ci); + if (test_bit(FFS_FL_BOUND, &ffs->flags)) + unregister_gadget_item(ci); return; done: ffs_dev_unlock(); Patches currently in stable-queue which might be from hemantk(a)codeaurora.org are queue-4.4/usb-f_fs-prevent-gadget-unbind-if-it-is-already-unbound.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: io_edgeport: fix possible sleep-in-atomic" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: io_edgeport: fix possible sleep-in-atomic to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-serial-io_edgeport-fix-possible-sleep-in-atomic.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c7b8f77872c73f69a16528a9eb87afefcccdc18b Mon Sep 17 00:00:00 2001 From: Jia-Ju Bai <baijiaju1990(a)gmail.com> Date: Wed, 13 Dec 2017 20:34:36 +0800 Subject: USB: serial: io_edgeport: fix possible sleep-in-atomic From: Jia-Ju Bai <baijiaju1990(a)gmail.com> commit c7b8f77872c73f69a16528a9eb87afefcccdc18b upstream. According to drivers/usb/serial/io_edgeport.c, the driver may sleep under a spinlock. The function call path is: edge_bulk_in_callback (acquire the spinlock) process_rcvd_data process_rcvd_status change_port_settings send_iosp_ext_cmd write_cmd_usb usb_kill_urb --> may sleep To fix it, the redundant usb_kill_urb() is removed from the error path after usb_submit_urb() fails. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai <baijiaju1990(a)gmail.com> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/io_edgeport.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/usb/serial/io_edgeport.c +++ b/drivers/usb/serial/io_edgeport.c @@ -2219,7 +2219,6 @@ static int write_cmd_usb(struct edgeport /* something went wrong */ dev_err(dev, "%s - usb_submit_urb(write command) failed, status = %d\n", __func__, status); - usb_kill_urb(urb); usb_free_urb(urb); atomic_dec(&CmdUrbs); return status; Patches currently in stable-queue which might be from baijiaju1990(a)gmail.com are queue-4.4/usb-serial-io_edgeport-fix-possible-sleep-in-atomic.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: cdc-acm: Do not log urb submission errors on disconnect" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: cdc-acm: Do not log urb submission errors on disconnect to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f0386c083c2ce85284dc0b419d7b89c8e567c09f Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Sun, 14 Jan 2018 16:09:00 +0100 Subject: USB: cdc-acm: Do not log urb submission errors on disconnect From: Hans de Goede <hdegoede(a)redhat.com> commit f0386c083c2ce85284dc0b419d7b89c8e567c09f upstream. When disconnected sometimes the cdc-acm driver logs errors like these: [20278.039417] cdc_acm 2-2:2.1: urb 9 failed submission with -19 [20278.042924] cdc_acm 2-2:2.1: urb 10 failed submission with -19 [20278.046449] cdc_acm 2-2:2.1: urb 11 failed submission with -19 [20278.049920] cdc_acm 2-2:2.1: urb 12 failed submission with -19 [20278.053442] cdc_acm 2-2:2.1: urb 13 failed submission with -19 [20278.056915] cdc_acm 2-2:2.1: urb 14 failed submission with -19 [20278.060418] cdc_acm 2-2:2.1: urb 15 failed submission with -19 Silence these by not logging errors when the result is -ENODEV. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Acked-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/class/cdc-acm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -377,7 +377,7 @@ static int acm_submit_read_urb(struct ac res = usb_submit_urb(acm->read_urbs[index], mem_flags); if (res) { - if (res != -EPERM) { + if (res != -EPERM && res != -ENODEV) { dev_err(&acm->data->dev, "%s - usb_submit_urb failed: %d\n", __func__, res); Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.4/usb-uas-unconditionally-bring-back-host-after-reset.patch queue-4.4/acpi-bus-leave-modalias-empty-for-devices-which-are-not-present.patch queue-4.4/usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "spi: imx: do not access registers while clocks disabled" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled spi: imx: do not access registers while clocks disabled to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: spi-imx-do-not-access-registers-while-clocks-disabled.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d593574aff0ab846136190b1729c151c736727ec Mon Sep 17 00:00:00 2001 From: Stefan Agner <stefan(a)agner.ch> Date: Sun, 7 Jan 2018 15:05:49 +0100 Subject: spi: imx: do not access registers while clocks disabled From: Stefan Agner <stefan(a)agner.ch> commit d593574aff0ab846136190b1729c151c736727ec upstream. Since clocks are disabled except during message transfer clocks are also disabled when spi_imx_remove gets called. Accessing registers leads to a freeeze at least on a i.MX 6ULL. Enable clocks before disabling accessing the MXC_CSPICTRL register. Fixes: 9e556dcc55774 ("spi: spi-imx: only enable the clocks when we start to transfer a message") Signed-off-by: Stefan Agner <stefan(a)agner.ch> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/spi/spi-imx.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) --- a/drivers/spi/spi-imx.c +++ b/drivers/spi/spi-imx.c @@ -1228,12 +1228,23 @@ static int spi_imx_remove(struct platfor { struct spi_master *master = platform_get_drvdata(pdev); struct spi_imx_data *spi_imx = spi_master_get_devdata(master); + int ret; spi_bitbang_stop(&spi_imx->bitbang); + ret = clk_enable(spi_imx->clk_per); + if (ret) + return ret; + + ret = clk_enable(spi_imx->clk_ipg); + if (ret) { + clk_disable(spi_imx->clk_per); + return ret; + } + writel(0, spi_imx->base + MXC_CSPICTRL); - clk_unprepare(spi_imx->clk_ipg); - clk_unprepare(spi_imx->clk_per); + clk_disable_unprepare(spi_imx->clk_ipg); + clk_disable_unprepare(spi_imx->clk_per); spi_imx_sdma_exit(spi_imx); spi_master_put(master); Patches currently in stable-queue which might be from stefan(a)agner.ch are queue-4.4/spi-imx-do-not-access-registers-while-clocks-disabled.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTS" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTS to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-imx-only-wakeup-via-rtsden-bit-if-the-system-has-rts-cts.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 38b1f0fb42f772b8c9aac53593883a18ff5eb9d7 Mon Sep 17 00:00:00 2001 From: Fabio Estevam <fabio.estevam(a)nxp.com> Date: Thu, 4 Jan 2018 15:58:34 -0200 Subject: serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTS From: Fabio Estevam <fabio.estevam(a)nxp.com> commit 38b1f0fb42f772b8c9aac53593883a18ff5eb9d7 upstream. The wakeup mechanism via RTSDEN bit relies on the system using the RTS/CTS lines, so only allow such wakeup method when the system actually has RTS/CTS support. Fixes: bc85734b126f ("serial: imx: allow waking up on RTSD") Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com> Reviewed-by: Martin Kaiser <martin(a)kaiser.cx> Acked-by: Fugang Duan <fugang.duan(a)nxp.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/imx.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -2057,12 +2057,14 @@ static void serial_imx_enable_wakeup(str val &= ~UCR3_AWAKEN; writel(val, sport->port.membase + UCR3); - val = readl(sport->port.membase + UCR1); - if (on) - val |= UCR1_RTSDEN; - else - val &= ~UCR1_RTSDEN; - writel(val, sport->port.membase + UCR1); + if (sport->have_rtscts) { + val = readl(sport->port.membase + UCR1); + if (on) + val |= UCR1_RTSDEN; + else + val &= ~UCR1_RTSDEN; + writel(val, sport->port.membase + UCR1); + } } static int imx_serial_port_suspend_noirq(struct device *dev) Patches currently in stable-queue which might be from fabio.estevam(a)nxp.com are queue-4.4/serial-imx-only-wakeup-via-rtsden-bit-if-the-system-has-rts-cts.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] [PATCH v2] general protection fault in sock_has_perm

by Mark Salyzyn

In the absence of commit a4298e4522d6 ("net: add SOCK_RCU_FREE socket flag") and all the associated infrastructure changes to take advantage of a RCU grace period before freeing, there is a heightened possibility that a security check is performed while an ill-timed setsockopt call races in from user space. It then is prudent to null check sk_security, and if the case, reject the permissions. Because of the nature of this problem, hard to duplicate, no clear path, this patch is a simplified band-aid for stable trees lacking the infrastructure for the series of commits leading up to providing a suitable RCU grace period. This adjustment is orthogonal to infrastructure improvements that may nullify the needed check, but could be added as good code hygiene in all trees. general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 14233 Comm: syz-executor2 Not tainted 4.4.112-g5f6325b #28 task: ffff8801d1095f00 task.stack: ffff8800b5950000 RIP: 0010:[<ffffffff81b69b7e>] [<ffffffff81b69b7e>] sock_has_perm+0x1fe/0x3e0 security/selinux/hooks.c:4069 RSP: 0018:ffff8800b5957ce0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 1ffff10016b2af9f RCX: ffffffff81b69b51 RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000010 RBP: ffff8800b5957de0 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 1ffff10016b2af68 R12: ffff8800b5957db8 R13: 0000000000000000 R14: ffff8800b7259f40 R15: 00000000000000d7 FS: 00007f72f5ae2700(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000a2fa38 CR3: 00000001d7980000 CR4: 0000000000160670 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: ffffffff81b69a1f ffff8800b5957d58 00008000b5957d30 0000000041b58ab3 ffffffff83fc82f2 ffffffff81b69980 0000000000000246 ffff8801d1096770 ffff8801d3165668 ffffffff8157844b ffff8801d1095f00 ffff880000000001 Call Trace: [<ffffffff81b6a19d>] selinux_socket_setsockopt+0x4d/0x80 security/selinux/hooks.c:4338 [<ffffffff81b4873d>] security_socket_setsockopt+0x7d/0xb0 security/security.c:1257 [<ffffffff82df1ac8>] SYSC_setsockopt net/socket.c:1757 [inline] [<ffffffff82df1ac8>] SyS_setsockopt+0xe8/0x250 net/socket.c:1746 [<ffffffff83776499>] entry_SYSCALL_64_fastpath+0x16/0x92 Code: c2 42 9b b6 81 be 01 00 00 00 48 c7 c7 a0 cb 2b 84 e8 f7 2f 6d ff 49 8d 7d 10 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 83 01 00 00 41 8b 75 10 31 RIP [<ffffffff81b69b7e>] sock_has_perm+0x1fe/0x3e0 security/selinux/hooks.c:4069 RSP <ffff8800b5957ce0> ---[ end trace 7b5aaf788fef6174 ]--- Signed-off-by: Mark Salyzyn <salyzyn(a)android.com> Signed-off-by: Paul Moore <paul(a)linuxfoundation.org> Signed-off-by: Greg KH <gregkh(a)linuxfoundation.org> Cc: Eric Dumazet <edumazet(a)google.com> Cc: Stephen Smalley <sds(a)tycho.nsa.gov> Cc: selinux(a)tycho.nsa.gov Cc: linux-security-module(a)vger.kernel.org Cc: Eric Paris <eparis(a)parisplace.org> Cc: Serge E. Hallyn <serge(a)hallyn.com> Cc: stable <stable(a)vger.kernel.org> # 3.18, 4.4 Cc: linux-kernel(a)vger.kernel.org --- v2: return -EFAULT for null sk_security instead of 0 security/selinux/hooks.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 8644d864e3c1..795efa71d656 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -4342,6 +4342,8 @@ static int sock_has_perm(struct sock *sk, u32 perms) struct common_audit_data ad; struct lsm_network_audit net = {0,}; + if (!sksec) + return -EFAULT; if (sksec->sid == SECINITSID_KERNEL) return 0; -- 2.16.0.rc1.238.g530d649a79-goog

7 years, 4 months

5
9
0 0

[Linux-stable-mirror] Patch "CDC-ACM: apply quirk for card reader" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled CDC-ACM: apply quirk for card reader to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cdc-acm-apply-quirk-for-card-reader.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From df1cc78a52491f71d8170d513d0f6f114faa1bda Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Thu, 18 Jan 2018 12:13:45 +0100 Subject: CDC-ACM: apply quirk for card reader From: Oliver Neukum <oneukum(a)suse.com> commit df1cc78a52491f71d8170d513d0f6f114faa1bda upstream. This devices drops random bytes from messages if you talk to it too fast. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/class/cdc-acm.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -1695,6 +1695,9 @@ static const struct usb_device_id acm_id { USB_DEVICE(0x0ace, 0x1611), /* ZyDAS 56K USB MODEM - new version */ .driver_info = SINGLE_RX_URB, /* firmware bug */ }, + { USB_DEVICE(0x11ca, 0x0201), /* VeriFone Mx870 Gadget Serial */ + .driver_info = SINGLE_RX_URB, + }, { USB_DEVICE(0x22b8, 0x7000), /* Motorola Q Phone */ .driver_info = NO_UNION_NORMAL, /* has no union descriptor */ }, Patches currently in stable-queue which might be from oneukum(a)suse.com are queue-4.4/usb-uas-unconditionally-bring-back-host-after-reset.patch queue-4.4/cdc-acm-apply-quirk-for-card-reader.patch queue-4.4/usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usbip: prevent bind loops on devices attached to vhci_hcd" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usbip: prevent bind loops on devices attached to vhci_hcd to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usbip-prevent-bind-loops-on-devices-attached-to-vhci_hcd.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ef54cf0c600fb8f5737fb001a9e357edda1a1de8 Mon Sep 17 00:00:00 2001 From: Shuah Khan <shuahkh(a)osg.samsung.com> Date: Wed, 17 Jan 2018 12:07:30 -0700 Subject: usbip: prevent bind loops on devices attached to vhci_hcd From: Shuah Khan <shuahkh(a)osg.samsung.com> commit ef54cf0c600fb8f5737fb001a9e357edda1a1de8 upstream. usbip host binds to devices attached to vhci_hcd on the same server when user does attach over localhost or specifies the server as the remote. usbip attach -r localhost -b busid or usbip attach -r servername (or server IP) Unbind followed by bind works, however device is left in a bad state with accesses via the attached busid result in errors and system hangs during shutdown. Fix it to check and bail out if the device is already attached to vhci_hcd. Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/usb/usbip/src/usbip_bind.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/tools/usb/usbip/src/usbip_bind.c +++ b/tools/usb/usbip/src/usbip_bind.c @@ -144,6 +144,7 @@ static int bind_device(char *busid) int rc; struct udev *udev; struct udev_device *dev; + const char *devpath; /* Check whether the device with this bus ID exists. */ udev = udev_new(); @@ -152,8 +153,16 @@ static int bind_device(char *busid) err("device with the specified bus ID does not exist"); return -1; } + devpath = udev_device_get_devpath(dev); udev_unref(udev); + /* If the device is already attached to vhci_hcd - bail out */ + if (strstr(devpath, USBIP_VHCI_DRV_NAME)) { + err("bind loop detected: device: %s is attached to %s\n", + devpath, USBIP_VHCI_DRV_NAME); + return -1; + } + rc = unbind_other(busid); if (rc == UNBIND_ST_FAILED) { err("could not unbind driver from device on busid %s", busid); Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are queue-3.18/usbip-list-don-t-list-devices-attached-to-vhci_hcd.patch queue-3.18/usbip-prevent-bind-loops-on-devices-attached-to-vhci_hcd.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usbip: list: don't list devices attached to vhci_hcd" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usbip: list: don't list devices attached to vhci_hcd to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usbip-list-don-t-list-devices-attached-to-vhci_hcd.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ef824501f50846589f02173d73ce3fe6021a9d2a Mon Sep 17 00:00:00 2001 From: Shuah Khan <shuahkh(a)osg.samsung.com> Date: Wed, 17 Jan 2018 12:08:03 -0700 Subject: usbip: list: don't list devices attached to vhci_hcd From: Shuah Khan <shuahkh(a)osg.samsung.com> commit ef824501f50846589f02173d73ce3fe6021a9d2a upstream. usbip host lists devices attached to vhci_hcd on the same server when user does attach over localhost or specifies the server as the remote. usbip attach -r localhost -b busid or usbip attach -r servername (or server IP) Fix it to check and not list devices that are attached to vhci_hcd. Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/usb/usbip/src/usbip_list.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/tools/usb/usbip/src/usbip_list.c +++ b/tools/usb/usbip/src/usbip_list.c @@ -180,6 +180,7 @@ static int list_devices(bool parsable) const char *busid; char product_name[128]; int ret = -1; + const char *devpath; /* Create libudev context. */ udev = udev_new(); @@ -202,6 +203,14 @@ static int list_devices(bool parsable) path = udev_list_entry_get_name(dev_list_entry); dev = udev_device_new_from_syspath(udev, path); + /* Ignore devices attached to vhci_hcd */ + devpath = udev_device_get_devpath(dev); + if (strstr(devpath, USBIP_VHCI_DRV_NAME)) { + dbg("Skip the device %s already attached to %s\n", + devpath, USBIP_VHCI_DRV_NAME); + continue; + } + /* Get device information. */ idVendor = udev_device_get_sysattr_value(dev, "idVendor"); idProduct = udev_device_get_sysattr_value(dev, "idProduct"); Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are queue-3.18/usbip-list-don-t-list-devices-attached-to-vhci_hcd.patch queue-3.18/usbip-prevent-bind-loops-on-devices-attached-to-vhci_hcd.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: uas: unconditionally bring back host after reset" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: uas: unconditionally bring back host after reset to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-uas-unconditionally-bring-back-host-after-reset.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From cbeef22fd611c4f47c494b821b2b105b8af970bb Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Thu, 11 Jan 2018 13:10:16 +0100 Subject: usb: uas: unconditionally bring back host after reset From: Oliver Neukum <oneukum(a)suse.com> commit cbeef22fd611c4f47c494b821b2b105b8af970bb upstream. Quoting Hans: If we return 1 from our post_reset handler, then our disconnect handler will be called immediately afterwards. Since pre_reset blocks all scsi requests our disconnect handler will then hang in the scsi_remove_host call. This is esp. bad because our disconnect handler hanging for ever also stops the USB subsys from enumerating any new USB devices, causes commands like lsusb to hang, etc. In practice this happens when unplugging some uas devices because the hub code may see the device as needing a warm-reset and calls usb_reset_device before seeing the disconnect. In this case uas_configure_endpoints fails with -ENODEV. We do not want to print an error for this, so this commit also silences the shost_printk for -ENODEV. ENDQUOTE However, if we do that we better drop any unconditional execution and report to the SCSI subsystem that we have undergone a reset but we are not operational now. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Reported-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/storage/uas.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- a/drivers/usb/storage/uas.c +++ b/drivers/usb/storage/uas.c @@ -1067,20 +1067,19 @@ static int uas_post_reset(struct usb_int return 0; err = uas_configure_endpoints(devinfo); - if (err) { + if (err && err != ENODEV) shost_printk(KERN_ERR, shost, "%s: alloc streams error %d after reset", __func__, err); - return 1; - } + /* we must unblock the host in every case lest we deadlock */ spin_lock_irqsave(shost->host_lock, flags); scsi_report_bus_reset(shost, 0); spin_unlock_irqrestore(shost->host_lock, flags); scsi_unblock_requests(shost); - return 0; + return err ? 1 : 0; } static int uas_suspend(struct usb_interface *intf, pm_message_t message) Patches currently in stable-queue which might be from oneukum(a)suse.com are queue-3.18/usb-uas-unconditionally-bring-back-host-after-reset.patch queue-3.18/cdc-acm-apply-quirk-for-card-reader.patch queue-3.18/usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: simple: add Motorola Tetra driver" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: simple: add Motorola Tetra driver to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-serial-simple-add-motorola-tetra-driver.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 46fe895e22ab3845515ec06b01eaf1282b342e29 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Thu, 18 Jan 2018 14:46:41 +1100 Subject: USB: serial: simple: add Motorola Tetra driver From: Johan Hovold <johan(a)kernel.org> commit 46fe895e22ab3845515ec06b01eaf1282b342e29 upstream. Add new Motorola Tetra (simple) driver for Motorola Solutions TETRA PEI devices. D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0cad ProdID=9011 Rev=24.16 S: Manufacturer=Motorola Solutions Inc. S: Product=Motorola Solutions TETRA PEI interface C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) Note that these devices do not support the CDC SET_CONTROL_LINE_STATE request (for any interface). Reported-by: Max Schulze <max.schulze(a)posteo.de> Tested-by: Max Schulze <max.schulze(a)posteo.de> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/Kconfig | 1 + drivers/usb/serial/usb-serial-simple.c | 7 +++++++ 2 files changed, 8 insertions(+) --- a/drivers/usb/serial/Kconfig +++ b/drivers/usb/serial/Kconfig @@ -62,6 +62,7 @@ config USB_SERIAL_SIMPLE - Fundamental Software dongle. - HP4x calculators - a number of Motorola phones + - Motorola Tetra devices - Novatel Wireless GPS receivers - Siemens USB/MPI adapter. - ViVOtech ViVOpay USB device. --- a/drivers/usb/serial/usb-serial-simple.c +++ b/drivers/usb/serial/usb-serial-simple.c @@ -72,6 +72,11 @@ DEVICE(vivopay, VIVOPAY_IDS); { USB_DEVICE(0x22b8, 0x2c64) } /* Motorola V950 phone */ DEVICE(moto_modem, MOTO_IDS); +/* Motorola Tetra driver */ +#define MOTOROLA_TETRA_IDS() \ + { USB_DEVICE(0x0cad, 0x9011) } /* Motorola Solutions TETRA PEI */ +DEVICE(motorola_tetra, MOTOROLA_TETRA_IDS); + /* Novatel Wireless GPS driver */ #define NOVATEL_IDS() \ { USB_DEVICE(0x09d7, 0x0100) } /* NovAtel FlexPack GPS */ @@ -101,6 +106,7 @@ static struct usb_serial_driver * const &flashloader_device, &vivopay_device, &moto_modem_device, + &motorola_tetra_device, &novatel_gps_device, &hp4x_device, &suunto_device, @@ -115,6 +121,7 @@ static const struct usb_device_id id_tab FLASHLOADER_IDS(), VIVOPAY_IDS(), MOTO_IDS(), + MOTOROLA_TETRA_IDS(), NOVATEL_IDS(), HP4X_IDS(), SUUNTO_IDS(), Patches currently in stable-queue which might be from johan(a)kernel.org are queue-3.18/usb-serial-pl2303-new-device-id-for-chilitag.patch queue-3.18/usb-serial-simple-add-motorola-tetra-driver.patch queue-3.18/usb-serial-io_edgeport-fix-possible-sleep-in-atomic.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: pl2303: new device id for Chilitag" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: pl2303: new device id for Chilitag to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-serial-pl2303-new-device-id-for-chilitag.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d08dd3f3dd2ae351b793fc5b76abdbf0fd317b12 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Date: Thu, 25 Jan 2018 09:48:55 +0100 Subject: USB: serial: pl2303: new device id for Chilitag MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> commit d08dd3f3dd2ae351b793fc5b76abdbf0fd317b12 upstream. This adds a new device id for Chilitag devices to the pl2303 driver. Reported-by: "Chu.Mike [朱堅宜]" <Mike-Chu(a)prolific.com.tw> Acked-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/pl2303.c | 1 + drivers/usb/serial/pl2303.h | 1 + 2 files changed, 2 insertions(+) --- a/drivers/usb/serial/pl2303.c +++ b/drivers/usb/serial/pl2303.c @@ -39,6 +39,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ2) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_DCU11) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ3) }, + { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_CHILITAG) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_PHAROS) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_ALDIGA) }, { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_MMX) }, --- a/drivers/usb/serial/pl2303.h +++ b/drivers/usb/serial/pl2303.h @@ -17,6 +17,7 @@ #define PL2303_PRODUCT_ID_DCU11 0x1234 #define PL2303_PRODUCT_ID_PHAROS 0xaaa0 #define PL2303_PRODUCT_ID_RSAQ3 0xaaa2 +#define PL2303_PRODUCT_ID_CHILITAG 0xaaa8 #define PL2303_PRODUCT_ID_ALDIGA 0x0611 #define PL2303_PRODUCT_ID_MMX 0x0612 #define PL2303_PRODUCT_ID_GPRS 0x0609 Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are queue-3.18/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-3.18/nfsd-check-for-use-of-the-closed-special-stateid.patch queue-3.18/bcache-check-return-value-of-register_shrinker.patch queue-3.18/nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch queue-3.18/um-stop-abusing-__kernel__.patch queue-3.18/quota-check-for-register_shrinker-failure.patch queue-3.18/mac80211-fix-the-update-of-path-metric-for-rann-frame.patch queue-3.18/xen-netfront-remove-warning-when-unloading-module.patch queue-3.18/kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch queue-3.18/net-ethernet-xilinx-mark-xilinx_ll_temac-broken-on-64-bit.patch queue-3.18/gpio-iop-add-missing-module_description-author-license.patch queue-3.18/usbip-list-don-t-list-devices-attached-to-vhci_hcd.patch queue-3.18/scsi-ufs-ufshcd-fix-potential-null-pointer-dereference-in-ufshcd_config_vreg.patch queue-3.18/kvm-x86-fix-operand-address-size-during-instruction-decoding.patch queue-3.18/usb-uas-unconditionally-bring-back-host-after-reset.patch queue-3.18/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-3.18/usbip-prevent-bind-loops-on-devices-attached-to-vhci_hcd.patch queue-3.18/um-link-vmlinux-with-no-pie.patch queue-3.18/um-remove-copy-paste-code-from-init.h.patch queue-3.18/spi-imx-do-not-access-registers-while-clocks-disabled.patch queue-3.18/cdc-acm-apply-quirk-for-card-reader.patch queue-3.18/staging-rtl8188eu-fix-incorrect-response-to-siocgiwessid.patch queue-3.18/input-do-not-emit-unneeded-ev_syn-when-suspending.patch queue-3.18/igb-free-irqs-when-device-is-hotplugged.patch queue-3.18/usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch queue-3.18/loop-fix-concurrent-lo_open-lo_release.patch queue-3.18/media-usbtv-add-a-new-usbid.patch queue-3.18/usb-serial-pl2303-new-device-id-for-chilitag.patch queue-3.18/usb-serial-simple-add-motorola-tetra-driver.patch queue-3.18/usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch queue-3.18/usb-serial-io_edgeport-fix-possible-sleep-in-atomic.patch queue-3.18/usb-f_fs-prevent-gadget-unbind-if-it-is-already-unbound.patch queue-3.18/alsa-seq-make-ioctls-race-free.patch queue-3.18/hwmon-pmbus-use-64bit-math-for-direct-format-values.patch queue-3.18/selinux-general-protection-fault-in-sock_has_perm.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: io_edgeport: fix possible sleep-in-atomic" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: io_edgeport: fix possible sleep-in-atomic to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-serial-io_edgeport-fix-possible-sleep-in-atomic.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c7b8f77872c73f69a16528a9eb87afefcccdc18b Mon Sep 17 00:00:00 2001 From: Jia-Ju Bai <baijiaju1990(a)gmail.com> Date: Wed, 13 Dec 2017 20:34:36 +0800 Subject: USB: serial: io_edgeport: fix possible sleep-in-atomic From: Jia-Ju Bai <baijiaju1990(a)gmail.com> commit c7b8f77872c73f69a16528a9eb87afefcccdc18b upstream. According to drivers/usb/serial/io_edgeport.c, the driver may sleep under a spinlock. The function call path is: edge_bulk_in_callback (acquire the spinlock) process_rcvd_data process_rcvd_status change_port_settings send_iosp_ext_cmd write_cmd_usb usb_kill_urb --> may sleep To fix it, the redundant usb_kill_urb() is removed from the error path after usb_submit_urb() fails. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai <baijiaju1990(a)gmail.com> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/io_edgeport.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/usb/serial/io_edgeport.c +++ b/drivers/usb/serial/io_edgeport.c @@ -2219,7 +2219,6 @@ static int write_cmd_usb(struct edgeport /* something went wrong */ dev_err(dev, "%s - usb_submit_urb(write command) failed, status = %d\n", __func__, status); - usb_kill_urb(urb); usb_free_urb(urb); atomic_dec(&CmdUrbs); return status; Patches currently in stable-queue which might be from baijiaju1990(a)gmail.com are queue-3.18/usb-serial-io_edgeport-fix-possible-sleep-in-atomic.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: f_fs: Prevent gadget unbind if it is already unbound" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: f_fs: Prevent gadget unbind if it is already unbound to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-f_fs-prevent-gadget-unbind-if-it-is-already-unbound.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ce5bf9a50daf2d9078b505aca1cea22e88ecb94a Mon Sep 17 00:00:00 2001 From: Hemant Kumar <hemantk(a)codeaurora.org> Date: Tue, 9 Jan 2018 12:30:53 +0530 Subject: usb: f_fs: Prevent gadget unbind if it is already unbound From: Hemant Kumar <hemantk(a)codeaurora.org> commit ce5bf9a50daf2d9078b505aca1cea22e88ecb94a upstream. Upon usb composition switch there is possibility of ep0 file release happening after gadget driver bind. In case of composition switch from adb to a non-adb composition gadget will never gets bound again resulting into failure of usb device enumeration. Fix this issue by checking FFS_FL_BOUND flag and avoid extra gadget driver unbind if it is already done as part of composition switch. This fixes adb reconnection error reported on Android running v4.4 and above kernel versions. Verified on Hikey running vanilla v4.15-rc7 + few out of tree Mali patches. Reviewed-at: https://android-review.googlesource.com/#/c/582632/ Cc: Felipe Balbi <balbi(a)kernel.org> Cc: Greg KH <gregkh(a)linux-foundation.org> Cc: Michal Nazarewicz <mina86(a)mina86.com> Cc: John Stultz <john.stultz(a)linaro.org> Cc: Dmitry Shmidt <dimitrysh(a)google.com> Cc: Badhri <badhri(a)google.com> Cc: Android Kernel Team <kernel-team(a)android.com> Signed-off-by: Hemant Kumar <hemantk(a)codeaurora.org> [AmitP: Cherry-picked it from android-4.14 and updated the commit log] Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/function/f_fs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -3438,7 +3438,8 @@ static void ffs_closed(struct ffs_data * ci = opts->func_inst.group.cg_item.ci_parent->ci_parent; ffs_dev_unlock(); - unregister_gadget_item(ci); + if (test_bit(FFS_FL_BOUND, &ffs->flags)) + unregister_gadget_item(ci); return; done: ffs_dev_unlock(); Patches currently in stable-queue which might be from hemantk(a)codeaurora.org are queue-3.18/usb-f_fs-prevent-gadget-unbind-if-it-is-already-unbound.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: cdc-acm: Do not log urb submission errors on disconnect" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: cdc-acm: Do not log urb submission errors on disconnect to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f0386c083c2ce85284dc0b419d7b89c8e567c09f Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Sun, 14 Jan 2018 16:09:00 +0100 Subject: USB: cdc-acm: Do not log urb submission errors on disconnect From: Hans de Goede <hdegoede(a)redhat.com> commit f0386c083c2ce85284dc0b419d7b89c8e567c09f upstream. When disconnected sometimes the cdc-acm driver logs errors like these: [20278.039417] cdc_acm 2-2:2.1: urb 9 failed submission with -19 [20278.042924] cdc_acm 2-2:2.1: urb 10 failed submission with -19 [20278.046449] cdc_acm 2-2:2.1: urb 11 failed submission with -19 [20278.049920] cdc_acm 2-2:2.1: urb 12 failed submission with -19 [20278.053442] cdc_acm 2-2:2.1: urb 13 failed submission with -19 [20278.056915] cdc_acm 2-2:2.1: urb 14 failed submission with -19 [20278.060418] cdc_acm 2-2:2.1: urb 15 failed submission with -19 Silence these by not logging errors when the result is -ENODEV. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Acked-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/class/cdc-acm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -381,7 +381,7 @@ static int acm_submit_read_urb(struct ac res = usb_submit_urb(acm->read_urbs[index], mem_flags); if (res) { - if (res != -EPERM) { + if (res != -EPERM && res != -ENODEV) { dev_err(&acm->data->dev, "%s - usb_submit_urb failed: %d\n", __func__, res); Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-3.18/usb-uas-unconditionally-bring-back-host-after-reset.patch queue-3.18/usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "spi: imx: do not access registers while clocks disabled" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled spi: imx: do not access registers while clocks disabled to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: spi-imx-do-not-access-registers-while-clocks-disabled.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d593574aff0ab846136190b1729c151c736727ec Mon Sep 17 00:00:00 2001 From: Stefan Agner <stefan(a)agner.ch> Date: Sun, 7 Jan 2018 15:05:49 +0100 Subject: spi: imx: do not access registers while clocks disabled From: Stefan Agner <stefan(a)agner.ch> commit d593574aff0ab846136190b1729c151c736727ec upstream. Since clocks are disabled except during message transfer clocks are also disabled when spi_imx_remove gets called. Accessing registers leads to a freeeze at least on a i.MX 6ULL. Enable clocks before disabling accessing the MXC_CSPICTRL register. Fixes: 9e556dcc55774 ("spi: spi-imx: only enable the clocks when we start to transfer a message") Signed-off-by: Stefan Agner <stefan(a)agner.ch> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/spi/spi-imx.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) --- a/drivers/spi/spi-imx.c +++ b/drivers/spi/spi-imx.c @@ -1220,12 +1220,23 @@ static int spi_imx_remove(struct platfor { struct spi_master *master = platform_get_drvdata(pdev); struct spi_imx_data *spi_imx = spi_master_get_devdata(master); + int ret; spi_bitbang_stop(&spi_imx->bitbang); + ret = clk_enable(spi_imx->clk_per); + if (ret) + return ret; + + ret = clk_enable(spi_imx->clk_ipg); + if (ret) { + clk_disable(spi_imx->clk_per); + return ret; + } + writel(0, spi_imx->base + MXC_CSPICTRL); - clk_unprepare(spi_imx->clk_ipg); - clk_unprepare(spi_imx->clk_per); + clk_disable_unprepare(spi_imx->clk_ipg); + clk_disable_unprepare(spi_imx->clk_per); spi_imx_sdma_exit(spi_imx); spi_master_put(master); Patches currently in stable-queue which might be from stefan(a)agner.ch are queue-3.18/spi-imx-do-not-access-registers-while-clocks-disabled.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "CDC-ACM: apply quirk for card reader" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled CDC-ACM: apply quirk for card reader to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cdc-acm-apply-quirk-for-card-reader.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From df1cc78a52491f71d8170d513d0f6f114faa1bda Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Thu, 18 Jan 2018 12:13:45 +0100 Subject: CDC-ACM: apply quirk for card reader From: Oliver Neukum <oneukum(a)suse.com> commit df1cc78a52491f71d8170d513d0f6f114faa1bda upstream. This devices drops random bytes from messages if you talk to it too fast. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/class/cdc-acm.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -1712,6 +1712,9 @@ static const struct usb_device_id acm_id { USB_DEVICE(0x0ace, 0x1611), /* ZyDAS 56K USB MODEM - new version */ .driver_info = SINGLE_RX_URB, /* firmware bug */ }, + { USB_DEVICE(0x11ca, 0x0201), /* VeriFone Mx870 Gadget Serial */ + .driver_info = SINGLE_RX_URB, + }, { USB_DEVICE(0x22b8, 0x7000), /* Motorola Q Phone */ .driver_info = NO_UNION_NORMAL, /* has no union descriptor */ }, Patches currently in stable-queue which might be from oneukum(a)suse.com are queue-3.18/usb-uas-unconditionally-bring-back-host-after-reset.patch queue-3.18/cdc-acm-apply-quirk-for-card-reader.patch queue-3.18/usb-cdc-acm-do-not-log-urb-submission-errors-on-disconnect.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] fpga: region: release of_parse_phandle nodes after use" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 0f5eb1545907edeea7672a9c1652c4231150ff22 Mon Sep 17 00:00:00 2001 From: Ian Abbott <abbotti(a)mev.co.uk> Date: Wed, 15 Nov 2017 16:33:12 -0600 Subject: [PATCH] fpga: region: release of_parse_phandle nodes after use Both fpga_region_get_manager() and fpga_region_get_bridges() call of_parse_phandle(), but nothing calls of_node_put() on the returned struct device_node pointers. Make sure to do that to stop their reference counters getting out of whack. Fixes: 0fa20cdfcc1f ("fpga: fpga-region: device tree control for FPGA") Cc: <stable(a)vger.kernel.org> # 4.10+ Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk> Signed-off-by: Alan Tull <atull(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c index c6b21194dcbc..119ff75522f1 100644 --- a/drivers/fpga/of-fpga-region.c +++ b/drivers/fpga/of-fpga-region.c @@ -73,6 +73,7 @@ static struct fpga_manager *of_fpga_region_get_mgr(struct device_node *np) mgr_node = of_parse_phandle(np, "fpga-mgr", 0); if (mgr_node) { mgr = of_fpga_mgr_get(mgr_node); + of_node_put(mgr_node); of_node_put(np); return mgr; } @@ -120,10 +121,13 @@ static int of_fpga_region_get_bridges(struct fpga_region *region) parent_br = region_np->parent; /* If overlay has a list of bridges, use it. */ - if (of_parse_phandle(info->overlay, "fpga-bridges", 0)) + br = of_parse_phandle(info->overlay, "fpga-bridges", 0); + if (br) { + of_node_put(br); np = info->overlay; - else + } else { np = region_np; + } for (i = 0; ; i++) { br = of_parse_phandle(np, "fpga-bridges", i); @@ -131,12 +135,15 @@ static int of_fpga_region_get_bridges(struct fpga_region *region) break; /* If parent bridge is in list, skip it. */ - if (br == parent_br) + if (br == parent_br) { + of_node_put(br); continue; + } /* If node is a bridge, get it and add to list */ ret = of_fpga_bridge_get_to_list(br, info, &region->bridge_list); + of_node_put(br); /* If any of the bridges are in use, give up */ if (ret == -EBUSY) {

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] fpga: region: release of_parse_phandle nodes after use" failed to apply to 4.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 0f5eb1545907edeea7672a9c1652c4231150ff22 Mon Sep 17 00:00:00 2001 From: Ian Abbott <abbotti(a)mev.co.uk> Date: Wed, 15 Nov 2017 16:33:12 -0600 Subject: [PATCH] fpga: region: release of_parse_phandle nodes after use Both fpga_region_get_manager() and fpga_region_get_bridges() call of_parse_phandle(), but nothing calls of_node_put() on the returned struct device_node pointers. Make sure to do that to stop their reference counters getting out of whack. Fixes: 0fa20cdfcc1f ("fpga: fpga-region: device tree control for FPGA") Cc: <stable(a)vger.kernel.org> # 4.10+ Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk> Signed-off-by: Alan Tull <atull(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c index c6b21194dcbc..119ff75522f1 100644 --- a/drivers/fpga/of-fpga-region.c +++ b/drivers/fpga/of-fpga-region.c @@ -73,6 +73,7 @@ static struct fpga_manager *of_fpga_region_get_mgr(struct device_node *np) mgr_node = of_parse_phandle(np, "fpga-mgr", 0); if (mgr_node) { mgr = of_fpga_mgr_get(mgr_node); + of_node_put(mgr_node); of_node_put(np); return mgr; } @@ -120,10 +121,13 @@ static int of_fpga_region_get_bridges(struct fpga_region *region) parent_br = region_np->parent; /* If overlay has a list of bridges, use it. */ - if (of_parse_phandle(info->overlay, "fpga-bridges", 0)) + br = of_parse_phandle(info->overlay, "fpga-bridges", 0); + if (br) { + of_node_put(br); np = info->overlay; - else + } else { np = region_np; + } for (i = 0; ; i++) { br = of_parse_phandle(np, "fpga-bridges", i); @@ -131,12 +135,15 @@ static int of_fpga_region_get_bridges(struct fpga_region *region) break; /* If parent bridge is in list, skip it. */ - if (br == parent_br) + if (br == parent_br) { + of_node_put(br); continue; + } /* If node is a bridge, get it and add to list */ ret = of_fpga_bridge_get_to_list(br, info, &region->bridge_list); + of_node_put(br); /* If any of the bridges are in use, give up */ if (ret == -EBUSY) {

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] stating: ccree: fix allocation of void sized buf" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2392b84fb2f8daf71e70dd13101ec70ff636a3d3 Mon Sep 17 00:00:00 2001 From: Gilad Ben-Yossef <gilad(a)benyossef.com> Date: Sun, 7 Jan 2018 12:14:34 +0000 Subject: [PATCH] stating: ccree: fix allocation of void sized buf We were allocating buffers using sizeof(*struct->field) where field was type void. Fix it by having a local variable with the real type. Cc: stable(a)vger.kernel.org Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/ccree/ssi_ivgen.c b/drivers/staging/ccree/ssi_ivgen.c index 6b926495c5d2..2ba15a5c631f 100644 --- a/drivers/staging/ccree/ssi_ivgen.c +++ b/drivers/staging/ccree/ssi_ivgen.c @@ -175,13 +175,10 @@ int cc_ivgen_init(struct cc_drvdata *drvdata) int rc; /* Allocate "this" context */ - drvdata->ivgen_handle = kzalloc(sizeof(*drvdata->ivgen_handle), - GFP_KERNEL); - if (!drvdata->ivgen_handle) + ivgen_ctx = kzalloc(sizeof(*ivgen_ctx), GFP_KERNEL); + if (!ivgen_ctx) return -ENOMEM; - ivgen_ctx = drvdata->ivgen_handle; - /* Allocate pool's header for initial enc. key/IV */ ivgen_ctx->pool_meta = dma_alloc_coherent(device, CC_IVPOOL_META_SIZE, &ivgen_ctx->pool_meta_dma, @@ -200,6 +197,8 @@ int cc_ivgen_init(struct cc_drvdata *drvdata) goto out; } + drvdata->ivgen_handle = ivgen_ctx; + return cc_init_iv_sram(drvdata); out: diff --git a/drivers/staging/ccree/ssi_sram_mgr.c b/drivers/staging/ccree/ssi_sram_mgr.c index 1a2a7f4dc657..c5497aacc71d 100644 --- a/drivers/staging/ccree/ssi_sram_mgr.c +++ b/drivers/staging/ccree/ssi_sram_mgr.c @@ -32,13 +32,16 @@ void cc_sram_mgr_fini(struct cc_drvdata *drvdata) */ int cc_sram_mgr_init(struct cc_drvdata *drvdata) { + struct cc_sram_ctx *ctx; + /* Allocate "this" context */ - drvdata->sram_mgr_handle = kzalloc(sizeof(*drvdata->sram_mgr_handle), - GFP_KERNEL); + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); - if (!drvdata->sram_mgr_handle) + if (!ctx) return -ENOMEM; + drvdata->sram_mgr_handle = ctx; + return 0; }

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] stating: ccree: fix allocation of void sized buf" failed to apply to 4.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2392b84fb2f8daf71e70dd13101ec70ff636a3d3 Mon Sep 17 00:00:00 2001 From: Gilad Ben-Yossef <gilad(a)benyossef.com> Date: Sun, 7 Jan 2018 12:14:34 +0000 Subject: [PATCH] stating: ccree: fix allocation of void sized buf We were allocating buffers using sizeof(*struct->field) where field was type void. Fix it by having a local variable with the real type. Cc: stable(a)vger.kernel.org Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/ccree/ssi_ivgen.c b/drivers/staging/ccree/ssi_ivgen.c index 6b926495c5d2..2ba15a5c631f 100644 --- a/drivers/staging/ccree/ssi_ivgen.c +++ b/drivers/staging/ccree/ssi_ivgen.c @@ -175,13 +175,10 @@ int cc_ivgen_init(struct cc_drvdata *drvdata) int rc; /* Allocate "this" context */ - drvdata->ivgen_handle = kzalloc(sizeof(*drvdata->ivgen_handle), - GFP_KERNEL); - if (!drvdata->ivgen_handle) + ivgen_ctx = kzalloc(sizeof(*ivgen_ctx), GFP_KERNEL); + if (!ivgen_ctx) return -ENOMEM; - ivgen_ctx = drvdata->ivgen_handle; - /* Allocate pool's header for initial enc. key/IV */ ivgen_ctx->pool_meta = dma_alloc_coherent(device, CC_IVPOOL_META_SIZE, &ivgen_ctx->pool_meta_dma, @@ -200,6 +197,8 @@ int cc_ivgen_init(struct cc_drvdata *drvdata) goto out; } + drvdata->ivgen_handle = ivgen_ctx; + return cc_init_iv_sram(drvdata); out: diff --git a/drivers/staging/ccree/ssi_sram_mgr.c b/drivers/staging/ccree/ssi_sram_mgr.c index 1a2a7f4dc657..c5497aacc71d 100644 --- a/drivers/staging/ccree/ssi_sram_mgr.c +++ b/drivers/staging/ccree/ssi_sram_mgr.c @@ -32,13 +32,16 @@ void cc_sram_mgr_fini(struct cc_drvdata *drvdata) */ int cc_sram_mgr_init(struct cc_drvdata *drvdata) { + struct cc_sram_ctx *ctx; + /* Allocate "this" context */ - drvdata->sram_mgr_handle = kzalloc(sizeof(*drvdata->sram_mgr_handle), - GFP_KERNEL); + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); - if (!drvdata->sram_mgr_handle) + if (!ctx) return -ENOMEM; + drvdata->sram_mgr_handle = ctx; + return 0; }

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] tty: fix data race between tty_init_dev and flush of buf" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From b027e2298bd588d6fa36ed2eda97447fb3eac078 Mon Sep 17 00:00:00 2001 From: Gaurav Kohli <gkohli(a)codeaurora.org> Date: Tue, 23 Jan 2018 13:16:34 +0530 Subject: [PATCH] tty: fix data race between tty_init_dev and flush of buf There can be a race, if receive_buf call comes before tty initialization completes in n_tty_open and tty->disc_data may be NULL. CPU0 CPU1 ---- ---- 000|n_tty_receive_buf_common() n_tty_open() -001|n_tty_receive_buf2() tty_ldisc_open.isra.3() -002|tty_ldisc_receive_buf(inline) tty_ldisc_setup() Using ldisc semaphore lock in tty_init_dev till disc_data initializes completely. Signed-off-by: Gaurav Kohli <gkohli(a)codeaurora.org> Reviewed-by: Alan Cox <alan(a)linux.intel.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index a6ca634411e1..688bd25aa6b0 100644 --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -1323,6 +1323,9 @@ struct tty_struct *tty_init_dev(struct tty_driver *driver, int idx) "%s: %s driver does not set tty->port. This will crash the kernel later. Fix the driver!\n", __func__, tty->driver->name); + retval = tty_ldisc_lock(tty, 5 * HZ); + if (retval) + goto err_release_lock; tty->port->itty = tty; /* @@ -1333,6 +1336,7 @@ struct tty_struct *tty_init_dev(struct tty_driver *driver, int idx) retval = tty_ldisc_setup(tty, tty->link); if (retval) goto err_release_tty; + tty_ldisc_unlock(tty); /* Return the tty locked so that it cannot vanish under the caller */ return tty; @@ -1345,9 +1349,11 @@ struct tty_struct *tty_init_dev(struct tty_driver *driver, int idx) /* call the tty release_tty routine to clean out this slot */ err_release_tty: - tty_unlock(tty); + tty_ldisc_unlock(tty); tty_info_ratelimited(tty, "ldisc open failed (%d), clearing slot %d\n", retval, idx); +err_release_lock: + tty_unlock(tty); release_tty(tty, idx); return ERR_PTR(retval); } diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c index 24ec5c7e6b20..4e7946c0484b 100644 --- a/drivers/tty/tty_ldisc.c +++ b/drivers/tty/tty_ldisc.c @@ -337,7 +337,7 @@ static inline void __tty_ldisc_unlock(struct tty_struct *tty) ldsem_up_write(&tty->ldisc_sem); } -static int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout) +int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout) { int ret; @@ -348,7 +348,7 @@ static int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout) return 0; } -static void tty_ldisc_unlock(struct tty_struct *tty) +void tty_ldisc_unlock(struct tty_struct *tty) { clear_bit(TTY_LDISC_HALTED, &tty->flags); __tty_ldisc_unlock(tty); diff --git a/include/linux/tty.h b/include/linux/tty.h index 7ac8ba208b1f..0a6c71e0ad01 100644 --- a/include/linux/tty.h +++ b/include/linux/tty.h @@ -405,6 +405,8 @@ extern const char *tty_name(const struct tty_struct *tty); extern struct tty_struct *tty_kopen(dev_t device); extern void tty_kclose(struct tty_struct *tty); extern int tty_dev_name_to_number(const char *name, dev_t *number); +extern int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout); +extern void tty_ldisc_unlock(struct tty_struct *tty); #else static inline void tty_kref_put(struct tty_struct *tty) { }

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] staging: ccree: handle end of sg list gracefully" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 6e92010b012116d10a3750c0406e3da67f274498 Mon Sep 17 00:00:00 2001 From: Gilad Ben-Yossef <gilad(a)benyossef.com> Date: Sun, 7 Jan 2018 12:14:25 +0000 Subject: [PATCH] staging: ccree: handle end of sg list gracefully If we are asked for number of entries of an offset bigger than the sg list we should not crash. Cc: stable(a)vger.kernel.org Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c b/drivers/staging/ccree/ssi_buffer_mgr.c index 78288ed75281..0f7126404a32 100644 --- a/drivers/staging/ccree/ssi_buffer_mgr.c +++ b/drivers/staging/ccree/ssi_buffer_mgr.c @@ -94,7 +94,7 @@ static unsigned int cc_get_sgl_nents(struct device *dev, { unsigned int nents = 0; - while (nbytes) { + while (nbytes && sg_list) { if (sg_list->length) { nents++; /* get the number of bytes in the last entry */

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] staging: ccree: handle end of sg list gracefully" failed to apply to 4.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 6e92010b012116d10a3750c0406e3da67f274498 Mon Sep 17 00:00:00 2001 From: Gilad Ben-Yossef <gilad(a)benyossef.com> Date: Sun, 7 Jan 2018 12:14:25 +0000 Subject: [PATCH] staging: ccree: handle end of sg list gracefully If we are asked for number of entries of an offset bigger than the sg list we should not crash. Cc: stable(a)vger.kernel.org Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c b/drivers/staging/ccree/ssi_buffer_mgr.c index 78288ed75281..0f7126404a32 100644 --- a/drivers/staging/ccree/ssi_buffer_mgr.c +++ b/drivers/staging/ccree/ssi_buffer_mgr.c @@ -94,7 +94,7 @@ static unsigned int cc_get_sgl_nents(struct device *dev, { unsigned int nents = 0; - while (nbytes) { + while (nbytes && sg_list) { if (sg_list->length) { nents++; /* get the number of bytes in the last entry */

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] staging: ccree: check DMA pool buf !NULL before free" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2f7caf6b02145bd9cd9d0b56204f51a5fefe7790 Mon Sep 17 00:00:00 2001 From: Gilad Ben-Yossef <gilad(a)benyossef.com> Date: Sun, 7 Jan 2018 12:14:24 +0000 Subject: [PATCH] staging: ccree: check DMA pool buf !NULL before free If we ran out of DMA pool buffers, we get into the unmap code path with a NULL before. Deal with this by checking the virtual mapping is not NULL. Cc: stable(a)vger.kernel.org Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c b/drivers/staging/ccree/ssi_buffer_mgr.c index e85bb53a3289..78288ed75281 100644 --- a/drivers/staging/ccree/ssi_buffer_mgr.c +++ b/drivers/staging/ccree/ssi_buffer_mgr.c @@ -465,7 +465,8 @@ void cc_unmap_blkcipher_request(struct device *dev, void *ctx, DMA_TO_DEVICE); } /* Release pool */ - if (req_ctx->dma_buf_type == CC_DMA_BUF_MLLI) { + if (req_ctx->dma_buf_type == CC_DMA_BUF_MLLI && + req_ctx->mlli_params.mlli_virt_addr) { dma_pool_free(req_ctx->mlli_params.curr_pool, req_ctx->mlli_params.mlli_virt_addr, req_ctx->mlli_params.mlli_dma_addr);

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] staging: ccree: check DMA pool buf !NULL before free" failed to apply to 4.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2f7caf6b02145bd9cd9d0b56204f51a5fefe7790 Mon Sep 17 00:00:00 2001 From: Gilad Ben-Yossef <gilad(a)benyossef.com> Date: Sun, 7 Jan 2018 12:14:24 +0000 Subject: [PATCH] staging: ccree: check DMA pool buf !NULL before free If we ran out of DMA pool buffers, we get into the unmap code path with a NULL before. Deal with this by checking the virtual mapping is not NULL. Cc: stable(a)vger.kernel.org Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c b/drivers/staging/ccree/ssi_buffer_mgr.c index e85bb53a3289..78288ed75281 100644 --- a/drivers/staging/ccree/ssi_buffer_mgr.c +++ b/drivers/staging/ccree/ssi_buffer_mgr.c @@ -465,7 +465,8 @@ void cc_unmap_blkcipher_request(struct device *dev, void *ctx, DMA_TO_DEVICE); } /* Release pool */ - if (req_ctx->dma_buf_type == CC_DMA_BUF_MLLI) { + if (req_ctx->dma_buf_type == CC_DMA_BUF_MLLI && + req_ctx->mlli_params.mlli_virt_addr) { dma_pool_free(req_ctx->mlli_params.curr_pool, req_ctx->mlli_params.mlli_virt_addr, req_ctx->mlli_params.mlli_dma_addr);

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] stating: ccree: revert "staging: ccree: fix leak of import()" failed to apply to 4.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 293edc27f8bc8a44978e9e95902b07b74f1c7523 Mon Sep 17 00:00:00 2001 From: Gilad Ben-Yossef <gilad(a)benyossef.com> Date: Sun, 7 Jan 2018 12:14:22 +0000 Subject: [PATCH] stating: ccree: revert "staging: ccree: fix leak of import() after init()" This reverts commit c5f39d07860c ("staging: ccree: fix leak of import() after init()") and commit aece09024414 ("staging: ccree: Uninitialized return in ssi_ahash_import()"). This is the wrong solution and ends up relying on uninitialized memory, although it was not obvious to me at the time. Cc: stable(a)vger.kernel.org Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c index ff05ac8eeb2c..ee7370c60426 100644 --- a/drivers/staging/ccree/ssi_hash.c +++ b/drivers/staging/ccree/ssi_hash.c @@ -1673,7 +1673,7 @@ static int cc_hash_import(struct ahash_request *req, const void *in) struct device *dev = drvdata_to_dev(ctx->drvdata); struct ahash_req_ctx *state = ahash_request_ctx(req); u32 tmp; - int rc = 0; + int rc; memcpy(&tmp, in, sizeof(u32)); if (tmp != CC_EXPORT_MAGIC) { @@ -1682,12 +1682,9 @@ static int cc_hash_import(struct ahash_request *req, const void *in) } in += sizeof(u32); - /* call init() to allocate bufs if the user hasn't */ - if (!state->digest_buff) { - rc = cc_hash_init(req); - if (rc) - goto out; - } + rc = cc_hash_init(req); + if (rc) + goto out; dma_sync_single_for_cpu(dev, state->digest_buff_dma_addr, ctx->inter_digestsize, DMA_BIDIRECTIONAL);

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] [PATCH 4.4] kaiser: fix intel_bts perf crashes

by Hugh Dickins

Vince reported perf_fuzzer quickly locks up on 4.15-rc7 with PTI; Robert reported Bad RIP with KPTI and Intel BTS also on 4.15-rc7: honggfuzz -f /tmp/somedirectorywithatleastonefile \ --linux_perf_bts_edge -s -- /bin/true (honggfuzz from https://github.com/google/honggfuzz) crashed with BUG: unable to handle kernel paging request at ffff9d3215100000 (then narrowed it down to perf record --per-thread -e intel_bts//u -- /bin/ls). The intel_bts driver does not use the 'normal' BTS buffer which is exposed through kaiser_add_mapping(), but instead uses the memory allocated for the perf AUX buffer. This obviously comes apart when using PTI, because then the kernel mapping, which includes that AUX buffer memory, disappears while switched to user page tables. Easily fixed in old-Kaiser backports, by applying kaiser_add_mapping() to those pages; perhaps not so easy for upstream, where 4.15-rc8 commit 99a9dc98ba52 ("x86,perf: Disable intel_bts when PTI") disables for now. Slightly reorganized surrounding code in bts_buffer_setup_aux(), so it can better match bts_buffer_free_aux(): free_aux with an #ifdef to avoid the loop when PTI is off, but setup_aux needs to loop anyway (and kaiser_add_mapping() is cheap when PTI config is off or "pti=off"). Reported-by: Vince Weaver <vincent.weaver(a)maine.edu> Reported-by: Robert Święcki <robert(a)swiecki.net> Analyzed-by: Peter Zijlstra <peterz(a)infradead.org> Analyzed-by: Stephane Eranian <eranian(a)google.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Andy Lutomirski <luto(a)amacapital.net> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Vince Weaver <vince(a)deater.net> Cc: stable(a)vger.kernel.org Cc: Jiri Kosina <jkosina(a)suze.cz> Signed-off-by: Hugh Dickins <hughd(a)google.com> --- arch/x86/kernel/cpu/perf_event_intel_bts.c | 44 ++++++++++++++++++++++-------- 1 file changed, 33 insertions(+), 11 deletions(-) diff --git a/arch/x86/kernel/cpu/perf_event_intel_bts.c b/arch/x86/kernel/cpu/perf_event_intel_bts.c index 2cad71d1b14c..5af11c46d0b9 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_bts.c +++ b/arch/x86/kernel/cpu/perf_event_intel_bts.c @@ -22,6 +22,7 @@ #include <linux/debugfs.h> #include <linux/device.h> #include <linux/coredump.h> +#include <linux/kaiser.h> #include <asm-generic/sizes.h> #include <asm/perf_event.h> @@ -67,6 +68,23 @@ static size_t buf_size(struct page *page) return 1 << (PAGE_SHIFT + page_private(page)); } +static void bts_buffer_free_aux(void *data) +{ +#ifdef CONFIG_PAGE_TABLE_ISOLATION + struct bts_buffer *buf = data; + int nbuf; + + for (nbuf = 0; nbuf < buf->nr_bufs; nbuf++) { + struct page *page = buf->buf[nbuf].page; + void *kaddr = page_address(page); + size_t page_size = buf_size(page); + + kaiser_remove_mapping((unsigned long)kaddr, page_size); + } +#endif + kfree(data); +} + static void * bts_buffer_setup_aux(int cpu, void **pages, int nr_pages, bool overwrite) { @@ -103,29 +121,33 @@ bts_buffer_setup_aux(int cpu, void **pages, int nr_pages, bool overwrite) buf->real_size = size - size % BTS_RECORD_SIZE; for (pg = 0, nbuf = 0, offset = 0, pad = 0; nbuf < buf->nr_bufs; nbuf++) { - unsigned int __nr_pages; + void *kaddr = pages[pg]; + size_t page_size; + + page = virt_to_page(kaddr); + page_size = buf_size(page); + + if (kaiser_add_mapping((unsigned long)kaddr, + page_size, __PAGE_KERNEL) < 0) { + buf->nr_bufs = nbuf; + bts_buffer_free_aux(buf); + return NULL; + } - page = virt_to_page(pages[pg]); - __nr_pages = PagePrivate(page) ? 1 << page_private(page) : 1; buf->buf[nbuf].page = page; buf->buf[nbuf].offset = offset; buf->buf[nbuf].displacement = (pad ? BTS_RECORD_SIZE - pad : 0); - buf->buf[nbuf].size = buf_size(page) - buf->buf[nbuf].displacement; + buf->buf[nbuf].size = page_size - buf->buf[nbuf].displacement; pad = buf->buf[nbuf].size % BTS_RECORD_SIZE; buf->buf[nbuf].size -= pad; - pg += __nr_pages; - offset += __nr_pages << PAGE_SHIFT; + pg += page_size >> PAGE_SHIFT; + offset += page_size; } return buf; } -static void bts_buffer_free_aux(void *data) -{ - kfree(data); -} - static unsigned long bts_buffer_offset(struct bts_buffer *buf, unsigned int idx) { return buf->buf[idx].offset + buf->buf[idx].displacement; -- 2.16.0.rc1.238.g530d649a79-goog

7 years, 4 months

7
8
0 0

[Linux-stable-mirror] [PATCH for-next] IB/core: Avoid a potential OOPs for an unused optional parameter

by Dennis Dalessandro

From: Michael J. Ruhl <michael.j.ruhl(a)intel.com> The ev_file is an optional parameter for CQ creation. If the parameter is not passed, the ev_file pointer will be NULL. Using that pointer to set the cq_context will result in an OOPs. Verify that ev_file is not NULL before using. Cc: <stable(a)vger.kernel.org> # 4.14.x Fixes: 9ee79fce3642 ("IB/core: Add completion queue (cq) object actions") Reviewed-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Reviewed-by: Ira Weiny <ira.weiny(a)intel.com> Signed-off-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> --- drivers/infiniband/core/uverbs_std_types.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/infiniband/core/uverbs_std_types.c b/drivers/infiniband/core/uverbs_std_types.c index b571176..cab0ac3 100644 --- a/drivers/infiniband/core/uverbs_std_types.c +++ b/drivers/infiniband/core/uverbs_std_types.c @@ -316,7 +316,7 @@ static int uverbs_create_cq_handler(struct ib_device *ib_dev, cq->uobject = &obj->uobject; cq->comp_handler = ib_uverbs_comp_handler; cq->event_handler = ib_uverbs_cq_event_handler; - cq->cq_context = &ev_file->ev_queue; + cq->cq_context = ev_file ? &ev_file->ev_queue : NULL; obj->uobject.object = cq; obj->uobject.user_handle = user_handle; atomic_set(&cq->usecnt, 0);

7 years, 4 months

2
1
0 0

[Linux-stable-mirror] + mm-kasan-dont-vfree-nonexistent-vm_area.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/kasan: don't vfree() nonexistent vm_area has been added to the -mm tree. Its filename is mm-kasan-dont-vfree-nonexistent-vm_area.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-kasan-dont-vfree-nonexistent-vm… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-kasan-dont-vfree-nonexistent-vm… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Subject: mm/kasan: don't vfree() nonexistent vm_area KASAN uses different routines to map shadow for hot added memory and memory obtained in boot process. Attempt to offline memory onlined by normal boot process leads to this: Trying to vfree() nonexistent vm area (000000005d3b34b9) WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190 Call Trace: kasan_mem_notifier+0xad/0xb9 notifier_call_chain+0x166/0x260 __blocking_notifier_call_chain+0xdb/0x140 __offline_pages+0x96a/0xb10 memory_subsys_offline+0x76/0xc0 device_offline+0xb8/0x120 store_mem_state+0xfa/0x120 kernfs_fop_write+0x1d5/0x320 __vfs_write+0xd4/0x530 vfs_write+0x105/0x340 SyS_write+0xb0/0x140 Obviously we can't call vfree() to free memory that wasn't allocated via vmalloc(). Use find_vm_area() to see if we can call vfree(). Unfortunately it's a bit tricky to properly unmap and free shadow allocated during boot, so we'll have to keep it. If memory will come online again that shadow will be reused. Link: http://lkml.kernel.org/r/20180201163349.8700-1-aryabinin@virtuozzo.com Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug") Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Reported-by: Paul Menzel <pmenzel+linux-kasan-dev(a)molgen.mpg.de> Cc: Alexander Potapenko <glider(a)google.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/kasan/kasan.c | 57 +++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 55 insertions(+), 2 deletions(-) diff -puN mm/kasan/kasan.c~mm-kasan-dont-vfree-nonexistent-vm_area mm/kasan/kasan.c --- a/mm/kasan/kasan.c~mm-kasan-dont-vfree-nonexistent-vm_area +++ a/mm/kasan/kasan.c @@ -791,6 +791,41 @@ DEFINE_ASAN_SET_SHADOW(f5); DEFINE_ASAN_SET_SHADOW(f8); #ifdef CONFIG_MEMORY_HOTPLUG +static bool shadow_mapped(unsigned long addr) +{ + pgd_t *pgd = pgd_offset_k(addr); + p4d_t *p4d; + pud_t *pud; + pmd_t *pmd; + pte_t *pte; + + if (pgd_none(*pgd)) + return false; + p4d = p4d_offset(pgd, addr); + if (p4d_none(*p4d)) + return false; + pud = pud_offset(p4d, addr); + if (pud_none(*pud)) + return false; + + /* + * We can't use pud_large() or pud_huge(), the first one + * is arch-specific, the last one depend on HUGETLB_PAGE. + * So let's abuse pud_bad(), if bud is bad it's has to + * because it's huge. + */ + if (pud_bad(*pud)) + return true; + pmd = pmd_offset(pud, addr); + if (pmd_none(*pmd)) + return false; + + if (pmd_bad(*pmd)) + return true; + pte = pte_offset_kernel(pmd, addr); + return !pte_none(*pte); +} + static int __meminit kasan_mem_notifier(struct notifier_block *nb, unsigned long action, void *data) { @@ -812,6 +847,14 @@ static int __meminit kasan_mem_notifier( case MEM_GOING_ONLINE: { void *ret; + /* + * If shadow is mapped already than it must have been mapped + * during the boot. This could happen if we onlining previously + * offlined memory. + */ + if (shadow_mapped(shadow_start)) + return NOTIFY_OK; + ret = __vmalloc_node_range(shadow_size, PAGE_SIZE, shadow_start, shadow_end, GFP_KERNEL, PAGE_KERNEL, VM_NO_GUARD, @@ -823,8 +866,18 @@ static int __meminit kasan_mem_notifier( kmemleak_ignore(ret); return NOTIFY_OK; } - case MEM_OFFLINE: - vfree((void *)shadow_start); + case MEM_OFFLINE: { + struct vm_struct *vm; + + /* + * Only hot-added memory have vm_area. Freeing shadow + * mapped during boot would be tricky, so we'll just + * have to keep it. + */ + vm = find_vm_area((void *)shadow_start); + if (vm) + vfree((void *)shadow_start); + } } return NOTIFY_OK; _ Patches currently in -mm which might be from aryabinin(a)virtuozzo.com are kasan-makefile-support-llvm-style-asan-parameters.patch mm-kasan-dont-vfree-nonexistent-vm_area.patch lib-ubsan-add-type-mismatch-handler-for-new-gcc-clang.patch lib-ubsan-remove-returns-nonnull-attribute-checks.patch lib-ubsan-remove-returns-nonnull-attribute-checks-fix.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] [merged] mm-memory_hotplug-fix-memmap-initialization.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm, memory_hotplug: fix memmap initialization has been removed from the -mm tree. Its filename was mm-memory_hotplug-fix-memmap-initialization.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Michal Hocko <mhocko(a)suse.com> Subject: mm, memory_hotplug: fix memmap initialization Bharata has noticed that onlining a newly added memory doesn't increase the total memory, pointing to f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap") as a culprit. This commit has changed the way how the memory for memmaps is initialized and moves it from the allocation time to the initialization time. This works properly for the early memmap init path. It doesn't work for the memory hotplug though because we need to mark page as reserved when the sparsemem section is created and later initialize it completely during onlining. memmap_init_zone is called in the early stage of onlining. With the current code it calls __init_single_page and as such it clears up the whole stage and therefore online_pages_range skips those pages. Fix this by skipping mm_zero_struct_page in __init_single_page for memory hotplug path. This is quite uggly but unifying both early init and memory hotplug init paths is a large project. Make sure we plug the regression at least. Link: http://lkml.kernel.org/r/20180130101141.GW21609@dhcp22.suse.cz Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap") Signed-off-by: Michal Hocko <mhocko(a)suse.com> Reported-by: Bharata B Rao <bharata(a)linux.vnet.ibm.com> Tested-by: Bharata B Rao <bharata(a)linux.vnet.ibm.com> Reviewed-by: Pavel Tatashin <pasha.tatashin(a)oracle.com> Cc: Steven Sistare <steven.sistare(a)oracle.com> Cc: Daniel Jordan <daniel.m.jordan(a)oracle.com> Cc: Bob Picco <bob.picco(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff -puN mm/page_alloc.c~mm-memory_hotplug-fix-memmap-initialization mm/page_alloc.c --- a/mm/page_alloc.c~mm-memory_hotplug-fix-memmap-initialization +++ a/mm/page_alloc.c @@ -1177,9 +1177,10 @@ static void free_one_page(struct zone *z } static void __meminit __init_single_page(struct page *page, unsigned long pfn, - unsigned long zone, int nid) + unsigned long zone, int nid, bool zero) { - mm_zero_struct_page(page); + if (zero) + mm_zero_struct_page(page); set_page_links(page, zone, nid, pfn); init_page_count(page); page_mapcount_reset(page); @@ -1194,9 +1195,9 @@ static void __meminit __init_single_page } static void __meminit __init_single_pfn(unsigned long pfn, unsigned long zone, - int nid) + int nid, bool zero) { - return __init_single_page(pfn_to_page(pfn), pfn, zone, nid); + return __init_single_page(pfn_to_page(pfn), pfn, zone, nid, zero); } #ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT @@ -1217,7 +1218,7 @@ static void __meminit init_reserved_page if (pfn >= zone->zone_start_pfn && pfn < zone_end_pfn(zone)) break; } - __init_single_pfn(pfn, zid, nid); + __init_single_pfn(pfn, zid, nid, true); } #else static inline void init_reserved_page(unsigned long pfn) @@ -1534,7 +1535,7 @@ static unsigned long __init deferred_in } else { page++; } - __init_single_page(page, pfn, zid, nid); + __init_single_page(page, pfn, zid, nid, true); nr_pages++; } return (nr_pages); @@ -5399,15 +5400,20 @@ not_early: * can be created for invalid pages (for alignment) * check here not to call set_pageblock_migratetype() against * pfn out of zone. + * + * Please note that MEMMAP_HOTPLUG path doesn't clear memmap + * because this is done early in sparse_add_one_section */ if (!(pfn & (pageblock_nr_pages - 1))) { struct page *page = pfn_to_page(pfn); - __init_single_page(page, pfn, zone, nid); + __init_single_page(page, pfn, zone, nid, + context != MEMMAP_HOTPLUG); set_pageblock_migratetype(page, MIGRATE_MOVABLE); cond_resched(); } else { - __init_single_pfn(pfn, zone, nid); + __init_single_pfn(pfn, zone, nid, + context != MEMMAP_HOTPLUG); } } } _ Patches currently in -mm which might be from mhocko(a)suse.com are mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix-2.patch mm-introduce-map_fixed_safe.patch fs-elf-drop-map_fixed-usage-from-elf_map.patch fs-elf-drop-map_fixed-usage-from-elf_map-fix-fix.patch mm-numa-rework-do_pages_move.patch mm-migrate-remove-reason-argument-from-new_page_t.patch mm-migrate-remove-reason-argument-from-new_page_t-fix-3.patch mm-unclutter-thp-migration.patch net-netfilter-x_tablesc-remove-size-check.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] [PATCH] KVM: x86: fix backward migration with async_PF

by Radim Krčmář

Guests on new hypersiors might set KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT bit when enabling async_PF, but this bit is reserved on old hypervisors, which results in a failure upon migration. Guests at least expect that KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT might not be present when booting, so we allow userspace to handle migration compatibility by adding a KVM CPUID flag that determines the presence of KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT. Fixes: 52a5c155cf79 ("KVM: async_pf: Let guest support delivery of async_pf from guest mode") Cc: <stable(a)vger.kernel.org> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> --- arch/x86/include/uapi/asm/kvm_para.h | 1 + arch/x86/kernel/kvm.c | 8 ++++---- arch/x86/kvm/cpuid.c | 3 ++- arch/x86/kvm/cpuid.h | 11 +++++++++++ arch/x86/kvm/x86.c | 6 ++++-- 5 files changed, 22 insertions(+), 7 deletions(-) diff --git a/arch/x86/include/uapi/asm/kvm_para.h b/arch/x86/include/uapi/asm/kvm_para.h index 7a2ade4aa235..6cfa9c8cb7d6 100644 --- a/arch/x86/include/uapi/asm/kvm_para.h +++ b/arch/x86/include/uapi/asm/kvm_para.h @@ -26,6 +26,7 @@ #define KVM_FEATURE_PV_EOI 6 #define KVM_FEATURE_PV_UNHALT 7 #define KVM_FEATURE_PV_TLB_FLUSH 9 +#define KVM_FEATURE_ASYNC_PF_VMEXIT 10 /* The last 8 bits are used to indicate how to interpret the flags field * in pvclock structure. If no bits are set, all flags are ignored. diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index 4e37d1a851a6..971babe964d2 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -341,10 +341,10 @@ static void kvm_guest_cpu_init(void) #endif pa |= KVM_ASYNC_PF_ENABLED; - /* Async page fault support for L1 hypervisor is optional */ - if (wrmsr_safe(MSR_KVM_ASYNC_PF_EN, - (pa | KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT) & 0xffffffff, pa >> 32) < 0) - wrmsrl(MSR_KVM_ASYNC_PF_EN, pa); + if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF_VMEXIT)) + pa |= KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT; + + wrmsrl(MSR_KVM_ASYNC_PF_EN, pa); __this_cpu_write(apf_reason.enabled, 1); printk(KERN_INFO"KVM setup async PF for cpu %d\n", smp_processor_id()); diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 20e491b94f44..7fc04a176c57 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -604,7 +604,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, (1 << KVM_FEATURE_PV_EOI) | (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) | (1 << KVM_FEATURE_PV_UNHALT) | - (1 << KVM_FEATURE_PV_TLB_FLUSH); + (1 << KVM_FEATURE_PV_TLB_FLUSH) | + (1 << KVM_FEATURE_ASYNC_PF_VMEXIT); if (sched_info_on()) entry->eax |= (1 << KVM_FEATURE_STEAL_TIME); diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h index c2cea6651279..f20731dfe28e 100644 --- a/arch/x86/kvm/cpuid.h +++ b/arch/x86/kvm/cpuid.h @@ -105,6 +105,17 @@ static __always_inline bool guest_cpuid_has(struct kvm_vcpu *vcpu, unsigned x86_ return *reg & bit(x86_feature); } +static inline bool guest_kvm_cpuid_has(struct kvm_vcpu *vcpu, unsigned kvm_feature) +{ + struct kvm_cpuid_entry2 *entry; + + entry = kvm_find_cpuid_entry(vcpu, KVM_CPUID_FEATURES, 0); + if (!entry) + return false; + + return entry->eax & bit(kvm_feature); +} + static __always_inline void guest_cpuid_clear(struct kvm_vcpu *vcpu, unsigned x86_feature) { int *reg; diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 4c3103f449a3..c16740a06f0c 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2139,8 +2139,10 @@ static int kvm_pv_enable_async_pf(struct kvm_vcpu *vcpu, u64 data) { gpa_t gpa = data & ~0x3f; - /* Bits 3:5 are reserved, Should be zero */ - if (data & 0x38) + /* Bits 3:5 are reserved, Should be zero. */ + if (data & 0x38 || + (data & KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT && + !guest_kvm_cpuid_has(vcpu, KVM_FEATURE_ASYNC_PF_VMEXIT))) return 1; vcpu->arch.apf.msr_val = data; -- 2.15.1

7 years, 4 months

2
3
0 0

[Linux-stable-mirror] [merged] ocfs2-try-a-blocking-lock-before-return-aop_truncated_page.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE has been removed from the -mm tree. Its filename was ocfs2-try-a-blocking-lock-before-return-aop_truncated_page.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Gang He <ghe(a)suse.com> Subject: ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE If we can't get inode lock immediately in the function ocfs2_inode_lock_with_page() when reading a page, we should not return directly here, since this will lead to a softlockup problem when the kernel is configured with CONFIG_PREEMPT is not set. The method is to get a blocking lock and immediately unlock before returning, this can avoid CPU resource waste due to lots of retries, and benefits fairness in getting lock among multiple nodes, increase efficiency in case modifying the same file frequently from multiple nodes. The softlockup crash (when set /proc/sys/kernel/softlockup_panic to 1) looks like: Kernel panic - not syncing: softlockup: hung tasks CPU: 0 PID: 885 Comm: multi_mmap Tainted: G L 4.12.14-6.1-default #1 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <IRQ> dump_stack+0x5c/0x82 panic+0xd5/0x21e watchdog_timer_fn+0x208/0x210 ? watchdog_park_threads+0x70/0x70 __hrtimer_run_queues+0xcc/0x200 hrtimer_interrupt+0xa6/0x1f0 smp_apic_timer_interrupt+0x34/0x50 apic_timer_interrupt+0x96/0xa0 </IRQ> RIP: 0010:unlock_page+0x17/0x30 RSP: 0000:ffffaf154080bc88 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10 RAX: dead000000000100 RBX: fffff21e009f5300 RCX: 0000000000000004 RDX: dead0000000000ff RSI: 0000000000000202 RDI: fffff21e009f5300 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffaf154080bb00 R10: ffffaf154080bc30 R11: 0000000000000040 R12: ffff993749a39518 R13: 0000000000000000 R14: fffff21e009f5300 R15: fffff21e009f5300 ocfs2_inode_lock_with_page+0x25/0x30 [ocfs2] ocfs2_readpage+0x41/0x2d0 [ocfs2] ? pagecache_get_page+0x30/0x200 filemap_fault+0x12b/0x5c0 ? recalc_sigpending+0x17/0x50 ? __set_task_blocked+0x28/0x70 ? __set_current_blocked+0x3d/0x60 ocfs2_fault+0x29/0xb0 [ocfs2] __do_fault+0x1a/0xa0 __handle_mm_fault+0xbe8/0x1090 handle_mm_fault+0xaa/0x1f0 __do_page_fault+0x235/0x4b0 trace_do_page_fault+0x3c/0x110 async_page_fault+0x28/0x30 RIP: 0033:0x7fa75ded638e RSP: 002b:00007ffd6657db18 EFLAGS: 00010287 RAX: 000055c7662fb700 RBX: 0000000000000001 RCX: 000055c7662fb700 RDX: 0000000000001770 RSI: 00007fa75e909000 RDI: 000055c7662fb700 RBP: 0000000000000003 R08: 000000000000000e R09: 0000000000000000 R10: 0000000000000483 R11: 00007fa75ded61b0 R12: 00007fa75e90a770 R13: 000000000000000e R14: 0000000000001770 R15: 0000000000000000 About performance improvement, we can see the testing time is reduced, and CPU utilization decreases, the detailed data is as follows. I ran multi_mmap test case in ocfs2-test package in a three nodes cluster. Before applying this patch: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2754 ocfs2te+ 20 0 170248 6980 4856 D 80.73 0.341 0:18.71 multi_mmap 1505 root rt 0 222236 123060 97224 S 2.658 6.015 0:01.44 corosync 5 root 20 0 0 0 0 S 1.329 0.000 0:00.19 kworker/u8:0 95 root 20 0 0 0 0 S 1.329 0.000 0:00.25 kworker/u8:1 2728 root 20 0 0 0 0 S 0.997 0.000 0:00.24 jbd2/sda1-33 2721 root 20 0 0 0 0 S 0.664 0.000 0:00.07 ocfs2dc-3C8CFD4 2750 ocfs2te+ 20 0 142976 4652 3532 S 0.664 0.227 0:00.28 mpirun ocfs2test@tb-node2:~>multiple_run.sh -i ens3 -k ~/linux-4.4.21-69.tar.gz -o ~/ocfs2mullog -C hacluster -s pcmk -n tb-node2,tb-node1,tb-node3 -d /dev/sda1 -b 4096 -c 32768 -t multi_mmap /mnt/shared Tests with "-b 4096 -C 32768" Thu Dec 28 14:44:52 CST 2017 multi_mmap..................................................Passed. Runtime 783 seconds. After apply this patch: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2508 ocfs2te+ 20 0 170248 6804 4680 R 54.00 0.333 0:55.37 multi_mmap 155 root 20 0 0 0 0 S 2.667 0.000 0:01.20 kworker/u8:3 95 root 20 0 0 0 0 S 2.000 0.000 0:01.58 kworker/u8:1 2504 ocfs2te+ 20 0 142976 4604 3480 R 1.667 0.225 0:01.65 mpirun 5 root 20 0 0 0 0 S 1.000 0.000 0:01.36 kworker/u8:0 2482 root 20 0 0 0 0 S 1.000 0.000 0:00.86 jbd2/sda1-33 299 root 0 -20 0 0 0 S 0.333 0.000 0:00.13 kworker/2:1H 335 root 0 -20 0 0 0 S 0.333 0.000 0:00.17 kworker/1:1H 535 root 20 0 12140 7268 1456 S 0.333 0.355 0:00.34 haveged 1282 root rt 0 222284 123108 97224 S 0.333 6.017 0:01.33 corosync ocfs2test@tb-node2:~>multiple_run.sh -i ens3 -k ~/linux-4.4.21-69.tar.gz -o ~/ocfs2mullog -C hacluster -s pcmk -n tb-node2,tb-node1,tb-node3 -d /dev/sda1 -b 4096 -c 32768 -t multi_mmap /mnt/shared Tests with "-b 4096 -C 32768" Thu Dec 28 15:04:12 CST 2017 multi_mmap..................................................Passed. Runtime 487 seconds. Link: http://lkml.kernel.org/r/1514447305-30814-1-git-send-email-ghe@suse.com Fixes: 1cce4df04f37 ("ocfs2: do not lock/unlock() inode DLM lock") Signed-off-by: Gang He <ghe(a)suse.com> Reviewed-by: Eric Ren <zren(a)suse.com> Acked-by: alex chen <alex.chen(a)huawei.com> Acked-by: piaojun <piaojun(a)huawei.com> Cc: Mark Fasheh <mfasheh(a)versity.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Joseph Qi <jiangqi903(a)gmail.com> Cc: Changwei Ge <ge.changwei(a)h3c.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/dlmglue.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff -puN fs/ocfs2/dlmglue.c~ocfs2-try-a-blocking-lock-before-return-aop_truncated_page fs/ocfs2/dlmglue.c --- a/fs/ocfs2/dlmglue.c~ocfs2-try-a-blocking-lock-before-return-aop_truncated_page +++ a/fs/ocfs2/dlmglue.c @@ -2486,6 +2486,15 @@ int ocfs2_inode_lock_with_page(struct in ret = ocfs2_inode_lock_full(inode, ret_bh, ex, OCFS2_LOCK_NONBLOCK); if (ret == -EAGAIN) { unlock_page(page); + /* + * If we can't get inode lock immediately, we should not return + * directly here, since this will lead to a softlockup problem. + * The method is to get a blocking lock and immediately unlock + * before returning, this can avoid CPU resource waste due to + * lots of retries, and benefits fairness in getting lock. + */ + if (ocfs2_inode_lock(inode, ret_bh, ex) == 0) + ocfs2_inode_unlock(inode, ex); ret = AOP_TRUNCATED_PAGE; } _ Patches currently in -mm which might be from ghe(a)suse.com are ocfs2-get-rid-of-ocfs2_is_o2cb_active-function.patch ocfs2-move-some-definitions-to-header-file.patch ocfs2-fix-some-small-problems.patch ocfs2-add-kobject-for-online-file-check.patch ocfs2-add-duplicative-ino-number-check.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] [PATCH v2 1/2] drm/i915/bxt, glk: Increase PCODE timeouts during CDCLK freq changing

by Imre Deak

Currently we see sporadic timeouts during CDCLK changing both on BXT and GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by changing the frequency in a tight loop after blanking the display. The upper bound for the completion time is 800us based on my tests, so increase it from the current 500us to 2ms; with that I couldn't trigger the problem either on BXT or GLK. Note that timeouts happened during both the change notification and the voltage level setting PCODE request. (For the latter one BSpec doesn't require us to wait for completion before further HW programming.) This issue is similar to 2c7d0602c815 ("drm/i915/gen9: Fix PCODE polling during CDCLK change notification") but there the PCODE request does complete (as shown by the mbox busy flag), only the reply we get from PCODE indicates a failure. So there we keep resending the request until a success reply, here we just have to increase the timeout for the one PCODE request we send. v2: - s/snb_pcode_request/sandybridge_pcode_write_timeout/ (Ville) Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> # v4.4+ Acked-by: Chris Wilson <chris(a)chris-wilson.co.uk> (v1) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326 Signed-off-by: Imre Deak <imre.deak(a)intel.com> --- drivers/gpu/drm/i915/i915_drv.h | 6 +++++- drivers/gpu/drm/i915/intel_cdclk.c | 22 +++++++++++++++++----- drivers/gpu/drm/i915/intel_pm.c | 6 +++--- 3 files changed, 25 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 454d8f937fae..7e83d0d3e632 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -3723,7 +3723,11 @@ extern void intel_display_print_error_state(struct drm_i915_error_state_buf *e, struct intel_display_error_state *error); int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32 *val); -int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox, u32 val); +int sandybridge_pcode_write_timeout(struct drm_i915_private *dev_priv, u32 mbox, + u32 val, int timeout_us); +#define sandybridge_pcode_write(dev_priv, mbox, val) \ + sandybridge_pcode_write_timeout(dev_priv, mbox, val, 500) + int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32 request, u32 reply_mask, u32 reply, int timeout_base_ms); diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c index c4392ea34a3d..a423b674fcec 100644 --- a/drivers/gpu/drm/i915/intel_cdclk.c +++ b/drivers/gpu/drm/i915/intel_cdclk.c @@ -1370,10 +1370,15 @@ static void bxt_set_cdclk(struct drm_i915_private *dev_priv, break; } - /* Inform power controller of upcoming frequency change */ + /* + * Inform power controller of upcoming frequency change. BSpec + * requires us to wait up to 150usec, but that leads to timeouts; + * the 2ms used here is based on experiment. + */ mutex_lock(&dev_priv->pcu_lock); - ret = sandybridge_pcode_write(dev_priv, HSW_PCODE_DE_WRITE_FREQ_REQ, - 0x80000000); + ret = sandybridge_pcode_write_timeout(dev_priv, + HSW_PCODE_DE_WRITE_FREQ_REQ, + 0x80000000, 2000); mutex_unlock(&dev_priv->pcu_lock); if (ret) { @@ -1404,8 +1409,15 @@ static void bxt_set_cdclk(struct drm_i915_private *dev_priv, I915_WRITE(CDCLK_CTL, val); mutex_lock(&dev_priv->pcu_lock); - ret = sandybridge_pcode_write(dev_priv, HSW_PCODE_DE_WRITE_FREQ_REQ, - cdclk_state->voltage_level); + /* + * The timeout isn't specified, the 2ms used here is based on + * experiment. + * FIXME: Waiting for the request completion could be delayed until + * the next PCODE request based on BSpec. + */ + ret = sandybridge_pcode_write_timeout(dev_priv, + HSW_PCODE_DE_WRITE_FREQ_REQ, + cdclk_state->voltage_level, 2000); mutex_unlock(&dev_priv->pcu_lock); if (ret) { diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 0b92ea1dbd40..a6098932be5a 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -9169,8 +9169,8 @@ int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32 *val return 0; } -int sandybridge_pcode_write(struct drm_i915_private *dev_priv, - u32 mbox, u32 val) +int sandybridge_pcode_write_timeout(struct drm_i915_private *dev_priv, + u32 mbox, u32 val, int timeout_us) { int status; @@ -9193,7 +9193,7 @@ int sandybridge_pcode_write(struct drm_i915_private *dev_priv, if (__intel_wait_for_register_fw(dev_priv, GEN6_PCODE_MAILBOX, GEN6_PCODE_READY, 0, - 500, 0, NULL)) { + timeout_us, 0, NULL)) { DRM_ERROR("timeout waiting for pcode write of 0x%08x to mbox %x to finish for %ps\n", val, mbox, __builtin_return_address(0)); return -ETIMEDOUT; -- 2.13.2

7 years, 4 months

2
1
0 0

[Linux-stable-mirror] net: cdc_ncm: initialize drvflags before usage

by Porto Rio

Hi all, we detected a problem in stable Kernel 4.4.114 in drivers/net/usb/cdc_ncm.c. In line 833, ctx->drvflags is checked in the if clause: if (ctx->drvflags & CDC_NCM_FLAG_RESET_NTB16) { but it is initialized *later* in line 877: /* Device-specific flags */ ctx->drvflags = drvflags; This initialization has to be done before the if clause. Note, that the if clause was backported from mainline at Nov. 15th 2017 (GetNtbFormat endian fix). In mainline, the initialization is at the right place before the if clause. Please find here a suggested patch: --- linux/drivers/net/usb/cdc_ncm.c.orig 2018-02-01 13:55:20.034393993 +0100 +++ linux/drivers/net/usb/cdc_ncm.c 2018-02-01 13:56:12.842393881 +0100 @@ -825,6 +825,9 @@ int cdc_ncm_bind_common(struct usbnet *d goto error2; } + /* Device-specific flags */ + ctx->drvflags = drvflags; + /* * Some Huawei devices have been observed to come out of reset in NDP32 mode. * Let's check if this is the case, and set the device to NDP16 mode again if @@ -873,9 +876,6 @@ int cdc_ncm_bind_common(struct usbnet *d /* finish setting up the device specific data */ cdc_ncm_setup(dev); - /* Device-specific flags */ - ctx->drvflags = drvflags; - /* Allocate the delayed NDP if needed. */ if (ctx->drvflags & CDC_NCM_FLAG_NDP_TO_END) { ctx->delayed_ndp16 = kzalloc(ctx->max_ndp_size, GFP_KERNEL);

7 years, 4 months

2
1
0 0

[Linux-stable-mirror] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

by Maarten Lankhorst

From: "Leo (Sunpeng) Li" <sunpeng.li(a)amd.com> During a non-blocking commit, it is possible to return before the commit_tail work is queued (-ERESTARTSYS, for example). Since a reference on the crtc commit object is obtained for the pending vblank event when preparing the commit, the above situation will leave us with an extra reference. Therefore, if the commit_tail worker has not consumed the event at the end of a commit, release it's reference. Changes since v1: - Also check for state->event->base.completion being set, to handle the case where stall_checks() fails in setup_crtc_commit(). Changes since v2: - Add a flag to drm_crtc_commit, to prevent dereferencing a freed event. i915 may unreference the state in a worker. Fixes: 24835e442f28 ("drm: reference count event->completion") Cc: <stable(a)vger.kernel.org> # v4.11+ Signed-off-by: Leo (Sunpeng) Li <sunpeng.li(a)amd.com> Acked-by: Harry Wentland <harry.wentland(a)amd.com> #v1 Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> --- drivers/gpu/drm/drm_atomic_helper.c | 15 +++++++++++++++ include/drm/drm_atomic.h | 9 +++++++++ 2 files changed, 24 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index ab4032167094..ae3cbfe9e01c 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1878,6 +1878,8 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, new_crtc_state->event->base.completion = &commit->flip_done; new_crtc_state->event->base.completion_release = release_crtc_commit; drm_crtc_commit_get(commit); + + commit->abort_completion = true; } for_each_oldnew_connector_in_state(state, conn, old_conn_state, new_conn_state, i) { @@ -3421,8 +3423,21 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state); void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state) { if (state->commit) { + /* + * In the event that a non-blocking commit returns + * -ERESTARTSYS before the commit_tail work is queued, we will + * have an extra reference to the commit object. Release it, if + * the event has not been consumed by the worker. + * + * state->event may be freed, so we can't directly look at + * state->event->base.completion. + */ + if (state->event && state->commit->abort_completion) + drm_crtc_commit_put(state->commit); + kfree(state->commit->event); state->commit->event = NULL; + drm_crtc_commit_put(state->commit); } diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index 1c27526c499e..cf13842a6dbd 100644 --- a/include/drm/drm_atomic.h +++ b/include/drm/drm_atomic.h @@ -134,6 +134,15 @@ struct drm_crtc_commit { * &drm_pending_vblank_event pointer to clean up private events. */ struct drm_pending_vblank_event *event; + + /** + * @abort_completion: + * + * A flag that's set after drm_atomic_helper_setup_commit takes a second + * reference for the completion of $drm_crtc_state.event. It's used by + * the free code to remove the second reference if commit fails. + */ + bool abort_completion; }; struct __drm_planes_state { -- 2.15.1

7 years, 4 months

4
8
0 0

[Linux-stable-mirror] Patch "xen-netfront: remove warning when unloading module" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xen-netfront: remove warning when unloading module to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xen-netfront-remove-warning-when-unloading-module.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Eduardo Otubo <otubo(a)redhat.com> Date: Thu, 23 Nov 2017 15:18:35 +0100 Subject: xen-netfront: remove warning when unloading module From: Eduardo Otubo <otubo(a)redhat.com> [ Upstream commit 5b5971df3bc2775107ddad164018a8a8db633b81 ] v2: * Replace busy wait with wait_event()/wake_up_all() * Cannot garantee that at the time xennet_remove is called, the xen_netback state will not be XenbusStateClosed, so added a condition for that * There's a small chance for the xen_netback state is XenbusStateUnknown by the time the xen_netfront switches to Closed, so added a condition for that. When unloading module xen_netfront from guest, dmesg would output warning messages like below: [ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use! [ 105.236839] deferring g.e. 0x903 (pfn 0x35805) This problem relies on netfront and netback being out of sync. By the time netfront revokes the g.e.'s netback didn't have enough time to free all of them, hence displaying the warnings on dmesg. The trick here is to make netfront to wait until netback frees all the g.e.'s and only then continue to cleanup for the module removal, and this is done by manipulating both device states. Signed-off-by: Eduardo Otubo <otubo(a)redhat.com> Acked-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/xen-netfront.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -85,6 +85,8 @@ struct netfront_cb { /* IRQ name is queue name with "-tx" or "-rx" appended */ #define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3) +static DECLARE_WAIT_QUEUE_HEAD(module_unload_q); + struct netfront_stats { u64 rx_packets; u64 tx_packets; @@ -2080,10 +2082,12 @@ static void netback_changed(struct xenbu break; case XenbusStateClosed: + wake_up_all(&module_unload_q); if (dev->state == XenbusStateClosed) break; /* Missed the backend's CLOSING state -- fallthrough */ case XenbusStateClosing: + wake_up_all(&module_unload_q); xenbus_frontend_closed(dev); break; } @@ -2305,6 +2309,20 @@ static int xennet_remove(struct xenbus_d dev_dbg(&dev->dev, "%s\n", dev->nodename); + if (xenbus_read_driver_state(dev->otherend) != XenbusStateClosed) { + xenbus_switch_state(dev, XenbusStateClosing); + wait_event(module_unload_q, + xenbus_read_driver_state(dev->otherend) == + XenbusStateClosing); + + xenbus_switch_state(dev, XenbusStateClosed); + wait_event(module_unload_q, + xenbus_read_driver_state(dev->otherend) == + XenbusStateClosed || + xenbus_read_driver_state(dev->otherend) == + XenbusStateUnknown); + } + xennet_disconnect_backend(info); xennet_sysfs_delif(info->netdev); Patches currently in stable-queue which might be from otubo(a)redhat.com are queue-3.18/xen-netfront-remove-warning-when-unloading-module.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: gadget: don't dereference g until after it has been null checked" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: don't dereference g until after it has been null checked to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Colin Ian King <colin.king(a)canonical.com> Date: Tue, 14 Nov 2017 16:18:28 +0000 Subject: usb: gadget: don't dereference g until after it has been null checked From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit b2fc059fa549fe6881d4c1f8d698b0f50bcd16ec ] Avoid dereferencing pointer g until after g has been sanity null checked; move the assignment of cdev much later when it is required into a more local scope. Detected by CoverityScan, CID#1222135 ("Dereference before null check") Fixes: b785ea7ce662 ("usb: gadget: composite: fix ep->maxburst initialization") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/composite.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -103,7 +103,6 @@ int config_ep_by_speed(struct usb_gadget struct usb_function *f, struct usb_ep *_ep) { - struct usb_composite_dev *cdev = get_gadget_data(g); struct usb_endpoint_descriptor *chosen_desc = NULL; struct usb_descriptor_header **speed_desc = NULL; @@ -170,8 +169,12 @@ ep_found: _ep->maxburst = comp_desc->bMaxBurst + 1; break; default: - if (comp_desc->bMaxBurst != 0) + if (comp_desc->bMaxBurst != 0) { + struct usb_composite_dev *cdev; + + cdev = get_gadget_data(g); ERROR(cdev, "ep0 bMaxBurst must be 0\n"); + } _ep->maxburst = 1; break; } Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-3.18/usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-rtl8188eu-fix-incorrect-response-to-siocgiwessid.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Larry Finger <Larry.Finger(a)lwfinger.net> Date: Sat, 25 Nov 2017 13:32:38 -0600 Subject: staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID From: Larry Finger <Larry.Finger(a)lwfinger.net> [ Upstream commit b77992d2df9e47144354d1b25328b180afa33442 ] When not associated with an AP, wifi device drivers should respond to the SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the behavior expected by dhcpcd. Currently, this driver returns an error code (-1) from the ioctl call, which causes dhcpcd to assume that the device is not a wireless interface and therefore it fails to work correctly with it thereafter. This problem was reported and tested at https://github.com/lwfinger/rtl8188eu/issues/234. Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) --- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c +++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c @@ -1396,19 +1396,13 @@ static int rtw_wx_get_essid(struct net_d if ((check_fwstate(pmlmepriv, _FW_LINKED)) || (check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE))) { len = pcur_bss->Ssid.SsidLength; - - wrqu->essid.length = len; - memcpy(extra, pcur_bss->Ssid.Ssid, len); - - wrqu->essid.flags = 1; } else { - ret = -1; - goto exit; + len = 0; + *extra = 0; } - -exit: - + wrqu->essid.length = len; + wrqu->essid.flags = 1; return ret; } Patches currently in stable-queue which might be from Larry.Finger(a)lwfinger.net are queue-3.18/staging-rtl8188eu-fix-incorrect-response-to-siocgiwessid.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-ufs-ufshcd-fix-potential-null-pointer-dereference-in-ufshcd_config_vreg.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> Date: Mon, 20 Nov 2017 08:12:29 -0600 Subject: scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> [ Upstream commit 727535903bea924c4f73abb202c4b3e85fff0ca4 ] _vreg_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _vreg_ has been null checked. This issue was detected with the help of Coccinelle. Fixes: aa4976130934 ("ufs: Add regulator enable support") Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> Reviewed-by: Subhash Jadavani <subhashj(a)codeaurora.org> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/ufs/ufshcd.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -4287,12 +4287,15 @@ static int ufshcd_config_vreg(struct dev struct ufs_vreg *vreg, bool on) { int ret = 0; - struct regulator *reg = vreg->reg; - const char *name = vreg->name; + struct regulator *reg; + const char *name; int min_uV, uA_load; BUG_ON(!vreg); + reg = vreg->reg; + name = vreg->name; + if (regulator_count_voltages(reg) > 0) { min_uV = on ? vreg->min_uV : 0; ret = regulator_set_voltage(reg, min_uV, vreg->max_uV); Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are queue-3.18/scsi-ufs-ufshcd-fix-potential-null-pointer-dereference-in-ufshcd_config_vreg.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "quota: Check for register_shrinker() failure." has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled quota: Check for register_shrinker() failure. to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: quota-check-for-register_shrinker-failure.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Date: Wed, 29 Nov 2017 22:34:50 +0900 Subject: quota: Check for register_shrinker() failure. From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> [ Upstream commit 88bc0ede8d35edc969350852894dc864a2dc1859 ] register_shrinker() might return -ENOMEM error since Linux 3.12. Call panic() as with other failure checks in this function if register_shrinker() failed. Fixes: 1d3d4437eae1 ("vmscan: per-node deferred work") Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Cc: Jan Kara <jack(a)suse.com> Cc: Michal Hocko <mhocko(a)suse.com> Reviewed-by: Michal Hocko <mhocko(a)suse.com> Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/quota/dquot.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/quota/dquot.c +++ b/fs/quota/dquot.c @@ -2730,7 +2730,8 @@ static int __init dquot_init(void) printk("Dquot-cache hash table entries: %ld (order %ld, %ld bytes)\n", nr_hash, order, (PAGE_SIZE << order)); - register_shrinker(&dqcache_shrinker); + if (register_shrinker(&dqcache_shrinker)) + panic("Cannot register dquot shrinker"); return 0; } Patches currently in stable-queue which might be from penguin-kernel(a)I-love.SAKURA.ne.jp are queue-3.18/quota-check-for-register_shrinker-failure.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0)" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0) to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Trond Myklebust <trond.myklebust(a)primarydata.com> Date: Fri, 3 Nov 2017 08:00:12 -0400 Subject: nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0) From: Trond Myklebust <trond.myklebust(a)primarydata.com> [ Upstream commit fb500a7cfee7f2f447d2bbf30cb59629feab6ac1 ] Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfs4state.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -62,6 +62,9 @@ static const stateid_t zero_stateid = { static const stateid_t currentstateid = { .si_generation = 1, }; +static const stateid_t close_stateid = { + .si_generation = 0xffffffffU, +}; static u64 current_sessionid = 1; @@ -4901,6 +4904,11 @@ nfsd4_close(struct svc_rqst *rqstp, stru nfsd4_close_open_stateid(stp); + /* See RFC5661 sectionm 18.2.4 */ + if (stp->st_stid.sc_client->cl_minorversion) + memcpy(&close->cl_stateid, &close_stateid, + sizeof(close->cl_stateid)); + /* put reference from nfs4_preprocess_seqid_op */ nfs4_put_stid(&stp->st_stid); out: Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are queue-3.18/nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "nfsd: check for use of the closed special stateid" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nfsd: check for use of the closed special stateid to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsd-check-for-use-of-the-closed-special-stateid.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Andrew Elble <aweits(a)rit.edu> Date: Thu, 9 Nov 2017 13:41:10 -0500 Subject: nfsd: check for use of the closed special stateid From: Andrew Elble <aweits(a)rit.edu> [ Upstream commit ae254dac721d44c0bfebe2795df87459e2e88219 ] Prevent the use of the closed (invalid) special stateid by clients. Signed-off-by: Andrew Elble <aweits(a)rit.edu> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfs4state.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -71,6 +71,7 @@ static u64 current_sessionid = 1; #define ZERO_STATEID(stateid) (!memcmp((stateid), &zero_stateid, sizeof(stateid_t))) #define ONE_STATEID(stateid) (!memcmp((stateid), &one_stateid, sizeof(stateid_t))) #define CURRENT_STATEID(stateid) (!memcmp((stateid), &currentstateid, sizeof(stateid_t))) +#define CLOSE_STATEID(stateid) (!memcmp((stateid), &close_stateid, sizeof(stateid_t))) /* forward declarations */ static bool check_for_locks(struct nfs4_file *fp, struct nfs4_lockowner *lowner); @@ -4414,7 +4415,8 @@ static __be32 nfsd4_validate_stateid(str struct nfs4_stid *s; __be32 status = nfserr_bad_stateid; - if (ZERO_STATEID(stateid) || ONE_STATEID(stateid)) + if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) || + CLOSE_STATEID(stateid)) return status; /* Client debugging aid. */ if (!same_clid(&stateid->si_opaque.so_clid, &cl->cl_clientid)) { @@ -4472,7 +4474,8 @@ nfsd4_lookup_stateid(struct nfsd4_compou else if (typemask & NFS4_DELEG_STID) typemask |= NFS4_REVOKED_DELEG_STID; - if (ZERO_STATEID(stateid) || ONE_STATEID(stateid)) + if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) || + CLOSE_STATEID(stateid)) return nfserr_bad_stateid; status = lookup_clientid(&stateid->si_opaque.so_clid, cstate, nn); if (status == nfserr_stale_clientid) { Patches currently in stable-queue which might be from aweits(a)rit.edu are queue-3.18/nfsd-check-for-use-of-the-closed-special-stateid.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-ethernet-xilinx-mark-xilinx_ll_temac-broken-on-64-bit.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Wed, 29 Nov 2017 11:01:09 +0100 Subject: net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 15bfe05c8d6386f1a90e9340d15336e85e32aad6 ] On 64-bit (e.g. powerpc64/allmodconfig): drivers/net/ethernet/xilinx/ll_temac_main.c: In function 'temac_start_xmit_done': drivers/net/ethernet/xilinx/ll_temac_main.c:633:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dev_kfree_skb_irq((struct sk_buff *)cur_p->app4); ^ cdmac_bd.app4 is u32, so it is too small to hold a kernel pointer. Note that several other fields in struct cdmac_bd are also too small to hold physical addresses on 64-bit platforms. Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/xilinx/Kconfig | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/ethernet/xilinx/Kconfig +++ b/drivers/net/ethernet/xilinx/Kconfig @@ -36,6 +36,7 @@ config XILINX_AXI_EMAC config XILINX_LL_TEMAC tristate "Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver" depends on (PPC || MICROBLAZE) + depends on !64BIT || BROKEN select PHYLIB ---help--- This driver supports the Xilinx 10/100/1000 LocalLink TEMAC Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-3.18/net-ethernet-xilinx-mark-xilinx_ll_temac-broken-on-64-bit.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "media: usbtv: add a new usbid" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: usbtv: add a new usbid to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-usbtv-add-a-new-usbid.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Icenowy Zheng <icenowy(a)aosc.io> Date: Sun, 16 Apr 2017 02:51:16 -0400 Subject: media: usbtv: add a new usbid From: Icenowy Zheng <icenowy(a)aosc.io> [ Upstream commit 04226916d2360f56d57ad00bc48d2d1854d1e0b0 ] A new usbid of UTV007 is found in a newly bought device. The usbid is 1f71:3301. The ID on the chip is: UTV007 A89029.1 1520L18K1 Both video and audio is tested with the modified usbtv driver. Signed-off-by: Icenowy Zheng <icenowy(a)aosc.io> Acked-by: Lubomir Rintel <lkundrak(a)v3.sk> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/usb/usbtv/usbtv-core.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/media/usb/usbtv/usbtv-core.c +++ b/drivers/media/usb/usbtv/usbtv-core.c @@ -127,6 +127,7 @@ static void usbtv_disconnect(struct usb_ static struct usb_device_id usbtv_id_table[] = { { USB_DEVICE(0x1b71, 0x3002) }, + { USB_DEVICE(0x1f71, 0x3301) }, {} }; MODULE_DEVICE_TABLE(usb, usbtv_id_table); Patches currently in stable-queue which might be from icenowy(a)aosc.io are queue-3.18/media-usbtv-add-a-new-usbid.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "mac80211: fix the update of path metric for RANN frame" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: fix the update of path metric for RANN frame to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mac80211-fix-the-update-of-path-metric-for-rann-frame.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Chun-Yeow Yeoh <yeohchunyeow(a)gmail.com> Date: Tue, 14 Nov 2017 23:20:05 +0800 Subject: mac80211: fix the update of path metric for RANN frame From: Chun-Yeow Yeoh <yeohchunyeow(a)gmail.com> [ Upstream commit fbbdad5edf0bb59786a51b94a9d006bc8c2da9a2 ] The previous path metric update from RANN frame has not considered the own link metric toward the transmitting mesh STA. Fix this. Reported-by: Michael65535 Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow(a)gmail.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/mesh_hwmp.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) --- a/net/mac80211/mesh_hwmp.c +++ b/net/mac80211/mesh_hwmp.c @@ -763,7 +763,7 @@ static void hwmp_rann_frame_process(stru struct mesh_path *mpath; u8 ttl, flags, hopcount; const u8 *orig_addr; - u32 orig_sn, metric, metric_txsta, interval; + u32 orig_sn, new_metric, orig_metric, last_hop_metric, interval; bool root_is_gate; ttl = rann->rann_ttl; @@ -774,7 +774,7 @@ static void hwmp_rann_frame_process(stru interval = le32_to_cpu(rann->rann_interval); hopcount = rann->rann_hopcount; hopcount++; - metric = le32_to_cpu(rann->rann_metric); + orig_metric = le32_to_cpu(rann->rann_metric); /* Ignore our own RANNs */ if (ether_addr_equal(orig_addr, sdata->vif.addr)) @@ -791,7 +791,10 @@ static void hwmp_rann_frame_process(stru return; } - metric_txsta = airtime_link_metric_get(local, sta); + last_hop_metric = airtime_link_metric_get(local, sta); + new_metric = orig_metric + last_hop_metric; + if (new_metric < orig_metric) + new_metric = MAX_METRIC; mpath = mesh_path_lookup(sdata, orig_addr); if (!mpath) { @@ -804,7 +807,7 @@ static void hwmp_rann_frame_process(stru } if (!(SN_LT(mpath->sn, orig_sn)) && - !(mpath->sn == orig_sn && metric < mpath->rann_metric)) { + !(mpath->sn == orig_sn && new_metric < mpath->rann_metric)) { rcu_read_unlock(); return; } @@ -822,7 +825,7 @@ static void hwmp_rann_frame_process(stru } mpath->sn = orig_sn; - mpath->rann_metric = metric + metric_txsta; + mpath->rann_metric = new_metric; mpath->is_root = true; /* Recording RANNs sender address to send individually * addressed PREQs destined for root mesh STA */ @@ -842,7 +845,7 @@ static void hwmp_rann_frame_process(stru mesh_path_sel_frame_tx(MPATH_RANN, flags, orig_addr, orig_sn, 0, NULL, 0, broadcast_addr, hopcount, ttl, interval, - metric + metric_txsta, 0, sdata); + new_metric, 0, sdata); } rcu_read_unlock(); Patches currently in stable-queue which might be from yeohchunyeow(a)gmail.com are queue-3.18/mac80211-fix-the-update-of-path-metric-for-rann-frame.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: X86: Fix operand/address-size during instruction decoding" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: X86: Fix operand/address-size during instruction decoding to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-fix-operand-address-size-during-instruction-decoding.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Wanpeng Li <wanpeng.li(a)hotmail.com> Date: Sun, 5 Nov 2017 16:54:47 -0800 Subject: KVM: X86: Fix operand/address-size during instruction decoding From: Wanpeng Li <wanpeng.li(a)hotmail.com> [ Upstream commit 3853be2603191829b442b64dac6ae8ba0c027bf9 ] Pedro reported: During tests that we conducted on KVM, we noticed that executing a "PUSH %ES" instruction under KVM produces different results on both memory and the SP register depending on whether EPT support is enabled. With EPT the SP is reduced by 4 bytes (and the written value is 0-padded) but without EPT support it is only reduced by 2 bytes. The difference can be observed when the CS.DB field is 1 (32-bit) but not when it's 0 (16-bit). The internal segment descriptor cache exist even in real/vm8096 mode. The CS.D also should be respected instead of just default operand/address-size/66H prefix/67H prefix during instruction decoding. This patch fixes it by also adjusting operand/address-size according to CS.D. Reported-by: Pedro Fonseca <pfonseca(a)cs.washington.edu> Tested-by: Pedro Fonseca <pfonseca(a)cs.washington.edu> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: Pedro Fonseca <pfonseca(a)cs.washington.edu> Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Reviewed-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/emulate.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -4385,6 +4385,8 @@ int x86_decode_insn(struct x86_emulate_c bool op_prefix = false; bool has_seg_override = false; struct opcode opcode; + u16 dummy; + struct desc_struct desc; ctxt->memop.type = OP_NONE; ctxt->memopp = NULL; @@ -4403,6 +4405,11 @@ int x86_decode_insn(struct x86_emulate_c switch (mode) { case X86EMUL_MODE_REAL: case X86EMUL_MODE_VM86: + def_op_bytes = def_ad_bytes = 2; + ctxt->ops->get_segment(ctxt, &dummy, &desc, NULL, VCPU_SREG_CS); + if (desc.d) + def_op_bytes = def_ad_bytes = 4; + break; case X86EMUL_MODE_PROT16: def_op_bytes = def_ad_bytes = 2; break; Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are queue-3.18/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-3.18/kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch queue-3.18/kvm-x86-fix-operand-address-size-during-instruction-decoding.patch queue-3.18/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Liran Alon <liran.alon(a)oracle.com> Date: Sun, 5 Nov 2017 16:56:33 +0200 Subject: KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure From: Liran Alon <liran.alon(a)oracle.com> [ Upstream commit 1f4dcb3b213235e642088709a1c54964d23365e9 ] On this case, handle_emulation_failure() fills kvm_run with internal-error information which it expects to be delivered to user-mode for further processing. However, the code reports a wrong return-value which makes KVM to never return to user-mode on this scenario. Fixes: 6d77dbfc88e3 ("KVM: inject #UD if instruction emulation fails and exit to userspace") Signed-off-by: Liran Alon <liran.alon(a)oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/x86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -5109,7 +5109,7 @@ static int handle_emulation_failure(stru vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR; vcpu->run->internal.suberror = KVM_INTERNAL_ERROR_EMULATION; vcpu->run->internal.ndata = 0; - r = EMULATE_FAIL; + r = EMULATE_USER_EXIT; } kvm_queue_exception(vcpu, UD_VECTOR); Patches currently in stable-queue which might be from liran.alon(a)oracle.com are queue-3.18/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-3.18/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: Don't re-execute instruction when not passing CR2 value" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: Don't re-execute instruction when not passing CR2 value to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Liran Alon <liran.alon(a)oracle.com> Date: Sun, 5 Nov 2017 16:56:34 +0200 Subject: KVM: x86: Don't re-execute instruction when not passing CR2 value From: Liran Alon <liran.alon(a)oracle.com> [ Upstream commit 9b8ae63798cb97e785a667ff27e43fa6220cb734 ] In case of instruction-decode failure or emulation failure, x86_emulate_instruction() will call reexecute_instruction() which will attempt to use the cr2 value passed to x86_emulate_instruction(). However, when x86_emulate_instruction() is called from emulate_instruction(), cr2 is not passed (passed as 0) and therefore it doesn't make sense to execute reexecute_instruction() logic at all. Fixes: 51d8b66199e9 ("KVM: cleanup emulate_instruction") Signed-off-by: Liran Alon <liran.alon(a)oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/kvm_host.h | 3 ++- arch/x86/kvm/vmx.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -849,7 +849,8 @@ int x86_emulate_instruction(struct kvm_v static inline int emulate_instruction(struct kvm_vcpu *vcpu, int emulation_type) { - return x86_emulate_instruction(vcpu, 0, emulation_type, NULL, 0); + return x86_emulate_instruction(vcpu, 0, + emulation_type | EMULTYPE_NO_REEXECUTE, NULL, 0); } void kvm_enable_efer_bits(u64); --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -5707,7 +5707,7 @@ static int handle_invalid_guest_state(st if (test_bit(KVM_REQ_EVENT, &vcpu->requests)) return 1; - err = emulate_instruction(vcpu, EMULTYPE_NO_REEXECUTE); + err = emulate_instruction(vcpu, 0); if (err == EMULATE_USER_EXIT) { ++vcpu->stat.mmio_exits; Patches currently in stable-queue which might be from liran.alon(a)oracle.com are queue-3.18/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-3.18/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: VMX: Fix rflags cache during vCPU reset" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: VMX: Fix rflags cache during vCPU reset to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Wanpeng Li <wanpeng.li(a)hotmail.com> Date: Mon, 20 Nov 2017 14:52:21 -0800 Subject: KVM: VMX: Fix rflags cache during vCPU reset From: Wanpeng Li <wanpeng.li(a)hotmail.com> [ Upstream commit c37c28730bb031cc8a44a130c2555c0f3efbe2d0 ] Reported by syzkaller: *** Guest State *** CR0: actual=0x0000000080010031, shadow=0x0000000060000010, gh_mask=fffffffffffffff7 CR4: actual=0x0000000000002061, shadow=0x0000000000000000, gh_mask=ffffffffffffe8f1 CR3 = 0x000000002081e000 RSP = 0x000000000000fffa RIP = 0x0000000000000000 RFLAGS=0x00023000 DR7 = 0x00000000000000 ^^^^^^^^^^ ------------[ cut here ]------------ WARNING: CPU: 6 PID: 24431 at /home/kernel/linux/arch/x86/kvm//x86.c:7302 kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm] CPU: 6 PID: 24431 Comm: reprotest Tainted: G W OE 4.14.0+ #26 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm] RSP: 0018:ffff880291d179e0 EFLAGS: 00010202 Call Trace: kvm_vcpu_ioctl+0x479/0x880 [kvm] do_vfs_ioctl+0x142/0x9a0 SyS_ioctl+0x74/0x80 entry_SYSCALL_64_fastpath+0x23/0x9a The failed vmentry is triggered by the following beautified testcase: #include <unistd.h> #include <sys/syscall.h> #include <string.h> #include <stdint.h> #include <linux/kvm.h> #include <fcntl.h> #include <sys/ioctl.h> long r[5]; int main() { struct kvm_debugregs dr = { 0 }; r[2] = open("/dev/kvm", O_RDONLY); r[3] = ioctl(r[2], KVM_CREATE_VM, 0); r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7); struct kvm_guest_debug debug = { .control = 0xf0403, .arch = { .debugreg[6] = 0x2, .debugreg[7] = 0x2 } }; ioctl(r[4], KVM_SET_GUEST_DEBUG, &debug); ioctl(r[4], KVM_RUN, 0); } which testcase tries to setup the processor specific debug registers and configure vCPU for handling guest debug events through KVM_SET_GUEST_DEBUG. The KVM_SET_GUEST_DEBUG ioctl will get and set rflags in order to set TF bit if single step is needed. All regs' caches are reset to avail and GUEST_RFLAGS vmcs field is reset to 0x2 during vCPU reset. However, the cache of rflags is not reset during vCPU reset. The function vmx_get_rflags() returns an unreset rflags cache value since the cache is marked avail, it is 0 after boot. Vmentry fails if the rflags reserved bit 1 is 0. This patch fixes it by resetting both the GUEST_RFLAGS vmcs field and its cache to 0x2 during vCPU reset. Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Tested-by: Dmitry Vyukov <dvyukov(a)google.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/vmx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -4569,7 +4569,7 @@ static void vmx_vcpu_reset(struct kvm_vc vmcs_writel(GUEST_SYSENTER_ESP, 0); vmcs_writel(GUEST_SYSENTER_EIP, 0); - vmcs_writel(GUEST_RFLAGS, 0x02); + kvm_set_rflags(vcpu, X86_EFLAGS_FIXED); kvm_rip_write(vcpu, 0xfff0); vmcs_writel(GUEST_GDTR_BASE, 0); Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are queue-3.18/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-3.18/kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch queue-3.18/kvm-x86-fix-operand-address-size-during-instruction-decoding.patch queue-3.18/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "hwmon: (pmbus) Use 64bit math for DIRECT format values" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hwmon: (pmbus) Use 64bit math for DIRECT format values to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hwmon-pmbus-use-64bit-math-for-direct-format-values.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Robert Lippert <roblip(a)gmail.com> Date: Mon, 27 Nov 2017 15:51:55 -0800 Subject: hwmon: (pmbus) Use 64bit math for DIRECT format values From: Robert Lippert <roblip(a)gmail.com> [ Upstream commit bd467e4eababe4c04272c1e646f066db02734c79 ] Power values in the 100s of watt range can easily blow past 32bit math limits when processing everything in microwatts. Use 64bit math instead to avoid these issues on common 32bit ARM BMC platforms. Fixes: 442aba78728e ("hwmon: PMBus device driver") Signed-off-by: Robert Lippert <rlippert(a)google.com> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwmon/pmbus/pmbus_core.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) --- a/drivers/hwmon/pmbus/pmbus_core.c +++ b/drivers/hwmon/pmbus/pmbus_core.c @@ -20,6 +20,7 @@ */ #include <linux/kernel.h> +#include <linux/math64.h> #include <linux/module.h> #include <linux/init.h> #include <linux/err.h> @@ -443,8 +444,8 @@ static long pmbus_reg2data_linear(struct static long pmbus_reg2data_direct(struct pmbus_data *data, struct pmbus_sensor *sensor) { - long val = (s16) sensor->data; - long m, b, R; + s64 b, val = (s16)sensor->data; + s32 m, R; m = data->info->m[sensor->class]; b = data->info->b[sensor->class]; @@ -472,11 +473,12 @@ static long pmbus_reg2data_direct(struct R--; } while (R < 0) { - val = DIV_ROUND_CLOSEST(val, 10); + val = div_s64(val + 5LL, 10L); /* round closest */ R++; } - return (val - b) / m; + val = div_s64(val - b, m); + return clamp_val(val, LONG_MIN, LONG_MAX); } /* @@ -588,7 +590,8 @@ static u16 pmbus_data2reg_linear(struct static u16 pmbus_data2reg_direct(struct pmbus_data *data, struct pmbus_sensor *sensor, long val) { - long m, b, R; + s64 b, val64 = val; + s32 m, R; m = data->info->m[sensor->class]; b = data->info->b[sensor->class]; @@ -605,18 +608,18 @@ static u16 pmbus_data2reg_direct(struct R -= 3; /* Adjust R and b for data in milli-units */ b *= 1000; } - val = val * m + b; + val64 = val64 * m + b; while (R > 0) { - val *= 10; + val64 *= 10; R--; } while (R < 0) { - val = DIV_ROUND_CLOSEST(val, 10); + val64 = div_s64(val64 + 5LL, 10L); /* round closest */ R++; } - return val; + return (u16)clamp_val(val64, S16_MIN, S16_MAX); } static u16 pmbus_data2reg_vid(struct pmbus_data *data, Patches currently in stable-queue which might be from roblip(a)gmail.com are queue-3.18/hwmon-pmbus-use-64bit-math-for-direct-format-values.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "bcache: check return value of register_shrinker" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bcache: check return value of register_shrinker to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bcache-check-return-value-of-register_shrinker.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:48:12 CET 2018 From: Michael Lyle <mlyle(a)lyle.org> Date: Fri, 24 Nov 2017 15:14:27 -0800 Subject: bcache: check return value of register_shrinker From: Michael Lyle <mlyle(a)lyle.org> [ Upstream commit 6c4ca1e36cdc1a0a7a84797804b87920ccbebf51 ] register_shrinker is now __must_check, so check it to kill a warning. Caller of bch_btree_cache_alloc in super.c appropriately checks return value so this is fully plumbed through. This V2 fixes checkpatch warnings and improves the commit description, as I was too hasty getting the previous version out. Signed-off-by: Michael Lyle <mlyle(a)lyle.org> Reviewed-by: Vojtech Pavlik <vojtech(a)suse.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/bcache/btree.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/md/bcache/btree.c +++ b/drivers/md/bcache/btree.c @@ -808,7 +808,10 @@ int bch_btree_cache_alloc(struct cache_s c->shrink.scan_objects = bch_mca_scan; c->shrink.seeks = 4; c->shrink.batch = c->btree_pages * 2; - register_shrinker(&c->shrink); + + if (register_shrinker(&c->shrink)) + pr_warn("bcache: %s: could not register shrinker", + __func__); return 0; } Patches currently in stable-queue which might be from mlyle(a)lyle.org are queue-3.18/bcache-check-return-value-of-register_shrinker.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "reiserfs: remove unneeded i_version bump" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled reiserfs: remove unneeded i_version bump to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: reiserfs-remove-unneeded-i_version-bump.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: Jeff Layton <jlayton(a)redhat.com> Date: Mon, 30 Oct 2017 11:20:15 -0400 Subject: reiserfs: remove unneeded i_version bump From: Jeff Layton <jlayton(a)redhat.com> [ Upstream commit 9f97df50c52c2887432debb6238f4e43567386a5 ] The i_version field in reiserfs is not initialized and is only ever updated here. Nothing ever views it, so just remove it. Signed-off-by: Jeff Layton <jlayton(a)redhat.com> Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/reiserfs/super.c | 1 - 1 file changed, 1 deletion(-) --- a/fs/reiserfs/super.c +++ b/fs/reiserfs/super.c @@ -2591,7 +2591,6 @@ out: return err; if (inode->i_size < off + len - towrite) i_size_write(inode, off + len - towrite); - inode->i_version++; inode->i_mtime = inode->i_ctime = current_time(inode); mark_inode_dirty(inode); return len - towrite; Patches currently in stable-queue which might be from jlayton(a)redhat.com are queue-4.14/lockd-fix-list_add-double-add-caused-by-legacy-signal-interface.patch queue-4.14/reiserfs-remove-unneeded-i_version-bump.patch

7 years, 4 months

3
2
0 0

[Linux-stable-mirror] Patch "xfs: ubsan fixes" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: ubsan fixes to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-ubsan-fixes.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: "Darrick J. Wong" <darrick.wong(a)oracle.com> Date: Mon, 27 Nov 2017 09:50:17 -0800 Subject: xfs: ubsan fixes From: "Darrick J. Wong" <darrick.wong(a)oracle.com> [ Upstream commit 22a6c83777ac7c17d6c63891beeeac24cf5da450 ] Fix some complaints from the UBSAN about signed integer addition overflows. Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Reviewed-by: Brian Foster <bfoster(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_aops.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -310,7 +310,7 @@ xfs_map_blocks( (ip->i_df.if_flags & XFS_IFEXTENTS)); ASSERT(offset <= mp->m_super->s_maxbytes); - if (offset + count > mp->m_super->s_maxbytes) + if ((xfs_ufsize_t)offset + count > mp->m_super->s_maxbytes) count = mp->m_super->s_maxbytes - offset; end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + count); offset_fsb = XFS_B_TO_FSBT(mp, offset); @@ -1360,7 +1360,7 @@ xfs_map_trim_size( if (mapping_size > size) mapping_size = size; if (offset < i_size_read(inode) && - offset + mapping_size >= i_size_read(inode)) { + (xfs_ufsize_t)offset + mapping_size >= i_size_read(inode)) { /* limit mapping to block that spans EOF */ mapping_size = roundup_64(i_size_read(inode) - offset, i_blocksize(inode)); @@ -1416,7 +1416,7 @@ __xfs_get_blocks( } ASSERT(offset <= mp->m_super->s_maxbytes); - if (offset + size > mp->m_super->s_maxbytes) + if ((xfs_ufsize_t)offset + size > mp->m_super->s_maxbytes) size = mp->m_super->s_maxbytes - offset; end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + size); offset_fsb = XFS_B_TO_FSBT(mp, offset); Patches currently in stable-queue which might be from darrick.wong(a)oracle.com are queue-4.4/xfs-ubsan-fixes.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "xen-netfront: remove warning when unloading module" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xen-netfront: remove warning when unloading module to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xen-netfront-remove-warning-when-unloading-module.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Eduardo Otubo <otubo(a)redhat.com> Date: Thu, 23 Nov 2017 15:18:35 +0100 Subject: xen-netfront: remove warning when unloading module From: Eduardo Otubo <otubo(a)redhat.com> [ Upstream commit 5b5971df3bc2775107ddad164018a8a8db633b81 ] v2: * Replace busy wait with wait_event()/wake_up_all() * Cannot garantee that at the time xennet_remove is called, the xen_netback state will not be XenbusStateClosed, so added a condition for that * There's a small chance for the xen_netback state is XenbusStateUnknown by the time the xen_netfront switches to Closed, so added a condition for that. When unloading module xen_netfront from guest, dmesg would output warning messages like below: [ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use! [ 105.236839] deferring g.e. 0x903 (pfn 0x35805) This problem relies on netfront and netback being out of sync. By the time netfront revokes the g.e.'s netback didn't have enough time to free all of them, hence displaying the warnings on dmesg. The trick here is to make netfront to wait until netback frees all the g.e.'s and only then continue to cleanup for the module removal, and this is done by manipulating both device states. Signed-off-by: Eduardo Otubo <otubo(a)redhat.com> Acked-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/xen-netfront.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -86,6 +86,8 @@ struct netfront_cb { /* IRQ name is queue name with "-tx" or "-rx" appended */ #define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3) +static DECLARE_WAIT_QUEUE_HEAD(module_unload_q); + struct netfront_stats { u64 packets; u64 bytes; @@ -2037,10 +2039,12 @@ static void netback_changed(struct xenbu break; case XenbusStateClosed: + wake_up_all(&module_unload_q); if (dev->state == XenbusStateClosed) break; /* Missed the backend's CLOSING state -- fallthrough */ case XenbusStateClosing: + wake_up_all(&module_unload_q); xenbus_frontend_closed(dev); break; } @@ -2146,6 +2150,20 @@ static int xennet_remove(struct xenbus_d dev_dbg(&dev->dev, "%s\n", dev->nodename); + if (xenbus_read_driver_state(dev->otherend) != XenbusStateClosed) { + xenbus_switch_state(dev, XenbusStateClosing); + wait_event(module_unload_q, + xenbus_read_driver_state(dev->otherend) == + XenbusStateClosing); + + xenbus_switch_state(dev, XenbusStateClosed); + wait_event(module_unload_q, + xenbus_read_driver_state(dev->otherend) == + XenbusStateClosed || + xenbus_read_driver_state(dev->otherend) == + XenbusStateUnknown); + } + xennet_disconnect_backend(info); unregister_netdev(info->netdev); Patches currently in stable-queue which might be from otubo(a)redhat.com are queue-4.4/xen-netfront-remove-warning-when-unloading-module.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: gadget: don't dereference g until after it has been null checked" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: don't dereference g until after it has been null checked to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Colin Ian King <colin.king(a)canonical.com> Date: Tue, 14 Nov 2017 16:18:28 +0000 Subject: usb: gadget: don't dereference g until after it has been null checked From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit b2fc059fa549fe6881d4c1f8d698b0f50bcd16ec ] Avoid dereferencing pointer g until after g has been sanity null checked; move the assignment of cdev much later when it is required into a more local scope. Detected by CoverityScan, CID#1222135 ("Dereference before null check") Fixes: b785ea7ce662 ("usb: gadget: composite: fix ep->maxburst initialization") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/composite.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -104,7 +104,6 @@ int config_ep_by_speed(struct usb_gadget struct usb_function *f, struct usb_ep *_ep) { - struct usb_composite_dev *cdev = get_gadget_data(g); struct usb_endpoint_descriptor *chosen_desc = NULL; struct usb_descriptor_header **speed_desc = NULL; @@ -176,8 +175,12 @@ ep_found: _ep->maxburst = comp_desc->bMaxBurst + 1; break; default: - if (comp_desc->bMaxBurst != 0) + if (comp_desc->bMaxBurst != 0) { + struct usb_composite_dev *cdev; + + cdev = get_gadget_data(g); ERROR(cdev, "ep0 bMaxBurst must be 0\n"); + } _ep->maxburst = 1; break; } Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-4.4/usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "SUNRPC: Allow connect to return EHOSTUNREACH" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled SUNRPC: Allow connect to return EHOSTUNREACH to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sunrpc-allow-connect-to-return-ehostunreach.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Trond Myklebust <trond.myklebust(a)primarydata.com> Date: Fri, 24 Nov 2017 12:00:24 -0500 Subject: SUNRPC: Allow connect to return EHOSTUNREACH From: Trond Myklebust <trond.myklebust(a)primarydata.com> [ Upstream commit 4ba161a793d5f43757c35feff258d9f20a082940 ] Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> Tested-by: Dmitry Vyukov <dvyukov(a)google.com> Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sunrpc/xprtsock.c | 1 + 1 file changed, 1 insertion(+) --- a/net/sunrpc/xprtsock.c +++ b/net/sunrpc/xprtsock.c @@ -2360,6 +2360,7 @@ static void xs_tcp_setup_socket(struct w case -ECONNREFUSED: case -ECONNRESET: case -ENETUNREACH: + case -EHOSTUNREACH: case -EADDRINUSE: case -ENOBUFS: /* retry with existing socket, after a delay */ Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are queue-4.4/nfsd-ensure-we-check-stateid-validity-in-the-seqid-operation-checks.patch queue-4.4/sunrpc-allow-connect-to-return-ehostunreach.patch queue-4.4/nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-rtl8188eu-fix-incorrect-response-to-siocgiwessid.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Larry Finger <Larry.Finger(a)lwfinger.net> Date: Sat, 25 Nov 2017 13:32:38 -0600 Subject: staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID From: Larry Finger <Larry.Finger(a)lwfinger.net> [ Upstream commit b77992d2df9e47144354d1b25328b180afa33442 ] When not associated with an AP, wifi device drivers should respond to the SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the behavior expected by dhcpcd. Currently, this driver returns an error code (-1) from the ioctl call, which causes dhcpcd to assume that the device is not a wireless interface and therefore it fails to work correctly with it thereafter. This problem was reported and tested at https://github.com/lwfinger/rtl8188eu/issues/234. Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) --- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c +++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c @@ -1399,19 +1399,13 @@ static int rtw_wx_get_essid(struct net_d if ((check_fwstate(pmlmepriv, _FW_LINKED)) || (check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE))) { len = pcur_bss->Ssid.SsidLength; - - wrqu->essid.length = len; - memcpy(extra, pcur_bss->Ssid.Ssid, len); - - wrqu->essid.flags = 1; } else { - ret = -1; - goto exit; + len = 0; + *extra = 0; } - -exit: - + wrqu->essid.length = len; + wrqu->essid.flags = 1; return ret; } Patches currently in stable-queue which might be from Larry.Finger(a)lwfinger.net are queue-4.4/staging-rtl8188eu-fix-incorrect-response-to-siocgiwessid.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-ufs-ufshcd-fix-potential-null-pointer-dereference-in-ufshcd_config_vreg.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> Date: Mon, 20 Nov 2017 08:12:29 -0600 Subject: scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> [ Upstream commit 727535903bea924c4f73abb202c4b3e85fff0ca4 ] _vreg_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _vreg_ has been null checked. This issue was detected with the help of Coccinelle. Fixes: aa4976130934 ("ufs: Add regulator enable support") Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> Reviewed-by: Subhash Jadavani <subhashj(a)codeaurora.org> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/ufs/ufshcd.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -4392,12 +4392,15 @@ static int ufshcd_config_vreg(struct dev struct ufs_vreg *vreg, bool on) { int ret = 0; - struct regulator *reg = vreg->reg; - const char *name = vreg->name; + struct regulator *reg; + const char *name; int min_uV, uA_load; BUG_ON(!vreg); + reg = vreg->reg; + name = vreg->name; + if (regulator_count_voltages(reg) > 0) { min_uV = on ? vreg->min_uV : 0; ret = regulator_set_voltage(reg, min_uV, vreg->max_uV); Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are queue-4.4/scsi-ufs-ufshcd-fix-potential-null-pointer-dereference-in-ufshcd_config_vreg.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-aacraid-prevent-crash-in-case-of-free-interrupt-during-scsi-eh-path.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 19:14:55 -0200 Subject: scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com> [ Upstream commit e4717292ddebcfe231651b5aff9fa19ca158d178 ] As part of the scsi EH path, aacraid performs a reinitialization of the adapter, which encompass freeing resources and IRQs, NULLifying lots of pointers, and then initialize it all over again. We've identified a problem during the free IRQ portion of this path if CONFIG_DEBUG_SHIRQ is enabled on kernel config file. Happens that, in case this flag was set, right after free_irq() effectively clears the interrupt, it checks if it was requested as IRQF_SHARED. In positive case, it performs another call to the IRQ handler on driver. Problem is: since aacraid currently free some resources *before* freeing the IRQ, once free_irq() path calls the handler again (due to CONFIG_DEBUG_SHIRQ), aacraid crashes due to NULL pointer dereference with the following trace: aac_src_intr_message+0xf8/0x740 [aacraid] __free_irq+0x33c/0x4a0 free_irq+0x78/0xb0 aac_free_irq+0x13c/0x150 [aacraid] aac_reset_adapter+0x2e8/0x970 [aacraid] aac_eh_reset+0x3a8/0x5d0 [aacraid] scsi_try_host_reset+0x74/0x180 scsi_eh_ready_devs+0xc70/0x1510 scsi_error_handler+0x624/0xa20 This patch prevents the crash by changing the order of the deinitialization in this path of aacraid: first we clear the IRQ, then we free other resources. No functional change intended. Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com> Reviewed-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/aacraid/commsup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/aacraid/commsup.c +++ b/drivers/scsi/aacraid/commsup.c @@ -1363,13 +1363,13 @@ static int _aac_reset_adapter(struct aac * will ensure that i/o is queisced and the card is flushed in that * case. */ + aac_free_irq(aac); aac_fib_map_free(aac); pci_free_consistent(aac->pdev, aac->comm_size, aac->comm_addr, aac->comm_phys); aac->comm_addr = NULL; aac->comm_phys = 0; kfree(aac->queues); aac->queues = NULL; - aac_free_irq(aac); kfree(aac->fsa_dev); aac->fsa_dev = NULL; quirks = aac_get_driver_ident(index)->quirks; Patches currently in stable-queue which might be from gpiccoli(a)linux.vnet.ibm.com are queue-4.4/scsi-aacraid-prevent-crash-in-case-of-free-interrupt-during-scsi-eh-path.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "quota: Check for register_shrinker() failure." has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled quota: Check for register_shrinker() failure. to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: quota-check-for-register_shrinker-failure.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Date: Wed, 29 Nov 2017 22:34:50 +0900 Subject: quota: Check for register_shrinker() failure. From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> [ Upstream commit 88bc0ede8d35edc969350852894dc864a2dc1859 ] register_shrinker() might return -ENOMEM error since Linux 3.12. Call panic() as with other failure checks in this function if register_shrinker() failed. Fixes: 1d3d4437eae1 ("vmscan: per-node deferred work") Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Cc: Jan Kara <jack(a)suse.com> Cc: Michal Hocko <mhocko(a)suse.com> Reviewed-by: Michal Hocko <mhocko(a)suse.com> Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/quota/dquot.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/quota/dquot.c +++ b/fs/quota/dquot.c @@ -2919,7 +2919,8 @@ static int __init dquot_init(void) pr_info("VFS: Dquot-cache hash table entries: %ld (order %ld," " %ld bytes)\n", nr_hash, order, (PAGE_SIZE << order)); - register_shrinker(&dqcache_shrinker); + if (register_shrinker(&dqcache_shrinker)) + panic("Cannot register dquot shrinker"); return 0; } Patches currently in stable-queue which might be from penguin-kernel(a)I-love.SAKURA.ne.jp are queue-4.4/quota-check-for-register_shrinker-failure.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "openvswitch: fix the incorrect flow action alloc size" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled openvswitch: fix the incorrect flow action alloc size to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: openvswitch-fix-the-incorrect-flow-action-alloc-size.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: zhangliping <zhangliping02(a)baidu.com> Date: Sat, 25 Nov 2017 22:02:12 +0800 Subject: openvswitch: fix the incorrect flow action alloc size From: zhangliping <zhangliping02(a)baidu.com> [ Upstream commit 67c8d22a73128ff910e2287567132530abcf5b71 ] If we want to add a datapath flow, which has more than 500 vxlan outputs' action, we will get the following error reports: openvswitch: netlink: Flow action size 32832 bytes exceeds max openvswitch: netlink: Flow action size 32832 bytes exceeds max openvswitch: netlink: Actions may not be safe on all matching packets ... ... It seems that we can simply enlarge the MAX_ACTIONS_BUFSIZE to fix it, but this is not the root cause. For example, for a vxlan output action, we need about 60 bytes for the nlattr, but after it is converted to the flow action, it only occupies 24 bytes. This means that we can still support more than 1000 vxlan output actions for a single datapath flow under the the current 32k max limitation. So even if the nla_len(attr) is larger than MAX_ACTIONS_BUFSIZE, we shouldn't report EINVAL and keep it move on, as the judgement can be done by the reserve_sfa_size. Signed-off-by: zhangliping <zhangliping02(a)baidu.com> Acked-by: Pravin B Shelar <pshelar(a)ovn.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/openvswitch/flow_netlink.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- a/net/openvswitch/flow_netlink.c +++ b/net/openvswitch/flow_netlink.c @@ -1672,14 +1672,11 @@ int ovs_nla_put_mask(const struct sw_flo #define MAX_ACTIONS_BUFSIZE (32 * 1024) -static struct sw_flow_actions *nla_alloc_flow_actions(int size, bool log) +static struct sw_flow_actions *nla_alloc_flow_actions(int size) { struct sw_flow_actions *sfa; - if (size > MAX_ACTIONS_BUFSIZE) { - OVS_NLERR(log, "Flow action size %u bytes exceeds max", size); - return ERR_PTR(-EINVAL); - } + WARN_ON_ONCE(size > MAX_ACTIONS_BUFSIZE); sfa = kmalloc(sizeof(*sfa) + size, GFP_KERNEL); if (!sfa) @@ -1752,12 +1749,15 @@ static struct nlattr *reserve_sfa_size(s new_acts_size = ksize(*sfa) * 2; if (new_acts_size > MAX_ACTIONS_BUFSIZE) { - if ((MAX_ACTIONS_BUFSIZE - next_offset) < req_size) + if ((MAX_ACTIONS_BUFSIZE - next_offset) < req_size) { + OVS_NLERR(log, "Flow action size exceeds max %u", + MAX_ACTIONS_BUFSIZE); return ERR_PTR(-EMSGSIZE); + } new_acts_size = MAX_ACTIONS_BUFSIZE; } - acts = nla_alloc_flow_actions(new_acts_size, log); + acts = nla_alloc_flow_actions(new_acts_size); if (IS_ERR(acts)) return (void *)acts; @@ -2369,7 +2369,7 @@ int ovs_nla_copy_actions(struct net *net { int err; - *sfa = nla_alloc_flow_actions(nla_len(attr), log); + *sfa = nla_alloc_flow_actions(min(nla_len(attr), MAX_ACTIONS_BUFSIZE)); if (IS_ERR(*sfa)) return PTR_ERR(*sfa); Patches currently in stable-queue which might be from zhangliping02(a)baidu.com are queue-4.4/openvswitch-fix-the-incorrect-flow-action-alloc-size.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "nfsd: Ensure we check stateid validity in the seqid operation checks" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nfsd: Ensure we check stateid validity in the seqid operation checks to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsd-ensure-we-check-stateid-validity-in-the-seqid-operation-checks.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Trond Myklebust <trond.myklebust(a)primarydata.com> Date: Fri, 3 Nov 2017 08:00:15 -0400 Subject: nfsd: Ensure we check stateid validity in the seqid operation checks From: Trond Myklebust <trond.myklebust(a)primarydata.com> [ Upstream commit 9271d7e509c1bfc0b9a418caec29ec8d1ac38270 ] After taking the stateid st_mutex, we want to know that the stateid still represents valid state before performing any non-idempotent actions. Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfs4state.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -5014,15 +5014,9 @@ static __be32 nfs4_seqid_op_checks(struc status = nfsd4_check_seqid(cstate, sop, seqid); if (status) return status; - if (stp->st_stid.sc_type == NFS4_CLOSED_STID - || stp->st_stid.sc_type == NFS4_REVOKED_DELEG_STID) - /* - * "Closed" stateid's exist *only* to return - * nfserr_replay_me from the previous step, and - * revoked delegations are kept only for free_stateid. - */ - return nfserr_bad_stateid; - mutex_lock(&stp->st_mutex); + status = nfsd4_lock_ol_stateid(stp); + if (status != nfs_ok) + return status; status = check_stateid_generation(stateid, &stp->st_stid.sc_stateid, nfsd4_has_session(cstate)); if (status == nfs_ok) status = nfs4_check_fh(current_fh, &stp->st_stid); Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are queue-4.4/nfsd-ensure-we-check-stateid-validity-in-the-seqid-operation-checks.patch queue-4.4/sunrpc-allow-connect-to-return-ehostunreach.patch queue-4.4/nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0)" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0) to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Trond Myklebust <trond.myklebust(a)primarydata.com> Date: Fri, 3 Nov 2017 08:00:12 -0400 Subject: nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0) From: Trond Myklebust <trond.myklebust(a)primarydata.com> [ Upstream commit fb500a7cfee7f2f447d2bbf30cb59629feab6ac1 ] Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfs4state.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -63,6 +63,9 @@ static const stateid_t zero_stateid = { static const stateid_t currentstateid = { .si_generation = 1, }; +static const stateid_t close_stateid = { + .si_generation = 0xffffffffU, +}; static u64 current_sessionid = 1; @@ -5243,6 +5246,11 @@ nfsd4_close(struct svc_rqst *rqstp, stru nfsd4_close_open_stateid(stp); mutex_unlock(&stp->st_mutex); + /* See RFC5661 sectionm 18.2.4 */ + if (stp->st_stid.sc_client->cl_minorversion) + memcpy(&close->cl_stateid, &close_stateid, + sizeof(close->cl_stateid)); + /* put reference from nfs4_preprocess_seqid_op */ nfs4_put_stid(&stp->st_stid); out: Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are queue-4.4/nfsd-ensure-we-check-stateid-validity-in-the-seqid-operation-checks.patch queue-4.4/sunrpc-allow-connect-to-return-ehostunreach.patch queue-4.4/nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "nfsd: check for use of the closed special stateid" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nfsd: check for use of the closed special stateid to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsd-check-for-use-of-the-closed-special-stateid.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Andrew Elble <aweits(a)rit.edu> Date: Thu, 9 Nov 2017 13:41:10 -0500 Subject: nfsd: check for use of the closed special stateid From: Andrew Elble <aweits(a)rit.edu> [ Upstream commit ae254dac721d44c0bfebe2795df87459e2e88219 ] Prevent the use of the closed (invalid) special stateid by clients. Signed-off-by: Andrew Elble <aweits(a)rit.edu> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfs4state.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -72,6 +72,7 @@ static u64 current_sessionid = 1; #define ZERO_STATEID(stateid) (!memcmp((stateid), &zero_stateid, sizeof(stateid_t))) #define ONE_STATEID(stateid) (!memcmp((stateid), &one_stateid, sizeof(stateid_t))) #define CURRENT_STATEID(stateid) (!memcmp((stateid), &currentstateid, sizeof(stateid_t))) +#define CLOSE_STATEID(stateid) (!memcmp((stateid), &close_stateid, sizeof(stateid_t))) /* forward declarations */ static bool check_for_locks(struct nfs4_file *fp, struct nfs4_lockowner *lowner); @@ -4704,7 +4705,8 @@ static __be32 nfsd4_validate_stateid(str struct nfs4_stid *s; __be32 status = nfserr_bad_stateid; - if (ZERO_STATEID(stateid) || ONE_STATEID(stateid)) + if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) || + CLOSE_STATEID(stateid)) return status; /* Client debugging aid. */ if (!same_clid(&stateid->si_opaque.so_clid, &cl->cl_clientid)) { @@ -4762,7 +4764,8 @@ nfsd4_lookup_stateid(struct nfsd4_compou else if (typemask & NFS4_DELEG_STID) typemask |= NFS4_REVOKED_DELEG_STID; - if (ZERO_STATEID(stateid) || ONE_STATEID(stateid)) + if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) || + CLOSE_STATEID(stateid)) return nfserr_bad_stateid; status = lookup_clientid(&stateid->si_opaque.so_clid, cstate, nn); if (status == nfserr_stale_clientid) { Patches currently in stable-queue which might be from aweits(a)rit.edu are queue-4.4/nfsd-check-for-use-of-the-closed-special-stateid.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-ethernet-xilinx-mark-xilinx_ll_temac-broken-on-64-bit.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Wed, 29 Nov 2017 11:01:09 +0100 Subject: net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 15bfe05c8d6386f1a90e9340d15336e85e32aad6 ] On 64-bit (e.g. powerpc64/allmodconfig): drivers/net/ethernet/xilinx/ll_temac_main.c: In function 'temac_start_xmit_done': drivers/net/ethernet/xilinx/ll_temac_main.c:633:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dev_kfree_skb_irq((struct sk_buff *)cur_p->app4); ^ cdmac_bd.app4 is u32, so it is too small to hold a kernel pointer. Note that several other fields in struct cdmac_bd are also too small to hold physical addresses on 64-bit platforms. Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/xilinx/Kconfig | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/ethernet/xilinx/Kconfig +++ b/drivers/net/ethernet/xilinx/Kconfig @@ -34,6 +34,7 @@ config XILINX_AXI_EMAC config XILINX_LL_TEMAC tristate "Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver" depends on (PPC || MICROBLAZE) + depends on !64BIT || BROKEN select PHYLIB ---help--- This driver supports the Xilinx 10/100/1000 LocalLink TEMAC Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-4.4/net-ethernet-xilinx-mark-xilinx_ll_temac-broken-on-64-bit.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "media: usbtv: add a new usbid" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: usbtv: add a new usbid to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-usbtv-add-a-new-usbid.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Icenowy Zheng <icenowy(a)aosc.io> Date: Sun, 16 Apr 2017 02:51:16 -0400 Subject: media: usbtv: add a new usbid From: Icenowy Zheng <icenowy(a)aosc.io> [ Upstream commit 04226916d2360f56d57ad00bc48d2d1854d1e0b0 ] A new usbid of UTV007 is found in a newly bought device. The usbid is 1f71:3301. The ID on the chip is: UTV007 A89029.1 1520L18K1 Both video and audio is tested with the modified usbtv driver. Signed-off-by: Icenowy Zheng <icenowy(a)aosc.io> Acked-by: Lubomir Rintel <lkundrak(a)v3.sk> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/usb/usbtv/usbtv-core.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/media/usb/usbtv/usbtv-core.c +++ b/drivers/media/usb/usbtv/usbtv-core.c @@ -127,6 +127,7 @@ static void usbtv_disconnect(struct usb_ static struct usb_device_id usbtv_id_table[] = { { USB_DEVICE(0x1b71, 0x3002) }, + { USB_DEVICE(0x1f71, 0x3301) }, {} }; MODULE_DEVICE_TABLE(usb, usbtv_id_table); Patches currently in stable-queue which might be from icenowy(a)aosc.io are queue-4.4/media-usbtv-add-a-new-usbid.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "mac80211: fix the update of path metric for RANN frame" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: fix the update of path metric for RANN frame to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mac80211-fix-the-update-of-path-metric-for-rann-frame.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Chun-Yeow Yeoh <yeohchunyeow(a)gmail.com> Date: Tue, 14 Nov 2017 23:20:05 +0800 Subject: mac80211: fix the update of path metric for RANN frame From: Chun-Yeow Yeoh <yeohchunyeow(a)gmail.com> [ Upstream commit fbbdad5edf0bb59786a51b94a9d006bc8c2da9a2 ] The previous path metric update from RANN frame has not considered the own link metric toward the transmitting mesh STA. Fix this. Reported-by: Michael65535 Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow(a)gmail.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/mesh_hwmp.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) --- a/net/mac80211/mesh_hwmp.c +++ b/net/mac80211/mesh_hwmp.c @@ -776,7 +776,7 @@ static void hwmp_rann_frame_process(stru struct mesh_path *mpath; u8 ttl, flags, hopcount; const u8 *orig_addr; - u32 orig_sn, metric, metric_txsta, interval; + u32 orig_sn, new_metric, orig_metric, last_hop_metric, interval; bool root_is_gate; ttl = rann->rann_ttl; @@ -787,7 +787,7 @@ static void hwmp_rann_frame_process(stru interval = le32_to_cpu(rann->rann_interval); hopcount = rann->rann_hopcount; hopcount++; - metric = le32_to_cpu(rann->rann_metric); + orig_metric = le32_to_cpu(rann->rann_metric); /* Ignore our own RANNs */ if (ether_addr_equal(orig_addr, sdata->vif.addr)) @@ -804,7 +804,10 @@ static void hwmp_rann_frame_process(stru return; } - metric_txsta = airtime_link_metric_get(local, sta); + last_hop_metric = airtime_link_metric_get(local, sta); + new_metric = orig_metric + last_hop_metric; + if (new_metric < orig_metric) + new_metric = MAX_METRIC; mpath = mesh_path_lookup(sdata, orig_addr); if (!mpath) { @@ -817,7 +820,7 @@ static void hwmp_rann_frame_process(stru } if (!(SN_LT(mpath->sn, orig_sn)) && - !(mpath->sn == orig_sn && metric < mpath->rann_metric)) { + !(mpath->sn == orig_sn && new_metric < mpath->rann_metric)) { rcu_read_unlock(); return; } @@ -835,7 +838,7 @@ static void hwmp_rann_frame_process(stru } mpath->sn = orig_sn; - mpath->rann_metric = metric + metric_txsta; + mpath->rann_metric = new_metric; mpath->is_root = true; /* Recording RANNs sender address to send individually * addressed PREQs destined for root mesh STA */ @@ -855,7 +858,7 @@ static void hwmp_rann_frame_process(stru mesh_path_sel_frame_tx(MPATH_RANN, flags, orig_addr, orig_sn, 0, NULL, 0, broadcast_addr, hopcount, ttl, interval, - metric + metric_txsta, 0, sdata); + new_metric, 0, sdata); } rcu_read_unlock(); Patches currently in stable-queue which might be from yeohchunyeow(a)gmail.com are queue-4.4/mac80211-fix-the-update-of-path-metric-for-rann-frame.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "lockd: fix "list_add double add" caused by legacy signal interface" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled lockd: fix "list_add double add" caused by legacy signal interface to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: lockd-fix-list_add-double-add-caused-by-legacy-signal-interface.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Vasily Averin <vvs(a)virtuozzo.com> Date: Mon, 13 Nov 2017 07:25:40 +0300 Subject: lockd: fix "list_add double add" caused by legacy signal interface From: Vasily Averin <vvs(a)virtuozzo.com> [ Upstream commit 81833de1a46edce9ca20cfe079872ac1c20ef359 ] restart_grace() uses hardcoded init_net. It can cause to "list_add double add" in following scenario: 1) nfsd and lockd was started in several net namespaces 2) nfsd in init_net was stopped (lockd was not stopped because it have users from another net namespaces) 3) lockd got signal, called restart_grace() -> set_grace_period() and enabled lock_manager in hardcoded init_net. 4) nfsd in init_net is started again, its lockd_up() calls set_grace_period() and tries to add lock_manager into init_net 2nd time. Jeff Layton suggest: "Make it safe to call locks_start_grace multiple times on the same lock_manager. If it's already on the global grace_list, then don't try to add it again. (But we don't intentionally add twice, so for now we WARN about that case.) With this change, we also need to ensure that the nfsd4 lock manager initializes the list before we call locks_start_grace. While we're at it, move the rest of the nfsd_net initialization into nfs4_state_create_net. I see no reason to have it spread over two functions like it is today." Suggested patch was updated to generate warning in described situation. Suggested-by: Jeff Layton <jlayton(a)redhat.com> Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfs_common/grace.c | 6 +++++- fs/nfsd/nfs4state.c | 7 ++++--- 2 files changed, 9 insertions(+), 4 deletions(-) --- a/fs/nfs_common/grace.c +++ b/fs/nfs_common/grace.c @@ -30,7 +30,11 @@ locks_start_grace(struct net *net, struc struct list_head *grace_list = net_generic(net, grace_net_id); spin_lock(&grace_lock); - list_add(&lm->list, grace_list); + if (list_empty(&lm->list)) + list_add(&lm->list, grace_list); + else + WARN(1, "double list_add attempt detected in net %x %s\n", + net->ns.inum, (net == &init_net) ? "(init_net)" : ""); spin_unlock(&grace_lock); } EXPORT_SYMBOL_GPL(locks_start_grace); --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -6792,6 +6792,10 @@ static int nfs4_state_create_net(struct INIT_LIST_HEAD(&nn->sessionid_hashtbl[i]); nn->conf_name_tree = RB_ROOT; nn->unconf_name_tree = RB_ROOT; + nn->boot_time = get_seconds(); + nn->grace_ended = false; + nn->nfsd4_manager.block_opens = true; + INIT_LIST_HEAD(&nn->nfsd4_manager.list); INIT_LIST_HEAD(&nn->client_lru); INIT_LIST_HEAD(&nn->close_lru); INIT_LIST_HEAD(&nn->del_recall_lru); @@ -6846,9 +6850,6 @@ nfs4_state_start_net(struct net *net) ret = nfs4_state_create_net(net); if (ret) return ret; - nn->boot_time = get_seconds(); - nn->grace_ended = false; - nn->nfsd4_manager.block_opens = true; locks_start_grace(net, &nn->nfsd4_manager); nfsd4_client_tracking_init(net); printk(KERN_INFO "NFSD: starting %ld-second grace period (net %p)\n", Patches currently in stable-queue which might be from vvs(a)virtuozzo.com are queue-4.4/lockd-fix-list_add-double-add-caused-by-legacy-signal-interface.patch queue-4.4/grace-replace-bug_on-by-warn_once-in-exit_net-hook.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: ioapic: Preserve read-only values in the redirection table" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: ioapic: Preserve read-only values in the redirection table to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Date: Sun, 5 Nov 2017 15:52:33 +0200 Subject: KVM: x86: ioapic: Preserve read-only values in the redirection table From: Nikita Leshenko <nikita.leshchenko(a)oracle.com> [ Upstream commit b200dded0a6974a3b69599832b2203483920ab25 ] According to 82093AA (IOAPIC) manual, Remote IRR and Delivery Status are read-only. QEMU implements the bits as RO in commit 479c2a1cb7fb ("ioapic: keep RO bits for IOAPIC entry"). Signed-off-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Reviewed-by: Liran Alon <liran.alon(a)oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Reviewed-by: Steve Rutherford <srutherford(a)google.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/ioapic.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/arch/x86/kvm/ioapic.c +++ b/arch/x86/kvm/ioapic.c @@ -268,6 +268,7 @@ static void ioapic_write_indirect(struct { unsigned index; bool mask_before, mask_after; + int old_remote_irr, old_delivery_status; union kvm_ioapic_redirect_entry *e; switch (ioapic->ioregsel) { @@ -290,6 +291,9 @@ static void ioapic_write_indirect(struct return; e = &ioapic->redirtbl[index]; mask_before = e->fields.mask; + /* Preserve read-only fields */ + old_remote_irr = e->fields.remote_irr; + old_delivery_status = e->fields.delivery_status; if (ioapic->ioregsel & 1) { e->bits &= 0xffffffff; e->bits |= (u64) val << 32; @@ -297,6 +301,8 @@ static void ioapic_write_indirect(struct e->bits &= ~0xffffffffULL; e->bits |= (u32) val; } + e->fields.remote_irr = old_remote_irr; + e->fields.delivery_status = old_delivery_status; /* * Some OSes (Linux, Xen) assume that Remote IRR bit will Patches currently in stable-queue which might be from nikita.leshchenko(a)oracle.com are queue-4.4/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.4/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.4/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch queue-4.4/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.4/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Date: Sun, 5 Nov 2017 15:52:29 +0200 Subject: KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race From: Nikita Leshenko <nikita.leshchenko(a)oracle.com> [ Upstream commit 0fc5a36dd6b345eb0d251a65c236e53bead3eef7 ] KVM uses ioapic_handled_vectors to track vectors that need to notify the IOAPIC on EOI. The problem is that IOAPIC can be reconfigured while an interrupt with old configuration is pending or running and ioapic_handled_vectors only remembers the newest configuration; thus EOI from the old interrupt is not delievered to the IOAPIC. A previous commit db2bdcbbbd32 ("KVM: x86: fix edge EOI and IOAPIC reconfig race") addressed this issue by adding pending edge-triggered interrupts to ioapic_handled_vectors, fixing this race for edge-triggered interrupts. The commit explicitly ignored level-triggered interrupts, but this race applies to them as well: 1) IOAPIC sends a level triggered interrupt vector to VCPU0 2) VCPU0's handler deasserts the irq line and reconfigures the IOAPIC to route the vector to VCPU1. The reconfiguration rewrites only the upper 32 bits of the IOREDTBLn register. (Causes KVM to update ioapic_handled_vectors for VCPU0 and it no longer includes the vector.) 3) VCPU0 sends EOI for the vector, but it's not delievered to the IOAPIC because the ioapic_handled_vectors doesn't include the vector. 4) New interrupts are not delievered to VCPU1 because remote_irr bit is set forever. Therefore, the correct behavior is to add all pending and running interrupts to ioapic_handled_vectors. This commit introduces a slight performance hit similar to commit db2bdcbbbd32 ("KVM: x86: fix edge EOI and IOAPIC reconfig race") for the rare case that the vector is reused by a non-IOAPIC source on VCPU0. We prefer to keep solution simple and not handle this case just as the original commit does. Fixes: db2bdcbbbd32 ("KVM: x86: fix edge EOI and IOAPIC reconfig race") Signed-off-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Reviewed-by: Liran Alon <liran.alon(a)oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/ioapic.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/arch/x86/kvm/ioapic.c +++ b/arch/x86/kvm/ioapic.c @@ -247,8 +247,7 @@ void kvm_ioapic_scan_entry(struct kvm_vc index == RTC_GSI) { if (kvm_apic_match_dest(vcpu, NULL, 0, e->fields.dest_id, e->fields.dest_mode) || - (e->fields.trig_mode == IOAPIC_EDGE_TRIG && - kvm_apic_pending_eoi(vcpu, e->fields.vector))) + kvm_apic_pending_eoi(vcpu, e->fields.vector)) __set_bit(e->fields.vector, (unsigned long *)eoi_exit_bitmap); } Patches currently in stable-queue which might be from nikita.leshchenko(a)oracle.com are queue-4.4/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.4/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.4/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch queue-4.4/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.4/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: ioapic: Clear Remote IRR when entry is switched to edge-triggered" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: ioapic: Clear Remote IRR when entry is switched to edge-triggered to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Date: Sun, 5 Nov 2017 15:52:32 +0200 Subject: KVM: x86: ioapic: Clear Remote IRR when entry is switched to edge-triggered From: Nikita Leshenko <nikita.leshchenko(a)oracle.com> [ Upstream commit a8bfec2930525808c01f038825d1df3904638631 ] Some OSes (Linux, Xen) use this behavior to clear the Remote IRR bit for IOAPICs without an EOI register. They simulate the EOI message manually by changing the trigger mode to edge and then back to level, with the entry being masked during this. QEMU implements this feature in commit ed1263c363c9 ("ioapic: clear remote irr bit for edge-triggered interrupts") As a side effect, this commit removes an incorrect behavior where Remote IRR was cleared when the redirection table entry was rewritten. This is not consistent with the manual and also opens an opportunity for a strange behavior when a redirection table entry is modified from an interrupt handler that handles the same entry: The modification will clear the Remote IRR bit even though the interrupt handler is still running. Signed-off-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Reviewed-by: Liran Alon <liran.alon(a)oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Reviewed-by: Steve Rutherford <srutherford(a)google.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/ioapic.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/arch/x86/kvm/ioapic.c +++ b/arch/x86/kvm/ioapic.c @@ -296,8 +296,17 @@ static void ioapic_write_indirect(struct } else { e->bits &= ~0xffffffffULL; e->bits |= (u32) val; - e->fields.remote_irr = 0; } + + /* + * Some OSes (Linux, Xen) assume that Remote IRR bit will + * be cleared by IOAPIC hardware when the entry is configured + * as edge-triggered. This behavior is used to simulate an + * explicit EOI on IOAPICs that don't have the EOI register. + */ + if (e->fields.trig_mode == IOAPIC_EDGE_TRIG) + e->fields.remote_irr = 0; + mask_after = e->fields.mask; if (mask_before != mask_after) kvm_fire_mask_notifiers(ioapic->kvm, KVM_IRQCHIP_IOAPIC, index, mask_after); Patches currently in stable-queue which might be from nikita.leshchenko(a)oracle.com are queue-4.4/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.4/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.4/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch queue-4.4/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.4/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: X86: Fix operand/address-size during instruction decoding" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: X86: Fix operand/address-size during instruction decoding to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-fix-operand-address-size-during-instruction-decoding.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Wanpeng Li <wanpeng.li(a)hotmail.com> Date: Sun, 5 Nov 2017 16:54:47 -0800 Subject: KVM: X86: Fix operand/address-size during instruction decoding From: Wanpeng Li <wanpeng.li(a)hotmail.com> [ Upstream commit 3853be2603191829b442b64dac6ae8ba0c027bf9 ] Pedro reported: During tests that we conducted on KVM, we noticed that executing a "PUSH %ES" instruction under KVM produces different results on both memory and the SP register depending on whether EPT support is enabled. With EPT the SP is reduced by 4 bytes (and the written value is 0-padded) but without EPT support it is only reduced by 2 bytes. The difference can be observed when the CS.DB field is 1 (32-bit) but not when it's 0 (16-bit). The internal segment descriptor cache exist even in real/vm8096 mode. The CS.D also should be respected instead of just default operand/address-size/66H prefix/67H prefix during instruction decoding. This patch fixes it by also adjusting operand/address-size according to CS.D. Reported-by: Pedro Fonseca <pfonseca(a)cs.washington.edu> Tested-by: Pedro Fonseca <pfonseca(a)cs.washington.edu> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: Pedro Fonseca <pfonseca(a)cs.washington.edu> Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Reviewed-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/emulate.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -4978,6 +4978,8 @@ int x86_decode_insn(struct x86_emulate_c bool op_prefix = false; bool has_seg_override = false; struct opcode opcode; + u16 dummy; + struct desc_struct desc; ctxt->memop.type = OP_NONE; ctxt->memopp = NULL; @@ -4996,6 +4998,11 @@ int x86_decode_insn(struct x86_emulate_c switch (mode) { case X86EMUL_MODE_REAL: case X86EMUL_MODE_VM86: + def_op_bytes = def_ad_bytes = 2; + ctxt->ops->get_segment(ctxt, &dummy, &desc, NULL, VCPU_SREG_CS); + if (desc.d) + def_op_bytes = def_ad_bytes = 4; + break; case X86EMUL_MODE_PROT16: def_op_bytes = def_ad_bytes = 2; break; Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are queue-4.4/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.4/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.4/kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch queue-4.4/kvm-x86-fix-operand-address-size-during-instruction-decoding.patch queue-4.4/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.4/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Liran Alon <liran.alon(a)oracle.com> Date: Sun, 5 Nov 2017 16:56:33 +0200 Subject: KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure From: Liran Alon <liran.alon(a)oracle.com> [ Upstream commit 1f4dcb3b213235e642088709a1c54964d23365e9 ] On this case, handle_emulation_failure() fills kvm_run with internal-error information which it expects to be delivered to user-mode for further processing. However, the code reports a wrong return-value which makes KVM to never return to user-mode on this scenario. Fixes: 6d77dbfc88e3 ("KVM: inject #UD if instruction emulation fails and exit to userspace") Signed-off-by: Liran Alon <liran.alon(a)oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/x86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -5153,7 +5153,7 @@ static int handle_emulation_failure(stru vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR; vcpu->run->internal.suberror = KVM_INTERNAL_ERROR_EMULATION; vcpu->run->internal.ndata = 0; - r = EMULATE_FAIL; + r = EMULATE_USER_EXIT; } kvm_queue_exception(vcpu, UD_VECTOR); Patches currently in stable-queue which might be from liran.alon(a)oracle.com are queue-4.4/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.4/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.4/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch queue-4.4/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.4/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: Don't re-execute instruction when not passing CR2 value" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: Don't re-execute instruction when not passing CR2 value to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Liran Alon <liran.alon(a)oracle.com> Date: Sun, 5 Nov 2017 16:56:34 +0200 Subject: KVM: x86: Don't re-execute instruction when not passing CR2 value From: Liran Alon <liran.alon(a)oracle.com> [ Upstream commit 9b8ae63798cb97e785a667ff27e43fa6220cb734 ] In case of instruction-decode failure or emulation failure, x86_emulate_instruction() will call reexecute_instruction() which will attempt to use the cr2 value passed to x86_emulate_instruction(). However, when x86_emulate_instruction() is called from emulate_instruction(), cr2 is not passed (passed as 0) and therefore it doesn't make sense to execute reexecute_instruction() logic at all. Fixes: 51d8b66199e9 ("KVM: cleanup emulate_instruction") Signed-off-by: Liran Alon <liran.alon(a)oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/kvm_host.h | 3 ++- arch/x86/kvm/vmx.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -998,7 +998,8 @@ int x86_emulate_instruction(struct kvm_v static inline int emulate_instruction(struct kvm_vcpu *vcpu, int emulation_type) { - return x86_emulate_instruction(vcpu, 0, emulation_type, NULL, 0); + return x86_emulate_instruction(vcpu, 0, + emulation_type | EMULTYPE_NO_REEXECUTE, NULL, 0); } void kvm_enable_efer_bits(u64); --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -6023,7 +6023,7 @@ static int handle_invalid_guest_state(st if (test_bit(KVM_REQ_EVENT, &vcpu->requests)) return 1; - err = emulate_instruction(vcpu, EMULTYPE_NO_REEXECUTE); + err = emulate_instruction(vcpu, 0); if (err == EMULATE_USER_EXIT) { ++vcpu->stat.mmio_exits; Patches currently in stable-queue which might be from liran.alon(a)oracle.com are queue-4.4/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.4/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.4/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch queue-4.4/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.4/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: VMX: Fix rflags cache during vCPU reset" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: VMX: Fix rflags cache during vCPU reset to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Wanpeng Li <wanpeng.li(a)hotmail.com> Date: Mon, 20 Nov 2017 14:52:21 -0800 Subject: KVM: VMX: Fix rflags cache during vCPU reset From: Wanpeng Li <wanpeng.li(a)hotmail.com> [ Upstream commit c37c28730bb031cc8a44a130c2555c0f3efbe2d0 ] Reported by syzkaller: *** Guest State *** CR0: actual=0x0000000080010031, shadow=0x0000000060000010, gh_mask=fffffffffffffff7 CR4: actual=0x0000000000002061, shadow=0x0000000000000000, gh_mask=ffffffffffffe8f1 CR3 = 0x000000002081e000 RSP = 0x000000000000fffa RIP = 0x0000000000000000 RFLAGS=0x00023000 DR7 = 0x00000000000000 ^^^^^^^^^^ ------------[ cut here ]------------ WARNING: CPU: 6 PID: 24431 at /home/kernel/linux/arch/x86/kvm//x86.c:7302 kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm] CPU: 6 PID: 24431 Comm: reprotest Tainted: G W OE 4.14.0+ #26 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm] RSP: 0018:ffff880291d179e0 EFLAGS: 00010202 Call Trace: kvm_vcpu_ioctl+0x479/0x880 [kvm] do_vfs_ioctl+0x142/0x9a0 SyS_ioctl+0x74/0x80 entry_SYSCALL_64_fastpath+0x23/0x9a The failed vmentry is triggered by the following beautified testcase: #include <unistd.h> #include <sys/syscall.h> #include <string.h> #include <stdint.h> #include <linux/kvm.h> #include <fcntl.h> #include <sys/ioctl.h> long r[5]; int main() { struct kvm_debugregs dr = { 0 }; r[2] = open("/dev/kvm", O_RDONLY); r[3] = ioctl(r[2], KVM_CREATE_VM, 0); r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7); struct kvm_guest_debug debug = { .control = 0xf0403, .arch = { .debugreg[6] = 0x2, .debugreg[7] = 0x2 } }; ioctl(r[4], KVM_SET_GUEST_DEBUG, &debug); ioctl(r[4], KVM_RUN, 0); } which testcase tries to setup the processor specific debug registers and configure vCPU for handling guest debug events through KVM_SET_GUEST_DEBUG. The KVM_SET_GUEST_DEBUG ioctl will get and set rflags in order to set TF bit if single step is needed. All regs' caches are reset to avail and GUEST_RFLAGS vmcs field is reset to 0x2 during vCPU reset. However, the cache of rflags is not reset during vCPU reset. The function vmx_get_rflags() returns an unreset rflags cache value since the cache is marked avail, it is 0 after boot. Vmentry fails if the rflags reserved bit 1 is 0. This patch fixes it by resetting both the GUEST_RFLAGS vmcs field and its cache to 0x2 during vCPU reset. Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Tested-by: Dmitry Vyukov <dvyukov(a)google.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/vmx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -4954,7 +4954,7 @@ static void vmx_vcpu_reset(struct kvm_vc vmcs_write64(GUEST_IA32_DEBUGCTL, 0); } - vmcs_writel(GUEST_RFLAGS, 0x02); + kvm_set_rflags(vcpu, X86_EFLAGS_FIXED); kvm_rip_write(vcpu, 0xfff0); vmcs_writel(GUEST_GDTR_BASE, 0); Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are queue-4.4/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.4/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.4/kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch queue-4.4/kvm-x86-fix-operand-address-size-during-instruction-decoding.patch queue-4.4/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.4/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "kmemleak: add scheduling point to kmemleak_scan()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kmemleak: add scheduling point to kmemleak_scan() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kmemleak-add-scheduling-point-to-kmemleak_scan.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Yisheng Xie <xieyisheng1(a)huawei.com> Date: Wed, 29 Nov 2017 16:11:08 -0800 Subject: kmemleak: add scheduling point to kmemleak_scan() From: Yisheng Xie <xieyisheng1(a)huawei.com> [ Upstream commit bde5f6bc68db51128f875a756e9082a6c6ff7b4c ] kmemleak_scan() will scan struct page for each node and it can be really large and resulting in a soft lockup. We have seen a soft lockup when do scan while compile kernel: watchdog: BUG: soft lockup - CPU#53 stuck for 22s! [bash:10287] [...] Call Trace: kmemleak_scan+0x21a/0x4c0 kmemleak_write+0x312/0x350 full_proxy_write+0x5a/0xa0 __vfs_write+0x33/0x150 vfs_write+0xad/0x1a0 SyS_write+0x52/0xc0 do_syscall_64+0x61/0x1a0 entry_SYSCALL64_slow_path+0x25/0x25 Fix this by adding cond_resched every MAX_SCAN_SIZE. Link: http://lkml.kernel.org/r/1511439788-20099-1-git-send-email-xieyisheng1@huaw… Signed-off-by: Yisheng Xie <xieyisheng1(a)huawei.com> Suggested-by: Catalin Marinas <catalin.marinas(a)arm.com> Acked-by: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Michal Hocko <mhocko(a)kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/kmemleak.c | 2 ++ 1 file changed, 2 insertions(+) --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -1394,6 +1394,8 @@ static void kmemleak_scan(void) if (page_count(page) == 0) continue; scan_block(page, page + 1, NULL); + if (!(pfn % (MAX_SCAN_SIZE / sizeof(*page)))) + cond_resched(); } } put_online_mems(); Patches currently in stable-queue which might be from xieyisheng1(a)huawei.com are queue-4.4/kmemleak-add-scheduling-point-to-kmemleak_scan.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "hwmon: (pmbus) Use 64bit math for DIRECT format values" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hwmon: (pmbus) Use 64bit math for DIRECT format values to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hwmon-pmbus-use-64bit-math-for-direct-format-values.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Robert Lippert <roblip(a)gmail.com> Date: Mon, 27 Nov 2017 15:51:55 -0800 Subject: hwmon: (pmbus) Use 64bit math for DIRECT format values From: Robert Lippert <roblip(a)gmail.com> [ Upstream commit bd467e4eababe4c04272c1e646f066db02734c79 ] Power values in the 100s of watt range can easily blow past 32bit math limits when processing everything in microwatts. Use 64bit math instead to avoid these issues on common 32bit ARM BMC platforms. Fixes: 442aba78728e ("hwmon: PMBus device driver") Signed-off-by: Robert Lippert <rlippert(a)google.com> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwmon/pmbus/pmbus_core.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) --- a/drivers/hwmon/pmbus/pmbus_core.c +++ b/drivers/hwmon/pmbus/pmbus_core.c @@ -20,6 +20,7 @@ */ #include <linux/kernel.h> +#include <linux/math64.h> #include <linux/module.h> #include <linux/init.h> #include <linux/err.h> @@ -476,8 +477,8 @@ static long pmbus_reg2data_linear(struct static long pmbus_reg2data_direct(struct pmbus_data *data, struct pmbus_sensor *sensor) { - long val = (s16) sensor->data; - long m, b, R; + s64 b, val = (s16)sensor->data; + s32 m, R; m = data->info->m[sensor->class]; b = data->info->b[sensor->class]; @@ -505,11 +506,12 @@ static long pmbus_reg2data_direct(struct R--; } while (R < 0) { - val = DIV_ROUND_CLOSEST(val, 10); + val = div_s64(val + 5LL, 10L); /* round closest */ R++; } - return (val - b) / m; + val = div_s64(val - b, m); + return clamp_val(val, LONG_MIN, LONG_MAX); } /* @@ -629,7 +631,8 @@ static u16 pmbus_data2reg_linear(struct static u16 pmbus_data2reg_direct(struct pmbus_data *data, struct pmbus_sensor *sensor, long val) { - long m, b, R; + s64 b, val64 = val; + s32 m, R; m = data->info->m[sensor->class]; b = data->info->b[sensor->class]; @@ -646,18 +649,18 @@ static u16 pmbus_data2reg_direct(struct R -= 3; /* Adjust R and b for data in milli-units */ b *= 1000; } - val = val * m + b; + val64 = val64 * m + b; while (R > 0) { - val *= 10; + val64 *= 10; R--; } while (R < 0) { - val = DIV_ROUND_CLOSEST(val, 10); + val64 = div_s64(val64 + 5LL, 10L); /* round closest */ R++; } - return val; + return (u16)clamp_val(val64, S16_MIN, S16_MAX); } static u16 pmbus_data2reg_vid(struct pmbus_data *data, Patches currently in stable-queue which might be from roblip(a)gmail.com are queue-4.4/hwmon-pmbus-use-64bit-math-for-direct-format-values.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "grace: replace BUG_ON by WARN_ONCE in exit_net hook" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled grace: replace BUG_ON by WARN_ONCE in exit_net hook to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: grace-replace-bug_on-by-warn_once-in-exit_net-hook.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Vasily Averin <vvs(a)virtuozzo.com> Date: Mon, 6 Nov 2017 16:22:48 +0300 Subject: grace: replace BUG_ON by WARN_ONCE in exit_net hook From: Vasily Averin <vvs(a)virtuozzo.com> [ Upstream commit b872285751c1af010e12d02bce7069e2061a58ca ] Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfs_common/grace.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/fs/nfs_common/grace.c +++ b/fs/nfs_common/grace.c @@ -104,7 +104,9 @@ grace_exit_net(struct net *net) { struct list_head *grace_list = net_generic(net, grace_net_id); - BUG_ON(!list_empty(grace_list)); + WARN_ONCE(!list_empty(grace_list), + "net %x %s: grace_list is not empty\n", + net->ns.inum, __func__); } static struct pernet_operations grace_net_ops = { Patches currently in stable-queue which might be from vvs(a)virtuozzo.com are queue-4.4/lockd-fix-list_add-double-add-caused-by-legacy-signal-interface.patch queue-4.4/grace-replace-bug_on-by-warn_once-in-exit_net-hook.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/omap: Fix error handling path in 'omap_dmm_probe()'" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/omap: Fix error handling path in 'omap_dmm_probe()' to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-omap-fix-error-handling-path-in-omap_dmm_probe.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Sun, 24 Sep 2017 08:01:03 +0200 Subject: drm/omap: Fix error handling path in 'omap_dmm_probe()' From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 8677b1ac2db021ab30bb1fa34f1e56ebe0051ec3 ] If we don't find a matching device node, we must free the memory allocated in 'omap_dmm' a few lines above. Fixes: 7cb0d6c17b96 ("drm/omap: fix TILER on OMAP5") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c @@ -611,7 +611,8 @@ static int omap_dmm_probe(struct platfor match = of_match_node(dmm_of_match, dev->dev.of_node); if (!match) { dev_err(&dev->dev, "failed to find matching device node\n"); - return -ENODEV; + ret = -ENODEV; + goto fail; } omap_dmm->plat_data = match->data; Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.4/drm-omap-fix-error-handling-path-in-omap_dmm_probe.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/amdkfd: Fix SDMA ring buffer size calculation" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/amdkfd: Fix SDMA ring buffer size calculation to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-amdkfd-fix-sdma-ring-buffer-size-calculation.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: shaoyunl <Shaoyun.Liu(a)amd.com> Date: Wed, 1 Nov 2017 19:21:56 -0400 Subject: drm/amdkfd: Fix SDMA ring buffer size calculation From: shaoyunl <Shaoyun.Liu(a)amd.com> [ Upstream commit d12fb13f23199faa7e536acec1db49068e5a067d ] ffs function return the position of the first bit set on 1 based. (bit zero returns 1). Signed-off-by: shaoyun liu <shaoyun.liu(a)amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling(a)amd.com> Reviewed-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c @@ -215,8 +215,8 @@ static int update_mqd_sdma(struct mqd_ma BUG_ON(!mm || !mqd || !q); m = get_sdma_mqd(mqd); - m->sdma_rlc_rb_cntl = ffs(q->queue_size / sizeof(unsigned int)) << - SDMA0_RLC0_RB_CNTL__RB_SIZE__SHIFT | + m->sdma_rlc_rb_cntl = (ffs(q->queue_size / sizeof(unsigned int)) - 1) + << SDMA0_RLC0_RB_CNTL__RB_SIZE__SHIFT | q->vmid << SDMA0_RLC0_RB_CNTL__RB_VMID__SHIFT | 1 << SDMA0_RLC0_RB_CNTL__RPTR_WRITEBACK_ENABLE__SHIFT | 6 << SDMA0_RLC0_RB_CNTL__RPTR_WRITEBACK_TIMER__SHIFT; Patches currently in stable-queue which might be from Shaoyun.Liu(a)amd.com are queue-4.4/drm-amdkfd-fix-sdma-ring-buffer-size-calculation.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/amdkfd: Fix SDMA oversubsription handling" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/amdkfd: Fix SDMA oversubsription handling to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-amdkfd-fix-sdma-oversubsription-handling.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Felix Kuehling <Felix.Kuehling(a)amd.com> Date: Wed, 1 Nov 2017 19:21:57 -0400 Subject: drm/amdkfd: Fix SDMA oversubsription handling From: Felix Kuehling <Felix.Kuehling(a)amd.com> [ Upstream commit 8c946b8988acec785bcf67088b6bd0747f36d2d3 ] SDMA only supports a fixed number of queues. HWS cannot handle oversubscription. Signed-off-by: shaoyun liu <shaoyun.liu(a)amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling(a)amd.com> Reviewed-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 18 +++++++++++++++++ 1 file changed, 18 insertions(+) --- a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c @@ -205,6 +205,24 @@ int pqm_create_queue(struct process_queu switch (type) { case KFD_QUEUE_TYPE_SDMA: + if (dev->dqm->queue_count >= + CIK_SDMA_QUEUES_PER_ENGINE * CIK_SDMA_ENGINE_NUM) { + pr_err("Over-subscription is not allowed for SDMA.\n"); + retval = -EPERM; + goto err_create_queue; + } + + retval = create_cp_queue(pqm, dev, &q, properties, f, *qid); + if (retval != 0) + goto err_create_queue; + pqn->q = q; + pqn->kq = NULL; + retval = dev->dqm->ops.create_queue(dev->dqm, q, &pdd->qpd, + &q->properties.vmid); + pr_debug("DQM returned %d for create_queue\n", retval); + print_queue(q); + break; + case KFD_QUEUE_TYPE_COMPUTE: /* check if there is over subscription */ if ((sched_policy == KFD_SCHED_POLICY_HWS_NO_OVERSUBSCRIPTION) && Patches currently in stable-queue which might be from Felix.Kuehling(a)amd.com are queue-4.4/drm-amdkfd-fix-sdma-oversubsription-handling.patch queue-4.4/drm-amdkfd-fix-sdma-ring-buffer-size-calculation.patch queue-4.4/drm-amdgpu-fix-sdma-load-unload-sequence-on-hws-disabled-mode.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/amdgpu: Fix SDMA load/unload sequence on HWS disabled mode" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/amdgpu: Fix SDMA load/unload sequence on HWS disabled mode to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-amdgpu-fix-sdma-load-unload-sequence-on-hws-disabled-mode.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Felix Kuehling <Felix.Kuehling(a)amd.com> Date: Wed, 1 Nov 2017 19:21:55 -0400 Subject: drm/amdgpu: Fix SDMA load/unload sequence on HWS disabled mode From: Felix Kuehling <Felix.Kuehling(a)amd.com> [ Upstream commit cf21654b40968609779751b34e7923180968fe5b ] Fix the SDMA load and unload sequence as suggested by HW document. Signed-off-by: shaoyun liu <shaoyun.liu(a)amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling(a)amd.com> Acked-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 47 +++++++++++++++------- 1 file changed, 34 insertions(+), 13 deletions(-) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c @@ -367,29 +367,50 @@ static int kgd_hqd_sdma_load(struct kgd_ { struct amdgpu_device *adev = get_amdgpu_device(kgd); struct cik_sdma_rlc_registers *m; + unsigned long end_jiffies; uint32_t sdma_base_addr; + uint32_t data; m = get_sdma_mqd(mqd); sdma_base_addr = get_sdma_base_addr(m); - WREG32(sdma_base_addr + mmSDMA0_RLC0_VIRTUAL_ADDR, - m->sdma_rlc_virtual_addr); + WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_CNTL, + m->sdma_rlc_rb_cntl & (~SDMA0_RLC0_RB_CNTL__RB_ENABLE_MASK)); - WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_BASE, - m->sdma_rlc_rb_base); + end_jiffies = msecs_to_jiffies(2000) + jiffies; + while (true) { + data = RREG32(sdma_base_addr + mmSDMA0_RLC0_CONTEXT_STATUS); + if (data & SDMA0_RLC0_CONTEXT_STATUS__IDLE_MASK) + break; + if (time_after(jiffies, end_jiffies)) + return -ETIME; + usleep_range(500, 1000); + } + if (m->sdma_engine_id) { + data = RREG32(mmSDMA1_GFX_CONTEXT_CNTL); + data = REG_SET_FIELD(data, SDMA1_GFX_CONTEXT_CNTL, + RESUME_CTX, 0); + WREG32(mmSDMA1_GFX_CONTEXT_CNTL, data); + } else { + data = RREG32(mmSDMA0_GFX_CONTEXT_CNTL); + data = REG_SET_FIELD(data, SDMA0_GFX_CONTEXT_CNTL, + RESUME_CTX, 0); + WREG32(mmSDMA0_GFX_CONTEXT_CNTL, data); + } + WREG32(sdma_base_addr + mmSDMA0_RLC0_DOORBELL, + m->sdma_rlc_doorbell); + WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_RPTR, 0); + WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_WPTR, 0); + WREG32(sdma_base_addr + mmSDMA0_RLC0_VIRTUAL_ADDR, + m->sdma_rlc_virtual_addr); + WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_BASE, m->sdma_rlc_rb_base); WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_BASE_HI, m->sdma_rlc_rb_base_hi); - WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_RPTR_ADDR_LO, m->sdma_rlc_rb_rptr_addr_lo); - WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_RPTR_ADDR_HI, m->sdma_rlc_rb_rptr_addr_hi); - - WREG32(sdma_base_addr + mmSDMA0_RLC0_DOORBELL, - m->sdma_rlc_doorbell); - WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_CNTL, m->sdma_rlc_rb_cntl); @@ -492,9 +513,9 @@ static int kgd_hqd_sdma_destroy(struct k } WREG32(sdma_base_addr + mmSDMA0_RLC0_DOORBELL, 0); - WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_RPTR, 0); - WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_WPTR, 0); - WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_BASE, 0); + WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_CNTL, + RREG32(sdma_base_addr + mmSDMA0_RLC0_RB_CNTL) | + SDMA0_RLC0_RB_CNTL__RB_ENABLE_MASK); return 0; } Patches currently in stable-queue which might be from Felix.Kuehling(a)amd.com are queue-4.4/drm-amdkfd-fix-sdma-oversubsription-handling.patch queue-4.4/drm-amdkfd-fix-sdma-ring-buffer-size-calculation.patch queue-4.4/drm-amdgpu-fix-sdma-load-unload-sequence-on-hws-disabled-mode.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "cpufreq: Add Loongson machine dependencies" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cpufreq: Add Loongson machine dependencies to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cpufreq-add-loongson-machine-dependencies.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: James Hogan <jhogan(a)kernel.org> Date: Wed, 15 Nov 2017 21:17:55 +0000 Subject: cpufreq: Add Loongson machine dependencies From: James Hogan <jhogan(a)kernel.org> [ Upstream commit 0d307935fefa6389eb726c6362351c162c949101 ] The MIPS loongson cpufreq drivers don't build unless configured for the correct machine type, due to dependency on machine specific architecture headers and symbols in machine specific platform code. More specifically loongson1-cpufreq.c uses RST_CPU_EN and RST_CPU, neither of which is defined in asm/mach-loongson32/regs-clk.h unless CONFIG_LOONGSON1_LS1B=y, and loongson2_cpufreq.c references loongson2_clockmod_table[], which is only defined in arch/mips/loongson64/lemote-2f/clock.c, i.e. when CONFIG_LEMOTE_MACH2F=y. Add these dependencies to Kconfig to avoid randconfig / allyesconfig build failures (e.g. when based on BMIPS which also has a cpufreq driver). Signed-off-by: James Hogan <jhogan(a)kernel.org> Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/cpufreq/Kconfig | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -236,6 +236,7 @@ endif if MIPS config LOONGSON2_CPUFREQ tristate "Loongson2 CPUFreq Driver" + depends on LEMOTE_MACH2F help This option adds a CPUFreq driver for loongson processors which support software configurable cpu frequency. @@ -248,6 +249,7 @@ config LOONGSON2_CPUFREQ config LOONGSON1_CPUFREQ tristate "Loongson1 CPUFreq Driver" + depends on LOONGSON1_LS1B help This option adds a CPUFreq driver for loongson1 processors which support software configurable cpu frequency. Patches currently in stable-queue which might be from jhogan(a)kernel.org are queue-4.4/cpufreq-add-loongson-machine-dependencies.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "btrfs: fix deadlock when writing out space cache" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: fix deadlock when writing out space cache to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-deadlock-when-writing-out-space-cache.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Josef Bacik <jbacik(a)fb.com> Date: Wed, 15 Nov 2017 16:20:52 -0500 Subject: btrfs: fix deadlock when writing out space cache From: Josef Bacik <jbacik(a)fb.com> [ Upstream commit b77000ed558daa3bef0899d29bf171b8c9b5e6a8 ] If we fail to prepare our pages for whatever reason (out of memory in our case) we need to make sure to drop the block_group->data_rwsem, otherwise hilarity ensues. Signed-off-by: Josef Bacik <jbacik(a)fb.com> Reviewed-by: Omar Sandoval <osandov(a)fb.com> Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: David Sterba <dsterba(a)suse.com> [ add label and use existing unlocking code ] Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/free-space-cache.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -1258,7 +1258,7 @@ static int __btrfs_write_out_cache(struc /* Lock all pages first so we can lock the extent safely. */ ret = io_ctl_prepare_pages(io_ctl, inode, 0); if (ret) - goto out; + goto out_unlock; lock_extent_bits(&BTRFS_I(inode)->io_tree, 0, i_size_read(inode) - 1, 0, &cached_state); @@ -1351,6 +1351,7 @@ out_nospc_locked: out_nospc: cleanup_write_cache_enospc(inode, io_ctl, &cached_state, &bitmap_list); +out_unlock: if (block_group && (block_group->flags & BTRFS_BLOCK_GROUP_DATA)) up_write(&block_group->data_rwsem); Patches currently in stable-queue which might be from jbacik(a)fb.com are queue-4.4/btrfs-fix-deadlock-when-writing-out-space-cache.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "bcache: check return value of register_shrinker" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bcache: check return value of register_shrinker to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bcache-check-return-value-of-register_shrinker.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Michael Lyle <mlyle(a)lyle.org> Date: Fri, 24 Nov 2017 15:14:27 -0800 Subject: bcache: check return value of register_shrinker From: Michael Lyle <mlyle(a)lyle.org> [ Upstream commit 6c4ca1e36cdc1a0a7a84797804b87920ccbebf51 ] register_shrinker is now __must_check, so check it to kill a warning. Caller of bch_btree_cache_alloc in super.c appropriately checks return value so this is fully plumbed through. This V2 fixes checkpatch warnings and improves the commit description, as I was too hasty getting the previous version out. Signed-off-by: Michael Lyle <mlyle(a)lyle.org> Reviewed-by: Vojtech Pavlik <vojtech(a)suse.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/bcache/btree.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/md/bcache/btree.c +++ b/drivers/md/bcache/btree.c @@ -808,7 +808,10 @@ int bch_btree_cache_alloc(struct cache_s c->shrink.scan_objects = bch_mca_scan; c->shrink.seeks = 4; c->shrink.batch = c->btree_pages * 2; - register_shrinker(&c->shrink); + + if (register_shrinker(&c->shrink)) + pr_warn("bcache: %s: could not register shrinker", + __func__); return 0; } Patches currently in stable-queue which might be from mlyle(a)lyle.org are queue-4.4/bcache-check-return-value-of-register_shrinker.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "ACPI / bus: Leave modalias empty for devices which are not present" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI / bus: Leave modalias empty for devices which are not present to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: acpi-bus-leave-modalias-empty-for-devices-which-are-not-present.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:14:46 CET 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Sun, 15 Oct 2017 21:24:49 +0200 Subject: ACPI / bus: Leave modalias empty for devices which are not present From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 10809bb976648ac58194a629e3d7af99e7400297 ] Most Bay and Cherry Trail devices use a generic DSDT with all possible peripheral devices present in the DSDT, with their _STA returning 0x00 or 0x0f based on AML variables which describe what is actually present on the board. Since ACPI device objects with a 0x00 status (not present) still get an entry under /sys/bus/acpi/devices, and those entry had an acpi:PNPID modalias, userspace would end up loading modules for non present hardware. This commit fixes this by leaving the modalias empty for non present devices. This results in 10 modules less being loaded with a generic distro kernel config on my Cherry Trail test-device (a GPD pocket). Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/device_sysfs.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/acpi/device_sysfs.c +++ b/drivers/acpi/device_sysfs.c @@ -146,6 +146,10 @@ static int create_pnp_modalias(struct ac int count; struct acpi_hardware_id *id; + /* Avoid unnecessarily loading modules for non present devices. */ + if (!acpi_device_is_present(acpi_dev)) + return 0; + /* * Since we skip ACPI_DT_NAMESPACE_HID from the modalias below, 0 should * be returned if ACPI_DT_NAMESPACE_HID is the only ACPI/PNP ID in the Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.4/acpi-bus-leave-modalias-empty-for-devices-which-are-not-present.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "xfs: ubsan fixes" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: ubsan fixes to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-ubsan-fixes.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: "Darrick J. Wong" <darrick.wong(a)oracle.com> Date: Mon, 27 Nov 2017 09:50:17 -0800 Subject: xfs: ubsan fixes From: "Darrick J. Wong" <darrick.wong(a)oracle.com> [ Upstream commit 22a6c83777ac7c17d6c63891beeeac24cf5da450 ] Fix some complaints from the UBSAN about signed integer addition overflows. Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Reviewed-by: Brian Foster <bfoster(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_aops.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -391,7 +391,7 @@ xfs_map_blocks( (ip->i_df.if_flags & XFS_IFEXTENTS)); ASSERT(offset <= mp->m_super->s_maxbytes); - if (offset + count > mp->m_super->s_maxbytes) + if ((xfs_ufsize_t)offset + count > mp->m_super->s_maxbytes) count = mp->m_super->s_maxbytes - offset; end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + count); offset_fsb = XFS_B_TO_FSBT(mp, offset); @@ -1295,7 +1295,7 @@ xfs_map_trim_size( if (mapping_size > size) mapping_size = size; if (offset < i_size_read(inode) && - offset + mapping_size >= i_size_read(inode)) { + (xfs_ufsize_t)offset + mapping_size >= i_size_read(inode)) { /* limit mapping to block that spans EOF */ mapping_size = roundup_64(i_size_read(inode) - offset, i_blocksize(inode)); @@ -1347,7 +1347,7 @@ __xfs_get_blocks( lockmode = xfs_ilock_data_map_shared(ip); ASSERT(offset <= mp->m_super->s_maxbytes); - if (offset + size > mp->m_super->s_maxbytes) + if ((xfs_ufsize_t)offset + size > mp->m_super->s_maxbytes) size = mp->m_super->s_maxbytes - offset; end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + size); offset_fsb = XFS_B_TO_FSBT(mp, offset); Patches currently in stable-queue which might be from darrick.wong(a)oracle.com are queue-4.9/xfs-always-free-inline-data-before-resetting-inode-fork-during-ifree.patch queue-4.9/xfs-ubsan-fixes.patch queue-4.9/xfs-fortify-xfs_alloc_buftarg-error-handling.patch queue-4.9/xfs-properly-retry-failed-dquot-items-in-case-of-error-during-buffer-writeback.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "xfs: Properly retry failed dquot items in case of error during buffer writeback" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: Properly retry failed dquot items in case of error during buffer writeback to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-properly-retry-failed-dquot-items-in-case-of-error-during-buffer-writeback.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Carlos Maiolino <cmaiolino(a)redhat.com> Date: Tue, 28 Nov 2017 08:54:10 -0800 Subject: xfs: Properly retry failed dquot items in case of error during buffer writeback From: Carlos Maiolino <cmaiolino(a)redhat.com> [ Upstream commit 373b0589dc8d58bc09c9a28d03611ae4fb216057 ] Once the inode item writeback errors is already fixed, it's time to fix the same problem in dquot code. Although there were no reports of users hitting this bug in dquot code (at least none I've seen), the bug is there and I was already planning to fix it when the correct approach to fix the inodes part was decided. This patch aims to fix the same problem in dquot code, regarding failed buffers being unable to be resubmitted once they are flush locked. Tested with the recently test-case sent to fstests list by Hou Tao. Reviewed-by: Brian Foster <bfoster(a)redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino(a)redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_dquot.c | 14 +++++++++++--- fs/xfs/xfs_dquot_item.c | 40 ++++++++++++++++++++++++++++++++++++++-- 2 files changed, 49 insertions(+), 5 deletions(-) --- a/fs/xfs/xfs_dquot.c +++ b/fs/xfs/xfs_dquot.c @@ -1004,14 +1004,22 @@ xfs_qm_dqflush_done( * holding the lock before removing the dquot from the AIL. */ if ((lip->li_flags & XFS_LI_IN_AIL) && - lip->li_lsn == qip->qli_flush_lsn) { + ((lip->li_lsn == qip->qli_flush_lsn) || + (lip->li_flags & XFS_LI_FAILED))) { /* xfs_trans_ail_delete() drops the AIL lock. */ spin_lock(&ailp->xa_lock); - if (lip->li_lsn == qip->qli_flush_lsn) + if (lip->li_lsn == qip->qli_flush_lsn) { xfs_trans_ail_delete(ailp, lip, SHUTDOWN_CORRUPT_INCORE); - else + } else { + /* + * Clear the failed state since we are about to drop the + * flush lock + */ + if (lip->li_flags & XFS_LI_FAILED) + xfs_clear_li_failed(lip); spin_unlock(&ailp->xa_lock); + } } /* --- a/fs/xfs/xfs_dquot_item.c +++ b/fs/xfs/xfs_dquot_item.c @@ -137,6 +137,26 @@ xfs_qm_dqunpin_wait( wait_event(dqp->q_pinwait, (atomic_read(&dqp->q_pincount) == 0)); } +/* + * Callback used to mark a buffer with XFS_LI_FAILED when items in the buffer + * have been failed during writeback + * + * this informs the AIL that the dquot is already flush locked on the next push, + * and acquires a hold on the buffer to ensure that it isn't reclaimed before + * dirty data makes it to disk. + */ +STATIC void +xfs_dquot_item_error( + struct xfs_log_item *lip, + struct xfs_buf *bp) +{ + struct xfs_dquot *dqp; + + dqp = DQUOT_ITEM(lip)->qli_dquot; + ASSERT(!completion_done(&dqp->q_flush)); + xfs_set_li_failed(lip, bp); +} + STATIC uint xfs_qm_dquot_logitem_push( struct xfs_log_item *lip, @@ -144,13 +164,28 @@ xfs_qm_dquot_logitem_push( __acquires(&lip->li_ailp->xa_lock) { struct xfs_dquot *dqp = DQUOT_ITEM(lip)->qli_dquot; - struct xfs_buf *bp = NULL; + struct xfs_buf *bp = lip->li_buf; uint rval = XFS_ITEM_SUCCESS; int error; if (atomic_read(&dqp->q_pincount) > 0) return XFS_ITEM_PINNED; + /* + * The buffer containing this item failed to be written back + * previously. Resubmit the buffer for IO + */ + if (lip->li_flags & XFS_LI_FAILED) { + if (!xfs_buf_trylock(bp)) + return XFS_ITEM_LOCKED; + + if (!xfs_buf_resubmit_failed_buffers(bp, lip, buffer_list)) + rval = XFS_ITEM_FLUSHING; + + xfs_buf_unlock(bp); + return rval; + } + if (!xfs_dqlock_nowait(dqp)) return XFS_ITEM_LOCKED; @@ -242,7 +277,8 @@ static const struct xfs_item_ops xfs_dqu .iop_unlock = xfs_qm_dquot_logitem_unlock, .iop_committed = xfs_qm_dquot_logitem_committed, .iop_push = xfs_qm_dquot_logitem_push, - .iop_committing = xfs_qm_dquot_logitem_committing + .iop_committing = xfs_qm_dquot_logitem_committing, + .iop_error = xfs_dquot_item_error }; /* Patches currently in stable-queue which might be from cmaiolino(a)redhat.com are queue-4.9/xfs-properly-retry-failed-dquot-items-in-case-of-error-during-buffer-writeback.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "xfs: fortify xfs_alloc_buftarg error handling" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: fortify xfs_alloc_buftarg error handling to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-fortify-xfs_alloc_buftarg-error-handling.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Michal Hocko <mhocko(a)suse.com> Date: Thu, 23 Nov 2017 17:13:40 +0100 Subject: xfs: fortify xfs_alloc_buftarg error handling From: Michal Hocko <mhocko(a)suse.com> [ Upstream commit d210a9874b8f6166579408131cb74495caff1958 ] percpu_counter_init failure path doesn't clean up &btp->bt_lru list. Call list_lru_destroy in that error path. Similarly register_shrinker error path is not handled. While it is unlikely to trigger these error path, it is not impossible especially the later might fail with large NUMAs. Let's handle the failure to make the code more robust. Noticed-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Signed-off-by: Michal Hocko <mhocko(a)suse.com> Acked-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_buf.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -1785,22 +1785,27 @@ xfs_alloc_buftarg( btp->bt_bdi = blk_get_backing_dev_info(bdev); if (xfs_setsize_buftarg_early(btp, bdev)) - goto error; + goto error_free; if (list_lru_init(&btp->bt_lru)) - goto error; + goto error_free; if (percpu_counter_init(&btp->bt_io_count, 0, GFP_KERNEL)) - goto error; + goto error_lru; btp->bt_shrinker.count_objects = xfs_buftarg_shrink_count; btp->bt_shrinker.scan_objects = xfs_buftarg_shrink_scan; btp->bt_shrinker.seeks = DEFAULT_SEEKS; btp->bt_shrinker.flags = SHRINKER_NUMA_AWARE; - register_shrinker(&btp->bt_shrinker); + if (register_shrinker(&btp->bt_shrinker)) + goto error_pcpu; return btp; -error: +error_pcpu: + percpu_counter_destroy(&btp->bt_io_count); +error_lru: + list_lru_destroy(&btp->bt_lru); +error_free: kmem_free(btp); return NULL; } Patches currently in stable-queue which might be from mhocko(a)suse.com are queue-4.9/quota-check-for-register_shrinker-failure.patch queue-4.9/xfs-fortify-xfs_alloc_buftarg-error-handling.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "xfs: always free inline data before resetting inode fork during ifree" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: always free inline data before resetting inode fork during ifree to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-always-free-inline-data-before-resetting-inode-fork-during-ifree.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: "Darrick J. Wong" <darrick.wong(a)oracle.com> Date: Wed, 22 Nov 2017 12:21:07 -0800 Subject: xfs: always free inline data before resetting inode fork during ifree From: "Darrick J. Wong" <darrick.wong(a)oracle.com> [ Upstream commit 98c4f78dcdd8cec112d1cbc5e9a792ee6e5ab7a6 ] In xfs_ifree, we reset the data/attr forks to extents format without bothering to free any inline data buffer that might still be around after all the blocks have been truncated off the file. Prior to commit 43518812d2 ("xfs: remove support for inlining data/extents into the inode fork") nobody noticed because the leftover inline data after truncation was small enough to fit inside the inline buffer inside the fork itself. However, now that we've removed the inline buffer, we /always/ have to free the inline data buffer or else we leak them like crazy. This test was found by turning on kmemleak for generic/001 or generic/388. Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_inode.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -2430,6 +2430,24 @@ retry: } /* + * Free any local-format buffers sitting around before we reset to + * extents format. + */ +static inline void +xfs_ifree_local_data( + struct xfs_inode *ip, + int whichfork) +{ + struct xfs_ifork *ifp; + + if (XFS_IFORK_FORMAT(ip, whichfork) != XFS_DINODE_FMT_LOCAL) + return; + + ifp = XFS_IFORK_PTR(ip, whichfork); + xfs_idata_realloc(ip, -ifp->if_bytes, whichfork); +} + +/* * This is called to return an inode to the inode free list. * The inode should already be truncated to 0 length and have * no pages associated with it. This routine also assumes that @@ -2466,6 +2484,9 @@ xfs_ifree( if (error) return error; + xfs_ifree_local_data(ip, XFS_DATA_FORK); + xfs_ifree_local_data(ip, XFS_ATTR_FORK); + VFS_I(ip)->i_mode = 0; /* mark incore inode as free */ ip->i_d.di_flags = 0; ip->i_d.di_dmevmask = 0; Patches currently in stable-queue which might be from darrick.wong(a)oracle.com are queue-4.9/xfs-always-free-inline-data-before-resetting-inode-fork-during-ifree.patch queue-4.9/xfs-ubsan-fixes.patch queue-4.9/xfs-fortify-xfs_alloc_buftarg-error-handling.patch queue-4.9/xfs-properly-retry-failed-dquot-items-in-case-of-error-during-buffer-writeback.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "xen-netfront: remove warning when unloading module" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xen-netfront: remove warning when unloading module to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xen-netfront-remove-warning-when-unloading-module.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Eduardo Otubo <otubo(a)redhat.com> Date: Thu, 23 Nov 2017 15:18:35 +0100 Subject: xen-netfront: remove warning when unloading module From: Eduardo Otubo <otubo(a)redhat.com> [ Upstream commit 5b5971df3bc2775107ddad164018a8a8db633b81 ] v2: * Replace busy wait with wait_event()/wake_up_all() * Cannot garantee that at the time xennet_remove is called, the xen_netback state will not be XenbusStateClosed, so added a condition for that * There's a small chance for the xen_netback state is XenbusStateUnknown by the time the xen_netfront switches to Closed, so added a condition for that. When unloading module xen_netfront from guest, dmesg would output warning messages like below: [ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use! [ 105.236839] deferring g.e. 0x903 (pfn 0x35805) This problem relies on netfront and netback being out of sync. By the time netfront revokes the g.e.'s netback didn't have enough time to free all of them, hence displaying the warnings on dmesg. The trick here is to make netfront to wait until netback frees all the g.e.'s and only then continue to cleanup for the module removal, and this is done by manipulating both device states. Signed-off-by: Eduardo Otubo <otubo(a)redhat.com> Acked-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/xen-netfront.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -86,6 +86,8 @@ struct netfront_cb { /* IRQ name is queue name with "-tx" or "-rx" appended */ #define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3) +static DECLARE_WAIT_QUEUE_HEAD(module_unload_q); + struct netfront_stats { u64 packets; u64 bytes; @@ -2051,10 +2053,12 @@ static void netback_changed(struct xenbu break; case XenbusStateClosed: + wake_up_all(&module_unload_q); if (dev->state == XenbusStateClosed) break; /* Missed the backend's CLOSING state -- fallthrough */ case XenbusStateClosing: + wake_up_all(&module_unload_q); xenbus_frontend_closed(dev); break; } @@ -2160,6 +2164,20 @@ static int xennet_remove(struct xenbus_d dev_dbg(&dev->dev, "%s\n", dev->nodename); + if (xenbus_read_driver_state(dev->otherend) != XenbusStateClosed) { + xenbus_switch_state(dev, XenbusStateClosing); + wait_event(module_unload_q, + xenbus_read_driver_state(dev->otherend) == + XenbusStateClosing); + + xenbus_switch_state(dev, XenbusStateClosed); + wait_event(module_unload_q, + xenbus_read_driver_state(dev->otherend) == + XenbusStateClosed || + xenbus_read_driver_state(dev->otherend) == + XenbusStateUnknown); + } + xennet_disconnect_backend(info); unregister_netdev(info->netdev); Patches currently in stable-queue which might be from otubo(a)redhat.com are queue-4.9/xen-netfront-remove-warning-when-unloading-module.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: gadget: don't dereference g until after it has been null checked" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: don't dereference g until after it has been null checked to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Colin Ian King <colin.king(a)canonical.com> Date: Tue, 14 Nov 2017 16:18:28 +0000 Subject: usb: gadget: don't dereference g until after it has been null checked From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit b2fc059fa549fe6881d4c1f8d698b0f50bcd16ec ] Avoid dereferencing pointer g until after g has been sanity null checked; move the assignment of cdev much later when it is required into a more local scope. Detected by CoverityScan, CID#1222135 ("Dereference before null check") Fixes: b785ea7ce662 ("usb: gadget: composite: fix ep->maxburst initialization") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/composite.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -150,7 +150,6 @@ int config_ep_by_speed(struct usb_gadget struct usb_function *f, struct usb_ep *_ep) { - struct usb_composite_dev *cdev = get_gadget_data(g); struct usb_endpoint_descriptor *chosen_desc = NULL; struct usb_descriptor_header **speed_desc = NULL; @@ -229,8 +228,12 @@ ep_found: _ep->maxburst = comp_desc->bMaxBurst + 1; break; default: - if (comp_desc->bMaxBurst != 0) + if (comp_desc->bMaxBurst != 0) { + struct usb_composite_dev *cdev; + + cdev = get_gadget_data(g); ERROR(cdev, "ep0 bMaxBurst must be 0\n"); + } _ep->maxburst = 1; break; } Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-4.9/usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "SUNRPC: Allow connect to return EHOSTUNREACH" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled SUNRPC: Allow connect to return EHOSTUNREACH to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sunrpc-allow-connect-to-return-ehostunreach.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Trond Myklebust <trond.myklebust(a)primarydata.com> Date: Fri, 24 Nov 2017 12:00:24 -0500 Subject: SUNRPC: Allow connect to return EHOSTUNREACH From: Trond Myklebust <trond.myklebust(a)primarydata.com> [ Upstream commit 4ba161a793d5f43757c35feff258d9f20a082940 ] Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> Tested-by: Dmitry Vyukov <dvyukov(a)google.com> Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sunrpc/xprtsock.c | 1 + 1 file changed, 1 insertion(+) --- a/net/sunrpc/xprtsock.c +++ b/net/sunrpc/xprtsock.c @@ -2381,6 +2381,7 @@ static void xs_tcp_setup_socket(struct w case -ECONNREFUSED: case -ECONNRESET: case -ENETUNREACH: + case -EHOSTUNREACH: case -EADDRINUSE: case -ENOBUFS: /* retry with existing socket, after a delay */ Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are queue-4.9/nfsd-ensure-we-check-stateid-validity-in-the-seqid-operation-checks.patch queue-4.9/sunrpc-allow-connect-to-return-ehostunreach.patch queue-4.9/nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-rtl8188eu-fix-incorrect-response-to-siocgiwessid.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Larry Finger <Larry.Finger(a)lwfinger.net> Date: Sat, 25 Nov 2017 13:32:38 -0600 Subject: staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID From: Larry Finger <Larry.Finger(a)lwfinger.net> [ Upstream commit b77992d2df9e47144354d1b25328b180afa33442 ] When not associated with an AP, wifi device drivers should respond to the SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the behavior expected by dhcpcd. Currently, this driver returns an error code (-1) from the ioctl call, which causes dhcpcd to assume that the device is not a wireless interface and therefore it fails to work correctly with it thereafter. This problem was reported and tested at https://github.com/lwfinger/rtl8188eu/issues/234. Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) --- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c +++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c @@ -1397,19 +1397,13 @@ static int rtw_wx_get_essid(struct net_d if ((check_fwstate(pmlmepriv, _FW_LINKED)) || (check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE))) { len = pcur_bss->Ssid.SsidLength; - - wrqu->essid.length = len; - memcpy(extra, pcur_bss->Ssid.Ssid, len); - - wrqu->essid.flags = 1; } else { - ret = -1; - goto exit; + len = 0; + *extra = 0; } - -exit: - + wrqu->essid.length = len; + wrqu->essid.flags = 1; return ret; } Patches currently in stable-queue which might be from Larry.Finger(a)lwfinger.net are queue-4.9/staging-rtl8188eu-fix-incorrect-response-to-siocgiwessid.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-ufs-ufshcd-fix-potential-null-pointer-dereference-in-ufshcd_config_vreg.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> Date: Mon, 20 Nov 2017 08:12:29 -0600 Subject: scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> [ Upstream commit 727535903bea924c4f73abb202c4b3e85fff0ca4 ] _vreg_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _vreg_ has been null checked. This issue was detected with the help of Coccinelle. Fixes: aa4976130934 ("ufs: Add regulator enable support") Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> Reviewed-by: Subhash Jadavani <subhashj(a)codeaurora.org> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/ufs/ufshcd.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -5327,12 +5327,15 @@ static int ufshcd_config_vreg(struct dev struct ufs_vreg *vreg, bool on) { int ret = 0; - struct regulator *reg = vreg->reg; - const char *name = vreg->name; + struct regulator *reg; + const char *name; int min_uV, uA_load; BUG_ON(!vreg); + reg = vreg->reg; + name = vreg->name; + if (regulator_count_voltages(reg) > 0) { min_uV = on ? vreg->min_uV : 0; ret = regulator_set_voltage(reg, min_uV, vreg->max_uV); Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are queue-4.9/scsi-ufs-ufshcd-fix-potential-null-pointer-dereference-in-ufshcd_config_vreg.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-aacraid-prevent-crash-in-case-of-free-interrupt-during-scsi-eh-path.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 19:14:55 -0200 Subject: scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com> [ Upstream commit e4717292ddebcfe231651b5aff9fa19ca158d178 ] As part of the scsi EH path, aacraid performs a reinitialization of the adapter, which encompass freeing resources and IRQs, NULLifying lots of pointers, and then initialize it all over again. We've identified a problem during the free IRQ portion of this path if CONFIG_DEBUG_SHIRQ is enabled on kernel config file. Happens that, in case this flag was set, right after free_irq() effectively clears the interrupt, it checks if it was requested as IRQF_SHARED. In positive case, it performs another call to the IRQ handler on driver. Problem is: since aacraid currently free some resources *before* freeing the IRQ, once free_irq() path calls the handler again (due to CONFIG_DEBUG_SHIRQ), aacraid crashes due to NULL pointer dereference with the following trace: aac_src_intr_message+0xf8/0x740 [aacraid] __free_irq+0x33c/0x4a0 free_irq+0x78/0xb0 aac_free_irq+0x13c/0x150 [aacraid] aac_reset_adapter+0x2e8/0x970 [aacraid] aac_eh_reset+0x3a8/0x5d0 [aacraid] scsi_try_host_reset+0x74/0x180 scsi_eh_ready_devs+0xc70/0x1510 scsi_error_handler+0x624/0xa20 This patch prevents the crash by changing the order of the deinitialization in this path of aacraid: first we clear the IRQ, then we free other resources. No functional change intended. Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com> Reviewed-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/aacraid/commsup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/aacraid/commsup.c +++ b/drivers/scsi/aacraid/commsup.c @@ -1416,13 +1416,13 @@ static int _aac_reset_adapter(struct aac * will ensure that i/o is queisced and the card is flushed in that * case. */ + aac_free_irq(aac); aac_fib_map_free(aac); pci_free_consistent(aac->pdev, aac->comm_size, aac->comm_addr, aac->comm_phys); aac->comm_addr = NULL; aac->comm_phys = 0; kfree(aac->queues); aac->queues = NULL; - aac_free_irq(aac); kfree(aac->fsa_dev); aac->fsa_dev = NULL; quirks = aac_get_driver_ident(index)->quirks; Patches currently in stable-queue which might be from gpiccoli(a)linux.vnet.ibm.com are queue-4.9/scsi-aacraid-prevent-crash-in-case-of-free-interrupt-during-scsi-eh-path.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "reiserfs: remove unneeded i_version bump" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled reiserfs: remove unneeded i_version bump to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: reiserfs-remove-unneeded-i_version-bump.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Jeff Layton <jlayton(a)redhat.com> Date: Mon, 30 Oct 2017 11:20:15 -0400 Subject: reiserfs: remove unneeded i_version bump From: Jeff Layton <jlayton(a)redhat.com> [ Upstream commit 9f97df50c52c2887432debb6238f4e43567386a5 ] The i_version field in reiserfs is not initialized and is only ever updated here. Nothing ever views it, so just remove it. Signed-off-by: Jeff Layton <jlayton(a)redhat.com> Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/reiserfs/super.c | 1 - 1 file changed, 1 deletion(-) --- a/fs/reiserfs/super.c +++ b/fs/reiserfs/super.c @@ -2521,7 +2521,6 @@ out: return err; if (inode->i_size < off + len - towrite) i_size_write(inode, off + len - towrite); - inode->i_version++; inode->i_mtime = inode->i_ctime = current_time(inode); mark_inode_dirty(inode); return len - towrite; Patches currently in stable-queue which might be from jlayton(a)redhat.com are queue-4.9/lockd-fix-list_add-double-add-caused-by-legacy-signal-interface.patch queue-4.9/reiserfs-remove-unneeded-i_version-bump.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "quota: Check for register_shrinker() failure." has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled quota: Check for register_shrinker() failure. to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: quota-check-for-register_shrinker-failure.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Date: Wed, 29 Nov 2017 22:34:50 +0900 Subject: quota: Check for register_shrinker() failure. From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> [ Upstream commit 88bc0ede8d35edc969350852894dc864a2dc1859 ] register_shrinker() might return -ENOMEM error since Linux 3.12. Call panic() as with other failure checks in this function if register_shrinker() failed. Fixes: 1d3d4437eae1 ("vmscan: per-node deferred work") Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Cc: Jan Kara <jack(a)suse.com> Cc: Michal Hocko <mhocko(a)suse.com> Reviewed-by: Michal Hocko <mhocko(a)suse.com> Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/quota/dquot.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/quota/dquot.c +++ b/fs/quota/dquot.c @@ -2985,7 +2985,8 @@ static int __init dquot_init(void) pr_info("VFS: Dquot-cache hash table entries: %ld (order %ld," " %ld bytes)\n", nr_hash, order, (PAGE_SIZE << order)); - register_shrinker(&dqcache_shrinker); + if (register_shrinker(&dqcache_shrinker)) + panic("Cannot register dquot shrinker"); return 0; } Patches currently in stable-queue which might be from penguin-kernel(a)I-love.SAKURA.ne.jp are queue-4.9/quota-check-for-register_shrinker-failure.patch queue-4.9/xfs-fortify-xfs_alloc_buftarg-error-handling.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "openvswitch: fix the incorrect flow action alloc size" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled openvswitch: fix the incorrect flow action alloc size to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: openvswitch-fix-the-incorrect-flow-action-alloc-size.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: zhangliping <zhangliping02(a)baidu.com> Date: Sat, 25 Nov 2017 22:02:12 +0800 Subject: openvswitch: fix the incorrect flow action alloc size From: zhangliping <zhangliping02(a)baidu.com> [ Upstream commit 67c8d22a73128ff910e2287567132530abcf5b71 ] If we want to add a datapath flow, which has more than 500 vxlan outputs' action, we will get the following error reports: openvswitch: netlink: Flow action size 32832 bytes exceeds max openvswitch: netlink: Flow action size 32832 bytes exceeds max openvswitch: netlink: Actions may not be safe on all matching packets ... ... It seems that we can simply enlarge the MAX_ACTIONS_BUFSIZE to fix it, but this is not the root cause. For example, for a vxlan output action, we need about 60 bytes for the nlattr, but after it is converted to the flow action, it only occupies 24 bytes. This means that we can still support more than 1000 vxlan output actions for a single datapath flow under the the current 32k max limitation. So even if the nla_len(attr) is larger than MAX_ACTIONS_BUFSIZE, we shouldn't report EINVAL and keep it move on, as the judgement can be done by the reserve_sfa_size. Signed-off-by: zhangliping <zhangliping02(a)baidu.com> Acked-by: Pravin B Shelar <pshelar(a)ovn.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/openvswitch/flow_netlink.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- a/net/openvswitch/flow_netlink.c +++ b/net/openvswitch/flow_netlink.c @@ -1789,14 +1789,11 @@ int ovs_nla_put_mask(const struct sw_flo #define MAX_ACTIONS_BUFSIZE (32 * 1024) -static struct sw_flow_actions *nla_alloc_flow_actions(int size, bool log) +static struct sw_flow_actions *nla_alloc_flow_actions(int size) { struct sw_flow_actions *sfa; - if (size > MAX_ACTIONS_BUFSIZE) { - OVS_NLERR(log, "Flow action size %u bytes exceeds max", size); - return ERR_PTR(-EINVAL); - } + WARN_ON_ONCE(size > MAX_ACTIONS_BUFSIZE); sfa = kmalloc(sizeof(*sfa) + size, GFP_KERNEL); if (!sfa) @@ -1869,12 +1866,15 @@ static struct nlattr *reserve_sfa_size(s new_acts_size = ksize(*sfa) * 2; if (new_acts_size > MAX_ACTIONS_BUFSIZE) { - if ((MAX_ACTIONS_BUFSIZE - next_offset) < req_size) + if ((MAX_ACTIONS_BUFSIZE - next_offset) < req_size) { + OVS_NLERR(log, "Flow action size exceeds max %u", + MAX_ACTIONS_BUFSIZE); return ERR_PTR(-EMSGSIZE); + } new_acts_size = MAX_ACTIONS_BUFSIZE; } - acts = nla_alloc_flow_actions(new_acts_size, log); + acts = nla_alloc_flow_actions(new_acts_size); if (IS_ERR(acts)) return (void *)acts; @@ -2500,7 +2500,7 @@ int ovs_nla_copy_actions(struct net *net { int err; - *sfa = nla_alloc_flow_actions(nla_len(attr), log); + *sfa = nla_alloc_flow_actions(min(nla_len(attr), MAX_ACTIONS_BUFSIZE)); if (IS_ERR(*sfa)) return PTR_ERR(*sfa); Patches currently in stable-queue which might be from zhangliping02(a)baidu.com are queue-4.9/openvswitch-fix-the-incorrect-flow-action-alloc-size.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "nfsd: Ensure we check stateid validity in the seqid operation checks" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nfsd: Ensure we check stateid validity in the seqid operation checks to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsd-ensure-we-check-stateid-validity-in-the-seqid-operation-checks.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Trond Myklebust <trond.myklebust(a)primarydata.com> Date: Fri, 3 Nov 2017 08:00:15 -0400 Subject: nfsd: Ensure we check stateid validity in the seqid operation checks From: Trond Myklebust <trond.myklebust(a)primarydata.com> [ Upstream commit 9271d7e509c1bfc0b9a418caec29ec8d1ac38270 ] After taking the stateid st_mutex, we want to know that the stateid still represents valid state before performing any non-idempotent actions. Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfs4state.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -5178,15 +5178,9 @@ static __be32 nfs4_seqid_op_checks(struc status = nfsd4_check_seqid(cstate, sop, seqid); if (status) return status; - if (stp->st_stid.sc_type == NFS4_CLOSED_STID - || stp->st_stid.sc_type == NFS4_REVOKED_DELEG_STID) - /* - * "Closed" stateid's exist *only* to return - * nfserr_replay_me from the previous step, and - * revoked delegations are kept only for free_stateid. - */ - return nfserr_bad_stateid; - mutex_lock(&stp->st_mutex); + status = nfsd4_lock_ol_stateid(stp); + if (status != nfs_ok) + return status; status = check_stateid_generation(stateid, &stp->st_stid.sc_stateid, nfsd4_has_session(cstate)); if (status == nfs_ok) status = nfs4_check_fh(current_fh, &stp->st_stid); Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are queue-4.9/nfsd-ensure-we-check-stateid-validity-in-the-seqid-operation-checks.patch queue-4.9/sunrpc-allow-connect-to-return-ehostunreach.patch queue-4.9/nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0)" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0) to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Trond Myklebust <trond.myklebust(a)primarydata.com> Date: Fri, 3 Nov 2017 08:00:12 -0400 Subject: nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0) From: Trond Myklebust <trond.myklebust(a)primarydata.com> [ Upstream commit fb500a7cfee7f2f447d2bbf30cb59629feab6ac1 ] Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfs4state.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -63,6 +63,9 @@ static const stateid_t zero_stateid = { static const stateid_t currentstateid = { .si_generation = 1, }; +static const stateid_t close_stateid = { + .si_generation = 0xffffffffU, +}; static u64 current_sessionid = 1; @@ -5407,6 +5410,11 @@ nfsd4_close(struct svc_rqst *rqstp, stru nfsd4_close_open_stateid(stp); mutex_unlock(&stp->st_mutex); + /* See RFC5661 sectionm 18.2.4 */ + if (stp->st_stid.sc_client->cl_minorversion) + memcpy(&close->cl_stateid, &close_stateid, + sizeof(close->cl_stateid)); + /* put reference from nfs4_preprocess_seqid_op */ nfs4_put_stid(&stp->st_stid); out: Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are queue-4.9/nfsd-ensure-we-check-stateid-validity-in-the-seqid-operation-checks.patch queue-4.9/sunrpc-allow-connect-to-return-ehostunreach.patch queue-4.9/nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "nfsd: check for use of the closed special stateid" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nfsd: check for use of the closed special stateid to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsd-check-for-use-of-the-closed-special-stateid.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Andrew Elble <aweits(a)rit.edu> Date: Thu, 9 Nov 2017 13:41:10 -0500 Subject: nfsd: check for use of the closed special stateid From: Andrew Elble <aweits(a)rit.edu> [ Upstream commit ae254dac721d44c0bfebe2795df87459e2e88219 ] Prevent the use of the closed (invalid) special stateid by clients. Signed-off-by: Andrew Elble <aweits(a)rit.edu> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfs4state.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -72,6 +72,7 @@ static u64 current_sessionid = 1; #define ZERO_STATEID(stateid) (!memcmp((stateid), &zero_stateid, sizeof(stateid_t))) #define ONE_STATEID(stateid) (!memcmp((stateid), &one_stateid, sizeof(stateid_t))) #define CURRENT_STATEID(stateid) (!memcmp((stateid), &currentstateid, sizeof(stateid_t))) +#define CLOSE_STATEID(stateid) (!memcmp((stateid), &close_stateid, sizeof(stateid_t))) /* forward declarations */ static bool check_for_locks(struct nfs4_file *fp, struct nfs4_lockowner *lowner); @@ -4869,7 +4870,8 @@ static __be32 nfsd4_validate_stateid(str struct nfs4_stid *s; __be32 status = nfserr_bad_stateid; - if (ZERO_STATEID(stateid) || ONE_STATEID(stateid)) + if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) || + CLOSE_STATEID(stateid)) return status; /* Client debugging aid. */ if (!same_clid(&stateid->si_opaque.so_clid, &cl->cl_clientid)) { @@ -4927,7 +4929,8 @@ nfsd4_lookup_stateid(struct nfsd4_compou else if (typemask & NFS4_DELEG_STID) typemask |= NFS4_REVOKED_DELEG_STID; - if (ZERO_STATEID(stateid) || ONE_STATEID(stateid)) + if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) || + CLOSE_STATEID(stateid)) return nfserr_bad_stateid; status = lookup_clientid(&stateid->si_opaque.so_clid, cstate, nn); if (status == nfserr_stale_clientid) { Patches currently in stable-queue which might be from aweits(a)rit.edu are queue-4.9/nfsd-check-for-use-of-the-closed-special-stateid.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-ethernet-xilinx-mark-xilinx_ll_temac-broken-on-64-bit.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Wed, 29 Nov 2017 11:01:09 +0100 Subject: net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 15bfe05c8d6386f1a90e9340d15336e85e32aad6 ] On 64-bit (e.g. powerpc64/allmodconfig): drivers/net/ethernet/xilinx/ll_temac_main.c: In function 'temac_start_xmit_done': drivers/net/ethernet/xilinx/ll_temac_main.c:633:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dev_kfree_skb_irq((struct sk_buff *)cur_p->app4); ^ cdmac_bd.app4 is u32, so it is too small to hold a kernel pointer. Note that several other fields in struct cdmac_bd are also too small to hold physical addresses on 64-bit platforms. Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/xilinx/Kconfig | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/ethernet/xilinx/Kconfig +++ b/drivers/net/ethernet/xilinx/Kconfig @@ -34,6 +34,7 @@ config XILINX_AXI_EMAC config XILINX_LL_TEMAC tristate "Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver" depends on (PPC || MICROBLAZE) + depends on !64BIT || BROKEN select PHYLIB ---help--- This driver supports the Xilinx 10/100/1000 LocalLink TEMAC Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-4.9/net-ethernet-xilinx-mark-xilinx_ll_temac-broken-on-64-bit.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "media: usbtv: add a new usbid" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: usbtv: add a new usbid to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-usbtv-add-a-new-usbid.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Icenowy Zheng <icenowy(a)aosc.io> Date: Sun, 16 Apr 2017 02:51:16 -0400 Subject: media: usbtv: add a new usbid From: Icenowy Zheng <icenowy(a)aosc.io> [ Upstream commit 04226916d2360f56d57ad00bc48d2d1854d1e0b0 ] A new usbid of UTV007 is found in a newly bought device. The usbid is 1f71:3301. The ID on the chip is: UTV007 A89029.1 1520L18K1 Both video and audio is tested with the modified usbtv driver. Signed-off-by: Icenowy Zheng <icenowy(a)aosc.io> Acked-by: Lubomir Rintel <lkundrak(a)v3.sk> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/usb/usbtv/usbtv-core.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/media/usb/usbtv/usbtv-core.c +++ b/drivers/media/usb/usbtv/usbtv-core.c @@ -141,6 +141,7 @@ static void usbtv_disconnect(struct usb_ static struct usb_device_id usbtv_id_table[] = { { USB_DEVICE(0x1b71, 0x3002) }, + { USB_DEVICE(0x1f71, 0x3301) }, {} }; MODULE_DEVICE_TABLE(usb, usbtv_id_table); Patches currently in stable-queue which might be from icenowy(a)aosc.io are queue-4.9/media-usbtv-add-a-new-usbid.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "mac80211: fix the update of path metric for RANN frame" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: fix the update of path metric for RANN frame to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mac80211-fix-the-update-of-path-metric-for-rann-frame.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Chun-Yeow Yeoh <yeohchunyeow(a)gmail.com> Date: Tue, 14 Nov 2017 23:20:05 +0800 Subject: mac80211: fix the update of path metric for RANN frame From: Chun-Yeow Yeoh <yeohchunyeow(a)gmail.com> [ Upstream commit fbbdad5edf0bb59786a51b94a9d006bc8c2da9a2 ] The previous path metric update from RANN frame has not considered the own link metric toward the transmitting mesh STA. Fix this. Reported-by: Michael65535 Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow(a)gmail.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/mesh_hwmp.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) --- a/net/mac80211/mesh_hwmp.c +++ b/net/mac80211/mesh_hwmp.c @@ -788,7 +788,7 @@ static void hwmp_rann_frame_process(stru struct mesh_path *mpath; u8 ttl, flags, hopcount; const u8 *orig_addr; - u32 orig_sn, metric, metric_txsta, interval; + u32 orig_sn, new_metric, orig_metric, last_hop_metric, interval; bool root_is_gate; ttl = rann->rann_ttl; @@ -799,7 +799,7 @@ static void hwmp_rann_frame_process(stru interval = le32_to_cpu(rann->rann_interval); hopcount = rann->rann_hopcount; hopcount++; - metric = le32_to_cpu(rann->rann_metric); + orig_metric = le32_to_cpu(rann->rann_metric); /* Ignore our own RANNs */ if (ether_addr_equal(orig_addr, sdata->vif.addr)) @@ -816,7 +816,10 @@ static void hwmp_rann_frame_process(stru return; } - metric_txsta = airtime_link_metric_get(local, sta); + last_hop_metric = airtime_link_metric_get(local, sta); + new_metric = orig_metric + last_hop_metric; + if (new_metric < orig_metric) + new_metric = MAX_METRIC; mpath = mesh_path_lookup(sdata, orig_addr); if (!mpath) { @@ -829,7 +832,7 @@ static void hwmp_rann_frame_process(stru } if (!(SN_LT(mpath->sn, orig_sn)) && - !(mpath->sn == orig_sn && metric < mpath->rann_metric)) { + !(mpath->sn == orig_sn && new_metric < mpath->rann_metric)) { rcu_read_unlock(); return; } @@ -847,7 +850,7 @@ static void hwmp_rann_frame_process(stru } mpath->sn = orig_sn; - mpath->rann_metric = metric + metric_txsta; + mpath->rann_metric = new_metric; mpath->is_root = true; /* Recording RANNs sender address to send individually * addressed PREQs destined for root mesh STA */ @@ -867,7 +870,7 @@ static void hwmp_rann_frame_process(stru mesh_path_sel_frame_tx(MPATH_RANN, flags, orig_addr, orig_sn, 0, NULL, 0, broadcast_addr, hopcount, ttl, interval, - metric + metric_txsta, 0, sdata); + new_metric, 0, sdata); } rcu_read_unlock(); Patches currently in stable-queue which might be from yeohchunyeow(a)gmail.com are queue-4.9/mac80211-fix-the-update-of-path-metric-for-rann-frame.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "lockd: fix "list_add double add" caused by legacy signal interface" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled lockd: fix "list_add double add" caused by legacy signal interface to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: lockd-fix-list_add-double-add-caused-by-legacy-signal-interface.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Vasily Averin <vvs(a)virtuozzo.com> Date: Mon, 13 Nov 2017 07:25:40 +0300 Subject: lockd: fix "list_add double add" caused by legacy signal interface From: Vasily Averin <vvs(a)virtuozzo.com> [ Upstream commit 81833de1a46edce9ca20cfe079872ac1c20ef359 ] restart_grace() uses hardcoded init_net. It can cause to "list_add double add" in following scenario: 1) nfsd and lockd was started in several net namespaces 2) nfsd in init_net was stopped (lockd was not stopped because it have users from another net namespaces) 3) lockd got signal, called restart_grace() -> set_grace_period() and enabled lock_manager in hardcoded init_net. 4) nfsd in init_net is started again, its lockd_up() calls set_grace_period() and tries to add lock_manager into init_net 2nd time. Jeff Layton suggest: "Make it safe to call locks_start_grace multiple times on the same lock_manager. If it's already on the global grace_list, then don't try to add it again. (But we don't intentionally add twice, so for now we WARN about that case.) With this change, we also need to ensure that the nfsd4 lock manager initializes the list before we call locks_start_grace. While we're at it, move the rest of the nfsd_net initialization into nfs4_state_create_net. I see no reason to have it spread over two functions like it is today." Suggested patch was updated to generate warning in described situation. Suggested-by: Jeff Layton <jlayton(a)redhat.com> Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfs_common/grace.c | 6 +++++- fs/nfsd/nfs4state.c | 7 ++++--- 2 files changed, 9 insertions(+), 4 deletions(-) --- a/fs/nfs_common/grace.c +++ b/fs/nfs_common/grace.c @@ -30,7 +30,11 @@ locks_start_grace(struct net *net, struc struct list_head *grace_list = net_generic(net, grace_net_id); spin_lock(&grace_lock); - list_add(&lm->list, grace_list); + if (list_empty(&lm->list)) + list_add(&lm->list, grace_list); + else + WARN(1, "double list_add attempt detected in net %x %s\n", + net->ns.inum, (net == &init_net) ? "(init_net)" : ""); spin_unlock(&grace_lock); } EXPORT_SYMBOL_GPL(locks_start_grace); --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -7012,6 +7012,10 @@ static int nfs4_state_create_net(struct INIT_LIST_HEAD(&nn->sessionid_hashtbl[i]); nn->conf_name_tree = RB_ROOT; nn->unconf_name_tree = RB_ROOT; + nn->boot_time = get_seconds(); + nn->grace_ended = false; + nn->nfsd4_manager.block_opens = true; + INIT_LIST_HEAD(&nn->nfsd4_manager.list); INIT_LIST_HEAD(&nn->client_lru); INIT_LIST_HEAD(&nn->close_lru); INIT_LIST_HEAD(&nn->del_recall_lru); @@ -7069,9 +7073,6 @@ nfs4_state_start_net(struct net *net) ret = nfs4_state_create_net(net); if (ret) return ret; - nn->boot_time = get_seconds(); - nn->grace_ended = false; - nn->nfsd4_manager.block_opens = true; locks_start_grace(net, &nn->nfsd4_manager); nfsd4_client_tracking_init(net); printk(KERN_INFO "NFSD: starting %ld-second grace period (net %p)\n", Patches currently in stable-queue which might be from vvs(a)virtuozzo.com are queue-4.9/lockd-fix-list_add-double-add-caused-by-legacy-signal-interface.patch queue-4.9/grace-replace-bug_on-by-warn_once-in-exit_net-hook.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: ioapic: Preserve read-only values in the redirection table" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: ioapic: Preserve read-only values in the redirection table to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:58:04 CET 2018 From: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Date: Sun, 5 Nov 2017 15:52:33 +0200 Subject: KVM: x86: ioapic: Preserve read-only values in the redirection table From: Nikita Leshenko <nikita.leshchenko(a)oracle.com> [ Upstream commit b200dded0a6974a3b69599832b2203483920ab25 ] According to 82093AA (IOAPIC) manual, Remote IRR and Delivery Status are read-only. QEMU implements the bits as RO in commit 479c2a1cb7fb ("ioapic: keep RO bits for IOAPIC entry"). Signed-off-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Reviewed-by: Liran Alon <liran.alon(a)oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Reviewed-by: Steve Rutherford <srutherford(a)google.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/ioapic.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/arch/x86/kvm/ioapic.c +++ b/arch/x86/kvm/ioapic.c @@ -278,6 +278,7 @@ static void ioapic_write_indirect(struct { unsigned index; bool mask_before, mask_after; + int old_remote_irr, old_delivery_status; union kvm_ioapic_redirect_entry *e; switch (ioapic->ioregsel) { @@ -300,6 +301,9 @@ static void ioapic_write_indirect(struct return; e = &ioapic->redirtbl[index]; mask_before = e->fields.mask; + /* Preserve read-only fields */ + old_remote_irr = e->fields.remote_irr; + old_delivery_status = e->fields.delivery_status; if (ioapic->ioregsel & 1) { e->bits &= 0xffffffff; e->bits |= (u64) val << 32; @@ -307,6 +311,8 @@ static void ioapic_write_indirect(struct e->bits &= ~0xffffffffULL; e->bits |= (u32) val; } + e->fields.remote_irr = old_remote_irr; + e->fields.delivery_status = old_delivery_status; /* * Some OSes (Linux, Xen) assume that Remote IRR bit will Patches currently in stable-queue which might be from nikita.leshchenko(a)oracle.com are queue-4.9/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.9/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.9/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch queue-4.9/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.9/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:58:04 CET 2018 From: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Date: Sun, 5 Nov 2017 15:52:29 +0200 Subject: KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race From: Nikita Leshenko <nikita.leshchenko(a)oracle.com> [ Upstream commit 0fc5a36dd6b345eb0d251a65c236e53bead3eef7 ] KVM uses ioapic_handled_vectors to track vectors that need to notify the IOAPIC on EOI. The problem is that IOAPIC can be reconfigured while an interrupt with old configuration is pending or running and ioapic_handled_vectors only remembers the newest configuration; thus EOI from the old interrupt is not delievered to the IOAPIC. A previous commit db2bdcbbbd32 ("KVM: x86: fix edge EOI and IOAPIC reconfig race") addressed this issue by adding pending edge-triggered interrupts to ioapic_handled_vectors, fixing this race for edge-triggered interrupts. The commit explicitly ignored level-triggered interrupts, but this race applies to them as well: 1) IOAPIC sends a level triggered interrupt vector to VCPU0 2) VCPU0's handler deasserts the irq line and reconfigures the IOAPIC to route the vector to VCPU1. The reconfiguration rewrites only the upper 32 bits of the IOREDTBLn register. (Causes KVM to update ioapic_handled_vectors for VCPU0 and it no longer includes the vector.) 3) VCPU0 sends EOI for the vector, but it's not delievered to the IOAPIC because the ioapic_handled_vectors doesn't include the vector. 4) New interrupts are not delievered to VCPU1 because remote_irr bit is set forever. Therefore, the correct behavior is to add all pending and running interrupts to ioapic_handled_vectors. This commit introduces a slight performance hit similar to commit db2bdcbbbd32 ("KVM: x86: fix edge EOI and IOAPIC reconfig race") for the rare case that the vector is reused by a non-IOAPIC source on VCPU0. We prefer to keep solution simple and not handle this case just as the original commit does. Fixes: db2bdcbbbd32 ("KVM: x86: fix edge EOI and IOAPIC reconfig race") Signed-off-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Reviewed-by: Liran Alon <liran.alon(a)oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/ioapic.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c index 6e219e5c07d2..a7ac8688bba8 100644 --- a/arch/x86/kvm/ioapic.c +++ b/arch/x86/kvm/ioapic.c @@ -257,8 +257,7 @@ void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, ulong *ioapic_handled_vectors) index == RTC_GSI) { if (kvm_apic_match_dest(vcpu, NULL, 0, e->fields.dest_id, e->fields.dest_mode) || - (e->fields.trig_mode == IOAPIC_EDGE_TRIG && - kvm_apic_pending_eoi(vcpu, e->fields.vector))) + kvm_apic_pending_eoi(vcpu, e->fields.vector)) __set_bit(e->fields.vector, ioapic_handled_vectors); } -- 2.16.1 Patches currently in stable-queue which might be from nikita.leshchenko(a)oracle.com are queue-4.9/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.9/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.9/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch queue-4.9/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.9/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: ioapic: Clear Remote IRR when entry is switched to edge-triggered" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: ioapic: Clear Remote IRR when entry is switched to edge-triggered to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:58:04 CET 2018 From: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Date: Sun, 5 Nov 2017 15:52:32 +0200 Subject: KVM: x86: ioapic: Clear Remote IRR when entry is switched to edge-triggered From: Nikita Leshenko <nikita.leshchenko(a)oracle.com> [ Upstream commit a8bfec2930525808c01f038825d1df3904638631 ] Some OSes (Linux, Xen) use this behavior to clear the Remote IRR bit for IOAPICs without an EOI register. They simulate the EOI message manually by changing the trigger mode to edge and then back to level, with the entry being masked during this. QEMU implements this feature in commit ed1263c363c9 ("ioapic: clear remote irr bit for edge-triggered interrupts") As a side effect, this commit removes an incorrect behavior where Remote IRR was cleared when the redirection table entry was rewritten. This is not consistent with the manual and also opens an opportunity for a strange behavior when a redirection table entry is modified from an interrupt handler that handles the same entry: The modification will clear the Remote IRR bit even though the interrupt handler is still running. Signed-off-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Reviewed-by: Liran Alon <liran.alon(a)oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Reviewed-by: Steve Rutherford <srutherford(a)google.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/ioapic.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c index a7ac8688bba8..4b573c8694ac 100644 --- a/arch/x86/kvm/ioapic.c +++ b/arch/x86/kvm/ioapic.c @@ -306,8 +306,17 @@ static void ioapic_write_indirect(struct kvm_ioapic *ioapic, u32 val) } else { e->bits &= ~0xffffffffULL; e->bits |= (u32) val; - e->fields.remote_irr = 0; } + + /* + * Some OSes (Linux, Xen) assume that Remote IRR bit will + * be cleared by IOAPIC hardware when the entry is configured + * as edge-triggered. This behavior is used to simulate an + * explicit EOI on IOAPICs that don't have the EOI register. + */ + if (e->fields.trig_mode == IOAPIC_EDGE_TRIG) + e->fields.remote_irr = 0; + mask_after = e->fields.mask; if (mask_before != mask_after) kvm_fire_mask_notifiers(ioapic->kvm, KVM_IRQCHIP_IOAPIC, index, mask_after); -- 2.16.1 Patches currently in stable-queue which might be from nikita.leshchenko(a)oracle.com are queue-4.9/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.9/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.9/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch queue-4.9/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.9/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: X86: Fix softlockup when get the current kvmclock" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: X86: Fix softlockup when get the current kvmclock to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-fix-softlockup-when-get-the-current-kvmclock.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Wanpeng Li <kernellwp(a)gmail.com> Date: Mon, 20 Nov 2017 14:55:05 -0800 Subject: KVM: X86: Fix softlockup when get the current kvmclock From: Wanpeng Li <kernellwp(a)gmail.com> [ Upstream commit e70b57a6ce4e8b92a56a615ae79bdb2bd66035e7 ] watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [qemu-system-x86:10185] CPU: 6 PID: 10185 Comm: qemu-system-x86 Tainted: G OE 4.14.0-rc4+ #4 RIP: 0010:kvm_get_time_scale+0x4e/0xa0 [kvm] Call Trace: get_time_ref_counter+0x5a/0x80 [kvm] kvm_hv_process_stimers+0x120/0x5f0 [kvm] kvm_arch_vcpu_ioctl_run+0x4b4/0x1690 [kvm] kvm_vcpu_ioctl+0x33a/0x620 [kvm] do_vfs_ioctl+0xa1/0x5d0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x1e/0xa9 This can be reproduced when running kvm-unit-tests/hyperv_stimer.flat and cpu-hotplug stress simultaneously. __this_cpu_read(cpu_tsc_khz) returns 0 (set in kvmclock_cpu_down_prep()) when the pCPU is unhotplug which results in kvm_get_time_scale() gets into an infinite loop. This patch fixes it by treating the unhotplug pCPU as not using master clock. Reviewed-by: Radim Krčmář <rkrcmar(a)redhat.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/x86.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1751,10 +1751,13 @@ static u64 __get_kvmclock_ns(struct kvm /* both __this_cpu_read() and rdtsc() should be on the same cpu */ get_cpu(); - kvm_get_time_scale(NSEC_PER_SEC, __this_cpu_read(cpu_tsc_khz) * 1000LL, - &hv_clock.tsc_shift, - &hv_clock.tsc_to_system_mul); - ret = __pvclock_read_cycles(&hv_clock, rdtsc()); + if (__this_cpu_read(cpu_tsc_khz)) { + kvm_get_time_scale(NSEC_PER_SEC, __this_cpu_read(cpu_tsc_khz) * 1000LL, + &hv_clock.tsc_shift, + &hv_clock.tsc_to_system_mul); + ret = __pvclock_read_cycles(&hv_clock, rdtsc()); + } else + ret = ktime_get_boot_ns() + ka->kvmclock_offset; put_cpu(); Patches currently in stable-queue which might be from kernellwp(a)gmail.com are queue-4.9/kvm-x86-fix-softlockup-when-get-the-current-kvmclock.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: X86: Fix operand/address-size during instruction decoding" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: X86: Fix operand/address-size during instruction decoding to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-fix-operand-address-size-during-instruction-decoding.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:58:04 CET 2018 From: Wanpeng Li <wanpeng.li(a)hotmail.com> Date: Sun, 5 Nov 2017 16:54:47 -0800 Subject: KVM: X86: Fix operand/address-size during instruction decoding From: Wanpeng Li <wanpeng.li(a)hotmail.com> [ Upstream commit 3853be2603191829b442b64dac6ae8ba0c027bf9 ] Pedro reported: During tests that we conducted on KVM, we noticed that executing a "PUSH %ES" instruction under KVM produces different results on both memory and the SP register depending on whether EPT support is enabled. With EPT the SP is reduced by 4 bytes (and the written value is 0-padded) but without EPT support it is only reduced by 2 bytes. The difference can be observed when the CS.DB field is 1 (32-bit) but not when it's 0 (16-bit). The internal segment descriptor cache exist even in real/vm8096 mode. The CS.D also should be respected instead of just default operand/address-size/66H prefix/67H prefix during instruction decoding. This patch fixes it by also adjusting operand/address-size according to CS.D. Reported-by: Pedro Fonseca <pfonseca(a)cs.washington.edu> Tested-by: Pedro Fonseca <pfonseca(a)cs.washington.edu> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: Pedro Fonseca <pfonseca(a)cs.washington.edu> Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Reviewed-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/emulate.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -4990,6 +4990,8 @@ int x86_decode_insn(struct x86_emulate_c bool op_prefix = false; bool has_seg_override = false; struct opcode opcode; + u16 dummy; + struct desc_struct desc; ctxt->memop.type = OP_NONE; ctxt->memopp = NULL; @@ -5008,6 +5010,11 @@ int x86_decode_insn(struct x86_emulate_c switch (mode) { case X86EMUL_MODE_REAL: case X86EMUL_MODE_VM86: + def_op_bytes = def_ad_bytes = 2; + ctxt->ops->get_segment(ctxt, &dummy, &desc, NULL, VCPU_SREG_CS); + if (desc.d) + def_op_bytes = def_ad_bytes = 4; + break; case X86EMUL_MODE_PROT16: def_op_bytes = def_ad_bytes = 2; break; Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are queue-4.9/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.9/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.9/kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch queue-4.9/kvm-x86-fix-operand-address-size-during-instruction-decoding.patch queue-4.9/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.9/kvm-x86-fix-softlockup-when-get-the-current-kvmclock.patch queue-4.9/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:58:04 CET 2018 From: Liran Alon <liran.alon(a)oracle.com> Date: Sun, 5 Nov 2017 16:56:33 +0200 Subject: KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure From: Liran Alon <liran.alon(a)oracle.com> [ Upstream commit 1f4dcb3b213235e642088709a1c54964d23365e9 ] On this case, handle_emulation_failure() fills kvm_run with internal-error information which it expects to be delivered to user-mode for further processing. However, the code reports a wrong return-value which makes KVM to never return to user-mode on this scenario. Fixes: 6d77dbfc88e3 ("KVM: inject #UD if instruction emulation fails and exit to userspace") Signed-off-by: Liran Alon <liran.alon(a)oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/x86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -5308,7 +5308,7 @@ static int handle_emulation_failure(stru vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR; vcpu->run->internal.suberror = KVM_INTERNAL_ERROR_EMULATION; vcpu->run->internal.ndata = 0; - r = EMULATE_FAIL; + r = EMULATE_USER_EXIT; } kvm_queue_exception(vcpu, UD_VECTOR); Patches currently in stable-queue which might be from liran.alon(a)oracle.com are queue-4.9/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.9/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.9/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch queue-4.9/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.9/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: x86: Don't re-execute instruction when not passing CR2 value" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: Don't re-execute instruction when not passing CR2 value to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:58:04 CET 2018 From: Liran Alon <liran.alon(a)oracle.com> Date: Sun, 5 Nov 2017 16:56:34 +0200 Subject: KVM: x86: Don't re-execute instruction when not passing CR2 value From: Liran Alon <liran.alon(a)oracle.com> [ Upstream commit 9b8ae63798cb97e785a667ff27e43fa6220cb734 ] In case of instruction-decode failure or emulation failure, x86_emulate_instruction() will call reexecute_instruction() which will attempt to use the cr2 value passed to x86_emulate_instruction(). However, when x86_emulate_instruction() is called from emulate_instruction(), cr2 is not passed (passed as 0) and therefore it doesn't make sense to execute reexecute_instruction() logic at all. Fixes: 51d8b66199e9 ("KVM: cleanup emulate_instruction") Signed-off-by: Liran Alon <liran.alon(a)oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/kvm_host.h | 3 ++- arch/x86/kvm/vmx.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1113,7 +1113,8 @@ int x86_emulate_instruction(struct kvm_v static inline int emulate_instruction(struct kvm_vcpu *vcpu, int emulation_type) { - return x86_emulate_instruction(vcpu, 0, emulation_type, NULL, 0); + return x86_emulate_instruction(vcpu, 0, + emulation_type | EMULTYPE_NO_REEXECUTE, NULL, 0); } void kvm_enable_efer_bits(u64); --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -6257,7 +6257,7 @@ static int handle_invalid_guest_state(st if (test_bit(KVM_REQ_EVENT, &vcpu->requests)) return 1; - err = emulate_instruction(vcpu, EMULTYPE_NO_REEXECUTE); + err = emulate_instruction(vcpu, 0); if (err == EMULATE_USER_EXIT) { ++vcpu->stat.mmio_exits; Patches currently in stable-queue which might be from liran.alon(a)oracle.com are queue-4.9/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.9/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.9/kvm-x86-ioapic-fix-level-triggered-eoi-and-ioapic-reconfigure-race.patch queue-4.9/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.9/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: VMX: Fix rflags cache during vCPU reset" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: VMX: Fix rflags cache during vCPU reset to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Wanpeng Li <wanpeng.li(a)hotmail.com> Date: Mon, 20 Nov 2017 14:52:21 -0800 Subject: KVM: VMX: Fix rflags cache during vCPU reset From: Wanpeng Li <wanpeng.li(a)hotmail.com> [ Upstream commit c37c28730bb031cc8a44a130c2555c0f3efbe2d0 ] Reported by syzkaller: *** Guest State *** CR0: actual=0x0000000080010031, shadow=0x0000000060000010, gh_mask=fffffffffffffff7 CR4: actual=0x0000000000002061, shadow=0x0000000000000000, gh_mask=ffffffffffffe8f1 CR3 = 0x000000002081e000 RSP = 0x000000000000fffa RIP = 0x0000000000000000 RFLAGS=0x00023000 DR7 = 0x00000000000000 ^^^^^^^^^^ ------------[ cut here ]------------ WARNING: CPU: 6 PID: 24431 at /home/kernel/linux/arch/x86/kvm//x86.c:7302 kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm] CPU: 6 PID: 24431 Comm: reprotest Tainted: G W OE 4.14.0+ #26 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm] RSP: 0018:ffff880291d179e0 EFLAGS: 00010202 Call Trace: kvm_vcpu_ioctl+0x479/0x880 [kvm] do_vfs_ioctl+0x142/0x9a0 SyS_ioctl+0x74/0x80 entry_SYSCALL_64_fastpath+0x23/0x9a The failed vmentry is triggered by the following beautified testcase: #include <unistd.h> #include <sys/syscall.h> #include <string.h> #include <stdint.h> #include <linux/kvm.h> #include <fcntl.h> #include <sys/ioctl.h> long r[5]; int main() { struct kvm_debugregs dr = { 0 }; r[2] = open("/dev/kvm", O_RDONLY); r[3] = ioctl(r[2], KVM_CREATE_VM, 0); r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7); struct kvm_guest_debug debug = { .control = 0xf0403, .arch = { .debugreg[6] = 0x2, .debugreg[7] = 0x2 } }; ioctl(r[4], KVM_SET_GUEST_DEBUG, &debug); ioctl(r[4], KVM_RUN, 0); } which testcase tries to setup the processor specific debug registers and configure vCPU for handling guest debug events through KVM_SET_GUEST_DEBUG. The KVM_SET_GUEST_DEBUG ioctl will get and set rflags in order to set TF bit if single step is needed. All regs' caches are reset to avail and GUEST_RFLAGS vmcs field is reset to 0x2 during vCPU reset. However, the cache of rflags is not reset during vCPU reset. The function vmx_get_rflags() returns an unreset rflags cache value since the cache is marked avail, it is 0 after boot. Vmentry fails if the rflags reserved bit 1 is 0. This patch fixes it by resetting both the GUEST_RFLAGS vmcs field and its cache to 0x2 during vCPU reset. Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Tested-by: Dmitry Vyukov <dvyukov(a)google.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/vmx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -5194,7 +5194,7 @@ static void vmx_vcpu_reset(struct kvm_vc vmcs_write64(GUEST_IA32_DEBUGCTL, 0); } - vmcs_writel(GUEST_RFLAGS, 0x02); + kvm_set_rflags(vcpu, X86_EFLAGS_FIXED); kvm_rip_write(vcpu, 0xfff0); vmcs_writel(GUEST_GDTR_BASE, 0); Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are queue-4.9/kvm-x86-don-t-re-execute-instruction-when-not-passing-cr2-value.patch queue-4.9/kvm-x86-ioapic-preserve-read-only-values-in-the-redirection-table.patch queue-4.9/kvm-vmx-fix-rflags-cache-during-vcpu-reset.patch queue-4.9/kvm-x86-fix-operand-address-size-during-instruction-decoding.patch queue-4.9/kvm-x86-emulator-return-to-user-mode-on-l1-cpl-0-emulation-failure.patch queue-4.9/kvm-x86-fix-softlockup-when-get-the-current-kvmclock.patch queue-4.9/kvm-x86-ioapic-clear-remote-irr-when-entry-is-switched-to-edge-triggered.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "kmemleak: add scheduling point to kmemleak_scan()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kmemleak: add scheduling point to kmemleak_scan() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kmemleak-add-scheduling-point-to-kmemleak_scan.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Yisheng Xie <xieyisheng1(a)huawei.com> Date: Wed, 29 Nov 2017 16:11:08 -0800 Subject: kmemleak: add scheduling point to kmemleak_scan() From: Yisheng Xie <xieyisheng1(a)huawei.com> [ Upstream commit bde5f6bc68db51128f875a756e9082a6c6ff7b4c ] kmemleak_scan() will scan struct page for each node and it can be really large and resulting in a soft lockup. We have seen a soft lockup when do scan while compile kernel: watchdog: BUG: soft lockup - CPU#53 stuck for 22s! [bash:10287] [...] Call Trace: kmemleak_scan+0x21a/0x4c0 kmemleak_write+0x312/0x350 full_proxy_write+0x5a/0xa0 __vfs_write+0x33/0x150 vfs_write+0xad/0x1a0 SyS_write+0x52/0xc0 do_syscall_64+0x61/0x1a0 entry_SYSCALL64_slow_path+0x25/0x25 Fix this by adding cond_resched every MAX_SCAN_SIZE. Link: http://lkml.kernel.org/r/1511439788-20099-1-git-send-email-xieyisheng1@huaw… Signed-off-by: Yisheng Xie <xieyisheng1(a)huawei.com> Suggested-by: Catalin Marinas <catalin.marinas(a)arm.com> Acked-by: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Michal Hocko <mhocko(a)kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/kmemleak.c | 2 ++ 1 file changed, 2 insertions(+) --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -1442,6 +1442,8 @@ static void kmemleak_scan(void) if (page_count(page) == 0) continue; scan_block(page, page + 1, NULL); + if (!(pfn % (MAX_SCAN_SIZE / sizeof(*page)))) + cond_resched(); } } put_online_mems(); Patches currently in stable-queue which might be from xieyisheng1(a)huawei.com are queue-4.9/kmemleak-add-scheduling-point-to-kmemleak_scan.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "iwlwifi: mvm: fix the TX queue hang timeout for MONITOR vif type" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iwlwifi: mvm: fix the TX queue hang timeout for MONITOR vif type to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iwlwifi-mvm-fix-the-tx-queue-hang-timeout-for-monitor-vif-type.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> Date: Wed, 15 Nov 2017 14:12:30 +0200 Subject: iwlwifi: mvm: fix the TX queue hang timeout for MONITOR vif type From: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> [ Upstream commit d1b275ffec459c5ae12b5c7086c84175696e5a9f ] The MONITOR type is missing in the interface type switch. Add it. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/net/wireless/intel/iwlwifi/mvm/utils.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/utils.c @@ -1040,6 +1040,8 @@ unsigned int iwl_mvm_get_wd_timeout(stru return le32_to_cpu(txq_timer->p2p_go); case NL80211_IFTYPE_P2P_DEVICE: return le32_to_cpu(txq_timer->p2p_device); + case NL80211_IFTYPE_MONITOR: + return default_timeout; default: WARN_ON(1); return mvm->cfg->base_params->wd_timeout; Patches currently in stable-queue which might be from emmanuel.grumbach(a)intel.com are queue-4.9/iwlwifi-mvm-fix-the-tx-queue-hang-timeout-for-monitor-vif-type.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "hwmon: (pmbus) Use 64bit math for DIRECT format values" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hwmon: (pmbus) Use 64bit math for DIRECT format values to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hwmon-pmbus-use-64bit-math-for-direct-format-values.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Robert Lippert <roblip(a)gmail.com> Date: Mon, 27 Nov 2017 15:51:55 -0800 Subject: hwmon: (pmbus) Use 64bit math for DIRECT format values From: Robert Lippert <roblip(a)gmail.com> [ Upstream commit bd467e4eababe4c04272c1e646f066db02734c79 ] Power values in the 100s of watt range can easily blow past 32bit math limits when processing everything in microwatts. Use 64bit math instead to avoid these issues on common 32bit ARM BMC platforms. Fixes: 442aba78728e ("hwmon: PMBus device driver") Signed-off-by: Robert Lippert <rlippert(a)google.com> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwmon/pmbus/pmbus_core.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) --- a/drivers/hwmon/pmbus/pmbus_core.c +++ b/drivers/hwmon/pmbus/pmbus_core.c @@ -20,6 +20,7 @@ */ #include <linux/kernel.h> +#include <linux/math64.h> #include <linux/module.h> #include <linux/init.h> #include <linux/err.h> @@ -476,8 +477,8 @@ static long pmbus_reg2data_linear(struct static long pmbus_reg2data_direct(struct pmbus_data *data, struct pmbus_sensor *sensor) { - long val = (s16) sensor->data; - long m, b, R; + s64 b, val = (s16)sensor->data; + s32 m, R; m = data->info->m[sensor->class]; b = data->info->b[sensor->class]; @@ -505,11 +506,12 @@ static long pmbus_reg2data_direct(struct R--; } while (R < 0) { - val = DIV_ROUND_CLOSEST(val, 10); + val = div_s64(val + 5LL, 10L); /* round closest */ R++; } - return (val - b) / m; + val = div_s64(val - b, m); + return clamp_val(val, LONG_MIN, LONG_MAX); } /* @@ -629,7 +631,8 @@ static u16 pmbus_data2reg_linear(struct static u16 pmbus_data2reg_direct(struct pmbus_data *data, struct pmbus_sensor *sensor, long val) { - long m, b, R; + s64 b, val64 = val; + s32 m, R; m = data->info->m[sensor->class]; b = data->info->b[sensor->class]; @@ -646,18 +649,18 @@ static u16 pmbus_data2reg_direct(struct R -= 3; /* Adjust R and b for data in milli-units */ b *= 1000; } - val = val * m + b; + val64 = val64 * m + b; while (R > 0) { - val *= 10; + val64 *= 10; R--; } while (R < 0) { - val = DIV_ROUND_CLOSEST(val, 10); + val64 = div_s64(val64 + 5LL, 10L); /* round closest */ R++; } - return val; + return (u16)clamp_val(val64, S16_MIN, S16_MAX); } static u16 pmbus_data2reg_vid(struct pmbus_data *data, Patches currently in stable-queue which might be from roblip(a)gmail.com are queue-4.9/hwmon-pmbus-use-64bit-math-for-direct-format-values.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "grace: replace BUG_ON by WARN_ONCE in exit_net hook" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled grace: replace BUG_ON by WARN_ONCE in exit_net hook to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: grace-replace-bug_on-by-warn_once-in-exit_net-hook.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Vasily Averin <vvs(a)virtuozzo.com> Date: Mon, 6 Nov 2017 16:22:48 +0300 Subject: grace: replace BUG_ON by WARN_ONCE in exit_net hook From: Vasily Averin <vvs(a)virtuozzo.com> [ Upstream commit b872285751c1af010e12d02bce7069e2061a58ca ] Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfs_common/grace.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/fs/nfs_common/grace.c +++ b/fs/nfs_common/grace.c @@ -104,7 +104,9 @@ grace_exit_net(struct net *net) { struct list_head *grace_list = net_generic(net, grace_net_id); - BUG_ON(!list_empty(grace_list)); + WARN_ONCE(!list_empty(grace_list), + "net %x %s: grace_list is not empty\n", + net->ns.inum, __func__); } static struct pernet_operations grace_net_ops = { Patches currently in stable-queue which might be from vvs(a)virtuozzo.com are queue-4.9/lockd-fix-list_add-double-add-caused-by-legacy-signal-interface.patch queue-4.9/grace-replace-bug_on-by-warn_once-in-exit_net-hook.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/vc4: Move IRQ enable to PM path" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/vc4: Move IRQ enable to PM path to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-vc4-move-irq-enable-to-pm-path.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Stefan Schake <stschake(a)gmail.com> Date: Fri, 29 Dec 2017 17:05:43 +0100 Subject: drm/vc4: Move IRQ enable to PM path From: Stefan Schake <stschake(a)gmail.com> [ Upstream commit ce9caf2f79a5aa170a4b6456a03db639eed9c988 ] We were calling enable_irq on bind, where it was already enabled previously by the IRQ helper. Additionally, dev->irq is not set correctly until after postinstall and so was always zero here, triggering a warning in 4.15. Fix both by moving the enable to the power management resume path, where we know there was a previous disable invocation during suspend. Fixes: 253696ccd613 ("drm/vc4: Account for interrupts in flight") Signed-off-by: Stefan Schake <stschake(a)gmail.com> Signed-off-by: Eric Anholt <eric(a)anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1514563543-32511-1-git-send-e… Tested-by: Stefan Wahren <stefan.wahren(a)i2se.com> Reviewed-by: Eric Anholt <eric(a)anholt.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/vc4/vc4_irq.c | 3 --- drivers/gpu/drm/vc4/vc4_v3d.c | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-) --- a/drivers/gpu/drm/vc4/vc4_irq.c +++ b/drivers/gpu/drm/vc4/vc4_irq.c @@ -208,9 +208,6 @@ vc4_irq_postinstall(struct drm_device *d { struct vc4_dev *vc4 = to_vc4_dev(dev); - /* Undo the effects of a previous vc4_irq_uninstall. */ - enable_irq(dev->irq); - /* Enable both the render done and out of memory interrupts. */ V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS); --- a/drivers/gpu/drm/vc4/vc4_v3d.c +++ b/drivers/gpu/drm/vc4/vc4_v3d.c @@ -173,6 +173,9 @@ static int vc4_v3d_runtime_resume(struct struct vc4_dev *vc4 = v3d->vc4; vc4_v3d_init_hw(vc4->dev); + + /* We disabled the IRQ as part of vc4_irq_uninstall in suspend. */ + enable_irq(vc4->dev->irq); vc4_irq_postinstall(vc4->dev); return 0; Patches currently in stable-queue which might be from stschake(a)gmail.com are queue-4.9/drm-vc4-move-irq-enable-to-pm-path.patch queue-4.9/drm-vc4-account-for-interrupts-in-flight.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/vc4: Account for interrupts in flight" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/vc4: Account for interrupts in flight to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-vc4-account-for-interrupts-in-flight.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:58:04 CET 2018 From: Stefan Schake <stschake(a)gmail.com> Date: Fri, 10 Nov 2017 02:05:06 +0100 Subject: drm/vc4: Account for interrupts in flight From: Stefan Schake <stschake(a)gmail.com> [ Upstream commit 253696ccd613fbdaa5aba1de44c461a058e0a114 ] Synchronously disable the IRQ to make the following cancel_work_sync invocation effective. An interrupt in flight could enqueue further overflow mem work. As we free the binner BO immediately following vc4_irq_uninstall this caused a NULL pointer dereference in the work callback vc4_overflow_mem_work. Link: https://github.com/anholt/linux/issues/114 Signed-off-by: Stefan Schake <stschake(a)gmail.com> Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.") Signed-off-by: Eric Anholt <eric(a)anholt.net> Reviewed-by: Eric Anholt <eric(a)anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1510275907-993-2-git-send-ema… Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/vc4/vc4_irq.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/gpu/drm/vc4/vc4_irq.c +++ b/drivers/gpu/drm/vc4/vc4_irq.c @@ -208,6 +208,9 @@ vc4_irq_postinstall(struct drm_device *d { struct vc4_dev *vc4 = to_vc4_dev(dev); + /* Undo the effects of a previous vc4_irq_uninstall. */ + enable_irq(dev->irq); + /* Enable both the render done and out of memory interrupts. */ V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS); @@ -225,6 +228,9 @@ vc4_irq_uninstall(struct drm_device *dev /* Clear any pending interrupts we might have left. */ V3D_WRITE(V3D_INTCTL, V3D_DRIVER_IRQS); + /* Finish any interrupt handler still in flight. */ + disable_irq(dev->irq); + cancel_work_sync(&vc4->overflow_mem_work); } Patches currently in stable-queue which might be from stschake(a)gmail.com are queue-4.9/drm-vc4-move-irq-enable-to-pm-path.patch queue-4.9/drm-vc4-account-for-interrupts-in-flight.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/omap: Fix error handling path in 'omap_dmm_probe()'" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/omap: Fix error handling path in 'omap_dmm_probe()' to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-omap-fix-error-handling-path-in-omap_dmm_probe.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Sun, 24 Sep 2017 08:01:03 +0200 Subject: drm/omap: Fix error handling path in 'omap_dmm_probe()' From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 8677b1ac2db021ab30bb1fa34f1e56ebe0051ec3 ] If we don't find a matching device node, we must free the memory allocated in 'omap_dmm' a few lines above. Fixes: 7cb0d6c17b96 ("drm/omap: fix TILER on OMAP5") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c @@ -638,7 +638,8 @@ static int omap_dmm_probe(struct platfor match = of_match_node(dmm_of_match, dev->dev.of_node); if (!match) { dev_err(&dev->dev, "failed to find matching device node\n"); - return -ENODEV; + ret = -ENODEV; + goto fail; } omap_dmm->plat_data = match->data; Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.9/bnxt_en-fix-an-error-handling-path-in-bnxt_get_module_eeprom.patch queue-4.9/drm-omap-fix-error-handling-path-in-omap_dmm_probe.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/bridge: tc358767: fix timing calculations" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/bridge: tc358767: fix timing calculations to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-bridge-tc358767-fix-timing-calculations.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Date: Tue, 7 Nov 2017 19:56:22 +0300 Subject: drm/bridge: tc358767: fix timing calculations From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> [ Upstream commit 66d1c3b94d5d59e4325e61a78d520f92c043d645 ] Fields in HTIM01 and HTIM02 regs should be even. Recomended thresh_dly value is max_tu_symbol. Remove set of VPCTRL0.VSDELAY as it is related to DSI input interface. Currently driver supports only DPI. Acked-by: Philipp Zabel <p.zabel(a)pengutronix.de> Signed-off-by: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-5-git-send-e… Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/bridge/tc358767.c | 34 ++++++++++++++++++++-------------- 1 file changed, 20 insertions(+), 14 deletions(-) --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -659,6 +659,14 @@ static int tc_set_video_mode(struct tc_d int lower_margin = mode->vsync_start - mode->vdisplay; int vsync_len = mode->vsync_end - mode->vsync_start; + /* + * Recommended maximum number of symbols transferred in a transfer unit: + * DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size, + * (output active video bandwidth in bytes)) + * Must be less than tu_size. + */ + max_tu_symbol = TU_SIZE_RECOMMENDED - 1; + dev_dbg(tc->dev, "set mode %dx%d\n", mode->hdisplay, mode->vdisplay); dev_dbg(tc->dev, "H margin %d,%d sync %d\n", @@ -668,13 +676,18 @@ static int tc_set_video_mode(struct tc_d dev_dbg(tc->dev, "total: %dx%d\n", mode->htotal, mode->vtotal); - /* LCD Ctl Frame Size */ - tc_write(VPCTRL0, (0x40 << 20) /* VSDELAY */ | + /* + * LCD Ctl Frame Size + * datasheet is not clear of vsdelay in case of DPI + * assume we do not need any delay when DPI is a source of + * sync signals + */ + tc_write(VPCTRL0, (0 << 20) /* VSDELAY */ | OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED); - tc_write(HTIM01, (left_margin << 16) | /* H back porch */ - (hsync_len << 0)); /* Hsync */ - tc_write(HTIM02, (right_margin << 16) | /* H front porch */ - (mode->hdisplay << 0)); /* width */ + tc_write(HTIM01, (ALIGN(left_margin, 2) << 16) | /* H back porch */ + (ALIGN(hsync_len, 2) << 0)); /* Hsync */ + tc_write(HTIM02, (ALIGN(right_margin, 2) << 16) | /* H front porch */ + (ALIGN(mode->hdisplay, 2) << 0)); /* width */ tc_write(VTIM01, (upper_margin << 16) | /* V back porch */ (vsync_len << 0)); /* Vsync */ tc_write(VTIM02, (lower_margin << 16) | /* V front porch */ @@ -693,7 +706,7 @@ static int tc_set_video_mode(struct tc_d /* DP Main Stream Attributes */ vid_sync_dly = hsync_len + left_margin + mode->hdisplay; tc_write(DP0_VIDSYNCDELAY, - (0x003e << 16) | /* thresh_dly */ + (max_tu_symbol << 16) | /* thresh_dly */ (vid_sync_dly << 0)); tc_write(DP0_TOTALVAL, (mode->vtotal << 16) | (mode->htotal)); @@ -709,13 +722,6 @@ static int tc_set_video_mode(struct tc_d tc_write(DPIPXLFMT, VS_POL_ACTIVE_LOW | HS_POL_ACTIVE_LOW | DE_POL_ACTIVE_HIGH | SUB_CFG_TYPE_CONFIG1 | DPI_BPP_RGB888); - /* - * Recommended maximum number of symbols transferred in a transfer unit: - * DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size, - * (output active video bandwidth in bytes)) - * Must be less than tu_size. - */ - max_tu_symbol = TU_SIZE_RECOMMENDED - 1; tc_write(DP0_MISC, (max_tu_symbol << 23) | (TU_SIZE_RECOMMENDED << 16) | BPC_8); Patches currently in stable-queue which might be from andrey.gusakov(a)cogentembedded.com are queue-4.9/drm-bridge-tc358767-fix-timing-calculations.patch queue-4.9/drm-bridge-tc358767-fix-auxdatan-registers-access.patch queue-4.9/drm-bridge-tc358767-filter-out-too-high-modes.patch queue-4.9/drm-bridge-tc358767-fix-1-lane-behavior.patch queue-4.9/drm-bridge-tc358767-fix-dp0_misc-register-set.patch queue-4.9/drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/bridge: tc358767: fix DP0_MISC register set" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/bridge: tc358767: fix DP0_MISC register set to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-bridge-tc358767-fix-dp0_misc-register-set.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Date: Tue, 7 Nov 2017 19:56:21 +0300 Subject: drm/bridge: tc358767: fix DP0_MISC register set From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> [ Upstream commit f3b8adbe1911f66fd3cab1aaa74f0f66b7ceda25 ] Remove shift from TU_SIZE_RECOMMENDED define as it used to calculate max_tu_symbols. Acked-by: Philipp Zabel <p.zabel(a)pengutronix.de> Signed-off-by: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-4-git-send-e… Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/bridge/tc358767.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -97,7 +97,7 @@ #define DP0_ACTIVEVAL 0x0650 #define DP0_SYNCVAL 0x0654 #define DP0_MISC 0x0658 -#define TU_SIZE_RECOMMENDED (0x3f << 16) /* LSCLK cycles per TU */ +#define TU_SIZE_RECOMMENDED (63) /* LSCLK cycles per TU */ #define BPC_6 (0 << 5) #define BPC_8 (1 << 5) @@ -716,7 +716,8 @@ static int tc_set_video_mode(struct tc_d * Must be less than tu_size. */ max_tu_symbol = TU_SIZE_RECOMMENDED - 1; - tc_write(DP0_MISC, (max_tu_symbol << 23) | TU_SIZE_RECOMMENDED | BPC_8); + tc_write(DP0_MISC, (max_tu_symbol << 23) | (TU_SIZE_RECOMMENDED << 16) | + BPC_8); return 0; err: Patches currently in stable-queue which might be from andrey.gusakov(a)cogentembedded.com are queue-4.9/drm-bridge-tc358767-fix-timing-calculations.patch queue-4.9/drm-bridge-tc358767-fix-auxdatan-registers-access.patch queue-4.9/drm-bridge-tc358767-filter-out-too-high-modes.patch queue-4.9/drm-bridge-tc358767-fix-1-lane-behavior.patch queue-4.9/drm-bridge-tc358767-fix-dp0_misc-register-set.patch queue-4.9/drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/bridge: tc358767: fix AUXDATAn registers access" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/bridge: tc358767: fix AUXDATAn registers access to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-bridge-tc358767-fix-auxdatan-registers-access.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Date: Tue, 7 Nov 2017 19:56:23 +0300 Subject: drm/bridge: tc358767: fix AUXDATAn registers access From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> [ Upstream commit 9217c1abbc145a77d65c476cf2004a3df02104c7 ] First four bytes should go to DP0_AUXWDATA0. Due to bug if len > 4 first four bytes was writen to DP0_AUXWDATA1 and all data get shifted by 4 bytes. Fix it. Acked-by: Philipp Zabel <p.zabel(a)pengutronix.de> Signed-off-by: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-6-git-send-e… Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/bridge/tc358767.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -318,7 +318,7 @@ static ssize_t tc_aux_transfer(struct dr tmp = (tmp << 8) | buf[i]; i++; if (((i % 4) == 0) || (i == size)) { - tc_write(DP0_AUXWDATA(i >> 2), tmp); + tc_write(DP0_AUXWDATA((i - 1) >> 2), tmp); tmp = 0; } } Patches currently in stable-queue which might be from andrey.gusakov(a)cogentembedded.com are queue-4.9/drm-bridge-tc358767-fix-timing-calculations.patch queue-4.9/drm-bridge-tc358767-fix-auxdatan-registers-access.patch queue-4.9/drm-bridge-tc358767-filter-out-too-high-modes.patch queue-4.9/drm-bridge-tc358767-fix-1-lane-behavior.patch queue-4.9/drm-bridge-tc358767-fix-dp0_misc-register-set.patch queue-4.9/drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/bridge: tc358767: fix 1-lane behavior" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/bridge: tc358767: fix 1-lane behavior to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-bridge-tc358767-fix-1-lane-behavior.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Date: Tue, 7 Nov 2017 19:56:24 +0300 Subject: drm/bridge: tc358767: fix 1-lane behavior From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> [ Upstream commit 4dbd6c03fbf88299c573d676838896c6e06aade2 ] Use drm_dp_channel_eq_ok helper Acked-by: Philipp Zabel <p.zabel(a)pengutronix.de> Signed-off-by: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-7-git-send-e… Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/bridge/tc358767.c | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-) --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -819,8 +819,6 @@ static int tc_main_link_setup(struct tc_ unsigned int rate; u32 dp_phy_ctrl; int timeout; - bool aligned; - bool ready; u32 value; int ret; u8 tmp[8]; @@ -965,16 +963,15 @@ static int tc_main_link_setup(struct tc_ ret = drm_dp_dpcd_read_link_status(aux, tmp + 2); if (ret < 0) goto err_dpcd_read; - ready = (tmp[2] == ((DP_CHANNEL_EQ_BITS << 4) | /* Lane1 */ - DP_CHANNEL_EQ_BITS)); /* Lane0 */ - aligned = tmp[4] & DP_INTERLANE_ALIGN_DONE; - } while ((--timeout) && !(ready && aligned)); + } while ((--timeout) && + !(drm_dp_channel_eq_ok(tmp + 2, tc->link.base.num_lanes))); if (timeout == 0) { /* Read DPCD 0x200-0x201 */ ret = drm_dp_dpcd_read(aux, DP_SINK_COUNT, tmp, 2); if (ret < 0) goto err_dpcd_read; + dev_err(dev, "channel(s) EQ not ok\n"); dev_info(dev, "0x0200 SINK_COUNT: 0x%02x\n", tmp[0]); dev_info(dev, "0x0201 DEVICE_SERVICE_IRQ_VECTOR: 0x%02x\n", tmp[1]); @@ -985,10 +982,6 @@ static int tc_main_link_setup(struct tc_ dev_info(dev, "0x0206 ADJUST_REQUEST_LANE0_1: 0x%02x\n", tmp[6]); - if (!ready) - dev_err(dev, "Lane0/1 not ready\n"); - if (!aligned) - dev_err(dev, "Lane0/1 not aligned\n"); return -EAGAIN; } Patches currently in stable-queue which might be from andrey.gusakov(a)cogentembedded.com are queue-4.9/drm-bridge-tc358767-fix-timing-calculations.patch queue-4.9/drm-bridge-tc358767-fix-auxdatan-registers-access.patch queue-4.9/drm-bridge-tc358767-filter-out-too-high-modes.patch queue-4.9/drm-bridge-tc358767-fix-1-lane-behavior.patch queue-4.9/drm-bridge-tc358767-fix-dp0_misc-register-set.patch queue-4.9/drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/bridge: tc358767: filter out too high modes" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/bridge: tc358767: filter out too high modes to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-bridge-tc358767-filter-out-too-high-modes.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Date: Tue, 7 Nov 2017 19:56:20 +0300 Subject: drm/bridge: tc358767: filter out too high modes From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> [ Upstream commit 99fc8e963a4c0203dba26a77cf737db6081bca14 ] Pixel clock limitation for DPI is 154 MHz. Do not accept modes with higher pixel clock rate. Reviewed-by: Andrzej Hajda <a.hajda(a)samsung.com> Signed-off-by: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-3-git-send-e… Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/bridge/tc358767.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -1109,7 +1109,10 @@ static bool tc_bridge_mode_fixup(struct static int tc_connector_mode_valid(struct drm_connector *connector, struct drm_display_mode *mode) { - /* Accept any mode */ + /* DPI interface clock limitation: upto 154 MHz */ + if (mode->clock > 154000) + return MODE_CLOCK_HIGH; + return MODE_OK; } Patches currently in stable-queue which might be from andrey.gusakov(a)cogentembedded.com are queue-4.9/drm-bridge-tc358767-fix-timing-calculations.patch queue-4.9/drm-bridge-tc358767-fix-auxdatan-registers-access.patch queue-4.9/drm-bridge-tc358767-filter-out-too-high-modes.patch queue-4.9/drm-bridge-tc358767-fix-1-lane-behavior.patch queue-4.9/drm-bridge-tc358767-fix-dp0_misc-register-set.patch queue-4.9/drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/bridge: tc358767: do no fail on hi-res displays" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/bridge: tc358767: do no fail on hi-res displays to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Date: Tue, 7 Nov 2017 19:56:19 +0300 Subject: drm/bridge: tc358767: do no fail on hi-res displays From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> [ Upstream commit cffd2b16c01c3431a7a7dd62e722af33490fc436 ] Do not fail data rates higher than 2.7 and more than 2 lanes. Try to fall back to 2.7Gbps and 2 lanes. Acked-by: Philipp Zabel <p.zabel(a)pengutronix.de> Reviewed-by: Andrzej Hajda <a.hajda(a)samsung.com> Signed-off-by: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-2-git-send-e… Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/bridge/tc358767.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -603,8 +603,15 @@ static int tc_get_display_props(struct t ret = drm_dp_link_probe(&tc->aux, &tc->link.base); if (ret < 0) goto err_dpcd_read; - if ((tc->link.base.rate != 162000) && (tc->link.base.rate != 270000)) - goto err_dpcd_inval; + if (tc->link.base.rate != 162000 && tc->link.base.rate != 270000) { + dev_dbg(tc->dev, "Falling to 2.7 Gbps rate\n"); + tc->link.base.rate = 270000; + } + + if (tc->link.base.num_lanes > 2) { + dev_dbg(tc->dev, "Falling to 2 lanes\n"); + tc->link.base.num_lanes = 2; + } ret = drm_dp_dpcd_readb(&tc->aux, DP_MAX_DOWNSPREAD, tmp); if (ret < 0) @@ -637,9 +644,6 @@ static int tc_get_display_props(struct t err_dpcd_read: dev_err(tc->dev, "failed to read DPCD: %d\n", ret); return ret; -err_dpcd_inval: - dev_err(tc->dev, "invalid DPCD\n"); - return -EINVAL; } static int tc_set_video_mode(struct tc_data *tc, struct drm_display_mode *mode) Patches currently in stable-queue which might be from andrey.gusakov(a)cogentembedded.com are queue-4.9/drm-bridge-tc358767-fix-timing-calculations.patch queue-4.9/drm-bridge-tc358767-fix-auxdatan-registers-access.patch queue-4.9/drm-bridge-tc358767-filter-out-too-high-modes.patch queue-4.9/drm-bridge-tc358767-fix-1-lane-behavior.patch queue-4.9/drm-bridge-tc358767-fix-dp0_misc-register-set.patch queue-4.9/drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/amdkfd: Fix SDMA ring buffer size calculation" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/amdkfd: Fix SDMA ring buffer size calculation to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-amdkfd-fix-sdma-ring-buffer-size-calculation.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: shaoyunl <Shaoyun.Liu(a)amd.com> Date: Wed, 1 Nov 2017 19:21:56 -0400 Subject: drm/amdkfd: Fix SDMA ring buffer size calculation From: shaoyunl <Shaoyun.Liu(a)amd.com> [ Upstream commit d12fb13f23199faa7e536acec1db49068e5a067d ] ffs function return the position of the first bit set on 1 based. (bit zero returns 1). Signed-off-by: shaoyun liu <shaoyun.liu(a)amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling(a)amd.com> Reviewed-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c @@ -215,8 +215,8 @@ static int update_mqd_sdma(struct mqd_ma BUG_ON(!mm || !mqd || !q); m = get_sdma_mqd(mqd); - m->sdma_rlc_rb_cntl = ffs(q->queue_size / sizeof(unsigned int)) << - SDMA0_RLC0_RB_CNTL__RB_SIZE__SHIFT | + m->sdma_rlc_rb_cntl = (ffs(q->queue_size / sizeof(unsigned int)) - 1) + << SDMA0_RLC0_RB_CNTL__RB_SIZE__SHIFT | q->vmid << SDMA0_RLC0_RB_CNTL__RB_VMID__SHIFT | 1 << SDMA0_RLC0_RB_CNTL__RPTR_WRITEBACK_ENABLE__SHIFT | 6 << SDMA0_RLC0_RB_CNTL__RPTR_WRITEBACK_TIMER__SHIFT; Patches currently in stable-queue which might be from Shaoyun.Liu(a)amd.com are queue-4.9/drm-amdkfd-fix-sdma-ring-buffer-size-calculation.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/amdkfd: Fix SDMA oversubsription handling" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/amdkfd: Fix SDMA oversubsription handling to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-amdkfd-fix-sdma-oversubsription-handling.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Felix Kuehling <Felix.Kuehling(a)amd.com> Date: Wed, 1 Nov 2017 19:21:57 -0400 Subject: drm/amdkfd: Fix SDMA oversubsription handling From: Felix Kuehling <Felix.Kuehling(a)amd.com> [ Upstream commit 8c946b8988acec785bcf67088b6bd0747f36d2d3 ] SDMA only supports a fixed number of queues. HWS cannot handle oversubscription. Signed-off-by: shaoyun liu <shaoyun.liu(a)amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling(a)amd.com> Reviewed-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 18 +++++++++++++++++ 1 file changed, 18 insertions(+) --- a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c @@ -205,6 +205,24 @@ int pqm_create_queue(struct process_queu switch (type) { case KFD_QUEUE_TYPE_SDMA: + if (dev->dqm->queue_count >= + CIK_SDMA_QUEUES_PER_ENGINE * CIK_SDMA_ENGINE_NUM) { + pr_err("Over-subscription is not allowed for SDMA.\n"); + retval = -EPERM; + goto err_create_queue; + } + + retval = create_cp_queue(pqm, dev, &q, properties, f, *qid); + if (retval != 0) + goto err_create_queue; + pqn->q = q; + pqn->kq = NULL; + retval = dev->dqm->ops.create_queue(dev->dqm, q, &pdd->qpd, + &q->properties.vmid); + pr_debug("DQM returned %d for create_queue\n", retval); + print_queue(q); + break; + case KFD_QUEUE_TYPE_COMPUTE: /* check if there is over subscription */ if ((sched_policy == KFD_SCHED_POLICY_HWS_NO_OVERSUBSCRIPTION) && Patches currently in stable-queue which might be from Felix.Kuehling(a)amd.com are queue-4.9/drm-amdkfd-fix-sdma-oversubsription-handling.patch queue-4.9/drm-amdkfd-fix-sdma-ring-buffer-size-calculation.patch queue-4.9/drm-amdgpu-fix-sdma-load-unload-sequence-on-hws-disabled-mode.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/amdgpu: Fix SDMA load/unload sequence on HWS disabled mode" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/amdgpu: Fix SDMA load/unload sequence on HWS disabled mode to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-amdgpu-fix-sdma-load-unload-sequence-on-hws-disabled-mode.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Felix Kuehling <Felix.Kuehling(a)amd.com> Date: Wed, 1 Nov 2017 19:21:55 -0400 Subject: drm/amdgpu: Fix SDMA load/unload sequence on HWS disabled mode From: Felix Kuehling <Felix.Kuehling(a)amd.com> [ Upstream commit cf21654b40968609779751b34e7923180968fe5b ] Fix the SDMA load and unload sequence as suggested by HW document. Signed-off-by: shaoyun liu <shaoyun.liu(a)amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling(a)amd.com> Acked-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 47 +++++++++++++++------- 1 file changed, 34 insertions(+), 13 deletions(-) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c @@ -367,29 +367,50 @@ static int kgd_hqd_sdma_load(struct kgd_ { struct amdgpu_device *adev = get_amdgpu_device(kgd); struct cik_sdma_rlc_registers *m; + unsigned long end_jiffies; uint32_t sdma_base_addr; + uint32_t data; m = get_sdma_mqd(mqd); sdma_base_addr = get_sdma_base_addr(m); - WREG32(sdma_base_addr + mmSDMA0_RLC0_VIRTUAL_ADDR, - m->sdma_rlc_virtual_addr); + WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_CNTL, + m->sdma_rlc_rb_cntl & (~SDMA0_RLC0_RB_CNTL__RB_ENABLE_MASK)); - WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_BASE, - m->sdma_rlc_rb_base); + end_jiffies = msecs_to_jiffies(2000) + jiffies; + while (true) { + data = RREG32(sdma_base_addr + mmSDMA0_RLC0_CONTEXT_STATUS); + if (data & SDMA0_RLC0_CONTEXT_STATUS__IDLE_MASK) + break; + if (time_after(jiffies, end_jiffies)) + return -ETIME; + usleep_range(500, 1000); + } + if (m->sdma_engine_id) { + data = RREG32(mmSDMA1_GFX_CONTEXT_CNTL); + data = REG_SET_FIELD(data, SDMA1_GFX_CONTEXT_CNTL, + RESUME_CTX, 0); + WREG32(mmSDMA1_GFX_CONTEXT_CNTL, data); + } else { + data = RREG32(mmSDMA0_GFX_CONTEXT_CNTL); + data = REG_SET_FIELD(data, SDMA0_GFX_CONTEXT_CNTL, + RESUME_CTX, 0); + WREG32(mmSDMA0_GFX_CONTEXT_CNTL, data); + } + WREG32(sdma_base_addr + mmSDMA0_RLC0_DOORBELL, + m->sdma_rlc_doorbell); + WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_RPTR, 0); + WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_WPTR, 0); + WREG32(sdma_base_addr + mmSDMA0_RLC0_VIRTUAL_ADDR, + m->sdma_rlc_virtual_addr); + WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_BASE, m->sdma_rlc_rb_base); WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_BASE_HI, m->sdma_rlc_rb_base_hi); - WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_RPTR_ADDR_LO, m->sdma_rlc_rb_rptr_addr_lo); - WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_RPTR_ADDR_HI, m->sdma_rlc_rb_rptr_addr_hi); - - WREG32(sdma_base_addr + mmSDMA0_RLC0_DOORBELL, - m->sdma_rlc_doorbell); - WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_CNTL, m->sdma_rlc_rb_cntl); @@ -493,9 +514,9 @@ static int kgd_hqd_sdma_destroy(struct k } WREG32(sdma_base_addr + mmSDMA0_RLC0_DOORBELL, 0); - WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_RPTR, 0); - WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_WPTR, 0); - WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_BASE, 0); + WREG32(sdma_base_addr + mmSDMA0_RLC0_RB_CNTL, + RREG32(sdma_base_addr + mmSDMA0_RLC0_RB_CNTL) | + SDMA0_RLC0_RB_CNTL__RB_ENABLE_MASK); return 0; } Patches currently in stable-queue which might be from Felix.Kuehling(a)amd.com are queue-4.9/drm-amdkfd-fix-sdma-oversubsription-handling.patch queue-4.9/drm-amdkfd-fix-sdma-ring-buffer-size-calculation.patch queue-4.9/drm-amdgpu-fix-sdma-load-unload-sequence-on-hws-disabled-mode.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/amdgpu: don't try to move pinned BOs" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/amdgpu: don't try to move pinned BOs to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-amdgpu-don-t-try-to-move-pinned-bos.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: "Christian König" <christian.koenig(a)amd.com> Date: Fri, 24 Nov 2017 11:39:30 +0100 Subject: drm/amdgpu: don't try to move pinned BOs From: "Christian König" <christian.koenig(a)amd.com> [ Upstream commit 6edc6910ba4cd6eab309263539c8f09b8ad772bf ] Never try to move pinned BOs during CS. Signed-off-by: Christian KÃ¶nig <christian.koenig(a)amd.com> Reviewed-by: Michel DÃ¤nzer <michel.daenzer(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -416,6 +416,10 @@ static bool amdgpu_cs_try_evict(struct a if (candidate == lobj) break; + /* We can't move pinned BOs here */ + if (bo->pin_count) + continue; + other = amdgpu_mem_type_to_domain(bo->tbo.mem.mem_type); /* Check if this BO is in one of the domains we need space for */ Patches currently in stable-queue which might be from christian.koenig(a)amd.com are queue-4.9/drm-amdgpu-don-t-try-to-move-pinned-bos.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "cpupowerutils: bench - Fix cpu online check" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cpupowerutils: bench - Fix cpu online check to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cpupowerutils-bench-fix-cpu-online-check.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:58:04 CET 2018 From: Abhishek Goel <huntbag(a)linux.vnet.ibm.com> Date: Tue, 7 Nov 2017 15:17:55 +0530 Subject: cpupowerutils: bench - Fix cpu online check From: Abhishek Goel <huntbag(a)linux.vnet.ibm.com> [ Upstream commit 53d1cd6b125fb9d69303516a1179ebc3b72f797a ] cpupower_is_cpu_online was incorrectly checking for 0. This patch fixes this by checking for 1 when the cpu is online. Signed-off-by: Abhishek Goel <huntbag(a)linux.vnet.ibm.com> Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/power/cpupower/bench/system.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/power/cpupower/bench/system.c +++ b/tools/power/cpupower/bench/system.c @@ -61,7 +61,7 @@ int set_cpufreq_governor(char *governor, dprintf("set %s as cpufreq governor\n", governor); - if (cpupower_is_cpu_online(cpu) != 0) { + if (cpupower_is_cpu_online(cpu) != 1) { perror("cpufreq_cpu_exists"); fprintf(stderr, "error: cpu %u does not exist\n", cpu); return -1; Patches currently in stable-queue which might be from huntbag(a)linux.vnet.ibm.com are queue-4.9/cpupowerutils-bench-fix-cpu-online-check.patch queue-4.9/cpupower-fix-cpupower-working-when-cpu0-is-offline.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "cpupower : Fix cpupower working when cpu0 is offline" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cpupower : Fix cpupower working when cpu0 is offline to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cpupower-fix-cpupower-working-when-cpu0-is-offline.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:58:04 CET 2018 From: Abhishek Goel <huntbag(a)linux.vnet.ibm.com> Date: Wed, 15 Nov 2017 14:10:02 +0530 Subject: cpupower : Fix cpupower working when cpu0 is offline From: Abhishek Goel <huntbag(a)linux.vnet.ibm.com> [ Upstream commit dbdc468f35ee827cab2753caa1c660bdb832243a ] cpuidle_monitor used to assume that cpu0 is always online which is not a valid assumption on POWER machines. This patch fixes this by getting the cpu on which the current thread is running, instead of always using cpu0 for monitoring which may not be online. Signed-off-by: Abhishek Goel <huntbag(a)linux.vnet.ibm.com> Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c +++ b/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c @@ -130,15 +130,18 @@ static struct cpuidle_monitor *cpuidle_r { int num; char *tmp; + int this_cpu; + + this_cpu = sched_getcpu(); /* Assume idle state count is the same for all CPUs */ - cpuidle_sysfs_monitor.hw_states_num = cpuidle_state_count(0); + cpuidle_sysfs_monitor.hw_states_num = cpuidle_state_count(this_cpu); if (cpuidle_sysfs_monitor.hw_states_num <= 0) return NULL; for (num = 0; num < cpuidle_sysfs_monitor.hw_states_num; num++) { - tmp = cpuidle_state_name(0, num); + tmp = cpuidle_state_name(this_cpu, num); if (tmp == NULL) continue; @@ -146,7 +149,7 @@ static struct cpuidle_monitor *cpuidle_r strncpy(cpuidle_cstates[num].name, tmp, CSTATE_NAME_LEN - 1); free(tmp); - tmp = cpuidle_state_desc(0, num); + tmp = cpuidle_state_desc(this_cpu, num); if (tmp == NULL) continue; strncpy(cpuidle_cstates[num].desc, tmp, CSTATE_DESC_LEN - 1); Patches currently in stable-queue which might be from huntbag(a)linux.vnet.ibm.com are queue-4.9/cpupowerutils-bench-fix-cpu-online-check.patch queue-4.9/cpupower-fix-cpupower-working-when-cpu0-is-offline.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "cpufreq: Add Loongson machine dependencies" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cpufreq: Add Loongson machine dependencies to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cpufreq-add-loongson-machine-dependencies.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: James Hogan <jhogan(a)kernel.org> Date: Wed, 15 Nov 2017 21:17:55 +0000 Subject: cpufreq: Add Loongson machine dependencies From: James Hogan <jhogan(a)kernel.org> [ Upstream commit 0d307935fefa6389eb726c6362351c162c949101 ] The MIPS loongson cpufreq drivers don't build unless configured for the correct machine type, due to dependency on machine specific architecture headers and symbols in machine specific platform code. More specifically loongson1-cpufreq.c uses RST_CPU_EN and RST_CPU, neither of which is defined in asm/mach-loongson32/regs-clk.h unless CONFIG_LOONGSON1_LS1B=y, and loongson2_cpufreq.c references loongson2_clockmod_table[], which is only defined in arch/mips/loongson64/lemote-2f/clock.c, i.e. when CONFIG_LEMOTE_MACH2F=y. Add these dependencies to Kconfig to avoid randconfig / allyesconfig build failures (e.g. when based on BMIPS which also has a cpufreq driver). Signed-off-by: James Hogan <jhogan(a)kernel.org> Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/cpufreq/Kconfig | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -273,6 +273,7 @@ endif if MIPS config LOONGSON2_CPUFREQ tristate "Loongson2 CPUFreq Driver" + depends on LEMOTE_MACH2F help This option adds a CPUFreq driver for loongson processors which support software configurable cpu frequency. @@ -285,6 +286,7 @@ config LOONGSON2_CPUFREQ config LOONGSON1_CPUFREQ tristate "Loongson1 CPUFreq Driver" + depends on LOONGSON1_LS1B help This option adds a CPUFreq driver for loongson1 processors which support software configurable cpu frequency. Patches currently in stable-queue which might be from jhogan(a)kernel.org are queue-4.9/cpufreq-add-loongson-machine-dependencies.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "btrfs: fix deadlock when writing out space cache" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: fix deadlock when writing out space cache to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-deadlock-when-writing-out-space-cache.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Josef Bacik <jbacik(a)fb.com> Date: Wed, 15 Nov 2017 16:20:52 -0500 Subject: btrfs: fix deadlock when writing out space cache From: Josef Bacik <jbacik(a)fb.com> [ Upstream commit b77000ed558daa3bef0899d29bf171b8c9b5e6a8 ] If we fail to prepare our pages for whatever reason (out of memory in our case) we need to make sure to drop the block_group->data_rwsem, otherwise hilarity ensues. Signed-off-by: Josef Bacik <jbacik(a)fb.com> Reviewed-by: Omar Sandoval <osandov(a)fb.com> Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: David Sterba <dsterba(a)suse.com> [ add label and use existing unlocking code ] Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/free-space-cache.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -1253,7 +1253,7 @@ static int __btrfs_write_out_cache(struc /* Lock all pages first so we can lock the extent safely. */ ret = io_ctl_prepare_pages(io_ctl, inode, 0); if (ret) - goto out; + goto out_unlock; lock_extent_bits(&BTRFS_I(inode)->io_tree, 0, i_size_read(inode) - 1, &cached_state); @@ -1346,6 +1346,7 @@ out_nospc_locked: out_nospc: cleanup_write_cache_enospc(inode, io_ctl, &cached_state, &bitmap_list); +out_unlock: if (block_group && (block_group->flags & BTRFS_BLOCK_GROUP_DATA)) up_write(&block_group->data_rwsem); Patches currently in stable-queue which might be from jbacik(a)fb.com are queue-4.9/btrfs-fix-deadlock-when-writing-out-space-cache.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "bnxt_en: Fix an error handling path in 'bnxt_get_module_eeprom()'" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bnxt_en: Fix an error handling path in 'bnxt_get_module_eeprom()' to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bnxt_en-fix-an-error-handling-path-in-bnxt_get_module_eeprom.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Tue, 21 Nov 2017 20:46:49 +0100 Subject: bnxt_en: Fix an error handling path in 'bnxt_get_module_eeprom()' From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit dea521a2b9f96e905fa2bb2f95e23ec00c2ec436 ] Error code returned by 'bnxt_read_sfp_module_eeprom_info()' is handled a few lines above when reading the A0 portion of the EEPROM. The same should be done when reading the A2 portion of the EEPROM. In order to correctly propagate an error, update 'rc' in this 2nd call as well, otherwise 0 (success) is returned. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c @@ -1843,8 +1843,8 @@ static int bnxt_get_module_eeprom(struct /* Read A2 portion of the EEPROM */ if (length) { start -= ETH_MODULE_SFF_8436_LEN; - bnxt_read_sfp_module_eeprom_info(bp, I2C_DEV_ADDR_A2, 1, start, - length, data); + rc = bnxt_read_sfp_module_eeprom_info(bp, I2C_DEV_ADDR_A2, 1, + start, length, data); } return rc; } Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.9/bnxt_en-fix-an-error-handling-path-in-bnxt_get_module_eeprom.patch queue-4.9/drm-omap-fix-error-handling-path-in-omap_dmm_probe.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "bcache: check return value of register_shrinker" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bcache: check return value of register_shrinker to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bcache-check-return-value-of-register_shrinker.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Michael Lyle <mlyle(a)lyle.org> Date: Fri, 24 Nov 2017 15:14:27 -0800 Subject: bcache: check return value of register_shrinker From: Michael Lyle <mlyle(a)lyle.org> [ Upstream commit 6c4ca1e36cdc1a0a7a84797804b87920ccbebf51 ] register_shrinker is now __must_check, so check it to kill a warning. Caller of bch_btree_cache_alloc in super.c appropriately checks return value so this is fully plumbed through. This V2 fixes checkpatch warnings and improves the commit description, as I was too hasty getting the previous version out. Signed-off-by: Michael Lyle <mlyle(a)lyle.org> Reviewed-by: Vojtech Pavlik <vojtech(a)suse.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/bcache/btree.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/md/bcache/btree.c +++ b/drivers/md/bcache/btree.c @@ -803,7 +803,10 @@ int bch_btree_cache_alloc(struct cache_s c->shrink.scan_objects = bch_mca_scan; c->shrink.seeks = 4; c->shrink.batch = c->btree_pages * 2; - register_shrinker(&c->shrink); + + if (register_shrinker(&c->shrink)) + pr_warn("bcache: %s: could not register shrinker", + __func__); return 0; } Patches currently in stable-queue which might be from mlyle(a)lyle.org are queue-4.9/bcache-check-return-value-of-register_shrinker.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "auxdisplay: img-ascii-lcd: Only build on archs that have IOMEM" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled auxdisplay: img-ascii-lcd: Only build on archs that have IOMEM to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: auxdisplay-img-ascii-lcd-only-build-on-archs-that-have-iomem.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Thomas Meyer <thomas(a)m3y3r.de> Date: Thu, 10 Aug 2017 10:53:53 +0200 Subject: auxdisplay: img-ascii-lcd: Only build on archs that have IOMEM From: Thomas Meyer <thomas(a)m3y3r.de> [ Upstream commit 141cbfba1d0502006463aa80f57c64086226af1a ] This avoids the MODPOST error: ERROR: "devm_ioremap_resource" [drivers/auxdisplay/img-ascii-lcd.ko] undefined! Signed-off-by: Thomas Meyer <thomas(a)m3y3r.de> Acked-by: Randy Dunlap <rdunlap(a)infradead.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/auxdisplay/Kconfig | 1 + 1 file changed, 1 insertion(+) --- a/drivers/auxdisplay/Kconfig +++ b/drivers/auxdisplay/Kconfig @@ -121,6 +121,7 @@ config CFAG12864B_RATE config IMG_ASCII_LCD tristate "Imagination Technologies ASCII LCD Display" + depends on HAS_IOMEM default y if MIPS_MALTA || MIPS_SEAD3 select SYSCON help Patches currently in stable-queue which might be from thomas(a)m3y3r.de are queue-4.9/auxdisplay-img-ascii-lcd-only-build-on-archs-that-have-iomem.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "ARM: dts: NSP: Fix PPI interrupt types" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: NSP: Fix PPI interrupt types to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-nsp-fix-ppi-interrupt-types.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Florian Fainelli <f.fainelli(a)gmail.com> Date: Tue, 7 Nov 2017 11:10:29 -0800 Subject: ARM: dts: NSP: Fix PPI interrupt types From: Florian Fainelli <f.fainelli(a)gmail.com> [ Upstream commit 5f1aa51c7a1eef1c5a60b8334e32c89904964245 ] Booting a kernel results in the kernel warning us about the following PPI interrupts configuration: [ 0.105127] smp: Bringing up secondary CPUs ... [ 0.110545] GIC: PPI11 is secure or misconfigured [ 0.110551] GIC: PPI13 is secure or misconfigured Fix this by using the appropriate edge configuration for PPI11 and PPI13, this is similar to what was fixed for Northstar (BCM5301X) in commit 0e34079cd1f6 ("ARM: dts: BCM5301X: Correct GIC_PPI interrupt flags"). Fixes: 7b2e987de207 ("ARM: NSP: add minimal Northstar Plus device tree") Fixes: 1a9d53cabaf4 ("ARM: dts: NSP: Add TWD Support to DT") Acked-by: Jon Mason <jon.mason(a)broadcom.com> Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/bcm-nsp.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/arm/boot/dts/bcm-nsp.dtsi +++ b/arch/arm/boot/dts/bcm-nsp.dtsi @@ -85,7 +85,7 @@ timer@20200 { compatible = "arm,cortex-a9-global-timer"; reg = <0x20200 0x100>; - interrupts = <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>; + interrupts = <GIC_PPI 11 IRQ_TYPE_EDGE_RISING>; clocks = <&periph_clk>; }; @@ -93,7 +93,7 @@ compatible = "arm,cortex-a9-twd-timer"; reg = <0x20600 0x20>; interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | - IRQ_TYPE_LEVEL_HIGH)>; + IRQ_TYPE_EDGE_RISING)>; clocks = <&periph_clk>; }; Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are queue-4.9/arm-dts-nsp-fix-ppi-interrupt-types.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "ACPI / bus: Leave modalias empty for devices which are not present" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI / bus: Leave modalias empty for devices which are not present to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: acpi-bus-leave-modalias-empty-for-devices-which-are-not-present.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 14:00:34 CET 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Sun, 15 Oct 2017 21:24:49 +0200 Subject: ACPI / bus: Leave modalias empty for devices which are not present From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 10809bb976648ac58194a629e3d7af99e7400297 ] Most Bay and Cherry Trail devices use a generic DSDT with all possible peripheral devices present in the DSDT, with their _STA returning 0x00 or 0x0f based on AML variables which describe what is actually present on the board. Since ACPI device objects with a 0x00 status (not present) still get an entry under /sys/bus/acpi/devices, and those entry had an acpi:PNPID modalias, userspace would end up loading modules for non present hardware. This commit fixes this by leaving the modalias empty for non present devices. This results in 10 modules less being loaded with a generic distro kernel config on my Cherry Trail test-device (a GPD pocket). Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/device_sysfs.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c index 7b2c48fde4e2..201c7ceb7052 100644 --- a/drivers/acpi/device_sysfs.c +++ b/drivers/acpi/device_sysfs.c @@ -146,6 +146,10 @@ static int create_pnp_modalias(struct acpi_device *acpi_dev, char *modalias, int count; struct acpi_hardware_id *id; + /* Avoid unnecessarily loading modules for non present devices. */ + if (!acpi_device_is_present(acpi_dev)) + return 0; + /* * Since we skip ACPI_DT_NAMESPACE_HID from the modalias below, 0 should * be returned if ACPI_DT_NAMESPACE_HID is the only ACPI/PNP ID in the -- 2.16.1 Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.9/acpi-bus-leave-modalias-empty-for-devices-which-are-not-present.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "xfs: ubsan fixes" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: ubsan fixes to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-ubsan-fixes.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: "Darrick J. Wong" <darrick.wong(a)oracle.com> Date: Mon, 27 Nov 2017 09:50:17 -0800 Subject: xfs: ubsan fixes From: "Darrick J. Wong" <darrick.wong(a)oracle.com> [ Upstream commit 22a6c83777ac7c17d6c63891beeeac24cf5da450 ] Fix some complaints from the UBSAN about signed integer addition overflows. Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Reviewed-by: Brian Foster <bfoster(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_aops.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -399,7 +399,7 @@ xfs_map_blocks( (ip->i_df.if_flags & XFS_IFEXTENTS)); ASSERT(offset <= mp->m_super->s_maxbytes); - if (offset + count > mp->m_super->s_maxbytes) + if ((xfs_ufsize_t)offset + count > mp->m_super->s_maxbytes) count = mp->m_super->s_maxbytes - offset; end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + count); offset_fsb = XFS_B_TO_FSBT(mp, offset); @@ -1265,7 +1265,7 @@ xfs_map_trim_size( if (mapping_size > size) mapping_size = size; if (offset < i_size_read(inode) && - offset + mapping_size >= i_size_read(inode)) { + (xfs_ufsize_t)offset + mapping_size >= i_size_read(inode)) { /* limit mapping to block that spans EOF */ mapping_size = roundup_64(i_size_read(inode) - offset, i_blocksize(inode)); @@ -1312,7 +1312,7 @@ xfs_get_blocks( lockmode = xfs_ilock_data_map_shared(ip); ASSERT(offset <= mp->m_super->s_maxbytes); - if (offset + size > mp->m_super->s_maxbytes) + if ((xfs_ufsize_t)offset + size > mp->m_super->s_maxbytes) size = mp->m_super->s_maxbytes - offset; end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + size); offset_fsb = XFS_B_TO_FSBT(mp, offset); Patches currently in stable-queue which might be from darrick.wong(a)oracle.com are queue-4.14/xfs-always-free-inline-data-before-resetting-inode-fork-during-ifree.patch queue-4.14/xfs-log-recovery-should-replay-deferred-ops-in-order.patch queue-4.14/xfs-ubsan-fixes.patch queue-4.14/xfs-fortify-xfs_alloc_buftarg-error-handling.patch queue-4.14/xfs-properly-retry-failed-dquot-items-in-case-of-error-during-buffer-writeback.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "xfs: Properly retry failed dquot items in case of error during buffer writeback" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: Properly retry failed dquot items in case of error during buffer writeback to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-properly-retry-failed-dquot-items-in-case-of-error-during-buffer-writeback.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: Carlos Maiolino <cmaiolino(a)redhat.com> Date: Tue, 28 Nov 2017 08:54:10 -0800 Subject: xfs: Properly retry failed dquot items in case of error during buffer writeback From: Carlos Maiolino <cmaiolino(a)redhat.com> [ Upstream commit 373b0589dc8d58bc09c9a28d03611ae4fb216057 ] Once the inode item writeback errors is already fixed, it's time to fix the same problem in dquot code. Although there were no reports of users hitting this bug in dquot code (at least none I've seen), the bug is there and I was already planning to fix it when the correct approach to fix the inodes part was decided. This patch aims to fix the same problem in dquot code, regarding failed buffers being unable to be resubmitted once they are flush locked. Tested with the recently test-case sent to fstests list by Hou Tao. Reviewed-by: Brian Foster <bfoster(a)redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino(a)redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_dquot.c | 14 +++++++++++--- fs/xfs/xfs_dquot_item.c | 40 ++++++++++++++++++++++++++++++++++++++-- 2 files changed, 49 insertions(+), 5 deletions(-) --- a/fs/xfs/xfs_dquot.c +++ b/fs/xfs/xfs_dquot.c @@ -987,14 +987,22 @@ xfs_qm_dqflush_done( * holding the lock before removing the dquot from the AIL. */ if ((lip->li_flags & XFS_LI_IN_AIL) && - lip->li_lsn == qip->qli_flush_lsn) { + ((lip->li_lsn == qip->qli_flush_lsn) || + (lip->li_flags & XFS_LI_FAILED))) { /* xfs_trans_ail_delete() drops the AIL lock. */ spin_lock(&ailp->xa_lock); - if (lip->li_lsn == qip->qli_flush_lsn) + if (lip->li_lsn == qip->qli_flush_lsn) { xfs_trans_ail_delete(ailp, lip, SHUTDOWN_CORRUPT_INCORE); - else + } else { + /* + * Clear the failed state since we are about to drop the + * flush lock + */ + if (lip->li_flags & XFS_LI_FAILED) + xfs_clear_li_failed(lip); spin_unlock(&ailp->xa_lock); + } } /* --- a/fs/xfs/xfs_dquot_item.c +++ b/fs/xfs/xfs_dquot_item.c @@ -137,6 +137,26 @@ xfs_qm_dqunpin_wait( wait_event(dqp->q_pinwait, (atomic_read(&dqp->q_pincount) == 0)); } +/* + * Callback used to mark a buffer with XFS_LI_FAILED when items in the buffer + * have been failed during writeback + * + * this informs the AIL that the dquot is already flush locked on the next push, + * and acquires a hold on the buffer to ensure that it isn't reclaimed before + * dirty data makes it to disk. + */ +STATIC void +xfs_dquot_item_error( + struct xfs_log_item *lip, + struct xfs_buf *bp) +{ + struct xfs_dquot *dqp; + + dqp = DQUOT_ITEM(lip)->qli_dquot; + ASSERT(!completion_done(&dqp->q_flush)); + xfs_set_li_failed(lip, bp); +} + STATIC uint xfs_qm_dquot_logitem_push( struct xfs_log_item *lip, @@ -144,13 +164,28 @@ xfs_qm_dquot_logitem_push( __acquires(&lip->li_ailp->xa_lock) { struct xfs_dquot *dqp = DQUOT_ITEM(lip)->qli_dquot; - struct xfs_buf *bp = NULL; + struct xfs_buf *bp = lip->li_buf; uint rval = XFS_ITEM_SUCCESS; int error; if (atomic_read(&dqp->q_pincount) > 0) return XFS_ITEM_PINNED; + /* + * The buffer containing this item failed to be written back + * previously. Resubmit the buffer for IO + */ + if (lip->li_flags & XFS_LI_FAILED) { + if (!xfs_buf_trylock(bp)) + return XFS_ITEM_LOCKED; + + if (!xfs_buf_resubmit_failed_buffers(bp, lip, buffer_list)) + rval = XFS_ITEM_FLUSHING; + + xfs_buf_unlock(bp); + return rval; + } + if (!xfs_dqlock_nowait(dqp)) return XFS_ITEM_LOCKED; @@ -242,7 +277,8 @@ static const struct xfs_item_ops xfs_dqu .iop_unlock = xfs_qm_dquot_logitem_unlock, .iop_committed = xfs_qm_dquot_logitem_committed, .iop_push = xfs_qm_dquot_logitem_push, - .iop_committing = xfs_qm_dquot_logitem_committing + .iop_committing = xfs_qm_dquot_logitem_committing, + .iop_error = xfs_dquot_item_error }; /* Patches currently in stable-queue which might be from cmaiolino(a)redhat.com are queue-4.14/xfs-properly-retry-failed-dquot-items-in-case-of-error-during-buffer-writeback.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "xfs: log recovery should replay deferred ops in order" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: log recovery should replay deferred ops in order to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-log-recovery-should-replay-deferred-ops-in-order.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: "Darrick J. Wong" <darrick.wong(a)oracle.com> Date: Tue, 21 Nov 2017 20:53:02 -0800 Subject: xfs: log recovery should replay deferred ops in order From: "Darrick J. Wong" <darrick.wong(a)oracle.com> [ Upstream commit 509955823cc9cc225c05673b1b83d70ca70c5c60 ] As part of testing log recovery with dm_log_writes, Amir Goldstein discovered an error in the deferred ops recovery that lead to corruption of the filesystem metadata if a reflink+rmap filesystem happened to shut down midway through a CoW remap: "This is what happens [after failed log recovery]: "Phase 1 - find and verify superblock... "Phase 2 - using internal log " - zero log... " - scan filesystem freespace and inode maps... " - found root inode chunk "Phase 3 - for each AG... " - scan (but don't clear) agi unlinked lists... " - process known inodes and perform inode discovery... " - agno = 0 "data fork in regular inode 134 claims CoW block 376 "correcting nextents for inode 134 "bad data fork in inode 134 "would have cleared inode 134" Hou Tao dissected the log contents of exactly such a crash: "According to the implementation of xfs_defer_finish(), these ops should be completed in the following sequence: "Have been done: "(1) CUI: Oper (160) "(2) BUI: Oper (161) "(3) CUD: Oper (194), for CUI Oper (160) "(4) RUI A: Oper (197), free rmap [0x155, 2, -9] "Should be done: "(5) BUD: for BUI Oper (161) "(6) RUI B: add rmap [0x155, 2, 137] "(7) RUD: for RUI A "(8) RUD: for RUI B "Actually be done by xlog_recover_process_intents() "(5) BUD: for BUI Oper (161) "(6) RUI B: add rmap [0x155, 2, 137] "(7) RUD: for RUI B "(8) RUD: for RUI A "So the rmap entry [0x155, 2, -9] for COW should be freed firstly, then a new rmap entry [0x155, 2, 137] will be added. However, as we can see from the log record in post_mount.log (generated after umount) and the trace print, the new rmap entry [0x155, 2, 137] are added firstly, then the rmap entry [0x155, 2, -9] are freed." When reconstructing the internal log state from the log items found on disk, it's required that deferred ops replay in exactly the same order that they would have had the filesystem not gone down. However, replaying unfinished deferred ops can create /more/ deferred ops. These new deferred ops are finished in the wrong order. This causes fs corruption and replay crashes, so let's create a single defer_ops to handle the subsequent ops created during replay, then use one single transaction at the end of log recovery to ensure that everything is replayed in the same order as they're supposed to be. Reported-by: Amir Goldstein <amir73il(a)gmail.com> Analyzed-by: Hou Tao <houtao1(a)huawei.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Tested-by: Amir Goldstein <amir73il(a)gmail.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_bmap_item.c | 23 ++++--------- fs/xfs/xfs_bmap_item.h | 3 + fs/xfs/xfs_log_recover.c | 75 ++++++++++++++++++++++++++++++++++++++++----- fs/xfs/xfs_refcount_item.c | 21 ++++-------- fs/xfs/xfs_refcount_item.h | 3 + 5 files changed, 85 insertions(+), 40 deletions(-) --- a/fs/xfs/xfs_bmap_item.c +++ b/fs/xfs/xfs_bmap_item.c @@ -389,7 +389,8 @@ xfs_bud_init( int xfs_bui_recover( struct xfs_mount *mp, - struct xfs_bui_log_item *buip) + struct xfs_bui_log_item *buip, + struct xfs_defer_ops *dfops) { int error = 0; unsigned int bui_type; @@ -404,9 +405,7 @@ xfs_bui_recover( xfs_exntst_t state; struct xfs_trans *tp; struct xfs_inode *ip = NULL; - struct xfs_defer_ops dfops; struct xfs_bmbt_irec irec; - xfs_fsblock_t firstfsb; ASSERT(!test_bit(XFS_BUI_RECOVERED, &buip->bui_flags)); @@ -464,7 +463,6 @@ xfs_bui_recover( if (VFS_I(ip)->i_nlink == 0) xfs_iflags_set(ip, XFS_IRECOVERY); - xfs_defer_init(&dfops, &firstfsb); /* Process deferred bmap item. */ state = (bmap->me_flags & XFS_BMAP_EXTENT_UNWRITTEN) ? @@ -479,16 +477,16 @@ xfs_bui_recover( break; default: error = -EFSCORRUPTED; - goto err_dfops; + goto err_inode; } xfs_trans_ijoin(tp, ip, 0); count = bmap->me_len; - error = xfs_trans_log_finish_bmap_update(tp, budp, &dfops, type, + error = xfs_trans_log_finish_bmap_update(tp, budp, dfops, type, ip, whichfork, bmap->me_startoff, bmap->me_startblock, &count, state); if (error) - goto err_dfops; + goto err_inode; if (count > 0) { ASSERT(type == XFS_BMAP_UNMAP); @@ -496,16 +494,11 @@ xfs_bui_recover( irec.br_blockcount = count; irec.br_startoff = bmap->me_startoff; irec.br_state = state; - error = xfs_bmap_unmap_extent(tp->t_mountp, &dfops, ip, &irec); + error = xfs_bmap_unmap_extent(tp->t_mountp, dfops, ip, &irec); if (error) - goto err_dfops; + goto err_inode; } - /* Finish transaction, free inodes. */ - error = xfs_defer_finish(&tp, &dfops); - if (error) - goto err_dfops; - set_bit(XFS_BUI_RECOVERED, &buip->bui_flags); error = xfs_trans_commit(tp); xfs_iunlock(ip, XFS_ILOCK_EXCL); @@ -513,8 +506,6 @@ xfs_bui_recover( return error; -err_dfops: - xfs_defer_cancel(&dfops); err_inode: xfs_trans_cancel(tp); if (ip) { --- a/fs/xfs/xfs_bmap_item.h +++ b/fs/xfs/xfs_bmap_item.h @@ -93,6 +93,7 @@ struct xfs_bud_log_item *xfs_bud_init(st struct xfs_bui_log_item *); void xfs_bui_item_free(struct xfs_bui_log_item *); void xfs_bui_release(struct xfs_bui_log_item *); -int xfs_bui_recover(struct xfs_mount *mp, struct xfs_bui_log_item *buip); +int xfs_bui_recover(struct xfs_mount *mp, struct xfs_bui_log_item *buip, + struct xfs_defer_ops *dfops); #endif /* __XFS_BMAP_ITEM_H__ */ --- a/fs/xfs/xfs_log_recover.c +++ b/fs/xfs/xfs_log_recover.c @@ -24,6 +24,7 @@ #include "xfs_bit.h" #include "xfs_sb.h" #include "xfs_mount.h" +#include "xfs_defer.h" #include "xfs_da_format.h" #include "xfs_da_btree.h" #include "xfs_inode.h" @@ -4714,7 +4715,8 @@ STATIC int xlog_recover_process_cui( struct xfs_mount *mp, struct xfs_ail *ailp, - struct xfs_log_item *lip) + struct xfs_log_item *lip, + struct xfs_defer_ops *dfops) { struct xfs_cui_log_item *cuip; int error; @@ -4727,7 +4729,7 @@ xlog_recover_process_cui( return 0; spin_unlock(&ailp->xa_lock); - error = xfs_cui_recover(mp, cuip); + error = xfs_cui_recover(mp, cuip, dfops); spin_lock(&ailp->xa_lock); return error; @@ -4754,7 +4756,8 @@ STATIC int xlog_recover_process_bui( struct xfs_mount *mp, struct xfs_ail *ailp, - struct xfs_log_item *lip) + struct xfs_log_item *lip, + struct xfs_defer_ops *dfops) { struct xfs_bui_log_item *buip; int error; @@ -4767,7 +4770,7 @@ xlog_recover_process_bui( return 0; spin_unlock(&ailp->xa_lock); - error = xfs_bui_recover(mp, buip); + error = xfs_bui_recover(mp, buip, dfops); spin_lock(&ailp->xa_lock); return error; @@ -4803,6 +4806,46 @@ static inline bool xlog_item_is_intent(s } } +/* Take all the collected deferred ops and finish them in order. */ +static int +xlog_finish_defer_ops( + struct xfs_mount *mp, + struct xfs_defer_ops *dfops) +{ + struct xfs_trans *tp; + int64_t freeblks; + uint resblks; + int error; + + /* + * We're finishing the defer_ops that accumulated as a result of + * recovering unfinished intent items during log recovery. We + * reserve an itruncate transaction because it is the largest + * permanent transaction type. Since we're the only user of the fs + * right now, take 93% (15/16) of the available free blocks. Use + * weird math to avoid a 64-bit division. + */ + freeblks = percpu_counter_sum(&mp->m_fdblocks); + if (freeblks <= 0) + return -ENOSPC; + resblks = min_t(int64_t, UINT_MAX, freeblks); + resblks = (resblks * 15) >> 4; + error = xfs_trans_alloc(mp, &M_RES(mp)->tr_itruncate, resblks, + 0, XFS_TRANS_RESERVE, &tp); + if (error) + return error; + + error = xfs_defer_finish(&tp, dfops); + if (error) + goto out_cancel; + + return xfs_trans_commit(tp); + +out_cancel: + xfs_trans_cancel(tp); + return error; +} + /* * When this is called, all of the log intent items which did not have * corresponding log done items should be in the AIL. What we do now @@ -4823,10 +4866,12 @@ STATIC int xlog_recover_process_intents( struct xlog *log) { - struct xfs_log_item *lip; - int error = 0; + struct xfs_defer_ops dfops; struct xfs_ail_cursor cur; + struct xfs_log_item *lip; struct xfs_ail *ailp; + xfs_fsblock_t firstfsb; + int error = 0; #if defined(DEBUG) || defined(XFS_WARN) xfs_lsn_t last_lsn; #endif @@ -4837,6 +4882,7 @@ xlog_recover_process_intents( #if defined(DEBUG) || defined(XFS_WARN) last_lsn = xlog_assign_lsn(log->l_curr_cycle, log->l_curr_block); #endif + xfs_defer_init(&dfops, &firstfsb); while (lip != NULL) { /* * We're done when we see something other than an intent. @@ -4857,6 +4903,12 @@ xlog_recover_process_intents( */ ASSERT(XFS_LSN_CMP(last_lsn, lip->li_lsn) >= 0); + /* + * NOTE: If your intent processing routine can create more + * deferred ops, you /must/ attach them to the dfops in this + * routine or else those subsequent intents will get + * replayed in the wrong order! + */ switch (lip->li_type) { case XFS_LI_EFI: error = xlog_recover_process_efi(log->l_mp, ailp, lip); @@ -4865,10 +4917,12 @@ xlog_recover_process_intents( error = xlog_recover_process_rui(log->l_mp, ailp, lip); break; case XFS_LI_CUI: - error = xlog_recover_process_cui(log->l_mp, ailp, lip); + error = xlog_recover_process_cui(log->l_mp, ailp, lip, + &dfops); break; case XFS_LI_BUI: - error = xlog_recover_process_bui(log->l_mp, ailp, lip); + error = xlog_recover_process_bui(log->l_mp, ailp, lip, + &dfops); break; } if (error) @@ -4878,6 +4932,11 @@ xlog_recover_process_intents( out: xfs_trans_ail_cursor_done(&cur); spin_unlock(&ailp->xa_lock); + if (error) + xfs_defer_cancel(&dfops); + else + error = xlog_finish_defer_ops(log->l_mp, &dfops); + return error; } --- a/fs/xfs/xfs_refcount_item.c +++ b/fs/xfs/xfs_refcount_item.c @@ -393,7 +393,8 @@ xfs_cud_init( int xfs_cui_recover( struct xfs_mount *mp, - struct xfs_cui_log_item *cuip) + struct xfs_cui_log_item *cuip, + struct xfs_defer_ops *dfops) { int i; int error = 0; @@ -405,11 +406,9 @@ xfs_cui_recover( struct xfs_trans *tp; struct xfs_btree_cur *rcur = NULL; enum xfs_refcount_intent_type type; - xfs_fsblock_t firstfsb; xfs_fsblock_t new_fsb; xfs_extlen_t new_len; struct xfs_bmbt_irec irec; - struct xfs_defer_ops dfops; bool requeue_only = false; ASSERT(!test_bit(XFS_CUI_RECOVERED, &cuip->cui_flags)); @@ -465,7 +464,6 @@ xfs_cui_recover( return error; cudp = xfs_trans_get_cud(tp, cuip); - xfs_defer_init(&dfops, &firstfsb); for (i = 0; i < cuip->cui_format.cui_nextents; i++) { refc = &cuip->cui_format.cui_extents[i]; refc_type = refc->pe_flags & XFS_REFCOUNT_EXTENT_TYPE_MASK; @@ -485,7 +483,7 @@ xfs_cui_recover( new_len = refc->pe_len; } else error = xfs_trans_log_finish_refcount_update(tp, cudp, - &dfops, type, refc->pe_startblock, refc->pe_len, + dfops, type, refc->pe_startblock, refc->pe_len, &new_fsb, &new_len, &rcur); if (error) goto abort_error; @@ -497,21 +495,21 @@ xfs_cui_recover( switch (type) { case XFS_REFCOUNT_INCREASE: error = xfs_refcount_increase_extent( - tp->t_mountp, &dfops, &irec); + tp->t_mountp, dfops, &irec); break; case XFS_REFCOUNT_DECREASE: error = xfs_refcount_decrease_extent( - tp->t_mountp, &dfops, &irec); + tp->t_mountp, dfops, &irec); break; case XFS_REFCOUNT_ALLOC_COW: error = xfs_refcount_alloc_cow_extent( - tp->t_mountp, &dfops, + tp->t_mountp, dfops, irec.br_startblock, irec.br_blockcount); break; case XFS_REFCOUNT_FREE_COW: error = xfs_refcount_free_cow_extent( - tp->t_mountp, &dfops, + tp->t_mountp, dfops, irec.br_startblock, irec.br_blockcount); break; @@ -525,17 +523,12 @@ xfs_cui_recover( } xfs_refcount_finish_one_cleanup(tp, rcur, error); - error = xfs_defer_finish(&tp, &dfops); - if (error) - goto abort_defer; set_bit(XFS_CUI_RECOVERED, &cuip->cui_flags); error = xfs_trans_commit(tp); return error; abort_error: xfs_refcount_finish_one_cleanup(tp, rcur, error); -abort_defer: - xfs_defer_cancel(&dfops); xfs_trans_cancel(tp); return error; } --- a/fs/xfs/xfs_refcount_item.h +++ b/fs/xfs/xfs_refcount_item.h @@ -96,6 +96,7 @@ struct xfs_cud_log_item *xfs_cud_init(st struct xfs_cui_log_item *); void xfs_cui_item_free(struct xfs_cui_log_item *); void xfs_cui_release(struct xfs_cui_log_item *); -int xfs_cui_recover(struct xfs_mount *mp, struct xfs_cui_log_item *cuip); +int xfs_cui_recover(struct xfs_mount *mp, struct xfs_cui_log_item *cuip, + struct xfs_defer_ops *dfops); #endif /* __XFS_REFCOUNT_ITEM_H__ */ Patches currently in stable-queue which might be from darrick.wong(a)oracle.com are queue-4.14/xfs-always-free-inline-data-before-resetting-inode-fork-during-ifree.patch queue-4.14/xfs-log-recovery-should-replay-deferred-ops-in-order.patch queue-4.14/xfs-ubsan-fixes.patch queue-4.14/xfs-fortify-xfs_alloc_buftarg-error-handling.patch queue-4.14/xfs-properly-retry-failed-dquot-items-in-case-of-error-during-buffer-writeback.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "xfs: fortify xfs_alloc_buftarg error handling" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: fortify xfs_alloc_buftarg error handling to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-fortify-xfs_alloc_buftarg-error-handling.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: Michal Hocko <mhocko(a)suse.com> Date: Thu, 23 Nov 2017 17:13:40 +0100 Subject: xfs: fortify xfs_alloc_buftarg error handling From: Michal Hocko <mhocko(a)suse.com> [ Upstream commit d210a9874b8f6166579408131cb74495caff1958 ] percpu_counter_init failure path doesn't clean up &btp->bt_lru list. Call list_lru_destroy in that error path. Similarly register_shrinker error path is not handled. While it is unlikely to trigger these error path, it is not impossible especially the later might fail with large NUMAs. Let's handle the failure to make the code more robust. Noticed-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Signed-off-by: Michal Hocko <mhocko(a)suse.com> Acked-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_buf.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -1813,22 +1813,27 @@ xfs_alloc_buftarg( btp->bt_daxdev = dax_dev; if (xfs_setsize_buftarg_early(btp, bdev)) - goto error; + goto error_free; if (list_lru_init(&btp->bt_lru)) - goto error; + goto error_free; if (percpu_counter_init(&btp->bt_io_count, 0, GFP_KERNEL)) - goto error; + goto error_lru; btp->bt_shrinker.count_objects = xfs_buftarg_shrink_count; btp->bt_shrinker.scan_objects = xfs_buftarg_shrink_scan; btp->bt_shrinker.seeks = DEFAULT_SEEKS; btp->bt_shrinker.flags = SHRINKER_NUMA_AWARE; - register_shrinker(&btp->bt_shrinker); + if (register_shrinker(&btp->bt_shrinker)) + goto error_pcpu; return btp; -error: +error_pcpu: + percpu_counter_destroy(&btp->bt_io_count); +error_lru: + list_lru_destroy(&btp->bt_lru); +error_free: kmem_free(btp); return NULL; } Patches currently in stable-queue which might be from mhocko(a)suse.com are queue-4.14/quota-check-for-register_shrinker-failure.patch queue-4.14/xfs-fortify-xfs_alloc_buftarg-error-handling.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "xfs: always free inline data before resetting inode fork during ifree" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: always free inline data before resetting inode fork during ifree to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-always-free-inline-data-before-resetting-inode-fork-during-ifree.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: "Darrick J. Wong" <darrick.wong(a)oracle.com> Date: Wed, 22 Nov 2017 12:21:07 -0800 Subject: xfs: always free inline data before resetting inode fork during ifree From: "Darrick J. Wong" <darrick.wong(a)oracle.com> [ Upstream commit 98c4f78dcdd8cec112d1cbc5e9a792ee6e5ab7a6 ] In xfs_ifree, we reset the data/attr forks to extents format without bothering to free any inline data buffer that might still be around after all the blocks have been truncated off the file. Prior to commit 43518812d2 ("xfs: remove support for inlining data/extents into the inode fork") nobody noticed because the leftover inline data after truncation was small enough to fit inside the inline buffer inside the fork itself. However, now that we've removed the inline buffer, we /always/ have to free the inline data buffer or else we leak them like crazy. This test was found by turning on kmemleak for generic/001 or generic/388. Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_inode.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -2422,6 +2422,24 @@ retry: } /* + * Free any local-format buffers sitting around before we reset to + * extents format. + */ +static inline void +xfs_ifree_local_data( + struct xfs_inode *ip, + int whichfork) +{ + struct xfs_ifork *ifp; + + if (XFS_IFORK_FORMAT(ip, whichfork) != XFS_DINODE_FMT_LOCAL) + return; + + ifp = XFS_IFORK_PTR(ip, whichfork); + xfs_idata_realloc(ip, -ifp->if_bytes, whichfork); +} + +/* * This is called to return an inode to the inode free list. * The inode should already be truncated to 0 length and have * no pages associated with it. This routine also assumes that @@ -2458,6 +2476,9 @@ xfs_ifree( if (error) return error; + xfs_ifree_local_data(ip, XFS_DATA_FORK); + xfs_ifree_local_data(ip, XFS_ATTR_FORK); + VFS_I(ip)->i_mode = 0; /* mark incore inode as free */ ip->i_d.di_flags = 0; ip->i_d.di_dmevmask = 0; Patches currently in stable-queue which might be from darrick.wong(a)oracle.com are queue-4.14/xfs-always-free-inline-data-before-resetting-inode-fork-during-ifree.patch queue-4.14/xfs-log-recovery-should-replay-deferred-ops-in-order.patch queue-4.14/xfs-ubsan-fixes.patch queue-4.14/xfs-fortify-xfs_alloc_buftarg-error-handling.patch queue-4.14/xfs-properly-retry-failed-dquot-items-in-case-of-error-during-buffer-writeback.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "xen-netfront: remove warning when unloading module" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xen-netfront: remove warning when unloading module to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xen-netfront-remove-warning-when-unloading-module.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: Eduardo Otubo <otubo(a)redhat.com> Date: Thu, 23 Nov 2017 15:18:35 +0100 Subject: xen-netfront: remove warning when unloading module From: Eduardo Otubo <otubo(a)redhat.com> [ Upstream commit 5b5971df3bc2775107ddad164018a8a8db633b81 ] v2: * Replace busy wait with wait_event()/wake_up_all() * Cannot garantee that at the time xennet_remove is called, the xen_netback state will not be XenbusStateClosed, so added a condition for that * There's a small chance for the xen_netback state is XenbusStateUnknown by the time the xen_netfront switches to Closed, so added a condition for that. When unloading module xen_netfront from guest, dmesg would output warning messages like below: [ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use! [ 105.236839] deferring g.e. 0x903 (pfn 0x35805) This problem relies on netfront and netback being out of sync. By the time netfront revokes the g.e.'s netback didn't have enough time to free all of them, hence displaying the warnings on dmesg. The trick here is to make netfront to wait until netback frees all the g.e.'s and only then continue to cleanup for the module removal, and this is done by manipulating both device states. Signed-off-by: Eduardo Otubo <otubo(a)redhat.com> Acked-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/xen-netfront.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -87,6 +87,8 @@ struct netfront_cb { /* IRQ name is queue name with "-tx" or "-rx" appended */ #define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3) +static DECLARE_WAIT_QUEUE_HEAD(module_unload_q); + struct netfront_stats { u64 packets; u64 bytes; @@ -2021,10 +2023,12 @@ static void netback_changed(struct xenbu break; case XenbusStateClosed: + wake_up_all(&module_unload_q); if (dev->state == XenbusStateClosed) break; /* Missed the backend's CLOSING state -- fallthrough */ case XenbusStateClosing: + wake_up_all(&module_unload_q); xenbus_frontend_closed(dev); break; } @@ -2130,6 +2134,20 @@ static int xennet_remove(struct xenbus_d dev_dbg(&dev->dev, "%s\n", dev->nodename); + if (xenbus_read_driver_state(dev->otherend) != XenbusStateClosed) { + xenbus_switch_state(dev, XenbusStateClosing); + wait_event(module_unload_q, + xenbus_read_driver_state(dev->otherend) == + XenbusStateClosing); + + xenbus_switch_state(dev, XenbusStateClosed); + wait_event(module_unload_q, + xenbus_read_driver_state(dev->otherend) == + XenbusStateClosed || + xenbus_read_driver_state(dev->otherend) == + XenbusStateUnknown); + } + xennet_disconnect_backend(info); unregister_netdev(info->netdev); Patches currently in stable-queue which might be from otubo(a)redhat.com are queue-4.14/xen-netfront-remove-warning-when-unloading-module.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/xen: Support early interrupts in xen pv guests" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/xen: Support early interrupts in xen pv guests to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-xen-support-early-interrupts-in-xen-pv-guests.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: Juergen Gross <jgross(a)suse.com> Date: Fri, 24 Nov 2017 09:42:21 +0100 Subject: x86/xen: Support early interrupts in xen pv guests From: Juergen Gross <jgross(a)suse.com> [ Upstream commit 42b3a4cb5609de757f5445fcad18945ba9239a07 ] Add early interrupt handlers activated by idt_setup_early_handler() to the handlers supported by Xen pv guests. This will allow for early WARN() calls not crashing the guest. Suggested-by: Andy Lutomirski <luto(a)kernel.org> Signed-off-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: xen-devel(a)lists.xenproject.org Cc: boris.ostrovsky(a)oracle.com Link: https://lkml.kernel.org/r/20171124084221.30172-1-jgross@suse.com Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/segment.h | 12 ++++++++++++ arch/x86/mm/extable.c | 4 +++- arch/x86/xen/enlighten_pv.c | 37 ++++++++++++++++++++++++------------- arch/x86/xen/xen-asm_64.S | 14 ++++++++++++++ 4 files changed, 53 insertions(+), 14 deletions(-) --- a/arch/x86/include/asm/segment.h +++ b/arch/x86/include/asm/segment.h @@ -236,11 +236,23 @@ */ #define EARLY_IDT_HANDLER_SIZE 9 +/* + * xen_early_idt_handler_array is for Xen pv guests: for each entry in + * early_idt_handler_array it contains a prequel in the form of + * pop %rcx; pop %r11; jmp early_idt_handler_array[i]; summing up to + * max 8 bytes. + */ +#define XEN_EARLY_IDT_HANDLER_SIZE 8 + #ifndef __ASSEMBLY__ extern const char early_idt_handler_array[NUM_EXCEPTION_VECTORS][EARLY_IDT_HANDLER_SIZE]; extern void early_ignore_irq(void); +#if defined(CONFIG_X86_64) && defined(CONFIG_XEN_PV) +extern const char xen_early_idt_handler_array[NUM_EXCEPTION_VECTORS][XEN_EARLY_IDT_HANDLER_SIZE]; +#endif + /* * Load a segment. Fall back on loading the zero segment if something goes * wrong. This variant assumes that loading zero fully clears the segment. --- a/arch/x86/mm/extable.c +++ b/arch/x86/mm/extable.c @@ -1,6 +1,7 @@ #include <linux/extable.h> #include <linux/uaccess.h> #include <linux/sched/debug.h> +#include <xen/xen.h> #include <asm/fpu/internal.h> #include <asm/traps.h> @@ -212,8 +213,9 @@ void __init early_fixup_exception(struct * Old CPUs leave the high bits of CS on the stack * undefined. I'm not sure which CPUs do this, but at least * the 486 DX works this way. + * Xen pv domains are not using the default __KERNEL_CS. */ - if (regs->cs != __KERNEL_CS) + if (!xen_pv_domain() && regs->cs != __KERNEL_CS) goto fail; /* --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -622,7 +622,7 @@ static struct trap_array_entry trap_arra { simd_coprocessor_error, xen_simd_coprocessor_error, false }, }; -static bool get_trap_addr(void **addr, unsigned int ist) +static bool __ref get_trap_addr(void **addr, unsigned int ist) { unsigned int nr; bool ist_okay = false; @@ -644,6 +644,14 @@ static bool get_trap_addr(void **addr, u } } + if (nr == ARRAY_SIZE(trap_array) && + *addr >= (void *)early_idt_handler_array[0] && + *addr < (void *)early_idt_handler_array[NUM_EXCEPTION_VECTORS]) { + nr = (*addr - (void *)early_idt_handler_array[0]) / + EARLY_IDT_HANDLER_SIZE; + *addr = (void *)xen_early_idt_handler_array[nr]; + } + if (WARN_ON(ist != 0 && !ist_okay)) return false; @@ -1261,6 +1269,21 @@ asmlinkage __visible void __init xen_sta xen_setup_gdt(0); xen_init_irq_ops(); + + /* Let's presume PV guests always boot on vCPU with id 0. */ + per_cpu(xen_vcpu_id, 0) = 0; + + /* + * Setup xen_vcpu early because idt_setup_early_handler needs it for + * local_irq_disable(), irqs_disabled(). + * + * Don't do the full vcpu_info placement stuff until we have + * the cpu_possible_mask and a non-dummy shared_info. + */ + xen_vcpu_info_reset(0); + + idt_setup_early_handler(); + xen_init_capabilities(); #ifdef CONFIG_X86_LOCAL_APIC @@ -1294,18 +1317,6 @@ asmlinkage __visible void __init xen_sta */ acpi_numa = -1; #endif - /* Let's presume PV guests always boot on vCPU with id 0. */ - per_cpu(xen_vcpu_id, 0) = 0; - - /* - * Setup xen_vcpu early because start_kernel needs it for - * local_irq_disable(), irqs_disabled(). - * - * Don't do the full vcpu_info placement stuff until we have - * the cpu_possible_mask and a non-dummy shared_info. - */ - xen_vcpu_info_reset(0); - WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_pv, xen_cpu_dead_pv)); local_irq_disable(); --- a/arch/x86/xen/xen-asm_64.S +++ b/arch/x86/xen/xen-asm_64.S @@ -15,6 +15,7 @@ #include <xen/interface/xen.h> +#include <linux/init.h> #include <linux/linkage.h> .macro xen_pv_trap name @@ -54,6 +55,19 @@ xen_pv_trap entry_INT80_compat #endif xen_pv_trap hypervisor_callback + __INIT +ENTRY(xen_early_idt_handler_array) + i = 0 + .rept NUM_EXCEPTION_VECTORS + pop %rcx + pop %r11 + jmp early_idt_handler_array + i*EARLY_IDT_HANDLER_SIZE + i = i + 1 + .fill xen_early_idt_handler_array + i*XEN_EARLY_IDT_HANDLER_SIZE - ., 1, 0xcc + .endr +END(xen_early_idt_handler_array) + __FINIT + hypercall_iret = hypercall_page + __HYPERVISOR_iret * 32 /* * Xen64 iret frame: Patches currently in stable-queue which might be from jgross(a)suse.com are queue-4.14/xen-netfront-remove-warning-when-unloading-module.patch queue-4.14/x86-xen-support-early-interrupts-in-xen-pv-guests.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: gadget: don't dereference g until after it has been null checked" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: don't dereference g until after it has been null checked to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: Colin Ian King <colin.king(a)canonical.com> Date: Tue, 14 Nov 2017 16:18:28 +0000 Subject: usb: gadget: don't dereference g until after it has been null checked From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit b2fc059fa549fe6881d4c1f8d698b0f50bcd16ec ] Avoid dereferencing pointer g until after g has been sanity null checked; move the assignment of cdev much later when it is required into a more local scope. Detected by CoverityScan, CID#1222135 ("Dereference before null check") Fixes: b785ea7ce662 ("usb: gadget: composite: fix ep->maxburst initialization") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/composite.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -150,7 +150,6 @@ int config_ep_by_speed(struct usb_gadget struct usb_function *f, struct usb_ep *_ep) { - struct usb_composite_dev *cdev = get_gadget_data(g); struct usb_endpoint_descriptor *chosen_desc = NULL; struct usb_descriptor_header **speed_desc = NULL; @@ -229,8 +228,12 @@ ep_found: _ep->maxburst = comp_desc->bMaxBurst + 1; break; default: - if (comp_desc->bMaxBurst != 0) + if (comp_desc->bMaxBurst != 0) { + struct usb_composite_dev *cdev; + + cdev = get_gadget_data(g); ERROR(cdev, "ep0 bMaxBurst must be 0\n"); + } _ep->maxburst = 1; break; } Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-4.14/i2c-i2c-boardinfo-fix-memory-leaks-on-devinfo.patch queue-4.14/usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "uapi: fix linux/kfd_ioctl.h userspace compilation errors" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled uapi: fix linux/kfd_ioctl.h userspace compilation errors to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: uapi-fix-linux-kfd_ioctl.h-userspace-compilation-errors.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: "Dmitry V. Levin" <ldv(a)altlinux.org> Date: Mon, 13 Nov 2017 03:35:27 +0300 Subject: uapi: fix linux/kfd_ioctl.h userspace compilation errors From: "Dmitry V. Levin" <ldv(a)altlinux.org> [ Upstream commit b4d085201d86af69cbda2214c6dafc0be240ef9f ] Consistently use types provided by <linux/types.h> via <drm/drm.h> to fix the following linux/kfd_ioctl.h userspace compilation errors: /usr/include/linux/kfd_ioctl.h:236:2: error: unknown type name 'uint64_t' uint64_t va_addr; /* to KFD */ /usr/include/linux/kfd_ioctl.h:237:2: error: unknown type name 'uint32_t' uint32_t gpu_id; /* to KFD */ /usr/include/linux/kfd_ioctl.h:238:2: error: unknown type name 'uint32_t' uint32_t pad; /usr/include/linux/kfd_ioctl.h:243:2: error: unknown type name 'uint64_t' uint64_t tile_config_ptr; /usr/include/linux/kfd_ioctl.h:245:2: error: unknown type name 'uint64_t' uint64_t macro_tile_config_ptr; /usr/include/linux/kfd_ioctl.h:249:2: error: unknown type name 'uint32_t' uint32_t num_tile_configs; /usr/include/linux/kfd_ioctl.h:253:2: error: unknown type name 'uint32_t' uint32_t num_macro_tile_configs; /usr/include/linux/kfd_ioctl.h:255:2: error: unknown type name 'uint32_t' uint32_t gpu_id; /* to KFD */ /usr/include/linux/kfd_ioctl.h:256:2: error: unknown type name 'uint32_t' uint32_t gb_addr_config; /* from KFD */ /usr/include/linux/kfd_ioctl.h:257:2: error: unknown type name 'uint32_t' uint32_t num_banks; /* from KFD */ /usr/include/linux/kfd_ioctl.h:258:2: error: unknown type name 'uint32_t' uint32_t num_ranks; /* from KFD */ Fixes: 6a1c9510694fe ("drm/amdkfd: Adding new IOCTL for scratch memory v2") Fixes: 5d71dbc3a5886 ("drm/amdkfd: Implement image tiling mode support v2") Signed-off-by: Dmitry V. Levin <ldv(a)altlinux.org> Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/uapi/linux/kfd_ioctl.h | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) --- a/include/uapi/linux/kfd_ioctl.h +++ b/include/uapi/linux/kfd_ioctl.h @@ -233,29 +233,29 @@ struct kfd_ioctl_wait_events_args { }; struct kfd_ioctl_set_scratch_backing_va_args { - uint64_t va_addr; /* to KFD */ - uint32_t gpu_id; /* to KFD */ - uint32_t pad; + __u64 va_addr; /* to KFD */ + __u32 gpu_id; /* to KFD */ + __u32 pad; }; struct kfd_ioctl_get_tile_config_args { /* to KFD: pointer to tile array */ - uint64_t tile_config_ptr; + __u64 tile_config_ptr; /* to KFD: pointer to macro tile array */ - uint64_t macro_tile_config_ptr; + __u64 macro_tile_config_ptr; /* to KFD: array size allocated by user mode * from KFD: array size filled by kernel */ - uint32_t num_tile_configs; + __u32 num_tile_configs; /* to KFD: array size allocated by user mode * from KFD: array size filled by kernel */ - uint32_t num_macro_tile_configs; + __u32 num_macro_tile_configs; - uint32_t gpu_id; /* to KFD */ - uint32_t gb_addr_config; /* from KFD */ - uint32_t num_banks; /* from KFD */ - uint32_t num_ranks; /* from KFD */ + __u32 gpu_id; /* to KFD */ + __u32 gb_addr_config; /* from KFD */ + __u32 num_banks; /* from KFD */ + __u32 num_ranks; /* from KFD */ /* struct size can be extended later if needed * without breaking ABI compatibility */ Patches currently in stable-queue which might be from ldv(a)altlinux.org are queue-4.14/uapi-fix-linux-kfd_ioctl.h-userspace-compilation-errors.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "SUNRPC: Allow connect to return EHOSTUNREACH" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled SUNRPC: Allow connect to return EHOSTUNREACH to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sunrpc-allow-connect-to-return-ehostunreach.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: Trond Myklebust <trond.myklebust(a)primarydata.com> Date: Fri, 24 Nov 2017 12:00:24 -0500 Subject: SUNRPC: Allow connect to return EHOSTUNREACH From: Trond Myklebust <trond.myklebust(a)primarydata.com> [ Upstream commit 4ba161a793d5f43757c35feff258d9f20a082940 ] Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> Tested-by: Dmitry Vyukov <dvyukov(a)google.com> Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sunrpc/xprtsock.c | 1 + 1 file changed, 1 insertion(+) --- a/net/sunrpc/xprtsock.c +++ b/net/sunrpc/xprtsock.c @@ -2437,6 +2437,7 @@ static void xs_tcp_setup_socket(struct w case -ECONNREFUSED: case -ECONNRESET: case -ENETUNREACH: + case -EHOSTUNREACH: case -EADDRINUSE: case -ENOBUFS: /* Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are queue-4.14/nfsd-ensure-we-check-stateid-validity-in-the-seqid-operation-checks.patch queue-4.14/sunrpc-allow-connect-to-return-ehostunreach.patch queue-4.14/nfsd-close-should-return-the-invalid-special-stateid-for-nfsv4.x-x-0.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-rtl8188eu-fix-incorrect-response-to-siocgiwessid.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: Larry Finger <Larry.Finger(a)lwfinger.net> Date: Sat, 25 Nov 2017 13:32:38 -0600 Subject: staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID From: Larry Finger <Larry.Finger(a)lwfinger.net> [ Upstream commit b77992d2df9e47144354d1b25328b180afa33442 ] When not associated with an AP, wifi device drivers should respond to the SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the behavior expected by dhcpcd. Currently, this driver returns an error code (-1) from the ioctl call, which causes dhcpcd to assume that the device is not a wireless interface and therefore it fails to work correctly with it thereafter. This problem was reported and tested at https://github.com/lwfinger/rtl8188eu/issues/234. Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) --- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c +++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c @@ -1395,19 +1395,13 @@ static int rtw_wx_get_essid(struct net_d if ((check_fwstate(pmlmepriv, _FW_LINKED)) || (check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE))) { len = pcur_bss->Ssid.SsidLength; - - wrqu->essid.length = len; - memcpy(extra, pcur_bss->Ssid.Ssid, len); - - wrqu->essid.flags = 1; } else { - ret = -1; - goto exit; + len = 0; + *extra = 0; } - -exit: - + wrqu->essid.length = len; + wrqu->essid.flags = 1; return ret; } Patches currently in stable-queue which might be from Larry.Finger(a)lwfinger.net are queue-4.14/staging-rtl8188eu-fix-incorrect-response-to-siocgiwessid.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "sctp: set sender next_tsn for the old result with ctsn_ack_point plus 1" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sctp: set sender next_tsn for the old result with ctsn_ack_point plus 1 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sctp-set-sender-next_tsn-for-the-old-result-with-ctsn_ack_point-plus-1.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: Xin Long <lucien.xin(a)gmail.com> Date: Sat, 25 Nov 2017 21:05:36 +0800 Subject: sctp: set sender next_tsn for the old result with ctsn_ack_point plus 1 From: Xin Long <lucien.xin(a)gmail.com> [ Upstream commit 52a395896a051a3d5c34fba67c324f69ec5e67c6 ] When doing asoc reset, if the sender of the response has already sent some chunk and increased asoc->next_tsn before the duplicate request comes, the response will use the old result with an incorrect sender next_tsn. Better than asoc->next_tsn, asoc->ctsn_ack_point can't be changed after the sender of the response has performed the asoc reset and before the peer has confirmed it, and it's value is still asoc->next_tsn original value minus 1. This patch sets sender next_tsn for the old result with ctsn_ack_point plus 1 when processing the duplicate request, to make sure the sender next_tsn value peer gets will be always right. Fixes: 692787cef651 ("sctp: implement receiver-side procedures for the SSN/TSN Reset Request Parameter") Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sctp/stream.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/sctp/stream.c +++ b/net/sctp/stream.c @@ -541,7 +541,7 @@ struct sctp_chunk *sctp_process_strreset i = asoc->strreset_inseq - request_seq - 1; result = asoc->strreset_result[i]; if (result == SCTP_STRRESET_PERFORMED) { - next_tsn = asoc->next_tsn; + next_tsn = asoc->ctsn_ack_point + 1; init_tsn = sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map) + 1; } Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are queue-4.14/sctp-set-sender-next_tsn-for-the-old-result-with-ctsn_ack_point-plus-1.patch queue-4.14/sctp-only-allow-the-asoc-reset-when-the-asoc-outq-is-empty.patch queue-4.14/sctp-avoid-flushing-unsent-queue-when-doing-asoc-reset.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "sctp: only allow the asoc reset when the asoc outq is empty" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sctp: only allow the asoc reset when the asoc outq is empty to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sctp-only-allow-the-asoc-reset-when-the-asoc-outq-is-empty.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: Xin Long <lucien.xin(a)gmail.com> Date: Sat, 25 Nov 2017 21:05:34 +0800 Subject: sctp: only allow the asoc reset when the asoc outq is empty From: Xin Long <lucien.xin(a)gmail.com> [ Upstream commit 5c6144a0eb5366ae07fc5059301b139338f39bbd ] As it says in rfc6525#section5.1.4, before sending the request, C2: The sender has either no outstanding TSNs or considers all outstanding TSNs abandoned. Prior to this patch, it tried to consider all outstanding TSNs abandoned by dropping all chunks in all outqs with sctp_outq_free (even including sacked, retransmit and transmitted queues) when doing this reset, which is too aggressive. To make it work gently, this patch will only allow the asoc reset when the sender has no outstanding TSNs by checking if unsent, transmitted and retransmit are all empty with sctp_outq_is_empty before sending and processing the request. Fixes: 692787cef651 ("sctp: implement receiver-side procedures for the SSN/TSN Reset Request Parameter") Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sctp/stream.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/net/sctp/stream.c +++ b/net/sctp/stream.c @@ -224,6 +224,9 @@ int sctp_send_reset_assoc(struct sctp_as if (asoc->strreset_outstanding) return -EINPROGRESS; + if (!sctp_outq_is_empty(&asoc->outqueue)) + return -EAGAIN; + chunk = sctp_make_strreset_tsnreq(asoc); if (!chunk) return -ENOMEM; @@ -544,6 +547,12 @@ struct sctp_chunk *sctp_process_strreset } goto err; } + + if (!sctp_outq_is_empty(&asoc->outqueue)) { + result = SCTP_STRRESET_IN_PROGRESS; + goto err; + } + asoc->strreset_inseq++; if (!(asoc->strreset_enable & SCTP_ENABLE_RESET_ASSOC_REQ)) Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are queue-4.14/sctp-set-sender-next_tsn-for-the-old-result-with-ctsn_ack_point-plus-1.patch queue-4.14/sctp-only-allow-the-asoc-reset-when-the-asoc-outq-is-empty.patch queue-4.14/sctp-avoid-flushing-unsent-queue-when-doing-asoc-reset.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "sctp: avoid flushing unsent queue when doing asoc reset" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sctp: avoid flushing unsent queue when doing asoc reset to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sctp-avoid-flushing-unsent-queue-when-doing-asoc-reset.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: Xin Long <lucien.xin(a)gmail.com> Date: Sat, 25 Nov 2017 21:05:35 +0800 Subject: sctp: avoid flushing unsent queue when doing asoc reset From: Xin Long <lucien.xin(a)gmail.com> [ Upstream commit 159f2a7456c6ae95c1e1a58e8b8ec65ef12d51cf ] Now when doing asoc reset, it cleans up sacked and abandoned queues by calling sctp_outq_free where it also cleans up unsent, retransmit and transmitted queues. It's safe for the sender of response, as these 3 queues are empty at that time. But when the receiver of response is doing the reset, the users may already enqueue some chunks into unsent during the time waiting the response, and these chunks should not be flushed. To void the chunks in it would be removed, it moves the queue into a temp list, then gets it back after sctp_outq_free is done. The patch also fixes some incorrect comments in sctp_process_strreset_tsnreq. Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sctp/stream.c | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) --- a/net/sctp/stream.c +++ b/net/sctp/stream.c @@ -563,9 +563,10 @@ struct sctp_chunk *sctp_process_strreset goto out; } - /* G3: The same processing as though a SACK chunk with no gap report - * and a cumulative TSN ACK of the Sender's Next TSN minus 1 were - * received MUST be performed. + /* G4: The same processing as though a FWD-TSN chunk (as defined in + * [RFC3758]) with all streams affected and a new cumulative TSN + * ACK of the Receiver's Next TSN minus 1 were received MUST be + * performed. */ max_tsn_seen = sctp_tsnmap_get_max_tsn_seen(&asoc->peer.tsn_map); sctp_ulpq_reasm_flushtsn(&asoc->ulpq, max_tsn_seen); @@ -580,10 +581,9 @@ struct sctp_chunk *sctp_process_strreset sctp_tsnmap_init(&asoc->peer.tsn_map, SCTP_TSN_MAP_INITIAL, init_tsn, GFP_ATOMIC); - /* G4: The same processing as though a FWD-TSN chunk (as defined in - * [RFC3758]) with all streams affected and a new cumulative TSN - * ACK of the Receiver's Next TSN minus 1 were received MUST be - * performed. + /* G3: The same processing as though a SACK chunk with no gap report + * and a cumulative TSN ACK of the Sender's Next TSN minus 1 were + * received MUST be performed. */ sctp_outq_free(&asoc->outqueue); @@ -844,6 +844,7 @@ struct sctp_chunk *sctp_process_strreset if (result == SCTP_STRRESET_PERFORMED) { __u32 mtsn = sctp_tsnmap_get_max_tsn_seen( &asoc->peer.tsn_map); + LIST_HEAD(temp); sctp_ulpq_reasm_flushtsn(&asoc->ulpq, mtsn); sctp_ulpq_abort_pd(&asoc->ulpq, GFP_ATOMIC); @@ -852,7 +853,13 @@ struct sctp_chunk *sctp_process_strreset SCTP_TSN_MAP_INITIAL, stsn, GFP_ATOMIC); + /* Clean up sacked and abandoned queues only. As the + * out_chunk_list may not be empty, splice it to temp, + * then get it back after sctp_outq_free is done. + */ + list_splice_init(&asoc->outqueue.out_chunk_list, &temp); sctp_outq_free(&asoc->outqueue); + list_splice_init(&temp, &asoc->outqueue.out_chunk_list); asoc->next_tsn = rtsn; asoc->ctsn_ack_point = asoc->next_tsn - 1; Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are queue-4.14/sctp-set-sender-next_tsn-for-the-old-result-with-ctsn_ack_point-plus-1.patch queue-4.14/sctp-only-allow-the-asoc-reset-when-the-asoc-outq-is-empty.patch queue-4.14/sctp-avoid-flushing-unsent-queue-when-doing-asoc-reset.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-ufs-ufshcd-fix-potential-null-pointer-dereference-in-ufshcd_config_vreg.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> Date: Mon, 20 Nov 2017 08:12:29 -0600 Subject: scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> [ Upstream commit 727535903bea924c4f73abb202c4b3e85fff0ca4 ] _vreg_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _vreg_ has been null checked. This issue was detected with the help of Coccinelle. Fixes: aa4976130934 ("ufs: Add regulator enable support") Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> Reviewed-by: Subhash Jadavani <subhashj(a)codeaurora.org> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/ufs/ufshcd.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -6555,12 +6555,15 @@ static int ufshcd_config_vreg(struct dev struct ufs_vreg *vreg, bool on) { int ret = 0; - struct regulator *reg = vreg->reg; - const char *name = vreg->name; + struct regulator *reg; + const char *name; int min_uV, uA_load; BUG_ON(!vreg); + reg = vreg->reg; + name = vreg->name; + if (regulator_count_voltages(reg) > 0) { min_uV = on ? vreg->min_uV : 0; ret = regulator_set_voltage(reg, min_uV, vreg->max_uV); Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are queue-4.14/scsi-ufs-ufshcd-fix-potential-null-pointer-dereference-in-ufshcd_config_vreg.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-aacraid-prevent-crash-in-case-of-free-interrupt-during-scsi-eh-path.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 19:14:55 -0200 Subject: scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com> [ Upstream commit e4717292ddebcfe231651b5aff9fa19ca158d178 ] As part of the scsi EH path, aacraid performs a reinitialization of the adapter, which encompass freeing resources and IRQs, NULLifying lots of pointers, and then initialize it all over again. We've identified a problem during the free IRQ portion of this path if CONFIG_DEBUG_SHIRQ is enabled on kernel config file. Happens that, in case this flag was set, right after free_irq() effectively clears the interrupt, it checks if it was requested as IRQF_SHARED. In positive case, it performs another call to the IRQ handler on driver. Problem is: since aacraid currently free some resources *before* freeing the IRQ, once free_irq() path calls the handler again (due to CONFIG_DEBUG_SHIRQ), aacraid crashes due to NULL pointer dereference with the following trace: aac_src_intr_message+0xf8/0x740 [aacraid] __free_irq+0x33c/0x4a0 free_irq+0x78/0xb0 aac_free_irq+0x13c/0x150 [aacraid] aac_reset_adapter+0x2e8/0x970 [aacraid] aac_eh_reset+0x3a8/0x5d0 [aacraid] scsi_try_host_reset+0x74/0x180 scsi_eh_ready_devs+0xc70/0x1510 scsi_error_handler+0x624/0xa20 This patch prevents the crash by changing the order of the deinitialization in this path of aacraid: first we clear the IRQ, then we free other resources. No functional change intended. Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com> Reviewed-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/aacraid/commsup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/aacraid/commsup.c +++ b/drivers/scsi/aacraid/commsup.c @@ -1583,6 +1583,7 @@ static int _aac_reset_adapter(struct aac * will ensure that i/o is queisced and the card is flushed in that * case. */ + aac_free_irq(aac); aac_fib_map_free(aac); dma_free_coherent(&aac->pdev->dev, aac->comm_size, aac->comm_addr, aac->comm_phys); @@ -1590,7 +1591,6 @@ static int _aac_reset_adapter(struct aac aac->comm_phys = 0; kfree(aac->queues); aac->queues = NULL; - aac_free_irq(aac); kfree(aac->fsa_dev); aac->fsa_dev = NULL; Patches currently in stable-queue which might be from gpiccoli(a)linux.vnet.ibm.com are queue-4.14/scsi-aacraid-prevent-crash-in-case-of-free-interrupt-during-scsi-eh-path.patch queue-4.14/scsi-aacraid-fix-hang-in-kdump.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "scripts/faddr2line: extend usage on generic arch" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scripts/faddr2line: extend usage on generic arch to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scripts-faddr2line-extend-usage-on-generic-arch.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: "Liu, Changcheng" <changcheng.liu(a)intel.com> Date: Wed, 29 Nov 2017 16:10:25 -0800 Subject: scripts/faddr2line: extend usage on generic arch From: "Liu, Changcheng" <changcheng.liu(a)intel.com> [ Upstream commit 95a87982541932503d3f59aba4c30b0bde0a6294 ] When cross-compiling, fadd2line should use the binary tool used for the target system, rather than that of the host. Link: http://lkml.kernel.org/r/20171121092911.GA150711@sofia Signed-off-by: Liu Changcheng <changcheng.liu(a)intel.com> Cc: Kate Stewart <kstewart(a)linuxfoundation.org> Cc: NeilBrown <neilb(a)suse.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- scripts/faddr2line | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) --- a/scripts/faddr2line +++ b/scripts/faddr2line @@ -44,9 +44,16 @@ set -o errexit set -o nounset +READELF="${CROSS_COMPILE}readelf" +ADDR2LINE="${CROSS_COMPILE}addr2line" +SIZE="${CROSS_COMPILE}size" +NM="${CROSS_COMPILE}nm" + command -v awk >/dev/null 2>&1 || die "awk isn't installed" -command -v readelf >/dev/null 2>&1 || die "readelf isn't installed" -command -v addr2line >/dev/null 2>&1 || die "addr2line isn't installed" +command -v ${READELF} >/dev/null 2>&1 || die "readelf isn't installed" +command -v ${ADDR2LINE} >/dev/null 2>&1 || die "addr2line isn't installed" +command -v ${SIZE} >/dev/null 2>&1 || die "size isn't installed" +command -v ${NM} >/dev/null 2>&1 || die "nm isn't installed" usage() { echo "usage: faddr2line <object file> <func+offset> <func+offset>..." >&2 @@ -69,10 +76,10 @@ die() { find_dir_prefix() { local objfile=$1 - local start_kernel_addr=$(readelf -sW $objfile | awk '$8 == "start_kernel" {printf "0x%s", $2}') + local start_kernel_addr=$(${READELF} -sW $objfile | awk '$8 == "start_kernel" {printf "0x%s", $2}') [[ -z $start_kernel_addr ]] && return - local file_line=$(addr2line -e $objfile $start_kernel_addr) + local file_line=$(${ADDR2LINE} -e $objfile $start_kernel_addr) [[ -z $file_line ]] && return local prefix=${file_line%init/main.c:*} @@ -104,7 +111,7 @@ __faddr2line() { # Go through each of the object's symbols which match the func name. # In rare cases there might be duplicates. - file_end=$(size -Ax $objfile | awk '$1 == ".text" {print $2}') + file_end=$(${SIZE} -Ax $objfile | awk '$1 == ".text" {print $2}') while read symbol; do local fields=($symbol) local sym_base=0x${fields[0]} @@ -156,10 +163,10 @@ __faddr2line() { # pass real address to addr2line echo "$func+$offset/$sym_size:" - addr2line -fpie $objfile $addr | sed "s; $dir_prefix$\./$*; ;" + ${ADDR2LINE} -fpie $objfile $addr | sed "s; $dir_prefix$\./$*; ;" DONE=1 - done < <(nm -n $objfile | awk -v fn=$func -v end=$file_end '$3 == fn { found=1; line=$0; start=$1; next } found == 1 { found=0; print line, "0x"$1 } END {if (found == 1) print line, end; }') + done < <(${NM} -n $objfile | awk -v fn=$func -v end=$file_end '$3 == fn { found=1; line=$0; start=$1; next } found == 1 { found=0; print line, "0x"$1 } END {if (found == 1) print line, end; }') } [[ $# -lt 2 ]] && usage Patches currently in stable-queue which might be from changcheng.liu(a)intel.com are queue-4.14/scripts-faddr2line-extend-usage-on-generic-arch.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "s390/zcrypt: Fix wrong comparison leading to strange load balancing" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled s390/zcrypt: Fix wrong comparison leading to strange load balancing to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: s390-zcrypt-fix-wrong-comparison-leading-to-strange-load-balancing.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: Harald Freudenberger <freude(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 16:32:22 +0100 Subject: s390/zcrypt: Fix wrong comparison leading to strange load balancing From: Harald Freudenberger <freude(a)linux.vnet.ibm.com> [ Upstream commit 0b0882672640ced4deeebf84da0b88b6389619c4 ] The function to decide if one zcrypt queue is better than another one compared two pointers instead of comparing the values where the pointers refer to. So within the same zcrypt card when load of each queue was equal just one queue was used. This effect only appears on relatively lite load, typically with one thread applications. This patch fixes the wrong comparison and now the counters show that requests are balanced equally over all available queues within the cards. There is no performance improvement coming with this fix. As long as the queue depth for an APQN queue is not touched, processing is not faster when requests are spread over queues within the same card hardware. So this fix only beautifies the lszcrypt counter printouts. Signed-off-by: Harald Freudenberger <freude(a)linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/s390/crypto/zcrypt_api.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/s390/crypto/zcrypt_api.c +++ b/drivers/s390/crypto/zcrypt_api.c @@ -218,8 +218,8 @@ static inline bool zcrypt_queue_compare( weight += atomic_read(&zq->load); pref_weight += atomic_read(&pref_zq->load); if (weight == pref_weight) - return &zq->queue->total_request_count > - &pref_zq->queue->total_request_count; + return zq->queue->total_request_count > + pref_zq->queue->total_request_count; return weight > pref_weight; } Patches currently in stable-queue which might be from freude(a)linux.vnet.ibm.com are queue-4.14/s390-zcrypt-fix-wrong-comparison-leading-to-strange-load-balancing.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "s390/topology: fix compile error in file arch/s390/kernel/smp.c" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled s390/topology: fix compile error in file arch/s390/kernel/smp.c to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: s390-topology-fix-compile-error-in-file-arch-s390-kernel-smp.c.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: Thomas Richter <tmricht(a)linux.vnet.ibm.com> Date: Thu, 16 Nov 2017 14:26:36 +0100 Subject: s390/topology: fix compile error in file arch/s390/kernel/smp.c From: Thomas Richter <tmricht(a)linux.vnet.ibm.com> [ Upstream commit 38389ec84e835fa31a59b7dabb18343106a6d0d5 ] Commit 1887aa07b676 ("s390/topology: add detection of dedicated vs shared CPUs") introduced following compiler error when CONFIG_SCHED_TOPOLOGY is not set. CC arch/s390/kernel/smp.o ... arch/s390/kernel/smp.c: In function ‘smp_start_secondary’: arch/s390/kernel/smp.c:812:6: error: implicit declaration of function ‘topology_cpu_dedicated’; did you mean ‘topology_cpu_init’? This patch fixes the compiler error by adding function topology_cpu_dedicated() to return false when this config option is not defined. Signed-off-by: Thomas Richter <tmricht(a)linux.vnet.ibm.com> Reviewed-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/include/asm/topology.h | 1 + arch/s390/kernel/smp.c | 1 + 2 files changed, 2 insertions(+) --- a/arch/s390/include/asm/topology.h +++ b/arch/s390/include/asm/topology.h @@ -51,6 +51,7 @@ const struct cpumask *cpu_coregroup_mask static inline void topology_init_early(void) { } static inline void topology_schedule_update(void) { } static inline int topology_cpu_init(struct cpu *cpu) { return 0; } +static inline int topology_cpu_dedicated(int cpu_nr) { return 0; } static inline void topology_expect_change(void) { } #endif /* CONFIG_SCHED_TOPOLOGY */ --- a/arch/s390/kernel/smp.c +++ b/arch/s390/kernel/smp.c @@ -54,6 +54,7 @@ #include <asm/sigp.h> #include <asm/idle.h> #include <asm/nmi.h> +#include <asm/topology.h> #include "entry.h" enum { Patches currently in stable-queue which might be from tmricht(a)linux.vnet.ibm.com are queue-4.14/s390-topology-fix-compile-error-in-file-arch-s390-kernel-smp.c.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "s390: fix alloc_pgste check in init_new_context again" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled s390: fix alloc_pgste check in init_new_context again to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: s390-fix-alloc_pgste-check-in-init_new_context-again.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Date: Wed, 22 Nov 2017 17:19:32 +0100 Subject: s390: fix alloc_pgste check in init_new_context again From: Martin Schwidefsky <schwidefsky(a)de.ibm.com> [ Upstream commit 53c4ab70c11c3ba1b9e3caa8e8c17e9c16d9cbc0 ] git commit badb8bb983e9 "fix alloc_pgste check in init_new_context" fixed the problem of 'current->mm == NULL' in init_new_context back in 2011. git commit 3eabaee998c7 "KVM: s390: allow sie enablement for multi- threaded programs" completely removed the check against alloc_pgste. git commit 23fefe119ceb "s390/kvm: avoid global config of vm.alloc_pgste=1" re-added a check against the alloc_pgste flag but without the required check for current->mm != NULL. For execve() called by a kernel thread init_new_context() reads from ((struct mm_struct *) NULL)->context.alloc_pgste to decide between 2K vs 4K page tables. If the bit happens to be set for the init process it will be created with large page tables. This decision is inherited by all the children of init, this waste quite some memory. Re-add the check for 'current->mm != NULL'. Fixes: 23fefe119ceb ("s390/kvm: avoid global config of vm.alloc_pgste=1") Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/include/asm/mmu_context.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/s390/include/asm/mmu_context.h +++ b/arch/s390/include/asm/mmu_context.h @@ -28,7 +28,7 @@ static inline int init_new_context(struc #ifdef CONFIG_PGSTE mm->context.alloc_pgste = page_table_allocate_pgste || test_thread_flag(TIF_PGSTE) || - current->mm->context.alloc_pgste; + (current->mm && current->mm->context.alloc_pgste); mm->context.has_pgste = 0; mm->context.use_skey = 0; mm->context.use_cmma = 0; Patches currently in stable-queue which might be from schwidefsky(a)de.ibm.com are queue-4.14/s390-zcrypt-fix-wrong-comparison-leading-to-strange-load-balancing.patch queue-4.14/s390-fix-alloc_pgste-check-in-init_new_context-again.patch queue-4.14/s390-topology-fix-compile-error-in-file-arch-s390-kernel-smp.c.patch

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] Patch "rxrpc: The mutex lock returned by rxrpc_accept_call() needs releasing" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rxrpc: The mutex lock returned by rxrpc_accept_call() needs releasing to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rxrpc-the-mutex-lock-returned-by-rxrpc_accept_call-needs-releasing.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Feb 1 13:45:42 CET 2018 From: David Howells <dhowells(a)redhat.com> Date: Fri, 24 Nov 2017 10:18:40 +0000 Subject: rxrpc: The mutex lock returned by rxrpc_accept_call() needs releasing From: David Howells <dhowells(a)redhat.com> [ Upstream commit 03a6c82218b9a87014b2c6c4e178294fdc8ebd8a ] The caller of rxrpc_accept_call() must release the lock on call->user_mutex returned by that function. Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rxrpc/sendmsg.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/net/rxrpc/sendmsg.c +++ b/net/rxrpc/sendmsg.c @@ -563,8 +563,8 @@ int rxrpc_do_sendmsg(struct rxrpc_sock * /* The socket is now unlocked. */ if (IS_ERR(call)) return PTR_ERR(call); - rxrpc_put_call(call, rxrpc_call_put); - return 0; + ret = 0; + goto out_put_unlock; } call = rxrpc_find_call_by_user_ID(rx, p.user_call_ID); @@ -633,6 +633,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock * ret = rxrpc_send_data(rx, call, msg, len, NULL); } +out_put_unlock: mutex_unlock(&call->user_mutex); error_put: rxrpc_put_call(call, rxrpc_call_put); Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-4.14/rxrpc-the-mutex-lock-returned-by-rxrpc_accept_call-needs-releasing.patch queue-4.14/rxrpc-provide-a-different-lockdep-key-for-call-user_mutex-for-kernel-calls.patch queue-4.14/rxrpc-fix-service-endpoint-expiry.patch

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror