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

Patch "rtc: snvs: fix an incorrect check of return 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 rtc: snvs: fix an incorrect check of return 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: rtc-snvs-fix-an-incorrect-check-of-return-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 Tue Apr 10 10:31:53 CEST 2018 From: Pan Bian <bianpan2016(a)163.com> Date: Sun, 23 Apr 2017 13:43:24 +0800 Subject: rtc: snvs: fix an incorrect check of return value From: Pan Bian <bianpan2016(a)163.com> [ Upstream commit 758929005f06f954b7e1c87a1c9fdb44157b228f ] Function devm_regmap_init_mmio() returns an ERR_PTR on error. However, in function snvs_rtc_probe() its return value is checked against NULL. This patch fixes it by checking the return value with IS_ERR(). Signed-off-by: Pan Bian <bianpan2016(a)163.com> Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/rtc/rtc-snvs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/rtc/rtc-snvs.c +++ b/drivers/rtc/rtc-snvs.c @@ -257,7 +257,7 @@ static int snvs_rtc_probe(struct platfor of_property_read_u32(pdev->dev.of_node, "offset", &data->offset); } - if (!data->regmap) { + if (IS_ERR(data->regmap)) { dev_err(&pdev->dev, "Can't find snvs syscon\n"); return -ENODEV; } Patches currently in stable-queue which might be from bianpan2016(a)163.com are queue-4.4/cx25840-fix-unchecked-return-values.patch queue-4.4/usb-dwc3-keystone-check-return-value.patch queue-4.4/rtc-snvs-fix-an-incorrect-check-of-return-value.patch

7 years, 7 months

1
0
0 0

Patch "rtc: opal: Handle disabled TPO in opal_get_tpo_time()" 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 rtc: opal: Handle disabled TPO in opal_get_tpo_time() 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: rtc-opal-handle-disabled-tpo-in-opal_get_tpo_time.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 Tue Apr 10 10:31:53 CEST 2018 From: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com> Date: Fri, 19 May 2017 15:35:09 +0530 Subject: rtc: opal: Handle disabled TPO in opal_get_tpo_time() From: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com> [ Upstream commit 6dc1cf6f932bb0ea4d8f5e913a0a401ecacd2f03 ] On PowerNV platform when Timed-Power-On(TPO) is disabled, read of stored TPO yields value with all date components set to '0' inside opal_get_tpo_time(). The function opal_to_tm() then converts it to an offset from year 1900 yielding alarm-time == "1900-00-01 00:00:00". This causes problems with __rtc_read_alarm() that expecting an offset from "1970-00-01 00:00:00" and returned alarm-time results in a -ve value for time64_t. Which ultimately results in this error reported in kernel logs with a seemingly garbage value: "rtc rtc0: invalid alarm value: -2-1--1041528741 2005511117:71582844:32" We fix this by explicitly handling the case of all alarm date-time components being '0' inside opal_get_tpo_time() and returning -ENOENT in such a case. This signals generic rtc that no alarm is set and it bails out from the alarm initialization flow without reporting the above error. Signed-off-by: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com> Reported-by: Steve Best <sbest(a)redhat.com> Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/rtc/rtc-opal.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/drivers/rtc/rtc-opal.c +++ b/drivers/rtc/rtc-opal.c @@ -150,6 +150,16 @@ static int opal_get_tpo_time(struct devi y_m_d = be32_to_cpu(__y_m_d); h_m_s_ms = ((u64)be32_to_cpu(__h_m) << 32); + + /* check if no alarm is set */ + if (y_m_d == 0 && h_m_s_ms == 0) { + pr_debug("No alarm is set\n"); + rc = -ENOENT; + goto exit; + } else { + pr_debug("Alarm set to %x %llx\n", y_m_d, h_m_s_ms); + } + opal_to_tm(y_m_d, h_m_s_ms, &alarm->time); exit: Patches currently in stable-queue which might be from vaibhav(a)linux.vnet.ibm.com are queue-4.4/rtc-interface-validate-alarm-time-before-handling-rollover.patch queue-4.4/rtc-opal-handle-disabled-tpo-in-opal_get_tpo_time.patch

7 years, 7 months

1
0
0 0

Patch "rtc: interface: Validate alarm-time before handling rollover" 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 rtc: interface: Validate alarm-time before handling rollover 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: rtc-interface-validate-alarm-time-before-handling-rollover.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 Tue Apr 10 10:31:53 CEST 2018 From: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com> Date: Fri, 19 May 2017 22:18:55 +0530 Subject: rtc: interface: Validate alarm-time before handling rollover From: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com> [ Upstream commit da96aea0ed177105cb13ee83b328f6c61e061d3f ] In function __rtc_read_alarm() its possible for an alarm time-stamp to be invalid even after replacing missing components with current time-stamp. The condition 'alarm->time.tm_year < 70' will trigger this case and will cause the call to 'rtc_tm_to_time64(&alarm->time)' return a negative value for variable t_alm. While handling alarm rollover this negative t_alm (assumed to seconds offset from '1970-01-01 00:00:00') is converted back to rtc_time via rtc_time64_to_tm() which results in this error log with seemingly garbage values: "rtc rtc0: invalid alarm value: -2-1--1041528741 2005511117:71582844:32" This error was generated when the rtc driver (rtc-opal in this case) returned an alarm time-stamp of '00-00-00 00:00:00' to indicate that the alarm is disabled. Though I have submitted a separate fix for the rtc-opal driver, this issue may potentially impact other existing/future rtc drivers. To fix this issue the patch validates the alarm time-stamp just after filling up the missing datetime components and if rtc_valid_tm() still reports it to be invalid then bails out of the function without handling the rollover. Reported-by: Steve Best <sbest(a)redhat.com> Signed-off-by: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com> Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/rtc/interface.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/drivers/rtc/interface.c +++ b/drivers/rtc/interface.c @@ -217,6 +217,13 @@ int __rtc_read_alarm(struct rtc_device * missing = year; } + /* Can't proceed if alarm is still invalid after replacing + * missing fields. + */ + err = rtc_valid_tm(&alarm->time); + if (err) + goto done; + /* with luck, no rollover is needed */ t_now = rtc_tm_to_time64(&now); t_alm = rtc_tm_to_time64(&alarm->time); @@ -268,9 +275,9 @@ int __rtc_read_alarm(struct rtc_device * dev_warn(&rtc->dev, "alarm rollover not handled\n"); } -done: err = rtc_valid_tm(&alarm->time); +done: if (err) { dev_warn(&rtc->dev, "invalid alarm value: %d-%d-%d %d:%d:%d\n", alarm->time.tm_year + 1900, alarm->time.tm_mon + 1, Patches currently in stable-queue which might be from vaibhav(a)linux.vnet.ibm.com are queue-4.4/rtc-interface-validate-alarm-time-before-handling-rollover.patch queue-4.4/rtc-opal-handle-disabled-tpo-in-opal_get_tpo_time.patch

7 years, 7 months

1
0
0 0

Patch "rds; Reset rs->rs_bound_addr in rds_add_bound() failure 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 rds; Reset rs->rs_bound_addr in rds_add_bound() failure 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: rds-reset-rs-rs_bound_addr-in-rds_add_bound-failure-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 Tue Apr 10 10:31:53 CEST 2018 From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> Date: Fri, 22 Dec 2017 09:38:59 -0800 Subject: rds; Reset rs->rs_bound_addr in rds_add_bound() failure path From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> [ Upstream commit 7ae0c649c47f1c5d2db8cee6dd75855970af1669 ] If the rds_sock is not added to the bind_hash_table, we must reset rs_bound_addr so that rds_remove_bound will not trip on this rds_sock. rds_add_bound() does a rds_sock_put() in this failure path, so failing to reset rs_bound_addr will result in a socket refcount bug, and will trigger a WARN_ON with the stack shown below when the application subsequently tries to close the PF_RDS socket. WARNING: CPU: 20 PID: 19499 at net/rds/af_rds.c:496 \ rds_sock_destruct+0x15/0x30 [rds] : __sk_destruct+0x21/0x190 rds_remove_bound.part.13+0xb6/0x140 [rds] rds_release+0x71/0x120 [rds] sock_release+0x1a/0x70 sock_close+0xe/0x20 __fput+0xd5/0x210 task_work_run+0x82/0xa0 do_exit+0x2ce/0xb30 ? syscall_trace_enter+0x1cc/0x2b0 do_group_exit+0x39/0xa0 SyS_exit_group+0x10/0x10 do_syscall_64+0x61/0x1a0 Signed-off-by: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/bind.c | 1 + 1 file changed, 1 insertion(+) --- a/net/rds/bind.c +++ b/net/rds/bind.c @@ -108,6 +108,7 @@ static int rds_add_bound(struct rds_sock rs, &addr, (int)ntohs(*port)); break; } else { + rs->rs_bound_addr = 0; rds_sock_put(rs); ret = -ENOMEM; break; Patches currently in stable-queue which might be from sowmini.varadhan(a)oracle.com are queue-4.4/rds-reset-rs-rs_bound_addr-in-rds_add_bound-failure-path.patch

7 years, 7 months

1
0
0 0

Patch "ray_cs: Avoid reading past end of buffer" 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 ray_cs: Avoid reading past end of buffer to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ray_cs-avoid-reading-past-end-of-buffer.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Apr 10 10:31:53 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.4/qlge-avoid-reading-past-end-of-buffer.patch queue-4.4/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch queue-4.4/ray_cs-avoid-reading-past-end-of-buffer.patch queue-4.4/bna-avoid-reading-past-end-of-buffer.patch

7 years, 7 months

1
0
0 0

Patch "qlge: Avoid reading past end of buffer" 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 qlge: Avoid reading past end of buffer to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: qlge-avoid-reading-past-end-of-buffer.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Apr 10 10:31:53 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.4/qlge-avoid-reading-past-end-of-buffer.patch queue-4.4/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch queue-4.4/ray_cs-avoid-reading-past-end-of-buffer.patch queue-4.4/bna-avoid-reading-past-end-of-buffer.patch

7 years, 7 months

1
0
0 0

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.4-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.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: 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.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 Tue Apr 10 10:31:53 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.4/misdn-fix-a-sleep-in-atomic-bug.patch queue-4.4/qlcnic-fix-a-sleep-in-atomic-bug-in-qlcnic_82xx_hw_write_wx_2m-and-qlcnic_82xx_hw_read_wx_2m.patch

7 years, 7 months

1
0
0 0

Patch "powerpc/spufs: Fix coredump of SPU contexts" 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 powerpc/spufs: Fix coredump of SPU contexts 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: powerpc-spufs-fix-coredump-of-spu-contexts.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 Tue Apr 10 10:31:53 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 @@ -174,6 +174,8 @@ static int spufs_arch_write_note(struct if (!dump_skip(cprm, roundup(cprm->written - total + sz, 4) - cprm->written)) 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.4/selftests-powerpc-fix-tm-resched-dscr-test-with-some-compilers.patch queue-4.4/powerpc-mm-fix-virt_addr_valid-etc.-on-64-bit-hash.patch queue-4.4/powerpc-spufs-fix-coredump-of-spu-contexts.patch queue-4.4/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch queue-4.4/powerpc-don-t-clobber-tcr-when-setting-tcr.patch

7 years, 7 months

1
0
0 0

Patch "powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash" 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 powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash 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: powerpc-mm-fix-virt_addr_valid-etc.-on-64-bit-hash.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 Tue Apr 10 10:31:53 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.4/selftests-powerpc-fix-tm-resched-dscr-test-with-some-compilers.patch queue-4.4/powerpc-mm-fix-virt_addr_valid-etc.-on-64-bit-hash.patch queue-4.4/powerpc-spufs-fix-coredump-of-spu-contexts.patch queue-4.4/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch queue-4.4/powerpc-don-t-clobber-tcr-when-setting-tcr.patch

7 years, 7 months

1
0
0 0

Patch "powerpc/[booke|4xx]: Don't clobber TCR[WP] when setting TCR[DIE]" 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 powerpc/[booke|4xx]: Don't clobber TCR[WP] when setting TCR[DIE] 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: powerpc-don-t-clobber-tcr-when-setting-tcr.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 Tue Apr 10 10:31:53 CEST 2018 From: Ivan Mikhaylov <ivan(a)de.ibm.com> Date: Fri, 19 May 2017 18:47:05 +0300 Subject: powerpc/[booke|4xx]: Don't clobber TCR[WP] when setting TCR[DIE] From: Ivan Mikhaylov <ivan(a)de.ibm.com> [ Upstream commit 6e2f03e292ef46eed2b31b0a344a91d514f9cd81 ] Prevent a kernel panic caused by unintentionally clearing TCR watchdog bits. At this point in the kernel boot, the watchdog may have already been enabled by u-boot. The original code's attempt to write to the TCR register results in an inadvertent clearing of the watchdog configuration bits, causing the 476 to reset. Signed-off-by: Ivan Mikhaylov <ivan(a)de.ibm.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/kernel/time.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -686,12 +686,20 @@ static int __init get_freq(char *name, i static void start_cpu_decrementer(void) { #if defined(CONFIG_BOOKE) || defined(CONFIG_40x) + unsigned int tcr; + /* Clear any pending timer interrupts */ mtspr(SPRN_TSR, TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS); - /* Enable decrementer interrupt */ - mtspr(SPRN_TCR, TCR_DIE); -#endif /* defined(CONFIG_BOOKE) || defined(CONFIG_40x) */ + tcr = mfspr(SPRN_TCR); + /* + * The watchdog may have already been enabled by u-boot. So leave + * TRC[WP] (Watchdog Period) alone. + */ + tcr &= TCR_WP_MASK; /* Clear all bits except for TCR[WP] */ + tcr |= TCR_DIE; /* Enable decrementer */ + mtspr(SPRN_TCR, tcr); +#endif } void __init generic_calibrate_decr(void) Patches currently in stable-queue which might be from ivan(a)de.ibm.com are queue-4.4/powerpc-don-t-clobber-tcr-when-setting-tcr.patch

7 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror