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

Patch "signal/arm: Document conflicts with SI_USER and SIGFPE" 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 signal/arm: Document conflicts with SI_USER and SIGFPE 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: signal-arm-document-conflicts-with-si_user-and-sigfpe.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 Tue Apr 10 13:58:07 CEST 2018 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Thu, 17 Aug 2017 17:07:46 -0500 Subject: signal/arm: Document conflicts with SI_USER and SIGFPE From: "Eric W. Biederman" <ebiederm(a)xmission.com> [ Upstream commit 7771c66457004977b616bab785209f49d164f527 ] Setting si_code to 0 results in a userspace seeing an si_code of 0. This is the same si_code as SI_USER. Posix and common sense requires that SI_USER not be a signal specific si_code. As such this use of 0 for the si_code is a pretty horribly broken ABI. Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a value of __SI_KILL and now sees a value of SIL_KILL with the result that uid and pid fields are copied and which might copying the si_addr field by accident but certainly not by design. Making this a very flakey implementation. Utilizing FPE_FIXME, siginfo_layout will now return SIL_FAULT and the appropriate fields will be reliably copied. Possible ABI fixes includee: - Send the signal without siginfo - Don't generate a signal - Possibly assign and use an appropriate si_code - Don't handle cases which can't happen Cc: Russell King <rmk(a)flint.arm.linux.org.uk> Cc: linux-arm-kernel(a)lists.infradead.org Ref: 451436b7bbb2 ("[ARM] Add support code for ARM hardware vector floating point") History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/include/uapi/asm/siginfo.h | 13 +++++++++++++ arch/arm/vfp/vfpmodule.c | 2 +- 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 arch/arm/include/uapi/asm/siginfo.h --- /dev/null +++ b/arch/arm/include/uapi/asm/siginfo.h @@ -0,0 +1,13 @@ +#ifndef __ASM_SIGINFO_H +#define __ASM_SIGINFO_H + +#include <asm-generic/siginfo.h> + +/* + * SIGFPE si_codes + */ +#ifdef __KERNEL__ +#define FPE_FIXME 0 /* Broken dup of SI_USER */ +#endif /* __KERNEL__ */ + +#endif --- a/arch/arm/vfp/vfpmodule.c +++ b/arch/arm/vfp/vfpmodule.c @@ -261,7 +261,7 @@ static void vfp_raise_exceptions(u32 exc if (exceptions == VFP_EXCEPTION_ERROR) { vfp_panic("unhandled bounce", inst); - vfp_raise_sigfpe(0, regs); + vfp_raise_sigfpe(FPE_FIXME, regs); return; } Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-3.18/signal-metag-document-a-conflict-with-si_user-with-sigfpe.patch queue-3.18/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch queue-3.18/signal-arm-document-conflicts-with-si_user-and-sigfpe.patch queue-3.18/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch

7 years, 4 months

1
0
0 0

Patch "sh_eth: Use platform device for printing before register_netdev()" 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 sh_eth: Use platform device for printing before register_netdev() 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: sh_eth-use-platform-device-for-printing-before-register_netdev.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 Tue Apr 10 13:58:07 CEST 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Thu, 18 May 2017 15:01:34 +0200 Subject: sh_eth: Use platform device for printing before register_netdev() From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 5f5c5449acad0cd3322e53e1ac68c044483b0aa5 ] The MDIO initialization failure message is printed using the network device, before it has been registered, leading to: (null): failed to initialise MDIO Use the platform device instead to fix this: sh-eth ee700000.ethernet: failed to initialise MDIO Fixes: daacf03f0bbfefee ("sh_eth: Register MDIO bus before registering the network device") Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.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/renesas/sh_eth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c @@ -2933,7 +2933,7 @@ static int sh_eth_drv_probe(struct platf /* MDIO bus init */ ret = sh_mdio_init(mdp, pd); if (ret) { - dev_err(&ndev->dev, "failed to initialise MDIO\n"); + dev_err(&pdev->dev, "failed to initialise MDIO\n"); goto out_release; } Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-3.18/sh_eth-use-platform-device-for-printing-before-register_netdev.patch

7 years, 4 months

1
0
0 0

Patch "selftests/powerpc: Fix TM resched DSCR test with some compilers" 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 selftests/powerpc: Fix TM resched DSCR test with some compilers 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: selftests-powerpc-fix-tm-resched-dscr-test-with-some-compilers.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 Tue Apr 10 13:58:07 CEST 2018 From: Michael Ellerman <mpe(a)ellerman.id.au> Date: Fri, 19 May 2017 11:29:04 +1000 Subject: selftests/powerpc: Fix TM resched DSCR test with some compilers From: Michael Ellerman <mpe(a)ellerman.id.au> [ Upstream commit fe06fe860250a4f01d0eaf70a2563b1997174a74 ] The tm-resched-dscr test has started failing sometimes, depending on what compiler it's built with, eg: test: tm_resched_dscr Check DSCR TM context switch: tm-resched-dscr: tm-resched-dscr.c:76: test_body: Assertion `rv' failed. !! child died by signal 6 When it fails we see that the compiler doesn't initialise rv to 1 before entering the inline asm block. Although that's counter intuitive, it is allowed because we tell the compiler that the inline asm will write to rv (using "=r"), meaning the original value is irrelevant. Marking it as a read/write parameter would presumably work, but it seems simpler to fix it by setting the initial value of rv in the inline asm. Fixes: 96d016108640 ("powerpc: Correct DSCR during TM context switch") Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Acked-by: Michael Neuling <mikey(a)neuling.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/powerpc/tm/tm-resched-dscr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/testing/selftests/powerpc/tm/tm-resched-dscr.c +++ b/tools/testing/selftests/powerpc/tm/tm-resched-dscr.c @@ -45,12 +45,12 @@ int test_body(void) printf("Check DSCR TM context switch: "); fflush(stdout); for (;;) { - rv = 1; asm __volatile__ ( /* set a known value into the DSCR */ "ld 3, %[dscr1];" "mtspr %[sprn_dscr], 3;" + "li %[rv], 1;" /* start and suspend a transaction */ TBEGIN "beq 1f;" Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are queue-3.18/selftests-powerpc-fix-tm-resched-dscr-test-with-some-compilers.patch queue-3.18/powerpc-spufs-fix-coredump-of-spu-contexts.patch queue-3.18/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch queue-3.18/powerpc-don-t-clobber-tcr-when-setting-tcr.patch

7 years, 4 months

1
0
0 0

Patch "sctp: fix recursive locking warning in sctp_do_peeloff" 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 sctp: fix recursive locking warning in sctp_do_peeloff 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: sctp-fix-recursive-locking-warning-in-sctp_do_peeloff.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 Tue Apr 10 13:58:07 CEST 2018 From: Xin Long <lucien.xin(a)gmail.com> Date: Sat, 10 Jun 2017 14:56:56 +0800 Subject: sctp: fix recursive locking warning in sctp_do_peeloff From: Xin Long <lucien.xin(a)gmail.com> [ Upstream commit 6dfe4b97e08ec3d1a593fdaca099f0ef0a3a19e6 ] Dmitry got the following recursive locking report while running syzkaller fuzzer, the Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0x2ee/0x3ef lib/dump_stack.c:52 print_deadlock_bug kernel/locking/lockdep.c:1729 [inline] check_deadlock kernel/locking/lockdep.c:1773 [inline] validate_chain kernel/locking/lockdep.c:2251 [inline] __lock_acquire+0xef2/0x3430 kernel/locking/lockdep.c:3340 lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755 lock_sock_nested+0xcb/0x120 net/core/sock.c:2536 lock_sock include/net/sock.h:1460 [inline] sctp_close+0xcd/0x9d0 net/sctp/socket.c:1497 inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425 inet6_release+0x50/0x70 net/ipv6/af_inet6.c:432 sock_release+0x8d/0x1e0 net/socket.c:597 __sock_create+0x38b/0x870 net/socket.c:1226 sock_create+0x7f/0xa0 net/socket.c:1237 sctp_do_peeloff+0x1a2/0x440 net/sctp/socket.c:4879 sctp_getsockopt_peeloff net/sctp/socket.c:4914 [inline] sctp_getsockopt+0x111a/0x67e0 net/sctp/socket.c:6628 sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2690 SYSC_getsockopt net/socket.c:1817 [inline] SyS_getsockopt+0x240/0x380 net/socket.c:1799 entry_SYSCALL_64_fastpath+0x1f/0xc2 This warning is caused by the lock held by sctp_getsockopt() is on one socket, while the other lock that sctp_close() is getting later is on the newly created (which failed) socket during peeloff operation. This patch is to avoid this warning by use lock_sock with subclass SINGLE_DEPTH_NESTING as Wang Cong and Marcelo's suggestion. Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Suggested-by: Cong Wang <xiyou.wangcong(a)gmail.com> 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)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sctp/socket.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -1513,7 +1513,7 @@ static void sctp_close(struct sock *sk, pr_debug("%s: sk:%p, timeout:%ld\n", __func__, sk, timeout); - lock_sock(sk); + lock_sock_nested(sk, SINGLE_DEPTH_NESTING); sk->sk_shutdown = SHUTDOWN_MASK; sk->sk_state = SCTP_SS_CLOSING; @@ -1564,7 +1564,7 @@ static void sctp_close(struct sock *sk, * held and that should be grabbed before socket lock. */ spin_lock_bh(&net->sctp.addr_wq_lock); - bh_lock_sock(sk); + bh_lock_sock_nested(sk); /* Hold the sock, since sk_common_release() will put sock_put() * and we have just a little more cleanup. Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are queue-3.18/sctp-fix-recursive-locking-warning-in-sctp_do_peeloff.patch

7 years, 4 months

1
0
0 0

Patch "scsi: libsas: initialize sas_phy status according to response of DISCOVER" 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: libsas: initialize sas_phy status according to response of DISCOVER 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-libsas-initialize-sas_phy-status-according-to-response-of-discover.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 Tue Apr 10 13:58:07 CEST 2018 From: chenxiang <chenxiang66(a)hisilicon.com> Date: Thu, 4 Jan 2018 21:04:33 +0800 Subject: scsi: libsas: initialize sas_phy status according to response of DISCOVER From: chenxiang <chenxiang66(a)hisilicon.com> [ Upstream commit affc67788fe5dfffad5cda3d461db5cf2b2ff2b0 ] The status of SAS PHY is in sas_phy->enabled. There is an issue that the status of a remote SAS PHY may be initialized incorrectly: if disable remote SAS PHY through sysfs interface (such as echo 0 > /sys/class/sas_phy/phy-1:0:0/enable), then reboot the system, and we will find the status of remote SAS PHY which is disabled before is 1 (cat /sys/class/sas_phy/phy-1:0:0/enable). But actually the status of remote SAS PHY is disabled and the device attached is not found. In SAS protocol, NEGOTIATED LOGICAL LINK RATE field of DISCOVER response is 0x1 when remote SAS PHY is disabled. So initialize sas_phy->enabled according to the value of NEGOTIATED LOGICAL LINK RATE field. Signed-off-by: chenxiang <chenxiang66(a)hisilicon.com> Reviewed-by: John Garry <john.garry(a)huawei.com> Signed-off-by: Jason Yan <yanaijie(a)huawei.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Hannes Reinecke <hare(a)suse.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/libsas/sas_expander.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -282,6 +282,7 @@ static void sas_set_ex_phy(struct domain phy->phy->minimum_linkrate = dr->pmin_linkrate; phy->phy->maximum_linkrate = dr->pmax_linkrate; phy->phy->negotiated_linkrate = phy->linkrate; + phy->phy->enabled = (phy->linkrate != SAS_PHY_DISABLED); skip: if (new_phy) Patches currently in stable-queue which might be from chenxiang66(a)hisilicon.com are queue-3.18/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-3.18/scsi-libsas-fix-error-when-getting-phy-events.patch queue-3.18/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch

7 years, 4 months

1
0
0 0

Patch "scsi: libsas: fix memory leak in sas_smp_get_phy_events()" 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: libsas: fix memory leak in sas_smp_get_phy_events() 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-libsas-fix-memory-leak-in-sas_smp_get_phy_events.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 Tue Apr 10 13:58:07 CEST 2018 From: Jason Yan <yanaijie(a)huawei.com> Date: Thu, 4 Jan 2018 21:04:31 +0800 Subject: scsi: libsas: fix memory leak in sas_smp_get_phy_events() From: Jason Yan <yanaijie(a)huawei.com> [ Upstream commit 4a491b1ab11ca0556d2fda1ff1301e862a2d44c4 ] We've got a memory leak with the following producer: while true; do cat /sys/class/sas_phy/phy-1:0:12/invalid_dword_count >/dev/null; done The buffer req is allocated and not freed after we return. Fix it. Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver") Signed-off-by: Jason Yan <yanaijie(a)huawei.com> CC: John Garry <john.garry(a)huawei.com> CC: chenqilin <chenqilin2(a)huawei.com> CC: chenxiang <chenxiang66(a)hisilicon.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Hannes Reinecke <hare(a)suse.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/libsas/sas_expander.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -684,6 +684,7 @@ int sas_smp_get_phy_events(struct sas_ph phy->phy_reset_problem_count = scsi_to_u32(&resp[24]); out: + kfree(req); kfree(resp); return res; Patches currently in stable-queue which might be from yanaijie(a)huawei.com are queue-3.18/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-3.18/scsi-libsas-fix-error-when-getting-phy-events.patch queue-3.18/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch

7 years, 4 months

1
0
0 0

Patch "scsi: libsas: fix error when getting phy events" 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: libsas: fix error when getting phy events 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-libsas-fix-error-when-getting-phy-events.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 Tue Apr 10 13:58:07 CEST 2018 From: Jason Yan <yanaijie(a)huawei.com> Date: Thu, 4 Jan 2018 21:04:32 +0800 Subject: scsi: libsas: fix error when getting phy events From: Jason Yan <yanaijie(a)huawei.com> [ Upstream commit 2b23d9509fd7174b362482cf5f3b5f9a2265bc33 ] The intend purpose here was to goto out if smp_execute_task() returned error. Obviously something got screwed up. We will never get these link error statistics below: ~:/sys/class/sas_phy/phy-1:0:12 # cat invalid_dword_count 0 ~:/sys/class/sas_phy/phy-1:0:12 # cat running_disparity_error_count 0 ~:/sys/class/sas_phy/phy-1:0:12 # cat loss_of_dword_sync_count 0 ~:/sys/class/sas_phy/phy-1:0:12 # cat phy_reset_problem_count 0 Obviously we should goto error handler if smp_execute_task() returns non-zero. Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver") Signed-off-by: Jason Yan <yanaijie(a)huawei.com> CC: John Garry <john.garry(a)huawei.com> CC: chenqilin <chenqilin2(a)huawei.com> CC: chenxiang <chenxiang66(a)hisilicon.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> 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/libsas/sas_expander.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -675,7 +675,7 @@ int sas_smp_get_phy_events(struct sas_ph res = smp_execute_task(dev, req, RPEL_REQ_SIZE, resp, RPEL_RESP_SIZE); - if (!res) + if (res) goto out; phy->invalid_dword_count = scsi_to_u32(&resp[12]); Patches currently in stable-queue which might be from yanaijie(a)huawei.com are queue-3.18/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-3.18/scsi-libsas-fix-error-when-getting-phy-events.patch queue-3.18/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch

7 years, 4 months

1
0
0 0

Patch "scsi: libiscsi: Allow sd_shutdown on bad transport" 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: libiscsi: Allow sd_shutdown on bad transport 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-libiscsi-allow-sd_shutdown-on-bad-transport.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 Tue Apr 10 13:58:07 CEST 2018 From: Rafael David Tinoco <rafael.tinoco(a)canonical.com> Date: Thu, 7 Dec 2017 19:59:13 -0200 Subject: scsi: libiscsi: Allow sd_shutdown on bad transport From: Rafael David Tinoco <rafael.tinoco(a)canonical.com> [ Upstream commit d754941225a7dbc61f6dd2173fa9498049f9a7ee ] If, for any reason, userland shuts down iscsi transport interfaces before proper logouts - like when logging in to LUNs manually, without logging out on server shutdown, or when automated scripts can't umount/logout from logged LUNs - kernel will hang forever on its sd_sync_cache() logic, after issuing the SYNCHRONIZE_CACHE cmd to all still existent paths. PID: 1 TASK: ffff8801a69b8000 CPU: 1 COMMAND: "systemd-shutdow" #0 [ffff8801a69c3a30] __schedule at ffffffff8183e9ee #1 [ffff8801a69c3a80] schedule at ffffffff8183f0d5 #2 [ffff8801a69c3a98] schedule_timeout at ffffffff81842199 #3 [ffff8801a69c3b40] io_schedule_timeout at ffffffff8183e604 #4 [ffff8801a69c3b70] wait_for_completion_io_timeout at ffffffff8183fc6c #5 [ffff8801a69c3bd0] blk_execute_rq at ffffffff813cfe10 #6 [ffff8801a69c3c88] scsi_execute at ffffffff815c3fc7 #7 [ffff8801a69c3cc8] scsi_execute_req_flags at ffffffff815c60fe #8 [ffff8801a69c3d30] sd_sync_cache at ffffffff815d37d7 #9 [ffff8801a69c3da8] sd_shutdown at ffffffff815d3c3c This happens because iscsi_eh_cmd_timed_out(), the transport layer timeout helper, would tell the queue timeout function (scsi_times_out) to reset the request timer over and over, until the session state is back to logged in state. Unfortunately, during server shutdown, this might never happen again. Other option would be "not to handle" the issue in the transport layer. That would trigger the error handler logic, which would also need the session state to be logged in again. Best option, for such case, is to tell upper layers that the command was handled during the transport layer error handler helper, marking it as DID_NO_CONNECT, which will allow completion and inform about the problem. After the session was marked as ISCSI_STATE_FAILED, due to the first timeout during the server shutdown phase, all subsequent cmds will fail to be queued, allowing upper logic to fail faster. Signed-off-by: Rafael David Tinoco <rafael.tinoco(a)canonical.com> Reviewed-by: Lee Duncan <lduncan(a)suse.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/libiscsi.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) --- a/drivers/scsi/libiscsi.c +++ b/drivers/scsi/libiscsi.c @@ -1695,6 +1695,15 @@ int iscsi_queuecommand(struct Scsi_Host */ switch (session->state) { case ISCSI_STATE_FAILED: + /* + * cmds should fail during shutdown, if the session + * state is bad, allowing completion to happen + */ + if (unlikely(system_state != SYSTEM_RUNNING)) { + reason = FAILURE_SESSION_FAILED; + sc->result = DID_NO_CONNECT << 16; + break; + } case ISCSI_STATE_IN_RECOVERY: reason = FAILURE_SESSION_IN_RECOVERY; sc->result = DID_IMM_RETRY << 16; @@ -1999,6 +2008,19 @@ static enum blk_eh_timer_return iscsi_eh if (session->state != ISCSI_STATE_LOGGED_IN) { /* + * During shutdown, if session is prematurely disconnected, + * recovery won't happen and there will be hung cmds. Not + * handling cmds would trigger EH, also bad in this case. + * Instead, handle cmd, allow completion to happen and let + * upper layer to deal with the result. + */ + if (unlikely(system_state != SYSTEM_RUNNING)) { + sc->result = DID_NO_CONNECT << 16; + ISCSI_DBG_EH(session, "sc on shutdown, handled\n"); + rc = BLK_EH_HANDLED; + goto done; + } + /* * We are probably in the middle of iscsi recovery so let * that complete and handle the error. */ @@ -2102,7 +2124,7 @@ done: task->last_timeout = jiffies; spin_unlock(&session->frwd_lock); ISCSI_DBG_EH(session, "return %s\n", rc == BLK_EH_RESET_TIMER ? - "timer reset" : "nh"); + "timer reset" : "shutdown or nh"); return rc; } Patches currently in stable-queue which might be from rafael.tinoco(a)canonical.com are queue-3.18/scsi-libiscsi-allow-sd_shutdown-on-bad-transport.patch

7 years, 4 months

1
0
0 0

Patch "scsi: bnx2fc: fix race condition in bnx2fc_get_host_stats()" 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: bnx2fc: fix race condition in bnx2fc_get_host_stats() 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-bnx2fc-fix-race-condition-in-bnx2fc_get_host_stats.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 Tue Apr 10 13:58:07 CEST 2018 From: Maurizio Lombardi <mlombard(a)redhat.com> Date: Wed, 24 May 2017 14:09:44 +0200 Subject: scsi: bnx2fc: fix race condition in bnx2fc_get_host_stats() From: Maurizio Lombardi <mlombard(a)redhat.com> [ Upstream commit c2dd893a3b0772d1c680e109b9d5715d7f73022b ] If multiple tasks attempt to read the stats, it may happen that the start_req_done completion is re-initialized while still being used by another task, causing a list corruption. This patch fixes the bug by adding a mutex to serialize the calls to bnx2fc_get_host_stats(). WARNING: at lib/list_debug.c:48 list_del+0x6e/0xa0() (Not tainted) Hardware name: PowerEdge R820 list_del corruption. prev->next should be ffff882035627d90, but was ffff884069541588 Pid: 40267, comm: perl Not tainted 2.6.32-642.3.1.el6.x86_64 #1 Call Trace: [<ffffffff8107c691>] ? warn_slowpath_common+0x91/0xe0 [<ffffffff8107c796>] ? warn_slowpath_fmt+0x46/0x60 [<ffffffff812ad16e>] ? list_del+0x6e/0xa0 [<ffffffff81547eed>] ? wait_for_common+0x14d/0x180 [<ffffffff8106c4a0>] ? default_wake_function+0x0/0x20 [<ffffffff81547fd3>] ? wait_for_completion_timeout+0x13/0x20 [<ffffffffa05410b1>] ? bnx2fc_get_host_stats+0xa1/0x280 [bnx2fc] [<ffffffffa04cf630>] ? fc_stat_show+0x90/0xc0 [scsi_transport_fc] [<ffffffffa04cf8b6>] ? show_fcstat_tx_frames+0x16/0x20 [scsi_transport_fc] [<ffffffff8137c647>] ? dev_attr_show+0x27/0x50 [<ffffffff8113b9be>] ? __get_free_pages+0xe/0x50 [<ffffffff812170e1>] ? sysfs_read_file+0x111/0x200 [<ffffffff8119a305>] ? vfs_read+0xb5/0x1a0 [<ffffffff8119b0b6>] ? fget_light_pos+0x16/0x50 [<ffffffff8119a651>] ? sys_read+0x51/0xb0 [<ffffffff810ee1fe>] ? __audit_syscall_exit+0x25e/0x290 [<ffffffff8100b0d2>] ? system_call_fastpath+0x16/0x1b Signed-off-by: Maurizio Lombardi <mlombard(a)redhat.com> Acked-by: Chad Dupuis <chad.dupuis(a)cavium.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/bnx2fc/bnx2fc.h | 1 + drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 10 ++++++++-- 2 files changed, 9 insertions(+), 2 deletions(-) --- a/drivers/scsi/bnx2fc/bnx2fc.h +++ b/drivers/scsi/bnx2fc/bnx2fc.h @@ -191,6 +191,7 @@ struct bnx2fc_hba { struct bnx2fc_cmd_mgr *cmd_mgr; spinlock_t hba_lock; struct mutex hba_mutex; + struct mutex hba_stats_mutex; unsigned long adapter_state; #define ADAPTER_STATE_UP 0 #define ADAPTER_STATE_GOING_DOWN 1 --- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c +++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c @@ -641,15 +641,17 @@ static struct fc_host_statistics *bnx2fc if (!fw_stats) return NULL; + mutex_lock(&hba->hba_stats_mutex); + bnx2fc_stats = fc_get_host_stats(shost); init_completion(&hba->stat_req_done); if (bnx2fc_send_stat_req(hba)) - return bnx2fc_stats; + goto unlock_stats_mutex; rc = wait_for_completion_timeout(&hba->stat_req_done, (2 * HZ)); if (!rc) { BNX2FC_HBA_DBG(lport, "FW stat req timed out\n"); - return bnx2fc_stats; + goto unlock_stats_mutex; } BNX2FC_STATS(hba, rx_stat2, fc_crc_cnt); bnx2fc_stats->invalid_crc_count += hba->bfw_stats.fc_crc_cnt; @@ -671,6 +673,9 @@ static struct fc_host_statistics *bnx2fc memcpy(&hba->prev_stats, hba->stats_buffer, sizeof(struct fcoe_statistics_params)); + +unlock_stats_mutex: + mutex_unlock(&hba->hba_stats_mutex); return bnx2fc_stats; } @@ -1303,6 +1308,7 @@ static struct bnx2fc_hba *bnx2fc_hba_cre } spin_lock_init(&hba->hba_lock); mutex_init(&hba->hba_mutex); + mutex_init(&hba->hba_stats_mutex); hba->cnic = cnic; Patches currently in stable-queue which might be from mlombard(a)redhat.com are queue-3.18/scsi-bnx2fc-fix-race-condition-in-bnx2fc_get_host_stats.patch

7 years, 4 months

1
0
0 0

Patch "s390: move _text symbol to address higher than zero" 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 s390: move _text symbol to address higher than zero 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: s390-move-_text-symbol-to-address-higher-than-zero.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 Tue Apr 10 13:58:07 CEST 2018 From: Heiko Carstens <heiko.carstens(a)de.ibm.com> Date: Thu, 4 May 2017 09:42:22 +0200 Subject: s390: move _text symbol to address higher than zero From: Heiko Carstens <heiko.carstens(a)de.ibm.com> [ Upstream commit d04a4c76f71dd5335f8e499b59617382d84e2b8d ] The perf tool assumes that kernel symbols are never present at address zero. In fact it assumes if functions that map symbols to addresses return zero, that the symbol was not found. Given that s390's _text symbol historically is located at address zero this yields at least a couple of false errors and warnings in one of perf's test cases about not present symbols ("perf test 1"). To fix this simply move the _text symbol to address 0x200, just behind the initial psw and channel program located at the beginning of the kernel image. This is now hard coded within the linker script. I tried a nicer solution which moves the initial psw and channel program into an own section. However that would move the symbols within the "real" head.text section to different addresses, since the ".org" statements within head.S are relative to the head.text section. If there is a new section in front, everything else will be moved. Alternatively I could have adjusted all ".org" statements. But this current solution seems to be the easiest one, since nobody really cares where the _text symbol is actually located. Reported-by: Zvonko Kosic <zkosic(a)linux.vnet.ibm.com> Signed-off-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)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/kernel/vmlinux.lds.S | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/arch/s390/kernel/vmlinux.lds.S +++ b/arch/s390/kernel/vmlinux.lds.S @@ -28,8 +28,14 @@ SECTIONS { . = 0x00000000; .text : { - _text = .; /* Text and read-only data */ + /* Text and read-only data */ HEAD_TEXT + /* + * E.g. perf doesn't like symbols starting at address zero, + * therefore skip the initial PSW and channel program located + * at address zero and let _text start at 0x200. + */ + _text = 0x200; TEXT_TEXT SCHED_TEXT LOCK_TEXT Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are queue-3.18/s390-move-_text-symbol-to-address-higher-than-zero.patch

7 years, 4 months

1
0
0 0

Patch "rtc: interface: Validate alarm-time before handling rollover" 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 rtc: interface: Validate alarm-time before handling rollover 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: rtc-interface-validate-alarm-time-before-handling-rollover.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 Tue Apr 10 13:58:07 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 @@ -249,6 +249,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 */ rtc_tm_to_time(&now, &t_now); rtc_tm_to_time(&alarm->time, &t_alm); @@ -300,9 +307,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-3.18/rtc-interface-validate-alarm-time-before-handling-rollover.patch

7 years, 4 months

1
0
0 0

Patch "rxrpc: check return value of skb_to_sgvec always" 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 rxrpc: check return value of skb_to_sgvec always 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: rxrpc-check-return-value-of-skb_to_sgvec-always.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 89a5ea99662505d2d61f2a3030a6896c2cb3cdb0 Mon Sep 17 00:00:00 2001 From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> Date: Sun, 4 Jun 2017 04:16:24 +0200 Subject: rxrpc: check return value of skb_to_sgvec always From: Jason A. Donenfeld <Jason(a)zx2c4.com> commit 89a5ea99662505d2d61f2a3030a6896c2cb3cdb0 upstream. Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> Acked-by: David Howells <dhowells(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> [natechancellor: backport to 3.18] Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rxrpc/rxkad.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) --- a/net/rxrpc/rxkad.c +++ b/net/rxrpc/rxkad.c @@ -209,7 +209,7 @@ static int rxkad_secure_packet_encrypt(c struct sk_buff *trailer; unsigned int len; u16 check; - int nsg; + int nsg, err; sp = rxrpc_skb(skb); @@ -240,7 +240,9 @@ static int rxkad_secure_packet_encrypt(c len &= ~(call->conn->size_align - 1); sg_init_table(sg, nsg); - skb_to_sgvec(skb, sg, 0, len); + err = skb_to_sgvec(skb, sg, 0, len); + if (unlikely(err < 0)) + return err; crypto_blkcipher_encrypt_iv(&desc, sg, sg, len); _leave(" = 0"); @@ -336,7 +338,7 @@ static int rxkad_verify_packet_auth(cons struct sk_buff *trailer; u32 data_size, buf; u16 check; - int nsg; + int nsg, ret; _enter(""); @@ -348,7 +350,9 @@ static int rxkad_verify_packet_auth(cons goto nomem; sg_init_table(sg, nsg); - skb_to_sgvec(skb, sg, 0, 8); + ret = skb_to_sgvec(skb, sg, 0, 8); + if (unlikely(ret < 0)) + return ret; /* start the decryption afresh */ memset(&iv, 0, sizeof(iv)); @@ -411,7 +415,7 @@ static int rxkad_verify_packet_encrypt(c struct sk_buff *trailer; u32 data_size, buf; u16 check; - int nsg; + int nsg, ret; _enter(",{%d}", skb->len); @@ -430,7 +434,12 @@ static int rxkad_verify_packet_encrypt(c } sg_init_table(sg, nsg); - skb_to_sgvec(skb, sg, 0, skb->len); + ret = skb_to_sgvec(skb, sg, 0, skb->len); + if (unlikely(ret < 0)) { + if (sg != _sg) + kfree(sg); + return ret; + } /* decrypt from the session key */ token = call->conn->key->payload.data; Patches currently in stable-queue which might be from Jason(a)zx2c4.com are queue-3.18/ipsec-check-return-value-of-skb_to_sgvec-always.patch queue-3.18/skbuff-return-emsgsize-in-skb_to_sgvec-to-prevent-overflow.patch queue-3.18/rxrpc-check-return-value-of-skb_to_sgvec-always.patch queue-3.18/virtio_net-check-return-value-of-skb_to_sgvec-always.patch queue-3.18/virtio_net-check-return-value-of-skb_to_sgvec-in-one-more-location.patch

7 years, 4 months

1
0
0 0

Patch "qlge: Avoid reading past end of buffer" 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 qlge: Avoid reading past end of buffer 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: qlge-avoid-reading-past-end-of-buffer.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 Tue Apr 10 13:58:07 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-3.18/qlge-avoid-reading-past-end-of-buffer.patch queue-3.18/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch queue-3.18/ray_cs-avoid-reading-past-end-of-buffer.patch queue-3.18/bna-avoid-reading-past-end-of-buffer.patch

7 years, 4 months

1
0
0 0

Patch "ray_cs: Avoid reading past end of buffer" 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 ray_cs: Avoid reading past end of buffer 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: ray_cs-avoid-reading-past-end-of-buffer.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 Tue Apr 10 13:58:07 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-3.18/qlge-avoid-reading-past-end-of-buffer.patch queue-3.18/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch queue-3.18/ray_cs-avoid-reading-past-end-of-buffer.patch queue-3.18/bna-avoid-reading-past-end-of-buffer.patch

7 years, 4 months

1
0
0 0

Patch "powerpc/spufs: Fix coredump of SPU contexts" 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 powerpc/spufs: Fix coredump of SPU contexts 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: powerpc-spufs-fix-coredump-of-spu-contexts.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 Tue Apr 10 13:58:07 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-3.18/selftests-powerpc-fix-tm-resched-dscr-test-with-some-compilers.patch queue-3.18/powerpc-spufs-fix-coredump-of-spu-contexts.patch queue-3.18/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch queue-3.18/powerpc-don-t-clobber-tcr-when-setting-tcr.patch

7 years, 4 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 3.18-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 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: 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-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 Tue Apr 10 13:58:07 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-3.18/misdn-fix-a-sleep-in-atomic-bug.patch queue-3.18/qlcnic-fix-a-sleep-in-atomic-bug-in-qlcnic_82xx_hw_write_wx_2m-and-qlcnic_82xx_hw_read_wx_2m.patch

7 years, 4 months

1
0
0 0

Patch "PowerCap: Fix an error code in powercap_register_zone()" 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 PowerCap: Fix an error code in powercap_register_zone() 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: powercap-fix-an-error-code-in-powercap_register_zone.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 Tue Apr 10 13:58:07 CEST 2018 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Wed, 10 May 2017 22:40:06 +0300 Subject: PowerCap: Fix an error code in powercap_register_zone() From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit 216c4e9db4c9d1d2a382b42880442dc632cd47d9 ] In the current code we accidentally return the successful result from idr_alloc() instead of a negative error pointer. The caller is looking for an error pointer and so it treats the returned value as a valid pointer. This one might be a bit serious because if it lets people get around the kernel's protection for remapping NULL. I'm not sure. Fixes: 75d2364ea0ca (PowerCap: Add class driver) Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.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/powercap/powercap_sys.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/powercap/powercap_sys.c +++ b/drivers/powercap/powercap_sys.c @@ -538,6 +538,7 @@ struct powercap_zone *powercap_register_ power_zone->id = result; idr_init(&power_zone->idr); + result = -ENOMEM; power_zone->name = kstrdup(name, GFP_KERNEL); if (!power_zone->name) goto err_name_alloc; Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-3.18/block-fix-an-error-code-in-add_partition.patch queue-3.18/powercap-fix-an-error-code-in-powercap_register_zone.patch queue-3.18/libceph-null-deref-on-crush_decode-error-path.patch

7 years, 4 months

1
0
0 0

Patch "powerpc/[booke|4xx]: Don't clobber TCR[WP] when setting TCR[DIE]" 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 powerpc/[booke|4xx]: Don't clobber TCR[WP] when setting TCR[DIE] 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: powerpc-don-t-clobber-tcr-when-setting-tcr.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 Tue Apr 10 13:58:07 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 @@ -646,12 +646,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-3.18/powerpc-don-t-clobber-tcr-when-setting-tcr.patch

7 years, 4 months

1
0
0 0

Patch "pidns: disable pid allocation if pid_ns_prepare_proc() is failed in alloc_pid()" 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 pidns: disable pid allocation if pid_ns_prepare_proc() is failed in alloc_pid() 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: pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.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 Tue Apr 10 13:58:07 CEST 2018 From: Kirill Tkhai <ktkhai(a)virtuozzo.com> Date: Mon, 8 May 2017 15:56:34 -0700 Subject: pidns: disable pid allocation if pid_ns_prepare_proc() is failed in alloc_pid() From: Kirill Tkhai <ktkhai(a)virtuozzo.com> [ Upstream commit 8896c23d2ef803f1883fea73117a435925c2b4c4 ] alloc_pidmap() advances pid_namespace::last_pid. When first pid allocation fails, then next created process will have pid 2 and pid_ns_prepare_proc() won't be called. So, pid_namespace::proc_mnt will never be initialized (not to mention that there won't be a child reaper). I saw crash stack of such case on kernel 3.10: BUG: unable to handle kernel NULL pointer dereference at (null) IP: proc_flush_task+0x8f/0x1b0 Call Trace: release_task+0x3f/0x490 wait_consider_task.part.10+0x7ff/0xb00 do_wait+0x11f/0x280 SyS_wait4+0x7d/0x110 We may fix this by restore of last_pid in 0 or by prohibiting of futher allocations. Since there was a similar issue in Oleg Nesterov's commit 314a8ad0f18a ("pidns: fix free_pid() to handle the first fork failure"). and it was fixed via prohibiting allocation, let's follow this way, and do the same. Link: http://lkml.kernel.org/r/149201021004.4863.6762095011554287922.stgit@localh… Signed-off-by: Kirill Tkhai <ktkhai(a)virtuozzo.com> Acked-by: Cyrill Gorcunov <gorcunov(a)openvz.org> Cc: Andrei Vagin <avagin(a)virtuozzo.com> Cc: Andreas Gruenbacher <agruenba(a)redhat.com> Cc: Kees Cook <keescook(a)chromium.org> Cc: Michael Kerrisk <mtk.manpages(a)googlemail.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: Paul Moore <paul(a)paul-moore.com> Cc: Eric Biederman <ebiederm(a)xmission.com> Cc: Andy Lutomirski <luto(a)amacapital.net> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Serge Hallyn <serge(a)hallyn.com> 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> --- kernel/pid.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/kernel/pid.c +++ b/kernel/pid.c @@ -316,8 +316,10 @@ struct pid *alloc_pid(struct pid_namespa } if (unlikely(is_child_reaper(pid))) { - if (pid_ns_prepare_proc(ns)) + if (pid_ns_prepare_proc(ns)) { + disable_pid_allocation(ns); goto out_free; + } } get_pid_ns(ns); Patches currently in stable-queue which might be from ktkhai(a)virtuozzo.com are queue-3.18/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch

7 years, 4 months

1
0
0 0

Patch "perf trace: Add mmap alias for s390" 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 perf trace: Add mmap alias for s390 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: perf-trace-add-mmap-alias-for-s390.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 Tue Apr 10 13:58:07 CEST 2018 From: Jiri Olsa <jolsa(a)kernel.org> Date: Wed, 31 May 2017 13:35:57 +0200 Subject: perf trace: Add mmap alias for s390 From: Jiri Olsa <jolsa(a)kernel.org> [ Upstream commit 54265664c15a68905d8d67d19205e9a767636434 ] The s390 architecture maps sys_mmap (nr 90) into sys_old_mmap. For this reason perf trace can't find the proper syscall event to get args format from and displays it wrongly as 'continued'. To fix that fill the "alias" field with "old_mmap" for trace's mmap record to get the correct translation. Before: 0.042 ( 0.011 ms): vest/43052 fstat(statbuf: 0x3ffff89fd90 ) = 0 0.042 ( 0.028 ms): vest/43052 ... [continued]: mmap()) = 0x3fffd6e2000 0.072 ( 0.025 ms): vest/43052 read(buf: 0x3fffd6e2000, count: 4096 ) = 6 After: 0.045 ( 0.011 ms): fstat(statbuf: 0x3ffff8a0930 ) = 0 0.057 ( 0.018 ms): mmap(arg: 0x3ffff8a0858 ) = 0x3fffd14a000 0.076 ( 0.025 ms): read(buf: 0x3fffd14a000, count: 4096 ) = 6 Signed-off-by: Jiri Olsa <jolsa(a)kernel.org> Cc: David Ahern <dsahern(a)gmail.com> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Peter Zijlstra <a.p.zijlstra(a)chello.nl> Link: http://lkml.kernel.org/r/20170531113557.19175-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/builtin-trace.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/tools/perf/builtin-trace.c +++ b/tools/perf/builtin-trace.c @@ -1020,6 +1020,10 @@ static struct syscall_fmt { { .name = "mlockall", .errmsg = true, .arg_scnprintf = { [0] = SCA_HEX, /* addr */ }, }, { .name = "mmap", .hexret = true, +/* The standard mmap maps to old_mmap on s390x */ +#if defined(__s390x__) + .alias = "old_mmap", +#endif .arg_scnprintf = { [0] = SCA_HEX, /* addr */ [2] = SCA_MMAP_PROT, /* prot */ [3] = SCA_MMAP_FLAGS, /* flags */ Patches currently in stable-queue which might be from jolsa(a)kernel.org are queue-3.18/perf-trace-add-mmap-alias-for-s390.patch queue-3.18/perf-core-correct-event-creation-with-perf_format_group.patch queue-3.18/perf-tests-decompress-kernel-module-before-objdump.patch

7 years, 4 months

1
0
0 0

Patch "perf tests: Decompress kernel module before objdump" 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 perf tests: Decompress kernel module before objdump 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: perf-tests-decompress-kernel-module-before-objdump.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 Tue Apr 10 13:58:07 CEST 2018 From: Namhyung Kim <namhyung(a)kernel.org> Date: Thu, 8 Jun 2017 16:31:07 +0900 Subject: perf tests: Decompress kernel module before objdump From: Namhyung Kim <namhyung(a)kernel.org> [ Upstream commit 94df1040b1e6aacd8dec0ba3c61d7e77cd695f26 ] If a kernel modules is compressed, it should be decompressed before running objdump to parse binary data correctly. This fixes a failure of object code reading test for me. Signed-off-by: Namhyung Kim <namhyung(a)kernel.org> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Acked-by: Jiri Olsa <jolsa(a)kernel.org> Cc: David Ahern <dsahern(a)gmail.com> Cc: Peter Zijlstra <a.p.zijlstra(a)chello.nl> Cc: Wang Nan <wangnan0(a)huawei.com> Cc: kernel-team(a)lge.com Link: http://lkml.kernel.org/r/20170608073109.30699-8-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/tests/code-reading.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) --- a/tools/perf/tests/code-reading.c +++ b/tools/perf/tests/code-reading.c @@ -141,6 +141,8 @@ static int read_object_code(u64 addr, si unsigned char buf2[BUFSZ]; size_t ret_len; u64 objdump_addr; + const char *objdump_name; + char decomp_name[KMOD_DECOMP_LEN]; int ret; pr_debug("Reading object code for memory address: %#"PRIx64"\n", addr); @@ -202,9 +204,25 @@ static int read_object_code(u64 addr, si state->done[state->done_cnt++] = al.map->start; } + objdump_name = al.map->dso->long_name; + if (dso__needs_decompress(al.map->dso)) { + if (dso__decompress_kmodule_path(al.map->dso, objdump_name, + decomp_name, + sizeof(decomp_name)) < 0) { + pr_debug("decompression failed\n"); + return -1; + } + + objdump_name = decomp_name; + } + /* Read the object code using objdump */ objdump_addr = map__rip_2objdump(al.map, al.addr); - ret = read_via_objdump(al.map->dso->long_name, objdump_addr, buf2, len); + ret = read_via_objdump(objdump_name, objdump_addr, buf2, len); + + if (dso__needs_decompress(al.map->dso)) + unlink(objdump_name); + if (ret > 0) { /* * The kernel maps are inaccurate - assume objdump is right in Patches currently in stable-queue which might be from namhyung(a)kernel.org are queue-3.18/perf-trace-add-mmap-alias-for-s390.patch queue-3.18/perf-report-ensure-the-perf-dso-mapping-matches-what-libdw-sees.patch queue-3.18/perf-tests-decompress-kernel-module-before-objdump.patch

7 years, 4 months

1
0
0 0

Patch "perf report: Ensure the perf DSO mapping matches what libdw sees" 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 perf report: Ensure the perf DSO mapping matches what libdw sees 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: perf-report-ensure-the-perf-dso-mapping-matches-what-libdw-sees.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 Tue Apr 10 13:58:07 CEST 2018 From: Milian Wolff <milian.wolff(a)kdab.com> Date: Fri, 2 Jun 2017 16:37:52 +0200 Subject: perf report: Ensure the perf DSO mapping matches what libdw sees From: Milian Wolff <milian.wolff(a)kdab.com> [ Upstream commit 2538b9e2450ae255337c04356e9e0f8cb9ec48d9 ] In some situations the libdw unwinder stopped working properly. I.e. with libunwind we see: ~~~~~ heaptrack_gui 2228 135073.400112: 641314 cycles: e8ed _dl_fixup (/usr/lib/ld-2.25.so) 15f06 _dl_runtime_resolve_sse_vex (/usr/lib/ld-2.25.so) ed94c KDynamicJobTracker::KDynamicJobTracker (/home/milian/projects/compiled/kf5/lib64/libKF5KIOWidgets.so.5.35.0) 608f3 _GLOBAL__sub_I_kdynamicjobtracker.cpp (/home/milian/projects/compiled/kf5/lib64/libKF5KIOWidgets.so.5.35.0) f199 call_init.part.0 (/usr/lib/ld-2.25.so) f2a5 _dl_init (/usr/lib/ld-2.25.so) db9 _dl_start_user (/usr/lib/ld-2.25.so) ~~~~~ But with libdw and without this patch this sample is not properly unwound: ~~~~~ heaptrack_gui 2228 135073.400112: 641314 cycles: e8ed _dl_fixup (/usr/lib/ld-2.25.so) 15f06 _dl_runtime_resolve_sse_vex (/usr/lib/ld-2.25.so) ed94c KDynamicJobTracker::KDynamicJobTracker (/home/milian/projects/compiled/kf5/lib64/libKF5KIOWidgets.so.5.35.0) ~~~~~ Debug output showed me that libdw found a module for the last frame address, but it thinks it belongs to /usr/lib/ld-2.25.so. This patch double-checks what libdw sees and what perf knows. If the mappings mismatch, we now report the elf known to perf. This fixes the situation above, and the libdw unwinder produces the same stack as libunwind. Signed-off-by: Milian Wolff <milian.wolff(a)kdab.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Namhyung Kim <namhyung(a)kernel.org> Link: http://lkml.kernel.org/r/20170602143753.16907-1-milian.wolff@kdab.com Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/util/unwind-libdw.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/tools/perf/util/unwind-libdw.c +++ b/tools/perf/util/unwind-libdw.c @@ -37,6 +37,14 @@ static int __report_module(struct addr_l return 0; mod = dwfl_addrmodule(ui->dwfl, ip); + if (mod) { + Dwarf_Addr s; + + dwfl_module_info(mod, NULL, &s, NULL, NULL, NULL, NULL, NULL); + if (s != al->map->start) + mod = 0; + } + if (!mod) mod = dwfl_report_elf(ui->dwfl, dso->short_name, dso->long_name, -1, al->map->start, Patches currently in stable-queue which might be from milian.wolff(a)kdab.com are queue-3.18/perf-report-ensure-the-perf-dso-mapping-matches-what-libdw-sees.patch

7 years, 4 months

1
0
0 0

Patch "ovl: filter trusted xattr for non-admin" 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 ovl: filter trusted xattr for non-admin 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: ovl-filter-trusted-xattr-for-non-admin.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 Tue Apr 10 13:58:07 CEST 2018 From: Miklos Szeredi <mszeredi(a)redhat.com> Date: Mon, 29 May 2017 15:15:27 +0200 Subject: ovl: filter trusted xattr for non-admin From: Miklos Szeredi <mszeredi(a)redhat.com> [ Upstream commit a082c6f680da298cf075886ff032f32ccb7c5e1a ] Filesystems filter out extended attributes in the "trusted." domain for unprivlieged callers. Overlay calls underlying filesystem's method with elevated privs, so need to do the filtering in overlayfs too. Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/overlayfs/inode.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/fs/overlayfs/inode.c +++ b/fs/overlayfs/inode.c @@ -258,6 +258,16 @@ ssize_t ovl_getxattr(struct dentry *dent return vfs_getxattr(realpath.dentry, name, value, size); } +static bool ovl_can_list(const char *s) +{ + /* List all non-trusted xatts */ + if (strncmp(s, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN) != 0) + return true; + + /* Never list trusted.overlay, list other trusted for superuser only */ + return !ovl_is_private_xattr(s) && capable(CAP_SYS_ADMIN); +} + ssize_t ovl_listxattr(struct dentry *dentry, char *list, size_t size) { struct path realpath; @@ -282,7 +292,7 @@ ssize_t ovl_listxattr(struct dentry *den return -EIO; len -= slen; - if (ovl_is_private_xattr(s)) { + if (!ovl_can_list(s)) { res -= slen; memmove(s, s + slen, len); } else { Patches currently in stable-queue which might be from mszeredi(a)redhat.com are queue-3.18/ovl-filter-trusted-xattr-for-non-admin.patch

7 years, 4 months

1
0
0 0

Patch "perf/core: Correct event creation with PERF_FORMAT_GROUP" 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 perf/core: Correct event creation with PERF_FORMAT_GROUP 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: perf-core-correct-event-creation-with-perf_format_group.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 Tue Apr 10 13:58:07 CEST 2018 From: Peter Zijlstra <peterz(a)infradead.org> Date: Tue, 30 May 2017 11:45:12 +0200 Subject: perf/core: Correct event creation with PERF_FORMAT_GROUP From: Peter Zijlstra <peterz(a)infradead.org> [ Upstream commit ba5213ae6b88fb170c4771fef6553f759c7d8cdd ] Andi was asking about PERF_FORMAT_GROUP vs inherited events, which led to the discovery of a bug from commit: 3dab77fb1bf8 ("perf: Rework/fix the whole read vs group stuff") - PERF_SAMPLE_GROUP = 1U << 4, + PERF_SAMPLE_READ = 1U << 4, - if (attr->inherit && (attr->sample_type & PERF_SAMPLE_GROUP)) + if (attr->inherit && (attr->read_format & PERF_FORMAT_GROUP)) is a clear fail :/ While this changes user visible behaviour; it was previously possible to create an inherited event with PERF_SAMPLE_READ; this is deemed acceptible because its results were always incorrect. Reported-by: Andi Kleen <ak(a)linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme(a)kernel.org> Cc: Jiri Olsa <jolsa(a)kernel.org> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Stephane Eranian <eranian(a)google.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Vince Weaver <vince(a)deater.net> Fixes: 3dab77fb1bf8 ("perf: Rework/fix the whole read vs group stuff") Link: http://lkml.kernel.org/r/20170530094512.dy2nljns2uq7qa3j@hirez.programming.… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/events/core.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -4861,9 +4861,6 @@ static void perf_output_read_one(struct __output_copy(handle, values, n * sizeof(u64)); } -/* - * XXX PERF_FORMAT_GROUP vs inherited events seems difficult. - */ static void perf_output_read_group(struct perf_output_handle *handle, struct perf_event *event, u64 enabled, u64 running) @@ -4908,6 +4905,13 @@ static void perf_output_read_group(struc #define PERF_FORMAT_TOTAL_TIMES (PERF_FORMAT_TOTAL_TIME_ENABLED|\ PERF_FORMAT_TOTAL_TIME_RUNNING) +/* + * XXX PERF_SAMPLE_READ vs inherited events seems difficult. + * + * The problem is that its both hard and excessively expensive to iterate the + * child list, not to mention that its impossible to IPI the children running + * on another CPU, from interrupt/NMI context. + */ static void perf_output_read(struct perf_output_handle *handle, struct perf_event *event) { @@ -7194,9 +7198,10 @@ perf_event_alloc(struct perf_event_attr local64_set(&hwc->period_left, hwc->sample_period); /* - * we currently do not support PERF_FORMAT_GROUP on inherited events + * We currently do not support PERF_SAMPLE_READ on inherited events. + * See perf_output_read(). */ - if (attr->inherit && (attr->read_format & PERF_FORMAT_GROUP)) + if (attr->inherit && (attr->sample_type & PERF_SAMPLE_READ)) goto err_ns; pmu = perf_init_event(event); Patches currently in stable-queue which might be from peterz(a)infradead.org are queue-3.18/perf-core-correct-event-creation-with-perf_format_group.patch queue-3.18/x86-tsc-provide-tsc-unstable-boot-parameter.patch

7 years, 4 months

1
0
0 0

Patch "netxen_nic: set rcode to the return status from the call to netxen_issue_cmd" 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 netxen_nic: set rcode to the return status from the call to netxen_issue_cmd 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: netxen_nic-set-rcode-to-the-return-status-from-the-call-to-netxen_issue_cmd.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 Tue Apr 10 13:58:07 CEST 2018 From: Colin Ian King <colin.king(a)canonical.com> Date: Tue, 9 May 2017 17:19:42 +0100 Subject: netxen_nic: set rcode to the return status from the call to netxen_issue_cmd From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit 0fe20fafd1791f993806d417048213ec57b81045 ] Currently rcode is being initialized to NX_RCODE_SUCCESS and later it is checked to see if it is not NX_RCODE_SUCCESS which is never true. It appears that there is an unintentional missing assignment of rcode from the return of the call to netxen_issue_cmd() that was dropped in an earlier fix, so add it in. Detected by CoverityScan, CID#401900 ("Logically dead code") Fixes: 2dcd5d95ad6b2 ("netxen_nic: fix cdrp race condition") Signed-off-by: Colin Ian King <colin.king(a)canonical.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/netxen/netxen_nic_ctx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c @@ -247,7 +247,7 @@ nx_fw_cmd_set_mtu(struct netxen_adapter cmd.req.arg3 = 0; if (recv_ctx->state == NX_HOST_CTX_STATE_ACTIVE) - netxen_issue_cmd(adapter, &cmd); + rcode = netxen_issue_cmd(adapter, &cmd); if (rcode != NX_RCODE_SUCCESS) return -EIO; Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-3.18/wl1251-check-return-from-call-to-wl1251_acx_arp_ip_filter.patch queue-3.18/netxen_nic-set-rcode-to-the-return-status-from-the-call-to-netxen_issue_cmd.patch queue-3.18/btrfs-fix-incorrect-error-return-ret-being-passed-to-mapping_set_error.patch queue-3.18/ath5k-fix-memory-leak-on-buf-on-failed-eeprom-read.patch

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror