Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

64 participants
123759 discussions

Patch "RDMA/hfi1: fix array termination by appending NULL to attr array" 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 RDMA/hfi1: fix array termination by appending NULL to attr array 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: rdma-hfi1-fix-array-termination-by-appending-null-to-attr-array.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: "Steven L. Roberts" <robers97(a)gmail.com> Date: Wed, 10 May 2017 10:54:12 -0500 Subject: RDMA/hfi1: fix array termination by appending NULL to attr array From: "Steven L. Roberts" <robers97(a)gmail.com> [ Upstream commit c4dd4b69f55abcc8dd079f8de55d9d8c2ddbefce ] This fixes a kernel panic when loading the hfi driver as a dynamic module. Signed-off-by: Steven L Roberts <robers97(a)gmail.com> Reviewed-by: Leon Romanovsky <leon(a)kernel.org> Acked-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/hfi1/sysfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/infiniband/hw/hfi1/sysfs.c +++ b/drivers/infiniband/hw/hfi1/sysfs.c @@ -196,7 +196,8 @@ static const struct sysfs_ops port_cc_sy }; static struct attribute *port_cc_default_attributes[] = { - &cc_prescan_attr.attr + &cc_prescan_attr.attr, + NULL }; static struct kobj_type port_cc_ktype = { Patches currently in stable-queue which might be from robers97(a)gmail.com are queue-4.9/rdma-hfi1-fix-array-termination-by-appending-null-to-attr-array.patch

7 years, 8 months

Patch "ray_cs: Avoid reading past end of buffer" 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 ray_cs: Avoid reading past end of buffer to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ray_cs-avoid-reading-past-end-of-buffer.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Kees Cook <keescook(a)chromium.org> Date: Fri, 5 May 2017 15:38:41 -0700 Subject: ray_cs: Avoid reading past end of buffer From: Kees Cook <keescook(a)chromium.org> [ Upstream commit e48d661eb13f2f83861428f001c567fdb3f317e8 ] Using memcpy() from a buffer that is shorter than the length copied means the destination buffer is being filled with arbitrary data from the kernel rodata segment. In this case, the source was made longer, since it did not match the destination structure size. Additionally removes a needless cast. This was found with the future CONFIG_FORTIFY_SOURCE feature. Cc: Daniel Micay <danielmicay(a)gmail.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ray_cs.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/net/wireless/ray_cs.c +++ b/drivers/net/wireless/ray_cs.c @@ -247,7 +247,10 @@ static const UCHAR b4_default_startup_pa 0x04, 0x08, /* Noise gain, limit offset */ 0x28, 0x28, /* det rssi, med busy offsets */ 7, /* det sync thresh */ - 0, 2, 2 /* test mode, min, max */ + 0, 2, 2, /* test mode, min, max */ + 0, /* rx/tx delay */ + 0, 0, 0, 0, 0, 0, /* current BSS id */ + 0 /* hop set */ }; /*===========================================================================*/ @@ -598,7 +601,7 @@ static void init_startup_params(ray_dev_ * a_beacon_period = hops a_beacon_period = KuS *//* 64ms = 010000 */ if (local->fw_ver == 0x55) { - memcpy((UCHAR *) &local->sparm.b4, b4_default_startup_parms, + memcpy(&local->sparm.b4, b4_default_startup_parms, sizeof(struct b4_startup_params)); /* Translate sane kus input values to old build 4/5 format */ /* i = hop time in uS truncated to 3 bytes */ Patches currently in stable-queue which might be from keescook(a)chromium.org are queue-4.9/qlge-avoid-reading-past-end-of-buffer.patch queue-4.9/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch queue-4.9/x86-mm-kaslr-use-the-_asm_mul-macro-for-multiplication-to-work-around-clang-incompatibility.patch queue-4.9/ray_cs-avoid-reading-past-end-of-buffer.patch queue-4.9/x86-boot-declare-error-as-noreturn.patch queue-4.9/selftests-kselftest_harness-fix-compile-warning.patch queue-4.9/bna-avoid-reading-past-end-of-buffer.patch

7 years, 8 months

Patch "qlge: Avoid reading past end of buffer" 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 qlge: Avoid reading past end of buffer to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: qlge-avoid-reading-past-end-of-buffer.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Kees Cook <keescook(a)chromium.org> Date: Fri, 5 May 2017 15:34:34 -0700 Subject: qlge: Avoid reading past end of buffer From: Kees Cook <keescook(a)chromium.org> [ Upstream commit df5303a8aa9a0a6934f4cea7427f1edf771f21c2 ] Using memcpy() from a string that is shorter than the length copied means the destination buffer is being filled with arbitrary data from the kernel rodata segment. Instead, use strncpy() which will fill the trailing bytes with zeros. This was found with the future CONFIG_FORTIFY_SOURCE feature. Cc: Daniel Micay <danielmicay(a)gmail.com> Signed-off-by: Kees Cook <keescook(a)chromium.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> --- drivers/net/ethernet/qlogic/qlge/qlge_dbg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c +++ b/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c @@ -765,7 +765,7 @@ int ql_core_dump(struct ql_adapter *qdev sizeof(struct mpi_coredump_global_header); mpi_coredump->mpi_global_header.imageSize = sizeof(struct ql_mpi_coredump); - memcpy(mpi_coredump->mpi_global_header.idString, "MPI Coredump", + strncpy(mpi_coredump->mpi_global_header.idString, "MPI Coredump", sizeof(mpi_coredump->mpi_global_header.idString)); /* Get generic NIC reg dump */ @@ -1255,7 +1255,7 @@ static void ql_gen_reg_dump(struct ql_ad sizeof(struct mpi_coredump_global_header); mpi_coredump->mpi_global_header.imageSize = sizeof(struct ql_reg_dump); - memcpy(mpi_coredump->mpi_global_header.idString, "MPI Coredump", + strncpy(mpi_coredump->mpi_global_header.idString, "MPI Coredump", sizeof(mpi_coredump->mpi_global_header.idString)); Patches currently in stable-queue which might be from keescook(a)chromium.org are queue-4.9/qlge-avoid-reading-past-end-of-buffer.patch queue-4.9/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch queue-4.9/x86-mm-kaslr-use-the-_asm_mul-macro-for-multiplication-to-work-around-clang-incompatibility.patch queue-4.9/ray_cs-avoid-reading-past-end-of-buffer.patch queue-4.9/x86-boot-declare-error-as-noreturn.patch queue-4.9/selftests-kselftest_harness-fix-compile-warning.patch queue-4.9/bna-avoid-reading-past-end-of-buffer.patch

7 years, 8 months

Patch "qlcnic: Fix a sleep-in-atomic bug in qlcnic_82xx_hw_write_wx_2M and qlcnic_82xx_hw_read_wx_2M" 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 qlcnic: Fix a sleep-in-atomic bug in qlcnic_82xx_hw_write_wx_2M and qlcnic_82xx_hw_read_wx_2M 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: qlcnic-fix-a-sleep-in-atomic-bug-in-qlcnic_82xx_hw_write_wx_2m-and-qlcnic_82xx_hw_read_wx_2m.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Jia-Ju Bai <baijiaju1990(a)163.com> Date: Thu, 1 Jun 2017 16:18:10 +0800 Subject: qlcnic: Fix a sleep-in-atomic bug in qlcnic_82xx_hw_write_wx_2M and qlcnic_82xx_hw_read_wx_2M From: Jia-Ju Bai <baijiaju1990(a)163.com> [ Upstream commit 5ea6d691aac6c93b790f0905e3460d44cc4c449b ] The driver may sleep under a write spin lock, and the function call path is: qlcnic_82xx_hw_write_wx_2M (acquire the lock by write_lock_irqsave) crb_win_lock qlcnic_pcie_sem_lock usleep_range qlcnic_82xx_hw_read_wx_2M (acquire the lock by write_lock_irqsave) crb_win_lock qlcnic_pcie_sem_lock usleep_range To fix it, the usleep_range is replaced with udelay. Signed-off-by: Jia-Ju Bai <baijiaju1990(a)163.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c @@ -341,7 +341,7 @@ qlcnic_pcie_sem_lock(struct qlcnic_adapt } return -EIO; } - usleep_range(1000, 1500); + udelay(1200); } if (id_reg) Patches currently in stable-queue which might be from baijiaju1990(a)163.com are queue-4.9/misdn-fix-a-sleep-in-atomic-bug.patch queue-4.9/qlcnic-fix-a-sleep-in-atomic-bug-in-qlcnic_82xx_hw_write_wx_2m-and-qlcnic_82xx_hw_read_wx_2m.patch

7 years, 8 months

Patch "qed: Correct doorbell configuration for !4Kb pages" 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 qed: Correct doorbell configuration for !4Kb pages 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: qed-correct-doorbell-configuration-for-4kb-pages.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Ram Amrani <Ram.Amrani(a)cavium.com> Date: Tue, 9 May 2017 15:07:50 +0300 Subject: qed: Correct doorbell configuration for !4Kb pages From: Ram Amrani <Ram.Amrani(a)cavium.com> [ Upstream commit a82dadbce47395747824971db08a128130786fdc ] When configuring the doorbell DPI address, driver aligns the start address to 4KB [HW-pages] instead of host PAGE_SIZE. As a result, RoCE applications might receive addresses which are unaligned to pages [when PAGE_SIZE > 4KB], which is a security risk. Fixes: 51ff17251c9c ("qed: Add support for RoCE hw init") Signed-off-by: Ram Amrani <Ram.Amrani(a)cavium.com> Signed-off-by: Yuval Mintz <Yuval.Mintz(a)cavium.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/qlogic/qed/qed_dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/qlogic/qed/qed_dev.c +++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c @@ -850,7 +850,7 @@ qed_hw_init_pf_doorbell_bar(struct qed_h NULL) + qed_cxt_get_proto_cid_count(p_hwfn, PROTOCOLID_ETH, NULL); - norm_regsize = roundup(QED_PF_DEMS_SIZE * non_pwm_conn, 4096); + norm_regsize = roundup(QED_PF_DEMS_SIZE * non_pwm_conn, PAGE_SIZE); min_addr_reg1 = norm_regsize / 4096; pwm_regsize = db_bar_size - norm_regsize; Patches currently in stable-queue which might be from Ram.Amrani(a)cavium.com are queue-4.9/qed-correct-doorbell-configuration-for-4kb-pages.patch

7 years, 8 months

Patch "[media] pxa_camera: fix module remove codepath for v4l2 clock" 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] pxa_camera: fix module remove codepath for v4l2 clock 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: pxa_camera-fix-module-remove-codepath-for-v4l2-clock.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Petr Cvek <petr.cvek(a)tul.cz> Date: Mon, 24 Apr 2017 22:51:58 -0300 Subject: [media] pxa_camera: fix module remove codepath for v4l2 clock From: Petr Cvek <petr.cvek(a)tul.cz> [ Upstream commit e3b4d10cc057522353c4a02f2f90dca6a52e006f ] The conversion from soc_camera omitted a correct handling of the clock gating for a sensor. When the pxa_camera driver module was removed it tried to unregister clk, but this caused a similar warning: WARNING: CPU: 0 PID: 6740 at drivers/media/v4l2-core/v4l2-clk.c:278 v4l2_clk_unregister(): Refusing to unregister ref-counted 0-0030 clock! The clock was at time still refcounted by the sensor driver. Before the removing of the pxa_camera the clock must be dropped by the sensor driver. This should be triggered by v4l2_async_notifier_unregister() call which removes sensor driver module too, calls unbind() function and then tries to probe sensor driver again. Inside unbind() we can safely unregister the v4l2 clock as the sensor driver got removed. The original v4l2_clk_unregister() should be put inside test as the clock can be already unregistered from unbind(). If there was not any bound sensor the clock is still present. The codepath is practically a copy from the old soc_camera. The bug was tested with a pxa_camera+ov9640 combination during the conversion of the ov9640 from the soc_camera. Signed-off-by: Petr Cvek <petr.cvek(a)tul.cz> Tested-by: Robert Jarzmik <robert.jarzmik(a)free.fr> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> 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/platform/pxa_camera.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) --- a/drivers/media/platform/pxa_camera.c +++ b/drivers/media/platform/pxa_camera.c @@ -2169,6 +2169,12 @@ static void pxa_camera_sensor_unbind(str pxa_dma_stop_channels(pcdev); pxa_camera_destroy_formats(pcdev); + + if (pcdev->mclk_clk) { + v4l2_clk_unregister(pcdev->mclk_clk); + pcdev->mclk_clk = NULL; + } + video_unregister_device(&pcdev->vdev); pcdev->sensor = NULL; @@ -2495,7 +2501,13 @@ static int pxa_camera_remove(struct plat dma_release_channel(pcdev->dma_chans[1]); dma_release_channel(pcdev->dma_chans[2]); - v4l2_clk_unregister(pcdev->mclk_clk); + v4l2_async_notifier_unregister(&pcdev->notifier); + + if (pcdev->mclk_clk) { + v4l2_clk_unregister(pcdev->mclk_clk); + pcdev->mclk_clk = NULL; + } + v4l2_device_unregister(&pcdev->v4l2_dev); dev_info(&pdev->dev, "PXA Camera driver unloaded\n"); Patches currently in stable-queue which might be from petr.cvek(a)tul.cz are queue-4.9/pxa_camera-fix-module-remove-codepath-for-v4l2-clock.patch

7 years, 8 months

Patch "qed: Fix overriding of supported autoneg 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 qed: Fix overriding of supported autoneg 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: qed-fix-overriding-of-supported-autoneg-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 Mon Apr 9 17:09:24 CEST 2018 From: "sudarsana.kalluru(a)cavium.com" <sudarsana.kalluru(a)cavium.com> Date: Thu, 4 May 2017 08:15:04 -0700 Subject: qed: Fix overriding of supported autoneg value. From: "sudarsana.kalluru(a)cavium.com" <sudarsana.kalluru(a)cavium.com> [ Upstream commit 34f9199ce7b7e5c641b96e928bd60e086bf7f278 ] Driver currently uses advertised-autoneg value to populate the supported-autoneg field. When advertised field is updated, user gets the same value for supported field. Supported-autoneg value need to be populated from the link capabilities value returned by the MFW. Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru(a)cavium.com> Signed-off-by: Yuval Mintz <Yuval.Mintz(a)cavium.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/qlogic/qed/qed_dev.c | 3 +++ drivers/net/ethernet/qlogic/qed/qed_main.c | 6 +++++- drivers/net/ethernet/qlogic/qed/qed_mcp.h | 1 + 3 files changed, 9 insertions(+), 1 deletion(-) --- a/drivers/net/ethernet/qlogic/qed/qed_dev.c +++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c @@ -1628,6 +1628,9 @@ static int qed_hw_get_nvm_info(struct qe DP_NOTICE(p_hwfn, "Unknown Speed in 0x%08x\n", link_temp); } + p_hwfn->mcp_info->link_capabilities.default_speed_autoneg = + link->speed.autoneg; + link_temp &= NVM_CFG1_PORT_DRV_FLOW_CONTROL_MASK; link_temp >>= NVM_CFG1_PORT_DRV_FLOW_CONTROL_OFFSET; link->pause.autoneg = !!(link_temp & --- a/drivers/net/ethernet/qlogic/qed/qed_main.c +++ b/drivers/net/ethernet/qlogic/qed/qed_main.c @@ -1240,7 +1240,7 @@ static void qed_fill_link(struct qed_hwf /* TODO - at the moment assume supported and advertised speed equal */ if_link->supported_caps = QED_LM_FIBRE_BIT; - if (params.speed.autoneg) + if (link_caps.default_speed_autoneg) if_link->supported_caps |= QED_LM_Autoneg_BIT; if (params.pause.autoneg || (params.pause.forced_rx && params.pause.forced_tx)) @@ -1250,6 +1250,10 @@ static void qed_fill_link(struct qed_hwf if_link->supported_caps |= QED_LM_Pause_BIT; if_link->advertised_caps = if_link->supported_caps; + if (params.speed.autoneg) + if_link->advertised_caps |= QED_LM_Autoneg_BIT; + else + if_link->advertised_caps &= ~QED_LM_Autoneg_BIT; if (params.speed.advertised_speeds & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G) if_link->advertised_caps |= QED_LM_1000baseT_Half_BIT | --- a/drivers/net/ethernet/qlogic/qed/qed_mcp.h +++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.h @@ -35,6 +35,7 @@ struct qed_mcp_link_params { struct qed_mcp_link_capabilities { u32 speed_capabilities; + bool default_speed_autoneg; }; struct qed_mcp_link_state { Patches currently in stable-queue which might be from sudarsana.kalluru(a)cavium.com are queue-4.9/qed-fix-overriding-of-supported-autoneg-value.patch

7 years, 8 months

Patch "powerpc/spufs: Fix coredump of SPU contexts" 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 powerpc/spufs: Fix coredump of SPU contexts 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: powerpc-spufs-fix-coredump-of-spu-contexts.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Michael Ellerman <mpe(a)ellerman.id.au> Date: Mon, 29 May 2017 20:26:07 +1000 Subject: powerpc/spufs: Fix coredump of SPU contexts From: Michael Ellerman <mpe(a)ellerman.id.au> [ Upstream commit 99acc9bede06bbb2662aafff51f5b9e529fa845e ] If a process dumps core while it has SPU contexts active then we have code to also dump information about the SPU contexts. Unfortunately it's been broken for 3 1/2 years, and we didn't notice. In commit 7b1f4020d0d1 ("spufs: get rid of dump_emit() wrappers") the nread variable was removed and rc used instead. That means when the loop exits successfully, rc has the number of bytes read, but it's then used as the return value for the function, which should return 0 on success. So fix it by setting rc = 0 before returning in the success case. Fixes: 7b1f4020d0d1 ("spufs: get rid of dump_emit() wrappers") Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Acked-by: Jeremy Kerr <jk(a)ozlabs.org> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/platforms/cell/spufs/coredump.c | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/powerpc/platforms/cell/spufs/coredump.c +++ b/arch/powerpc/platforms/cell/spufs/coredump.c @@ -175,6 +175,8 @@ static int spufs_arch_write_note(struct skip = roundup(cprm->pos - total + sz, 4) - cprm->pos; if (!dump_skip(cprm, skip)) goto Eio; + + rc = 0; out: free_page((unsigned long)buf); return rc; Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are queue-4.9/selftests-powerpc-fix-tm-resched-dscr-test-with-some-compilers.patch queue-4.9/powerpc-modules-if-mprofile-kernel-is-enabled-add-it-to-vermagic.patch queue-4.9/powerpc-mm-fix-virt_addr_valid-etc.-on-64-bit-hash.patch queue-4.9/powerpc-spufs-fix-coredump-of-spu-contexts.patch queue-4.9/cxl-unlock-on-error-in-probe.patch queue-4.9/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch queue-4.9/powerpc-don-t-clobber-tcr-when-setting-tcr.patch queue-4.9/powerpc-8xx-fix-mpc8xx_get_irq-return-on-no-irq.patch

7 years, 8 months

Patch "powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash" 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 powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash 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: powerpc-mm-fix-virt_addr_valid-etc.-on-64-bit-hash.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Michael Ellerman <mpe(a)ellerman.id.au> Date: Thu, 18 May 2017 20:37:31 +1000 Subject: powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash From: Michael Ellerman <mpe(a)ellerman.id.au> [ Upstream commit e41e53cd4fe331d0d1f06f8e4ed7e2cc63ee2c34 ] virt_addr_valid() is supposed to tell you if it's OK to call virt_to_page() on an address. What this means in practice is that it should only return true for addresses in the linear mapping which are backed by a valid PFN. We are failing to properly check that the address is in the linear mapping, because virt_to_pfn() will return a valid looking PFN for more or less any address. That bug is actually caused by __pa(), used in virt_to_pfn(). eg: __pa(0xc000000000010000) = 0x10000 # Good __pa(0xd000000000010000) = 0x10000 # Bad! __pa(0x0000000000010000) = 0x10000 # Bad! This started happening after commit bdbc29c19b26 ("powerpc: Work around gcc miscompilation of __pa() on 64-bit") (Aug 2013), where we changed the definition of __pa() to work around a GCC bug. Prior to that we subtracted PAGE_OFFSET from the value passed to __pa(), meaning __pa() of a 0xd or 0x0 address would give you something bogus back. Until we can verify if that GCC bug is no longer an issue, or come up with another solution, this commit does the minimal fix to make virt_addr_valid() work, by explicitly checking that the address is in the linear mapping region. Fixes: bdbc29c19b26 ("powerpc: Work around gcc miscompilation of __pa() on 64-bit") Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Reviewed-by: Paul Mackerras <paulus(a)ozlabs.org> Reviewed-by: Balbir Singh <bsingharora(a)gmail.com> Tested-by: Breno Leitao <breno.leitao(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/include/asm/page.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/arch/powerpc/include/asm/page.h +++ b/arch/powerpc/include/asm/page.h @@ -132,7 +132,19 @@ extern long long virt_phys_offset; #define virt_to_pfn(kaddr) (__pa(kaddr) >> PAGE_SHIFT) #define virt_to_page(kaddr) pfn_to_page(virt_to_pfn(kaddr)) #define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT) + +#ifdef CONFIG_PPC_BOOK3S_64 +/* + * On hash the vmalloc and other regions alias to the kernel region when passed + * through __pa(), which virt_to_pfn() uses. That means virt_addr_valid() can + * return true for some vmalloc addresses, which is incorrect. So explicitly + * check that the address is in the kernel region. + */ +#define virt_addr_valid(kaddr) (REGION_ID(kaddr) == KERNEL_REGION_ID && \ + pfn_valid(virt_to_pfn(kaddr))) +#else #define virt_addr_valid(kaddr) pfn_valid(virt_to_pfn(kaddr)) +#endif /* * On Book-E parts we need __va to parse the device tree and we can't Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are queue-4.9/selftests-powerpc-fix-tm-resched-dscr-test-with-some-compilers.patch queue-4.9/powerpc-modules-if-mprofile-kernel-is-enabled-add-it-to-vermagic.patch queue-4.9/powerpc-mm-fix-virt_addr_valid-etc.-on-64-bit-hash.patch queue-4.9/powerpc-spufs-fix-coredump-of-spu-contexts.patch queue-4.9/cxl-unlock-on-error-in-probe.patch queue-4.9/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch queue-4.9/powerpc-don-t-clobber-tcr-when-setting-tcr.patch queue-4.9/powerpc-8xx-fix-mpc8xx_get_irq-return-on-no-irq.patch

7 years, 8 months

Patch "powerpc/modules: If mprofile-kernel is enabled add it to vermagic" 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 powerpc/modules: If mprofile-kernel is enabled add it to vermagic 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: powerpc-modules-if-mprofile-kernel-is-enabled-add-it-to-vermagic.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Michael Ellerman <mpe(a)ellerman.id.au> Date: Wed, 10 May 2017 16:57:49 +1000 Subject: powerpc/modules: If mprofile-kernel is enabled add it to vermagic From: Michael Ellerman <mpe(a)ellerman.id.au> [ Upstream commit 43e24e82f35291d4c1ca78877ce1b20d3aeb78f1 ] On powerpc we can build the kernel with two different ABIs for mcount(), which is used by ftrace. Kernels built with one ABI do not know how to load modules built with the other ABI. The new style ABI is called "mprofile-kernel", for want of a better name. Currently if we build a module using the old style ABI, and the kernel with mprofile-kernel, when we load the module we'll oops something like: # insmod autofs4-no-mprofile-kernel.ko ftrace-powerpc: Unexpected instruction f8810028 around bl _mcount ------------[ cut here ]------------ WARNING: CPU: 6 PID: 3759 at ../kernel/trace/ftrace.c:2024 ftrace_bug+0x2b8/0x3c0 CPU: 6 PID: 3759 Comm: insmod Not tainted 4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269 #11 ... NIP [c0000000001eaa48] ftrace_bug+0x2b8/0x3c0 LR [c0000000001eaff8] ftrace_process_locs+0x4a8/0x590 Call Trace: alloc_pages_current+0xc4/0x1d0 (unreliable) ftrace_process_locs+0x4a8/0x590 load_module+0x1c8c/0x28f0 SyS_finit_module+0x110/0x140 system_call+0x38/0xfc ... ftrace failed to modify [<d000000002a31024>] 0xd000000002a31024 actual: 35:65:00:48 We can avoid this by including in the vermagic whether the kernel/module was built with mprofile-kernel. Which results in: # insmod autofs4-pg.ko autofs4: version magic '4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269 SMP mod_unload modversions ' should be '4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269-dirty SMP mod_unload modversions mprofile-kernel' insmod: ERROR: could not insert module autofs4-pg.ko: Invalid module format Fixes: 8c50b72a3b4f ("powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel") Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Acked-by: Balbir Singh <bsingharora(a)gmail.com> Acked-by: Jessica Yu <jeyu(a)redhat.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/include/asm/module.h | 4 ++++ 1 file changed, 4 insertions(+) --- a/arch/powerpc/include/asm/module.h +++ b/arch/powerpc/include/asm/module.h @@ -14,6 +14,10 @@ #include <asm-generic/module.h> +#ifdef CC_USING_MPROFILE_KERNEL +#define MODULE_ARCH_VERMAGIC "mprofile-kernel" +#endif + #ifndef __powerpc64__ /* * Thanks to Paul M for explaining this. Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are queue-4.9/selftests-powerpc-fix-tm-resched-dscr-test-with-some-compilers.patch queue-4.9/powerpc-modules-if-mprofile-kernel-is-enabled-add-it-to-vermagic.patch queue-4.9/powerpc-mm-fix-virt_addr_valid-etc.-on-64-bit-hash.patch queue-4.9/powerpc-spufs-fix-coredump-of-spu-contexts.patch queue-4.9/cxl-unlock-on-error-in-probe.patch queue-4.9/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch queue-4.9/powerpc-don-t-clobber-tcr-when-setting-tcr.patch queue-4.9/powerpc-8xx-fix-mpc8xx_get_irq-return-on-no-irq.patch

7 years, 8 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror