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

Patch "sit: reload iphdr in ipip6_rcv" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sit: reload iphdr in ipip6_rcv to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sit-reload-iphdr-in-ipip6_rcv.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Haishuang Yan <yanhaishuang(a)cmss.chinamobile.com> Date: Sun, 4 Jun 2017 14:43:43 +0800 Subject: sit: reload iphdr in ipip6_rcv From: Haishuang Yan <yanhaishuang(a)cmss.chinamobile.com> [ Upstream commit b699d0035836f6712917a41e7ae58d84359b8ff9 ] Since iptunnel_pull_header() can call pskb_may_pull(), we must reload any pointer that was related to skb->head. Fixes: a09a4c8dd1ec ("tunnels: Remove encapsulation offloads on decap") Signed-off-by: Haishuang Yan <yanhaishuang(a)cmss.chinamobile.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/ipv6/sit.c | 1 + 1 file changed, 1 insertion(+) --- a/net/ipv6/sit.c +++ b/net/ipv6/sit.c @@ -657,6 +657,7 @@ static int ipip6_rcv(struct sk_buff *skb if (iptunnel_pull_header(skb, 0, htons(ETH_P_IPV6), !net_eq(tunnel->net, dev_net(tunnel->dev)))) goto out; + iph = ip_hdr(skb); err = IP_ECN_decapsulate(iph, skb); if (unlikely(err)) { Patches currently in stable-queue which might be from yanhaishuang(a)cmss.chinamobile.com are queue-4.9/sit-reload-iphdr-in-ipip6_rcv.patch

7 years, 4 months

1
0
0 0

Patch "signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Sat, 19 Aug 2017 15:26:01 -0500 Subject: signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP From: "Eric W. Biederman" <ebiederm(a)xmission.com> [ Upstream commit cf4674c46c66e45f238f8f7e81af2a444b970c0a ] 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 and TRAP_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: Paul Mackerras <paulus(a)samba.org> Cc: Kumar Gala <kumar.gala(a)freescale.com> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: linuxppc-dev(a)lists.ozlabs.org Ref: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx") Ref: 0ed70f6105ef ("PPC32: Provide proper siginfo information on various exceptions.") 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/powerpc/include/uapi/asm/siginfo.h | 15 +++++++++++++++ arch/powerpc/kernel/traps.c | 10 +++++----- 2 files changed, 20 insertions(+), 5 deletions(-) --- a/arch/powerpc/include/uapi/asm/siginfo.h +++ b/arch/powerpc/include/uapi/asm/siginfo.h @@ -17,4 +17,19 @@ #undef NSIGTRAP #define NSIGTRAP 4 +/* + * SIGFPE si_codes + */ +#ifdef __KERNEL__ +#define FPE_FIXME 0 /* Broken dup of SI_USER */ +#endif /* __KERNEL__ */ + +/* + * SIGTRAP si_codes + */ +#ifdef __KERNEL__ +#define TRAP_FIXME 0 /* Broken dup of SI_USER */ +#endif /* __KERNEL__ */ + + #endif /* _ASM_POWERPC_SIGINFO_H */ --- a/arch/powerpc/kernel/traps.c +++ b/arch/powerpc/kernel/traps.c @@ -793,7 +793,7 @@ void unknown_exception(struct pt_regs *r printk("Bad trap at PC: %lx, SR: %lx, vector=%lx\n", regs->nip, regs->msr, regs->trap); - _exception(SIGTRAP, regs, 0, 0); + _exception(SIGTRAP, regs, TRAP_FIXME, 0); exception_exit(prev_state); } @@ -815,7 +815,7 @@ bail: void RunModeException(struct pt_regs *regs) { - _exception(SIGTRAP, regs, 0, 0); + _exception(SIGTRAP, regs, TRAP_FIXME, 0); } void single_step_exception(struct pt_regs *regs) @@ -851,7 +851,7 @@ static void emulate_single_step(struct p static inline int __parse_fpscr(unsigned long fpscr) { - int ret = 0; + int ret = FPE_FIXME; /* Invalid operation */ if ((fpscr & FPSCR_VE) && (fpscr & FPSCR_VX)) @@ -1855,7 +1855,7 @@ void SPEFloatingPointException(struct pt extern int do_spe_mathemu(struct pt_regs *regs); unsigned long spefscr; int fpexc_mode; - int code = 0; + int code = FPE_FIXME; int err; flush_spe_to_thread(current); @@ -1924,7 +1924,7 @@ void SPEFloatingPointRoundException(stru printk(KERN_ERR "unrecognized spe instruction " "in %s at %lx\n", current->comm, regs->nip); } else { - _exception(SIGFPE, regs, 0, regs->nip); + _exception(SIGFPE, regs, FPE_FIXME, regs->nip); return; } } Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-4.9/signal-metag-document-a-conflict-with-si_user-with-sigfpe.patch queue-4.9/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch queue-4.9/signal-arm-document-conflicts-with-si_user-and-sigfpe.patch queue-4.9/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch

7 years, 4 months

1
0
0 0

Patch "signal/metag: Document a conflict with SI_USER with SIGFPE" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled signal/metag: Document a conflict with SI_USER with SIGFPE to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: signal-metag-document-a-conflict-with-si_user-with-sigfpe.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Tue, 1 Aug 2017 10:37:40 -0500 Subject: signal/metag: Document a conflict with SI_USER with SIGFPE From: "Eric W. Biederman" <ebiederm(a)xmission.com> [ Upstream commit b80328be53c215346b153769267b38f531d89b4f ] 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 hat 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 reliably be 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: James Hogan <james.hogan(a)imgtec.com> Cc: linux-metag(a)vger.kernel.org Ref: ac919f0883e5 ("metag: Traps") 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/metag/include/uapi/asm/siginfo.h | 7 +++++++ arch/metag/kernel/traps.c | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) --- a/arch/metag/include/uapi/asm/siginfo.h +++ b/arch/metag/include/uapi/asm/siginfo.h @@ -5,4 +5,11 @@ #include <asm-generic/siginfo.h> +/* + * SIGFPE si_codes + */ +#ifdef __KERNEL__ +#define FPE_FIXME 0 /* Broken dup of SI_USER */ +#endif /* __KERNEL__ */ + #endif --- a/arch/metag/kernel/traps.c +++ b/arch/metag/kernel/traps.c @@ -732,7 +732,7 @@ TBIRES fpe_handler(TBIRES State, int Sig else if (error_state & TXSTAT_FPE_INEXACT_BIT) info.si_code = FPE_FLTRES; else - info.si_code = 0; + info.si_code = FPE_FIXME; info.si_errno = 0; info.si_addr = (__force void __user *)regs->ctx.CurrPC; force_sig_info(SIGFPE, &info, current); Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-4.9/signal-metag-document-a-conflict-with-si_user-with-sigfpe.patch queue-4.9/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch queue-4.9/signal-arm-document-conflicts-with-si_user-and-sigfpe.patch queue-4.9/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch

7 years, 4 months

1
0
0 0

Patch "serial: sh-sci: Fix race condition causing garbage during shutdown" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: sh-sci: Fix race condition causing garbage during shutdown to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-sh-sci-fix-race-condition-causing-garbage-during-shutdown.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Tue, 25 Apr 2017 20:15:35 +0200 Subject: serial: sh-sci: Fix race condition causing garbage during shutdown From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 1cf4a7efdc71cab84c42cfea7200608711ea954f ] If DMA is enabled and used, a burst of old data may be seen on the serial console during "poweroff" or "reboot". uart_flush_buffer() clears the circular buffer, but sci_port.tx_dma_len is not reset. This leads to a circular buffer overflow, dumping (UART_XMIT_SIZE - sci_port.tx_dma_len) bytes. To fix this, add a .flush_buffer() callback that resets sci_port.tx_dma_len. Inspired by commit 31ca2c63fdc0aee7 ("tty/serial: atmel: fix race condition (TX+DMA)"). Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/sh-sci.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -1545,7 +1545,16 @@ static void sci_free_dma(struct uart_por if (s->chan_rx) sci_rx_dma_release(s, false); } -#else + +static void sci_flush_buffer(struct uart_port *port) +{ + /* + * In uart_flush_buffer(), the xmit circular buffer has just been + * cleared, so we have to reset tx_dma_len accordingly. + */ + to_sci_port(port)->tx_dma_len = 0; +} +#else /* !CONFIG_SERIAL_SH_SCI_DMA */ static inline void sci_request_dma(struct uart_port *port) { } @@ -1553,7 +1562,9 @@ static inline void sci_request_dma(struc static inline void sci_free_dma(struct uart_port *port) { } -#endif + +#define sci_flush_buffer NULL +#endif /* !CONFIG_SERIAL_SH_SCI_DMA */ static irqreturn_t sci_rx_interrupt(int irq, void *ptr) { @@ -2551,6 +2562,7 @@ static const struct uart_ops sci_uart_op .break_ctl = sci_break_ctl, .startup = sci_startup, .shutdown = sci_shutdown, + .flush_buffer = sci_flush_buffer, .set_termios = sci_set_termios, .pm = sci_pm, .type = sci_type, Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-4.9/acpi-ec-fix-debugfs_create_-usage.patch queue-4.9/serial-sh-sci-fix-race-condition-causing-garbage-during-shutdown.patch queue-4.9/clk-renesas-rcar-gen2-fix-pll0-on-r-car-v2h-and-e2.patch queue-4.9/sh_eth-use-platform-device-for-printing-before-register_netdev.patch queue-4.9/arm-dts-armadillo800eva-split-lcd-mux-and-gpio.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 4.9-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 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sh_eth-use-platform-device-for-printing-before-register_netdev.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: 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 @@ -3133,7 +3133,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-4.9/acpi-ec-fix-debugfs_create_-usage.patch queue-4.9/serial-sh-sci-fix-race-condition-causing-garbage-during-shutdown.patch queue-4.9/clk-renesas-rcar-gen2-fix-pll0-on-r-car-v2h-and-e2.patch queue-4.9/sh_eth-use-platform-device-for-printing-before-register_netdev.patch queue-4.9/arm-dts-armadillo800eva-split-lcd-mux-and-gpio.patch

7 years, 4 months

1
0
0 0

Patch "serial: 8250: omap: Disable DMA for console UART" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: 8250: omap: Disable DMA for console UART to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-8250-omap-disable-dma-for-console-uart.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Vignesh R <vigneshr(a)ti.com> Date: Sat, 22 Apr 2017 18:37:19 +0530 Subject: serial: 8250: omap: Disable DMA for console UART From: Vignesh R <vigneshr(a)ti.com> [ Upstream commit 84b40e3b57eef1417479c00490dd4c9f6e5ffdbc ] Kernel always writes log messages to console via serial8250_console_write()->serial8250_console_putchar() which directly accesses UART_TX register _without_ using DMA. But, if other processes like systemd using same UART port, then these writes are handled by a different code flow using 8250_omap driver where there is provision to use DMA. It seems that it is possible that both DMA and CPU might simultaneously put data to UART FIFO and lead to potential loss of data due to FIFO overflow and weird data corruption. This happens when both kernel console and userspace tries to write simultaneously to the same UART port. Therefore, disable DMA on kernel console port to avoid potential race between CPU and DMA. Signed-off-by: Vignesh R <vigneshr(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_omap.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/tty/serial/8250/8250_omap.c +++ b/drivers/tty/serial/8250/8250_omap.c @@ -613,6 +613,10 @@ static int omap_8250_startup(struct uart up->lsr_saved_flags = 0; up->msr_saved_flags = 0; + /* Disable DMA for console UART */ + if (uart_console(port)) + up->dma = NULL; + if (up->dma) { ret = serial8250_request_dma(up); if (ret) { Patches currently in stable-queue which might be from vigneshr(a)ti.com are queue-4.9/serial-8250-omap-disable-dma-for-console-uart.patch

7 years, 4 months

1
0
0 0

Patch "selinux: do not check open permission on sockets" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selinux: do not check open permission on sockets to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selinux-do-not-check-open-permission-on-sockets.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Stephen Smalley <sds(a)tycho.nsa.gov> Date: Fri, 12 May 2017 12:41:24 -0400 Subject: selinux: do not check open permission on sockets From: Stephen Smalley <sds(a)tycho.nsa.gov> [ Upstream commit ccb544781d34afdb73a9a73ae53035d824d193bf ] open permission is currently only defined for files in the kernel (COMMON_FILE_PERMS rather than COMMON_FILE_SOCK_PERMS). Construction of an artificial test case that tries to open a socket via /proc/pid/fd will generate a recvfrom avc denial because recvfrom and open happen to map to the same permission bit in socket vs file classes. open of a socket via /proc/pid/fd is not supported by the kernel regardless and will ultimately return ENXIO. But we hit the permission check first and can thus produce these odd/misleading denials. Omit the open check when operating on a socket. Signed-off-by: Stephen Smalley <sds(a)tycho.nsa.gov> Signed-off-by: Paul Moore <paul(a)paul-moore.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/selinux/hooks.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2033,8 +2033,9 @@ static inline u32 file_to_av(struct file static inline u32 open_file_to_av(struct file *file) { u32 av = file_to_av(file); + struct inode *inode = file_inode(file); - if (selinux_policycap_openperm) + if (selinux_policycap_openperm && inode->i_sb->s_magic != SOCKFS_MAGIC) av |= FILE__OPEN; return av; @@ -3031,6 +3032,7 @@ static int selinux_inode_permission(stru static int selinux_inode_setattr(struct dentry *dentry, struct iattr *iattr) { const struct cred *cred = current_cred(); + struct inode *inode = d_backing_inode(dentry); unsigned int ia_valid = iattr->ia_valid; __u32 av = FILE__WRITE; @@ -3046,8 +3048,10 @@ static int selinux_inode_setattr(struct ATTR_ATIME_SET | ATTR_MTIME_SET | ATTR_TIMES_SET)) return dentry_has_perm(cred, dentry, FILE__SETATTR); - if (selinux_policycap_openperm && (ia_valid & ATTR_SIZE) - && !(ia_valid & ATTR_FILE)) + if (selinux_policycap_openperm && + inode->i_sb->s_magic != SOCKFS_MAGIC && + (ia_valid & ATTR_SIZE) && + !(ia_valid & ATTR_FILE)) av |= FILE__OPEN; return dentry_has_perm(cred, dentry, av); Patches currently in stable-queue which might be from sds(a)tycho.nsa.gov are queue-4.9/selinux-do-not-check-open-permission-on-sockets.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 4.9-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 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-powerpc-fix-tm-resched-dscr-test-with-some-compilers.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Michael Ellerman <mpe(a)ellerman.id.au> Date: 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 @@ -42,12 +42,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-4.9/selftests-powerpc-fix-tm-resched-dscr-test-with-some-compilers.patch queue-4.9/powerpc-modules-if-mprofile-kernel-is-enabled-add-it-to-vermagic.patch queue-4.9/powerpc-mm-fix-virt_addr_valid-etc.-on-64-bit-hash.patch queue-4.9/powerpc-spufs-fix-coredump-of-spu-contexts.patch queue-4.9/cxl-unlock-on-error-in-probe.patch queue-4.9/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch queue-4.9/powerpc-don-t-clobber-tcr-when-setting-tcr.patch queue-4.9/powerpc-8xx-fix-mpc8xx_get_irq-return-on-no-irq.patch

7 years, 4 months

1
0
0 0

Patch "sdhci: Advertise 2.0v supply on SDIO host controller" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sdhci: Advertise 2.0v supply on SDIO host controller to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sdhci-advertise-2.0v-supply-on-sdio-host-controller.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Date: Thu, 11 Jan 2018 15:51:58 +0200 Subject: sdhci: Advertise 2.0v supply on SDIO host controller From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> [ Upstream commit 2a609abe71ca59e4bd7139e161eaca2144ae6f2e ] On Intel Edison the Broadcom Wi-Fi card, which is connected to SDIO, requires 2.0v, while the host, according to Intel Merrifield TRM, supports 1.8v supply only. The card announces itself as mmc2: new ultra high speed DDR50 SDIO card at address 0001 Introduce a custom OCR mask for SDIO host controller on Intel Merrifield and add a special case to sdhci_set_power_noreg() to override 2.0v supply by enforcing 1.8v power choice. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/sdhci-pci-core.c | 2 ++ drivers/mmc/host/sdhci.c | 7 +++++++ 2 files changed, 9 insertions(+) --- a/drivers/mmc/host/sdhci-pci-core.c +++ b/drivers/mmc/host/sdhci-pci-core.c @@ -492,6 +492,8 @@ static int intel_mrfld_mmc_probe_slot(st slot->host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V; break; case INTEL_MRFLD_SDIO: + /* Advertise 2.0v for compatibility with the SDIO card's OCR */ + slot->host->ocr_mask = MMC_VDD_20_21 | MMC_VDD_165_195; slot->host->mmc->caps |= MMC_CAP_NONREMOVABLE | MMC_CAP_POWER_OFF_CARD; break; --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1404,6 +1404,13 @@ void sdhci_set_power_noreg(struct sdhci_ if (mode != MMC_POWER_OFF) { switch (1 << vdd) { case MMC_VDD_165_195: + /* + * Without a regulator, SDHCI does not support 2.0v + * so we only get here if the driver deliberately + * added the 2.0v range to ocr_avail. Map it to 1.8v + * for the purpose of turning on the power. + */ + case MMC_VDD_20_21: pwr = SDHCI_POWER_180; break; case MMC_VDD_29_30: Patches currently in stable-queue which might be from andriy.shevchenko(a)linux.intel.com are queue-4.9/gpio-crystalcove-do-not-write-regular-gpio-registers-for-virtual-gpios.patch queue-4.9/sdhci-advertise-2.0v-supply-on-sdio-host-controller.patch

7 years, 4 months

1
0
0 0

Patch "selftests: kselftest_harness: Fix compile warning" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests: kselftest_harness: Fix compile warning to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-kselftest_harness-fix-compile-warning.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: "Mickaël Salaün" <mic(a)digikod.net> Date: Sun, 11 Jun 2017 14:32:58 +0200 Subject: selftests: kselftest_harness: Fix compile warning From: "Mickaël Salaün" <mic(a)digikod.net> [ Upstream commit 34a048cc06802556e5f96f325dc32cc2f6a11225 ] Do not confuse the compiler with a semicolon preceding a block. Replace the semicolon with an empty block to avoid a warning: gcc -Wl,-no-as-needed -Wall -lpthread seccomp_bpf.c -o /.../linux/tools/testing/selftests/seccomp/seccomp_bpf In file included from seccomp_bpf.c:40:0: seccomp_bpf.c: In function âchange_syscallâ: ../kselftest_harness.h:558:2: warning: this âforâ clause does not guard... [-Wmisleading-indentation] for (; _metadata->trigger; _metadata->trigger = __bail(_assert)) ^ ../kselftest_harness.h:574:14: note: in expansion of macro âOPTIONAL_HANDLERâ } while (0); OPTIONAL_HANDLER(_assert) ^~~~~~~~~~~~~~~~ ../kselftest_harness.h:440:2: note: in expansion of macro â__EXPECTâ __EXPECT(expected, seen, ==, 0) ^~~~~~~~ seccomp_bpf.c:1313:2: note: in expansion of macro âEXPECT_EQâ EXPECT_EQ(0, ret); ^~~~~~~~~ seccomp_bpf.c:1317:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the âforâ { ^ Signed-off-by: MickaÃ«l SalaÃ¼n <mic(a)digikod.net> Cc: Andy Lutomirski <luto(a)amacapital.net> Cc: Kees Cook <keescook(a)chromium.org> Cc: Shuah Khan <shuahkh(a)osg.samsung.com> Cc: Will Drewry <wad(a)chromium.org> Acked-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/testing/selftests/seccomp/seccomp_bpf.c +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c @@ -1318,7 +1318,7 @@ void change_syscall(struct __test_metada iov.iov_len = sizeof(regs); ret = ptrace(PTRACE_GETREGSET, tracee, NT_PRSTATUS, &iov); #endif - EXPECT_EQ(0, ret); + EXPECT_EQ(0, ret) {} #if defined(__x86_64__) || defined(__i386__) || defined(__powerpc__) || \ defined(__s390__) || defined(__hppa__) Patches currently in stable-queue which might be from mic(a)digikod.net are queue-4.9/selftests-kselftest_harness-fix-compile-warning.patch

7 years, 4 months

1
0
0 0

Patch "sctp: fix recursive locking warning in sctp_do_peeloff" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sctp: fix recursive locking warning in sctp_do_peeloff to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sctp-fix-recursive-locking-warning-in-sctp_do_peeloff.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: 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 @@ -1519,7 +1519,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; @@ -1569,7 +1569,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-4.9/sctp-fix-recursive-locking-warning-in-sctp_do_peeloff.patch

7 years, 4 months

1
0
0 0

Patch "scsi: mpt3sas: Proper handling of set/clear of "ATA command pending" flag." has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: mpt3sas: Proper handling of set/clear of "ATA command pending" flag. to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-mpt3sas-proper-handling-of-set-clear-of-ata-command-pending-flag.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Chaitra P B <chaitra.basappa(a)broadcom.com> Date: Wed, 27 Dec 2017 23:09:11 -0800 Subject: scsi: mpt3sas: Proper handling of set/clear of "ATA command pending" flag. From: Chaitra P B <chaitra.basappa(a)broadcom.com> [ Upstream commit f49d4aed1315a7b766d855f1367142e682b0cc87 ] 1. In IO path, setting of "ATA command pending" flag early before device removal, invalid device handle etc., checks causes any new commands to be always returned with SAM_STAT_BUSY and when the driver removes the drive the SML issues SYNC Cache command and that command is always returned with SAM_STAT_BUSY and thus making SYNC Cache command to requeued. 2. If the driver gets an ATA PT command for a SATA drive then the driver set "ATA command pending" flag in device specific data structure not to allow any further commands until the ATA PT command is completed. However, after setting the flag if the driver decides to return the command back to upper layers without actually issuing to the firmware (i.e., returns from qcmd failure return paths) then the corresponding flag is not cleared and this prevents the driver from sending any new commands to the drive. This patch fixes above two issues by setting of "ATA command pending" flag after checking for whether device deleted, invalid device handle, device busy with task management. And by setting "ATA command pending" flag to false in all of the qcmd failure return paths after setting the flag. Signed-off-by: Chaitra P B <chaitra.basappa(a)broadcom.com> Signed-off-by: Suganath Prabu S <suganath-prabu.subramani(a)broadcom.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/mpt3sas/mpt3sas_scsih.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c @@ -4065,19 +4065,6 @@ scsih_qcmd(struct Scsi_Host *shost, stru return 0; } - /* - * Bug work around for firmware SATL handling. The loop - * is based on atomic operations and ensures consistency - * since we're lockless at this point - */ - do { - if (test_bit(0, &sas_device_priv_data->ata_command_pending)) { - scmd->result = SAM_STAT_BUSY; - scmd->scsi_done(scmd); - return 0; - } - } while (_scsih_set_satl_pending(scmd, true)); - sas_target_priv_data = sas_device_priv_data->sas_target; /* invalid device handle */ @@ -4103,6 +4090,19 @@ scsih_qcmd(struct Scsi_Host *shost, stru sas_device_priv_data->block) return SCSI_MLQUEUE_DEVICE_BUSY; + /* + * Bug work around for firmware SATL handling. The loop + * is based on atomic operations and ensures consistency + * since we're lockless at this point + */ + do { + if (test_bit(0, &sas_device_priv_data->ata_command_pending)) { + scmd->result = SAM_STAT_BUSY; + scmd->scsi_done(scmd); + return 0; + } + } while (_scsih_set_satl_pending(scmd, true)); + if (scmd->sc_data_direction == DMA_FROM_DEVICE) mpi_control = MPI2_SCSIIO_CONTROL_READ; else if (scmd->sc_data_direction == DMA_TO_DEVICE) @@ -4124,6 +4124,7 @@ scsih_qcmd(struct Scsi_Host *shost, stru if (!smid) { pr_err(MPT3SAS_FMT "%s: failed obtaining a smid\n", ioc->name, __func__); + _scsih_set_satl_pending(scmd, false); goto out; } mpi_request = mpt3sas_base_get_msg_frame(ioc, smid); @@ -4154,6 +4155,7 @@ scsih_qcmd(struct Scsi_Host *shost, stru if (mpi_request->DataLength) { if (ioc->build_sg_scmd(ioc, scmd, smid)) { mpt3sas_base_free_smid(ioc, smid); + _scsih_set_satl_pending(scmd, false); goto out; } } else Patches currently in stable-queue which might be from chaitra.basappa(a)broadcom.com are queue-4.9/scsi-mpt3sas-proper-handling-of-set-clear-of-ata-command-pending-flag.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 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: libsas: initialize sas_phy status according to response of DISCOVER to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: 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-4.9/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.9/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.9/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 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: libsas: fix memory leak in sas_smp_get_phy_events() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: 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-4.9/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.9/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.9/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 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: libiscsi: Allow sd_shutdown on bad transport to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-libiscsi-allow-sd_shutdown-on-bad-transport.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: 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; @@ -1980,6 +1989,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. */ @@ -2083,7 +2105,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-4.9/scsi-libiscsi-allow-sd_shutdown-on-bad-transport.patch

7 years, 4 months

1
0
0 0

Patch "scsi: libsas: fix error when getting phy events" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: libsas: fix error when getting phy events to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-libsas-fix-error-when-getting-phy-events.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: 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-4.9/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.9/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.9/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.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 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: bnx2fc: fix race condition in bnx2fc_get_host_stats() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-bnx2fc-fix-race-condition-in-bnx2fc_get_host_stats.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: 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 @@ -670,15 +670,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; @@ -700,6 +702,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; } @@ -1348,6 +1353,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-4.9/scsi-bnx2fc-fix-race-condition-in-bnx2fc_get_host_stats.patch

7 years, 4 months

1
0
0 0

Patch "scsi: csiostor: fix use after free in csio_hw_use_fwconfig()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: csiostor: fix use after free in csio_hw_use_fwconfig() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-csiostor-fix-use-after-free-in-csio_hw_use_fwconfig.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Varun Prakash <varun(a)chelsio.com> Date: Wed, 17 May 2017 20:30:43 +0530 Subject: scsi: csiostor: fix use after free in csio_hw_use_fwconfig() From: Varun Prakash <varun(a)chelsio.com> [ Upstream commit a351e40b6de550049423a26f7ded7b639e363d89 ] mbp pointer is passed to csio_hw_validate_caps() so call mempool_free() after calling csio_hw_validate_caps(). Signed-off-by: Varun Prakash <varun(a)chelsio.com> Fixes: 541c571fa2fd ("csiostor:Use firmware version from cxgb4/t4fw_version.h") Reviewed-by: Johannes Thumshirn <jthumshirn(a)suse.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/csiostor/csio_hw.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/scsi/csiostor/csio_hw.c +++ b/drivers/scsi/csiostor/csio_hw.c @@ -1769,7 +1769,6 @@ csio_hw_use_fwconfig(struct csio_hw *hw, goto bye; } - mempool_free(mbp, hw->mb_mempool); if (finicsum != cfcsum) { csio_warn(hw, "Config File checksum mismatch: csum=%#x, computed=%#x\n", @@ -1780,6 +1779,10 @@ csio_hw_use_fwconfig(struct csio_hw *hw, rv = csio_hw_validate_caps(hw, mbp); if (rv != 0) goto bye; + + mempool_free(mbp, hw->mb_mempool); + mbp = NULL; + /* * Note that we're operating with parameters * not supplied by the driver, rather than from hard-wired Patches currently in stable-queue which might be from varun(a)chelsio.com are queue-4.9/scsi-csiostor-fix-use-after-free-in-csio_hw_use_fwconfig.patch

7 years, 4 months

1
0
0 0

Patch "sched/numa: Use down_read_trylock() for the mmap_sem" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sched/numa: Use down_read_trylock() for the mmap_sem to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sched-numa-use-down_read_trylock-for-the-mmap_sem.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Vlastimil Babka <vbabka(a)suse.cz> Date: Mon, 15 May 2017 15:13:16 +0200 Subject: sched/numa: Use down_read_trylock() for the mmap_sem From: Vlastimil Babka <vbabka(a)suse.cz> [ Upstream commit 8655d5497735b288f8a9b458bd22e7d1bf95bb61 ] A customer has reported a soft-lockup when running an intensive memory stress test, where the trace on multiple CPU's looks like this: RIP: 0010:[<ffffffff810c53fe>] [<ffffffff810c53fe>] native_queued_spin_lock_slowpath+0x10e/0x190 ... Call Trace: [<ffffffff81182d07>] queued_spin_lock_slowpath+0x7/0xa [<ffffffff811bc331>] change_protection_range+0x3b1/0x930 [<ffffffff811d4be8>] change_prot_numa+0x18/0x30 [<ffffffff810adefe>] task_numa_work+0x1fe/0x310 [<ffffffff81098322>] task_work_run+0x72/0x90 Further investigation showed that the lock contention here is pmd_lock(). The task_numa_work() function makes sure that only one thread is let to perform the work in a single scan period (via cmpxchg), but if there's a thread with mmap_sem locked for writing for several periods, multiple threads in task_numa_work() can build up a convoy waiting for mmap_sem for read and then all get unblocked at once. This patch changes the down_read() to the trylock version, which prevents the build up. For a workload experiencing mmap_sem contention, it's probably better to postpone the NUMA balancing work anyway. This seems to have fixed the soft lockups involving pmd_lock(), which is in line with the convoy theory. Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Acked-by: Rik van Riel <riel(a)redhat.com> Acked-by: Mel Gorman <mgorman(a)techsingularity.net> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Link: http://lkml.kernel.org/r/20170515131316.21909-1-vbabka@suse.cz 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/sched/fair.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -2429,7 +2429,8 @@ void task_numa_work(struct callback_head return; - down_read(&mm->mmap_sem); + if (!down_read_trylock(&mm->mmap_sem)) + return; vma = find_vma(mm, start); if (!vma) { reset_ptenuma_scan(p); Patches currently in stable-queue which might be from vbabka(a)suse.cz are queue-4.9/sched-numa-use-down_read_trylock-for-the-mmap_sem.patch queue-4.9/mm-vmstat-remove-spurious-warn-during-zoneinfo-print.patch

7 years, 4 months

1
0
0 0

Patch "sched/deadline: Use the revised wakeup rule for suspending constrained dl tasks" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sched/deadline: Use the revised wakeup rule for suspending constrained dl tasks to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sched-deadline-use-the-revised-wakeup-rule-for-suspending-constrained-dl-tasks.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Daniel Bristot de Oliveira <bristot(a)redhat.com> Date: Mon, 29 May 2017 16:24:03 +0200 Subject: sched/deadline: Use the revised wakeup rule for suspending constrained dl tasks From: Daniel Bristot de Oliveira <bristot(a)redhat.com> [ Upstream commit 3effcb4247e74a51f5d8b775a1ee4abf87cc089a ] We have been facing some problems with self-suspending constrained deadline tasks. The main reason is that the original CBS was not designed for such sort of tasks. One problem reported by Xunlei Pang takes place when a task suspends, and then is awakened before the deadline, but so close to the deadline that its remaining runtime can cause the task to have an absolute density higher than allowed. In such situation, the original CBS assumes that the task is facing an early activation, and so it replenishes the task and set another deadline, one deadline in the future. This rule works fine for implicit deadline tasks. Moreover, it allows the system to adapt the period of a task in which the external event source suffered from a clock drift. However, this opens the window for bandwidth leakage for constrained deadline tasks. For instance, a task with the following parameters: runtime = 5 ms deadline = 7 ms [density] = 5 / 7 = 0.71 period = 1000 ms If the task runs for 1 ms, and then suspends for another 1ms, it will be awakened with the following parameters: remaining runtime = 4 laxity = 5 presenting a absolute density of 4 / 5 = 0.80. In this case, the original CBS would assume the task had an early wakeup. Then, CBS will reset the runtime, and the absolute deadline will be postponed by one relative deadline, allowing the task to run. The problem is that, if the task runs this pattern forever, it will keep receiving bandwidth, being able to run 1ms every 2ms. Following this behavior, the task would be able to run 500 ms in 1 sec. Thus running more than the 5 ms / 1 sec the admission control allowed it to run. Trying to address the self-suspending case, Luca Abeni, Giuseppe Lipari, and Juri Lelli [1] revisited the CBS in order to deal with self-suspending tasks. In the new approach, rather than replenishing/postponing the absolute deadline, the revised wakeup rule adjusts the remaining runtime, reducing it to fit into the allowed density. A revised version of the idea is: At a given time t, the maximum absolute density of a task cannot be higher than its relative density, that is: runtime / (deadline - t) <= dl_runtime / dl_deadline Knowing the laxity of a task (deadline - t), it is possible to move it to the other side of the equality, thus enabling to define max remaining runtime a task can use within the absolute deadline, without over-running the allowed density: runtime = (dl_runtime / dl_deadline) * (deadline - t) For instance, in our previous example, the task could still run: runtime = ( 5 / 7 ) * 5 runtime = 3.57 ms Without causing damage for other deadline tasks. It is note worthy that the laxity cannot be negative because that would cause a negative runtime. Thus, this patch depends on the patch: df8eac8cafce ("sched/deadline: Throttle a constrained deadline task activated after the deadline") Which throttles a constrained deadline task activated after the deadline. Finally, it is also possible to use the revised wakeup rule for all other tasks, but that would require some more discussions about pros and cons. Reported-by: Xunlei Pang <xpang(a)redhat.com> Signed-off-by: Daniel Bristot de Oliveira <bristot(a)redhat.com> [peterz: replaced dl_is_constrained with dl_is_implicit] Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Juri Lelli <juri.lelli(a)arm.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Luca Abeni <luca.abeni(a)santannapisa.it> Cc: Mike Galbraith <efault(a)gmx.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Romulo Silva de Oliveira <romulo.deoliveira(a)ufsc.br> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Tommaso Cucinotta <tommaso.cucinotta(a)sssup.it> Link: http://lkml.kernel.org/r/5c800ab3a74a168a84ee5f3f84d12a02e11383be.149580380… 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> --- include/linux/sched.h | 1 kernel/sched/core.c | 2 kernel/sched/deadline.c | 98 ++++++++++++++++++++++++++++++++++++++++++------ 3 files changed, 89 insertions(+), 12 deletions(-) --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1412,6 +1412,7 @@ struct sched_dl_entity { u64 dl_deadline; /* relative deadline of each instance */ u64 dl_period; /* separation of two instances (period) */ u64 dl_bw; /* dl_runtime / dl_deadline */ + u64 dl_density; /* dl_runtime / dl_deadline */ /* * Actual scheduling parameters. Initialized with the values above, --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -2184,6 +2184,7 @@ void __dl_clear_params(struct task_struc dl_se->dl_period = 0; dl_se->flags = 0; dl_se->dl_bw = 0; + dl_se->dl_density = 0; dl_se->dl_throttled = 0; dl_se->dl_yielded = 0; @@ -3912,6 +3913,7 @@ __setparam_dl(struct task_struct *p, con dl_se->dl_period = attr->sched_period ?: dl_se->dl_deadline; dl_se->flags = attr->sched_flags; dl_se->dl_bw = to_ratio(dl_se->dl_period, dl_se->dl_runtime); + dl_se->dl_density = to_ratio(dl_se->dl_deadline, dl_se->dl_runtime); /* * Changing the parameters of a task is 'tricky' and we're not doing --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -484,13 +484,84 @@ static bool dl_entity_overflow(struct sc } /* - * When a -deadline entity is queued back on the runqueue, its runtime and - * deadline might need updating. + * Revised wakeup rule [1]: For self-suspending tasks, rather then + * re-initializing task's runtime and deadline, the revised wakeup + * rule adjusts the task's runtime to avoid the task to overrun its + * density. * - * The policy here is that we update the deadline of the entity only if: - * - the current deadline is in the past, - * - using the remaining runtime with the current deadline would make - * the entity exceed its bandwidth. + * Reasoning: a task may overrun the density if: + * runtime / (deadline - t) > dl_runtime / dl_deadline + * + * Therefore, runtime can be adjusted to: + * runtime = (dl_runtime / dl_deadline) * (deadline - t) + * + * In such way that runtime will be equal to the maximum density + * the task can use without breaking any rule. + * + * [1] Luca Abeni, Giuseppe Lipari, and Juri Lelli. 2015. Constant + * bandwidth server revisited. SIGBED Rev. 11, 4 (January 2015), 19-24. + */ +static void +update_dl_revised_wakeup(struct sched_dl_entity *dl_se, struct rq *rq) +{ + u64 laxity = dl_se->deadline - rq_clock(rq); + + /* + * If the task has deadline < period, and the deadline is in the past, + * it should already be throttled before this check. + * + * See update_dl_entity() comments for further details. + */ + WARN_ON(dl_time_before(dl_se->deadline, rq_clock(rq))); + + dl_se->runtime = (dl_se->dl_density * laxity) >> 20; +} + +/* + * Regarding the deadline, a task with implicit deadline has a relative + * deadline == relative period. A task with constrained deadline has a + * relative deadline <= relative period. + * + * We support constrained deadline tasks. However, there are some restrictions + * applied only for tasks which do not have an implicit deadline. See + * update_dl_entity() to know more about such restrictions. + * + * The dl_is_implicit() returns true if the task has an implicit deadline. + */ +static inline bool dl_is_implicit(struct sched_dl_entity *dl_se) +{ + return dl_se->dl_deadline == dl_se->dl_period; +} + +/* + * When a deadline entity is placed in the runqueue, its runtime and deadline + * might need to be updated. This is done by a CBS wake up rule. There are two + * different rules: 1) the original CBS; and 2) the Revisited CBS. + * + * When the task is starting a new period, the Original CBS is used. In this + * case, the runtime is replenished and a new absolute deadline is set. + * + * When a task is queued before the begin of the next period, using the + * remaining runtime and deadline could make the entity to overflow, see + * dl_entity_overflow() to find more about runtime overflow. When such case + * is detected, the runtime and deadline need to be updated. + * + * If the task has an implicit deadline, i.e., deadline == period, the Original + * CBS is applied. the runtime is replenished and a new absolute deadline is + * set, as in the previous cases. + * + * However, the Original CBS does not work properly for tasks with + * deadline < period, which are said to have a constrained deadline. By + * applying the Original CBS, a constrained deadline task would be able to run + * runtime/deadline in a period. With deadline < period, the task would + * overrun the runtime/period allowed bandwidth, breaking the admission test. + * + * In order to prevent this misbehave, the Revisited CBS is used for + * constrained deadline tasks when a runtime overflow is detected. In the + * Revisited CBS, rather than replenishing & setting a new absolute deadline, + * the remaining runtime of the task is reduced to avoid runtime overflow. + * Please refer to the comments update_dl_revised_wakeup() function to find + * more about the Revised CBS rule. */ static void update_dl_entity(struct sched_dl_entity *dl_se, struct sched_dl_entity *pi_se) @@ -500,6 +571,14 @@ static void update_dl_entity(struct sche if (dl_time_before(dl_se->deadline, rq_clock(rq)) || dl_entity_overflow(dl_se, pi_se, rq_clock(rq))) { + + if (unlikely(!dl_is_implicit(dl_se) && + !dl_time_before(dl_se->deadline, rq_clock(rq)) && + !dl_se->dl_boosted)){ + update_dl_revised_wakeup(dl_se, rq); + return; + } + dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline; dl_se->runtime = pi_se->dl_runtime; } @@ -961,11 +1040,6 @@ static void dequeue_dl_entity(struct sch __dequeue_dl_entity(dl_se); } -static inline bool dl_is_constrained(struct sched_dl_entity *dl_se) -{ - return dl_se->dl_deadline < dl_se->dl_period; -} - static void enqueue_task_dl(struct rq *rq, struct task_struct *p, int flags) { struct task_struct *pi_task = rt_mutex_get_top_task(p); @@ -997,7 +1071,7 @@ static void enqueue_task_dl(struct rq *r * If that is the case, the task will be throttled and * the replenishment timer will be set to the next period. */ - if (!p->dl.dl_throttled && dl_is_constrained(&p->dl)) + if (!p->dl.dl_throttled && !dl_is_implicit(&p->dl)) dl_check_constrained_dl(&p->dl); /* Patches currently in stable-queue which might be from bristot(a)redhat.com are queue-4.9/sched-deadline-use-the-revised-wakeup-rule-for-suspending-constrained-dl-tasks.patch

7 years, 4 months

1
0
0 0

Patch "s390: move _text symbol to address higher than zero" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled s390: move _text symbol to address higher than zero to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: s390-move-_text-symbol-to-address-higher-than-zero.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: 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 @@ -31,8 +31,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 CPUIDLE_TEXT Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are queue-4.9/s390-move-_text-symbol-to-address-higher-than-zero.patch

7 years, 4 months

1
0
0 0

Patch "rtc: snvs: fix an incorrect check of return value" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtc: snvs: fix an incorrect check of return value to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtc-snvs-fix-an-incorrect-check-of-return-value.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: 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.9/cx25840-fix-unchecked-return-values.patch queue-4.9/usb-dwc3-keystone-check-return-value.patch queue-4.9/rtc-snvs-fix-an-incorrect-check-of-return-value.patch

7 years, 4 months

1
0
0 0

Patch "s390/dasd: fix hanging safe offline" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled s390/dasd: fix hanging safe offline to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: s390-dasd-fix-hanging-safe-offline.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Stefan Haberland <sth(a)linux.vnet.ibm.com> Date: Thu, 18 May 2017 13:24:45 +0200 Subject: s390/dasd: fix hanging safe offline From: Stefan Haberland <sth(a)linux.vnet.ibm.com> [ Upstream commit e8ac01555d9e464249e8bb122337d6d6e5589ccc ] The safe offline processing may hang forever because it waits for I/O which can not be started because of the offline flag that prevents new I/O from being started. Allow I/O to be started during safe offline processing because in this special case we take care that the queues are empty before throwing away the device. Signed-off-by: Stefan Haberland <sth(a)linux.vnet.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> --- drivers/s390/block/dasd.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/drivers/s390/block/dasd.c +++ b/drivers/s390/block/dasd.c @@ -1950,8 +1950,12 @@ static int __dasd_device_is_unusable(str { int mask = ~(DASD_STOPPED_DC_WAIT | DASD_UNRESUMED_PM); - if (test_bit(DASD_FLAG_OFFLINE, &device->flags)) { - /* dasd is being set offline. */ + if (test_bit(DASD_FLAG_OFFLINE, &device->flags) && + !test_bit(DASD_FLAG_SAFE_OFFLINE_RUNNING, &device->flags)) { + /* + * dasd is being set offline + * but it is no safe offline where we have to allow I/O + */ return 1; } if (device->stopped) { Patches currently in stable-queue which might be from sth(a)linux.vnet.ibm.com are queue-4.9/s390-dasd-fix-hanging-safe-offline.patch

7 years, 4 months

1
0
0 0

Patch "rtc: opal: Handle disabled TPO in opal_get_tpo_time()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtc: opal: Handle disabled TPO in opal_get_tpo_time() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtc-opal-handle-disabled-tpo-in-opal_get_tpo_time.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: 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.9/rtc-interface-validate-alarm-time-before-handling-rollover.patch queue-4.9/rtc-opal-handle-disabled-tpo-in-opal_get_tpo_time.patch

7 years, 4 months

1
0
0 0

Patch "rtc: interface: Validate alarm-time before handling rollover" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtc: interface: Validate alarm-time before handling rollover to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtc-interface-validate-alarm-time-before-handling-rollover.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: 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 @@ -227,6 +227,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); @@ -278,9 +285,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.9/rtc-interface-validate-alarm-time-before-handling-rollover.patch queue-4.9/rtc-opal-handle-disabled-tpo-in-opal_get_tpo_time.patch

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror