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

Patch "tty/serial: atmel: add new version check for usart" 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 tty/serial: atmel: add new version check for usart 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: tty-serial-atmel-add-new-version-check-for-usart.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 fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 Mon Sep 17 00:00:00 2001 From: Jonas Danielsson <jonas(a)orbital-systems.com> Date: Mon, 29 Jan 2018 12:39:15 +0100 Subject: tty/serial: atmel: add new version check for usart From: Jonas Danielsson <jonas(a)orbital-systems.com> commit fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 upstream. On our at91sam9260 based board the usart0 and usart1 ports report their versions (ATMEL_US_VERSION) as 0x10302. This version is not included in the current checks in the driver. Signed-off-by: Jonas Danielsson <jonas(a)orbital-systems.com> Acked-by: Richard Genoud <richard.genoud(a)gmail.com> Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/atmel_serial.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/tty/serial/atmel_serial.c +++ b/drivers/tty/serial/atmel_serial.c @@ -1643,6 +1643,7 @@ static void atmel_get_ip_name(struct uar switch (version) { case 0x302: case 0x10213: + case 0x10302: dev_dbg(port->dev, "This version is usart\n"); atmel_port->is_usart = true; break; Patches currently in stable-queue which might be from jonas(a)orbital-systems.com are queue-3.18/tty-serial-atmel-add-new-version-check-for-usart.patch

7 years, 3 months

1
0
0 0

Patch "serial: sh-sci: prevent lockup on full TTY buffers" 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 serial: sh-sci: prevent lockup on full TTY buffers 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: serial-sh-sci-prevent-lockup-on-full-tty-buffers.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 7842055bfce4bf0170d0f61df8b2add8399697be Mon Sep 17 00:00:00 2001 From: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com> Date: Thu, 15 Feb 2018 13:02:27 +0100 Subject: serial: sh-sci: prevent lockup on full TTY buffers From: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com> commit 7842055bfce4bf0170d0f61df8b2add8399697be upstream. When the TTY buffers fill up to the configured maximum, a system lockup occurs: [ 598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 598.825796] 0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1 [ 598.832577] (detected by 3, t=62517 jiffies, g=296, c=295, q=126) [ 598.838755] Task dump for CPU 0: [ 598.841977] swapper/0 R running task 0 0 0 0x00000022 [ 598.849023] Call trace: [ 598.851476] __switch_to+0x98/0xb0 [ 598.854870] (null) This can be prevented by doing a dummy read of the RX data register. This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0; reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms as well. Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com> Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Cc: stable <stable(a)vger.kernel.org> Tested-by: Nguyen Viet Dung <dung.nguyen.aj(a)renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/sh-sci.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -736,6 +736,8 @@ static void sci_receive_chars(struct uar /* Tell the rest of the system the news. New characters! */ tty_flip_buffer_push(tport); } else { + /* TTY buffers full; read from RX reg to prevent lockup */ + serial_port_in(port, SCxRDR); serial_port_in(port, SCxSR); /* dummy read */ serial_port_out(port, SCxSR, SCxSR_RDxF_CLEAR(port)); } Patches currently in stable-queue which might be from ulrich.hecht+renesas(a)gmail.com are queue-3.18/serial-sh-sci-prevent-lockup-on-full-tty-buffers.patch

7 years, 3 months

1
0
0 0

Patch "serial: 8250_pci: Add Brainboxes UC-260 4 port serial device" 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 serial: 8250_pci: Add Brainboxes UC-260 4 port serial device 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: serial-8250_pci-add-brainboxes-uc-260-4-port-serial-device.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 9f2068f35729948bde84d87a40d135015911345d Mon Sep 17 00:00:00 2001 From: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz> Date: Tue, 13 Feb 2018 15:04:46 +0100 Subject: serial: 8250_pci: Add Brainboxes UC-260 4 port serial device From: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz> commit 9f2068f35729948bde84d87a40d135015911345d upstream. Add PCI ids for two variants of Brainboxes UC-260 quad port PCI serial cards. Suggested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_pci.c | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/drivers/tty/serial/8250/8250_pci.c +++ b/drivers/tty/serial/8250/8250_pci.c @@ -4982,6 +4982,17 @@ static struct pci_device_id serial_pci_t PCI_ANY_ID, PCI_ANY_ID, 0, 0, /* 135a.0dc0 */ pbn_b2_4_115200 }, /* + * BrainBoxes UC-260 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0D21, + PCI_ANY_ID, PCI_ANY_ID, + PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00, + pbn_b2_4_115200 }, + { PCI_VENDOR_ID_INTASHIELD, 0x0E34, + PCI_ANY_ID, PCI_ANY_ID, + PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00, + pbn_b2_4_115200 }, + /* * Perle PCI-RAS cards */ { PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9030, Patches currently in stable-queue which might be from nikola.ciprich(a)linuxbox.cz are queue-3.18/serial-8250_pci-add-brainboxes-uc-260-4-port-serial-device.patch

7 years, 3 months

1
0
0 0

Patch "x86: Treat R_X86_64_PLT32 as R_X86_64_PC32" 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 x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 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: x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.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 b21ebf2fb4cde1618915a97cc773e287ff49173e Mon Sep 17 00:00:00 2001 From: "H.J. Lu" <hjl.tools(a)gmail.com> Date: Wed, 7 Feb 2018 14:20:09 -0800 Subject: x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 From: H.J. Lu <hjl.tools(a)gmail.com> commit b21ebf2fb4cde1618915a97cc773e287ff49173e upstream. On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared objects must use PIC PLT. To use PIC PLT, you need to load _GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on x86-64 since x86-64 uses PC-relative PLT. On x86-64, for 32-bit PC-relative branches, we can generate PLT32 relocation, instead of PC32 relocation, which can also be used as a marker for 32-bit PC-relative branches. Linker can always reduce PLT32 relocation to PC32 if function is defined locally. Local functions should use PC32 relocation. As far as Linux kernel is concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32 since Linux kernel doesn't use PLT. R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in binutils master branch which will become binutils 2.31. [ hjl is working on having better documentation on this all, but a few more notes from him: "PLT32 relocation is used as marker for PC-relative branches. Because of EBX, it looks odd to generate PLT32 relocation on i386 when EBX doesn't have GOT. As for symbol resolution, PLT32 and PC32 relocations are almost interchangeable. But when linker sees PLT32 relocation against a protected symbol, it can resolved locally at link-time since it is used on a branch instruction. Linker can't do that for PC32 relocation" but for the kernel use, the two are basically the same, and this commit gets things building and working with the current binutils master - Linus ] Signed-off-by: H.J. Lu <hjl.tools(a)gmail.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Matthias Kaehlcke <mka(a)chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/machine_kexec_64.c | 1 + arch/x86/kernel/module.c | 1 + arch/x86/tools/relocs.c | 3 +++ 3 files changed, 5 insertions(+) --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -524,6 +524,7 @@ int arch_kexec_apply_relocations_add(con goto overflow; break; case R_X86_64_PC32: + case R_X86_64_PLT32: value -= (u64)address; *(u32 *)location = value; break; --- a/arch/x86/kernel/module.c +++ b/arch/x86/kernel/module.c @@ -190,6 +190,7 @@ int apply_relocate_add(Elf64_Shdr *sechd goto overflow; break; case R_X86_64_PC32: + case R_X86_64_PLT32: if (*(u32 *)loc != 0) goto invalid_relocation; val -= (u64)loc; --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -769,9 +769,12 @@ static int do_reloc64(struct section *se break; case R_X86_64_PC32: + case R_X86_64_PLT32: /* * PC relative relocations don't need to be adjusted unless * referencing a percpu symbol. + * + * NB: R_X86_64_PLT32 can be treated as R_X86_64_PC32. */ if (is_percpu_sym(sym, symname)) add_reloc(&relocs32neg, offset); Patches currently in stable-queue which might be from hjl.tools(a)gmail.com are queue-4.9/x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch

7 years, 3 months

1
0
0 0

Patch "x86/module: Detect and skip invalid relocations" 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 x86/module: Detect and skip invalid relocations 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: x86-module-detect-and-skip-invalid-relocations.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 eda9cec4c9a12208a6f69fbe68f72a6311d50032 Mon Sep 17 00:00:00 2001 From: Josh Poimboeuf <jpoimboe(a)redhat.com> Date: Fri, 3 Nov 2017 07:58:54 -0500 Subject: x86/module: Detect and skip invalid relocations From: Josh Poimboeuf <jpoimboe(a)redhat.com> commit eda9cec4c9a12208a6f69fbe68f72a6311d50032 upstream. There have been some cases where external tooling (e.g., kpatch-build) creates a corrupt relocation which targets the wrong address. This is a silent failure which can corrupt memory in unexpected places. On x86, the bytes of data being overwritten by relocations are always initialized to zero beforehand. Use that knowledge to add sanity checks to detect such cases before they corrupt memory. Signed-off-by: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: jeyu(a)kernel.org Cc: live-patching(a)vger.kernel.org Link: http://lkml.kernel.org/r/37450d6c6225e54db107fba447ce9e56e5f758e9.150971355… [ Restructured the messages, as it's unclear whether the relocation or the target is corrupted. ] Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: Matthias Kaehlcke <mka(a)chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/module.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- a/arch/x86/kernel/module.c +++ b/arch/x86/kernel/module.c @@ -171,19 +171,27 @@ int apply_relocate_add(Elf64_Shdr *sechd case R_X86_64_NONE: break; case R_X86_64_64: + if (*(u64 *)loc != 0) + goto invalid_relocation; *(u64 *)loc = val; break; case R_X86_64_32: + if (*(u32 *)loc != 0) + goto invalid_relocation; *(u32 *)loc = val; if (val != *(u32 *)loc) goto overflow; break; case R_X86_64_32S: + if (*(s32 *)loc != 0) + goto invalid_relocation; *(s32 *)loc = val; if ((s64)val != *(s32 *)loc) goto overflow; break; case R_X86_64_PC32: + if (*(u32 *)loc != 0) + goto invalid_relocation; val -= (u64)loc; *(u32 *)loc = val; #if 0 @@ -199,6 +207,11 @@ int apply_relocate_add(Elf64_Shdr *sechd } return 0; +invalid_relocation: + pr_err("x86/modules: Skipping invalid relocation target, existing value is nonzero for type %d, loc %p, val %Lx\n", + (int)ELF64_R_TYPE(rel[i].r_info), loc, val); + return -ENOEXEC; + overflow: pr_err("overflow in relocation type %d val %Lx\n", (int)ELF64_R_TYPE(rel[i].r_info), val); Patches currently in stable-queue which might be from jpoimboe(a)redhat.com are queue-4.9/x86-boot-objtool-annotate-indirect-jump-in-secondary_startup_64.patch queue-4.9/x86-module-detect-and-skip-invalid-relocations.patch queue-4.9/nospec-include-asm-barrier.h-dependency.patch queue-4.9/x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool.patch queue-4.9/x86-paravirt-objtool-annotate-indirect-calls.patch queue-4.9/nospec-kill-array_index_nospec_mask_check.patch

7 years, 3 months

1
0
0 0

Patch "x86: Treat R_X86_64_PLT32 as R_X86_64_PC32" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b21ebf2fb4cde1618915a97cc773e287ff49173e Mon Sep 17 00:00:00 2001 From: "H.J. Lu" <hjl.tools(a)gmail.com> Date: Wed, 7 Feb 2018 14:20:09 -0800 Subject: x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 From: H.J. Lu <hjl.tools(a)gmail.com> commit b21ebf2fb4cde1618915a97cc773e287ff49173e upstream. On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared objects must use PIC PLT. To use PIC PLT, you need to load _GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on x86-64 since x86-64 uses PC-relative PLT. On x86-64, for 32-bit PC-relative branches, we can generate PLT32 relocation, instead of PC32 relocation, which can also be used as a marker for 32-bit PC-relative branches. Linker can always reduce PLT32 relocation to PC32 if function is defined locally. Local functions should use PC32 relocation. As far as Linux kernel is concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32 since Linux kernel doesn't use PLT. R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in binutils master branch which will become binutils 2.31. [ hjl is working on having better documentation on this all, but a few more notes from him: "PLT32 relocation is used as marker for PC-relative branches. Because of EBX, it looks odd to generate PLT32 relocation on i386 when EBX doesn't have GOT. As for symbol resolution, PLT32 and PC32 relocations are almost interchangeable. But when linker sees PLT32 relocation against a protected symbol, it can resolved locally at link-time since it is used on a branch instruction. Linker can't do that for PC32 relocation" but for the kernel use, the two are basically the same, and this commit gets things building and working with the current binutils master - Linus ] Signed-off-by: H.J. Lu <hjl.tools(a)gmail.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Matthias Kaehlcke <mka(a)chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/machine_kexec_64.c | 1 + arch/x86/kernel/module.c | 1 + arch/x86/tools/relocs.c | 3 +++ 3 files changed, 5 insertions(+) --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -519,6 +519,7 @@ int arch_kexec_apply_relocations_add(con goto overflow; break; case R_X86_64_PC32: + case R_X86_64_PLT32: value -= (u64)address; *(u32 *)location = value; break; --- a/arch/x86/kernel/module.c +++ b/arch/x86/kernel/module.c @@ -189,6 +189,7 @@ int apply_relocate_add(Elf64_Shdr *sechd goto overflow; break; case R_X86_64_PC32: + case R_X86_64_PLT32: if (*(u32 *)loc != 0) goto invalid_relocation; val -= (u64)loc; --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -769,9 +769,12 @@ static int do_reloc64(struct section *se break; case R_X86_64_PC32: + case R_X86_64_PLT32: /* * PC relative relocations don't need to be adjusted unless * referencing a percpu symbol. + * + * NB: R_X86_64_PLT32 can be treated as R_X86_64_PC32. */ if (is_percpu_sym(sym, symname)) add_reloc(&relocs32neg, offset); Patches currently in stable-queue which might be from hjl.tools(a)gmail.com are queue-4.4/x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch

7 years, 3 months

1
0
0 0

Patch "x86/module: Detect and skip invalid relocations" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/module: Detect and skip invalid relocations to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-module-detect-and-skip-invalid-relocations.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From eda9cec4c9a12208a6f69fbe68f72a6311d50032 Mon Sep 17 00:00:00 2001 From: Josh Poimboeuf <jpoimboe(a)redhat.com> Date: Fri, 3 Nov 2017 07:58:54 -0500 Subject: x86/module: Detect and skip invalid relocations From: Josh Poimboeuf <jpoimboe(a)redhat.com> commit eda9cec4c9a12208a6f69fbe68f72a6311d50032 upstream. There have been some cases where external tooling (e.g., kpatch-build) creates a corrupt relocation which targets the wrong address. This is a silent failure which can corrupt memory in unexpected places. On x86, the bytes of data being overwritten by relocations are always initialized to zero beforehand. Use that knowledge to add sanity checks to detect such cases before they corrupt memory. Signed-off-by: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: jeyu(a)kernel.org Cc: live-patching(a)vger.kernel.org Link: http://lkml.kernel.org/r/37450d6c6225e54db107fba447ce9e56e5f758e9.150971355… [ Restructured the messages, as it's unclear whether the relocation or the target is corrupted. ] Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: Matthias Kaehlcke <mka(a)chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/module.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- a/arch/x86/kernel/module.c +++ b/arch/x86/kernel/module.c @@ -170,19 +170,27 @@ int apply_relocate_add(Elf64_Shdr *sechd case R_X86_64_NONE: break; case R_X86_64_64: + if (*(u64 *)loc != 0) + goto invalid_relocation; *(u64 *)loc = val; break; case R_X86_64_32: + if (*(u32 *)loc != 0) + goto invalid_relocation; *(u32 *)loc = val; if (val != *(u32 *)loc) goto overflow; break; case R_X86_64_32S: + if (*(s32 *)loc != 0) + goto invalid_relocation; *(s32 *)loc = val; if ((s64)val != *(s32 *)loc) goto overflow; break; case R_X86_64_PC32: + if (*(u32 *)loc != 0) + goto invalid_relocation; val -= (u64)loc; *(u32 *)loc = val; #if 0 @@ -198,6 +206,11 @@ int apply_relocate_add(Elf64_Shdr *sechd } return 0; +invalid_relocation: + pr_err("x86/modules: Skipping invalid relocation target, existing value is nonzero for type %d, loc %p, val %Lx\n", + (int)ELF64_R_TYPE(rel[i].r_info), loc, val); + return -ENOEXEC; + overflow: pr_err("overflow in relocation type %d val %Lx\n", (int)ELF64_R_TYPE(rel[i].r_info), val); Patches currently in stable-queue which might be from jpoimboe(a)redhat.com are queue-4.4/x86-module-detect-and-skip-invalid-relocations.patch queue-4.4/nospec-include-asm-barrier.h-dependency.patch

7 years, 3 months

1
0
0 0

Patch "x86: Treat R_X86_64_PLT32 as R_X86_64_PC32" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch and it can be found in the queue-4.15 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 b21ebf2fb4cde1618915a97cc773e287ff49173e Mon Sep 17 00:00:00 2001 From: "H.J. Lu" <hjl.tools(a)gmail.com> Date: Wed, 7 Feb 2018 14:20:09 -0800 Subject: x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 From: H.J. Lu <hjl.tools(a)gmail.com> commit b21ebf2fb4cde1618915a97cc773e287ff49173e upstream. On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared objects must use PIC PLT. To use PIC PLT, you need to load _GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on x86-64 since x86-64 uses PC-relative PLT. On x86-64, for 32-bit PC-relative branches, we can generate PLT32 relocation, instead of PC32 relocation, which can also be used as a marker for 32-bit PC-relative branches. Linker can always reduce PLT32 relocation to PC32 if function is defined locally. Local functions should use PC32 relocation. As far as Linux kernel is concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32 since Linux kernel doesn't use PLT. R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in binutils master branch which will become binutils 2.31. [ hjl is working on having better documentation on this all, but a few more notes from him: "PLT32 relocation is used as marker for PC-relative branches. Because of EBX, it looks odd to generate PLT32 relocation on i386 when EBX doesn't have GOT. As for symbol resolution, PLT32 and PC32 relocations are almost interchangeable. But when linker sees PLT32 relocation against a protected symbol, it can resolved locally at link-time since it is used on a branch instruction. Linker can't do that for PC32 relocation" but for the kernel use, the two are basically the same, and this commit gets things building and working with the current binutils master - Linus ] Signed-off-by: H.J. Lu <hjl.tools(a)gmail.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Matthias Kaehlcke <mka(a)chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/machine_kexec_64.c | 1 + arch/x86/kernel/module.c | 1 + arch/x86/tools/relocs.c | 3 +++ 3 files changed, 5 insertions(+) --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -542,6 +542,7 @@ int arch_kexec_apply_relocations_add(con goto overflow; break; case R_X86_64_PC32: + case R_X86_64_PLT32: value -= (u64)address; *(u32 *)location = value; break; --- a/arch/x86/kernel/module.c +++ b/arch/x86/kernel/module.c @@ -191,6 +191,7 @@ int apply_relocate_add(Elf64_Shdr *sechd goto overflow; break; case R_X86_64_PC32: + case R_X86_64_PLT32: if (*(u32 *)loc != 0) goto invalid_relocation; val -= (u64)loc; --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -770,9 +770,12 @@ static int do_reloc64(struct section *se break; case R_X86_64_PC32: + case R_X86_64_PLT32: /* * PC relative relocations don't need to be adjusted unless * referencing a percpu symbol. + * + * NB: R_X86_64_PLT32 can be treated as R_X86_64_PC32. */ if (is_percpu_sym(sym, symname)) add_reloc(&relocs32neg, offset); Patches currently in stable-queue which might be from hjl.tools(a)gmail.com are queue-4.15/x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch

7 years, 3 months

1
0
0 0

Patch "x86: Treat R_X86_64_PLT32 as R_X86_64_PC32" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b21ebf2fb4cde1618915a97cc773e287ff49173e Mon Sep 17 00:00:00 2001 From: "H.J. Lu" <hjl.tools(a)gmail.com> Date: Wed, 7 Feb 2018 14:20:09 -0800 Subject: x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 From: H.J. Lu <hjl.tools(a)gmail.com> commit b21ebf2fb4cde1618915a97cc773e287ff49173e upstream. On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared objects must use PIC PLT. To use PIC PLT, you need to load _GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on x86-64 since x86-64 uses PC-relative PLT. On x86-64, for 32-bit PC-relative branches, we can generate PLT32 relocation, instead of PC32 relocation, which can also be used as a marker for 32-bit PC-relative branches. Linker can always reduce PLT32 relocation to PC32 if function is defined locally. Local functions should use PC32 relocation. As far as Linux kernel is concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32 since Linux kernel doesn't use PLT. R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in binutils master branch which will become binutils 2.31. [ hjl is working on having better documentation on this all, but a few more notes from him: "PLT32 relocation is used as marker for PC-relative branches. Because of EBX, it looks odd to generate PLT32 relocation on i386 when EBX doesn't have GOT. As for symbol resolution, PLT32 and PC32 relocations are almost interchangeable. But when linker sees PLT32 relocation against a protected symbol, it can resolved locally at link-time since it is used on a branch instruction. Linker can't do that for PC32 relocation" but for the kernel use, the two are basically the same, and this commit gets things building and working with the current binutils master - Linus ] Signed-off-by: H.J. Lu <hjl.tools(a)gmail.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Matthias Kaehlcke <mka(a)chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/machine_kexec_64.c | 1 + arch/x86/kernel/module.c | 1 + arch/x86/tools/relocs.c | 3 +++ 3 files changed, 5 insertions(+) --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -542,6 +542,7 @@ int arch_kexec_apply_relocations_add(con goto overflow; break; case R_X86_64_PC32: + case R_X86_64_PLT32: value -= (u64)address; *(u32 *)location = value; break; --- a/arch/x86/kernel/module.c +++ b/arch/x86/kernel/module.c @@ -191,6 +191,7 @@ int apply_relocate_add(Elf64_Shdr *sechd goto overflow; break; case R_X86_64_PC32: + case R_X86_64_PLT32: if (*(u32 *)loc != 0) goto invalid_relocation; val -= (u64)loc; --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -770,9 +770,12 @@ static int do_reloc64(struct section *se break; case R_X86_64_PC32: + case R_X86_64_PLT32: /* * PC relative relocations don't need to be adjusted unless * referencing a percpu symbol. + * + * NB: R_X86_64_PLT32 can be treated as R_X86_64_PC32. */ if (is_percpu_sym(sym, symname)) add_reloc(&relocs32neg, offset); Patches currently in stable-queue which might be from hjl.tools(a)gmail.com are queue-4.14/x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch

7 years, 3 months

1
0
0 0

Patch "x86: Treat R_X86_64_PLT32 as R_X86_64_PC32" 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 x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 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: x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.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 b21ebf2fb4cde1618915a97cc773e287ff49173e Mon Sep 17 00:00:00 2001 From: "H.J. Lu" <hjl.tools(a)gmail.com> Date: Wed, 7 Feb 2018 14:20:09 -0800 Subject: x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 From: H.J. Lu <hjl.tools(a)gmail.com> commit b21ebf2fb4cde1618915a97cc773e287ff49173e upstream. On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared objects must use PIC PLT. To use PIC PLT, you need to load _GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on x86-64 since x86-64 uses PC-relative PLT. On x86-64, for 32-bit PC-relative branches, we can generate PLT32 relocation, instead of PC32 relocation, which can also be used as a marker for 32-bit PC-relative branches. Linker can always reduce PLT32 relocation to PC32 if function is defined locally. Local functions should use PC32 relocation. As far as Linux kernel is concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32 since Linux kernel doesn't use PLT. R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in binutils master branch which will become binutils 2.31. [ hjl is working on having better documentation on this all, but a few more notes from him: "PLT32 relocation is used as marker for PC-relative branches. Because of EBX, it looks odd to generate PLT32 relocation on i386 when EBX doesn't have GOT. As for symbol resolution, PLT32 and PC32 relocations are almost interchangeable. But when linker sees PLT32 relocation against a protected symbol, it can resolved locally at link-time since it is used on a branch instruction. Linker can't do that for PC32 relocation" but for the kernel use, the two are basically the same, and this commit gets things building and working with the current binutils master - Linus ] Signed-off-by: H.J. Lu <hjl.tools(a)gmail.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Matthias Kaehlcke <mka(a)chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/machine_kexec_64.c | 1 + arch/x86/kernel/module.c | 1 + arch/x86/tools/relocs.c | 3 +++ 3 files changed, 5 insertions(+) --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -516,6 +516,7 @@ int arch_kexec_apply_relocations_add(con goto overflow; break; case R_X86_64_PC32: + case R_X86_64_PLT32: value -= (u64)address; *(u32 *)location = value; break; --- a/arch/x86/kernel/module.c +++ b/arch/x86/kernel/module.c @@ -186,6 +186,7 @@ int apply_relocate_add(Elf64_Shdr *sechd goto overflow; break; case R_X86_64_PC32: + case R_X86_64_PLT32: if (*(u32 *)loc != 0) goto invalid_relocation; val -= (u64)loc; --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -769,9 +769,12 @@ static int do_reloc64(struct section *se break; case R_X86_64_PC32: + case R_X86_64_PLT32: /* * PC relative relocations don't need to be adjusted unless * referencing a percpu symbol. + * + * NB: R_X86_64_PLT32 can be treated as R_X86_64_PC32. */ if (is_percpu_sym(sym, symname)) add_reloc(&relocs32neg, offset); Patches currently in stable-queue which might be from hjl.tools(a)gmail.com are queue-3.18/x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch

7 years, 3 months

1
0
0 0

Patch "x86/module: Detect and skip invalid relocations" 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 x86/module: Detect and skip invalid relocations 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: x86-module-detect-and-skip-invalid-relocations.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 eda9cec4c9a12208a6f69fbe68f72a6311d50032 Mon Sep 17 00:00:00 2001 From: Josh Poimboeuf <jpoimboe(a)redhat.com> Date: Fri, 3 Nov 2017 07:58:54 -0500 Subject: x86/module: Detect and skip invalid relocations From: Josh Poimboeuf <jpoimboe(a)redhat.com> commit eda9cec4c9a12208a6f69fbe68f72a6311d50032 upstream. There have been some cases where external tooling (e.g., kpatch-build) creates a corrupt relocation which targets the wrong address. This is a silent failure which can corrupt memory in unexpected places. On x86, the bytes of data being overwritten by relocations are always initialized to zero beforehand. Use that knowledge to add sanity checks to detect such cases before they corrupt memory. Signed-off-by: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: jeyu(a)kernel.org Cc: live-patching(a)vger.kernel.org Link: http://lkml.kernel.org/r/37450d6c6225e54db107fba447ce9e56e5f758e9.150971355… [ Restructured the messages, as it's unclear whether the relocation or the target is corrupted. ] Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: Matthias Kaehlcke <mka(a)chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/module.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- a/arch/x86/kernel/module.c +++ b/arch/x86/kernel/module.c @@ -167,19 +167,27 @@ int apply_relocate_add(Elf64_Shdr *sechd case R_X86_64_NONE: break; case R_X86_64_64: + if (*(u64 *)loc != 0) + goto invalid_relocation; *(u64 *)loc = val; break; case R_X86_64_32: + if (*(u32 *)loc != 0) + goto invalid_relocation; *(u32 *)loc = val; if (val != *(u32 *)loc) goto overflow; break; case R_X86_64_32S: + if (*(s32 *)loc != 0) + goto invalid_relocation; *(s32 *)loc = val; if ((s64)val != *(s32 *)loc) goto overflow; break; case R_X86_64_PC32: + if (*(u32 *)loc != 0) + goto invalid_relocation; val -= (u64)loc; *(u32 *)loc = val; #if 0 @@ -195,6 +203,11 @@ int apply_relocate_add(Elf64_Shdr *sechd } return 0; +invalid_relocation: + pr_err("x86/modules: Skipping invalid relocation target, existing value is nonzero for type %d, loc %p, val %Lx\n", + (int)ELF64_R_TYPE(rel[i].r_info), loc, val); + return -ENOEXEC; + overflow: pr_err("overflow in relocation type %d val %Lx\n", (int)ELF64_R_TYPE(rel[i].r_info), val); Patches currently in stable-queue which might be from jpoimboe(a)redhat.com are queue-3.18/x86-module-detect-and-skip-invalid-relocations.patch

7 years, 3 months

1
0
0 0

Add patch "x86: Treat R_X86_64_PLT32 as R_X86_64_PC32" to stable?

by Matthias Kaehlcke

Hi Greg, The below patch recently landed in Linus' tree: commit b21ebf2fb4cde1618915a97cc773e287ff49173e Author: H.J. Lu <hjl.tools(a)gmail.com> Date: Wed Feb 7 14:20:09 2018 -0800 x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared objects must use PIC PLT. To use PIC PLT, you need to load _GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on x86-64 since x86-64 uses PC-relative PLT. On x86-64, for 32-bit PC-relative branches, we can generate PLT32 relocation, instead of PC32 relocation, which can also be used as a marker for 32-bit PC-relative branches. Linker can always reduce PLT32 relocation to PC32 if function is defined locally. Local functions should use PC32 relocation. As far as Linux kernel is concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32 since Linux kernel doesn't use PLT. R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in binutils master branch which will become binutils 2.31. [ hjl is working on having better documentation on this all, but a few more notes from him: "PLT32 relocation is used as marker for PC-relative branches. Because of EBX, it looks odd to generate PLT32 relocation on i386 when EBX doesn't have GOT. As for symbol resolution, PLT32 and PC32 relocations are almost interchangeable. But when linker sees PLT32 relocation against a protected symbol, it can resolved locally at link-time since it is used on a branch instruction. Linker can't do that for PC32 relocation" but for the kernel use, the two are basically the same, and this commit gets things building and working with the current binutils master - Linus ] Signed-off-by: H.J. Lu <hjl.tools(a)gmail.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> The commit message mentions that "R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in binutils master branch which will become binutils 2.31." This probably means that builds of older kernels could fail with binutils >= 2.31 and that the patch should be included in stable. FYI: for pre-v4.14 kernel you might also want to include the below patch. It isn't strictly needed, but is trivial and including it avoids a conflict. commit eda9cec4c9a12208a6f69fbe68f72a6311d50032 Author: Josh Poimboeuf <jpoimboe(a)redhat.com> Date: Fri Nov 3 07:58:54 2017 -0500 x86/module: Detect and skip invalid relocations Thanks Matthias

7 years, 3 months

2
1
0 0

Re: [PATCH AUTOSEL for 4.14 065/110] led: core: Fix brightness setting when setting delay_off=0

by Jacek Anaszewski

On 03/13/2018 02:27 PM, Pavel Machek wrote: > Hi! > >>>> At least 7b6af2c531 ("leds: core: Fix regression caused by commit >>>> 2b83ff96f51d") is missing, causing visible regressions (LEDs not working at >>>> all) on some OpenWrt devices. This was fixed in 4.4.121 by reverting the >>>> offending commit, but if I followed the discussion correctly, 4.9 should >>>> get the follow-up commit 7b6af2c531 instead (like 4.14 already did). >>>> >>>> Jacek's mail I replied to mentions that eb1610b4c273 ("led: core: Fix >>>> blink_brightness setting race") should be included in 4.9 as well, but I >>>> don't know the impact of the issue it fixes. >>> >>> It doesn't fix any reported issue, but is just an improvement >>> aiming at preventing potential races while changing blink brightness. >>> >>> After taking closer look it turns out that for the patches in question >>> to apply cleanly we need in 4.9 also a patch which introduces atomic >>> bit fields for blink flags. >>> >>> Effectively, here is the list of patches required in 4.9 stable: >>> >>> Revert "led: core: Fix brightness setting when setting delay_off=0" >>> >>> followed by: >>> >>> a9c6ce57ec ("led: core: Use atomic bit-field for the blink-flags") >>> eb1610b4c2 ("led: core: Fix blink_brightness setting race") >>> 2b83ff96f5 ("led: core: Fix brightness setting when setting delay_off=0") >>> 7b6af2c531 ("leds: core: Fix regression caused by commit 2b83ff96f51d") >> >> Odd, I just got another report that the 4.9.87 release fixed some >> reported LED issues, so why do I need all of these? Because 2b83ff96f5 introduces another bug, fixed in 7b6af2c531. 7b6af2c531 in turn uses atomic blink flags introduced in a9c6ce57ec. eb1610b4c2 fixes theoretical races, actually we can do without it in stable. In order to avoid applying patch a9c6ce57ec, we could come up with the below change which does exactly what 7b6af2c531 intended, but without atomic blink flags, which are irrelevant for this bug. diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c index 3bce448..454ed4d 100644 --- a/drivers/leds/led-core.c +++ b/drivers/leds/led-core.c @@ -188,6 +188,7 @@ void led_blink_set(struct led_classdev *led_cdev, { del_timer_sync(&led_cdev->blink_timer); + led_cdev->flags &= ~LED_BLINK_SW; led_cdev->flags &= ~LED_BLINK_ONESHOT; led_cdev->flags &= ~LED_BLINK_ONESHOT_STOP; I can submit it to stable if it is preferred. In every case tha patch 2b83ff96f5 needs to be reverted beforehand, since otherwise none of the discussed patches will apply cleanly (besides the aforementioned reasoning it has a truncated commit message). >> Should I just revert the single 2b83ff96f51d commit here instead? > > I believe so, yes. > > I'm not aware of any _really bad_ issues with LED subsystem in > 4.9. Take a look at changelog of > 2b83ff96f51d0b039c4561b9f95c824d7bddb85c -- it fixes rather > theoretical issue; user can reproduce it by hand in shell, but, > well... don't do it then. Greg mentioned that 4.9.87 release fixed some LED issue for someone, and it was the only LED related patch in that release. > The rest of fixes ... fix some more theoretical races. I don't think > it is -stable material, as I pointed out before. -- Best regards, Jacek Anaszewski

7 years, 3 months

2
1
0 0

Patch "Revert "ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux"" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Revert "ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux" to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: revert-arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 669f2dc901fbac917e494d392cfcc0b8db764947 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Date: Fri, 16 Mar 2018 13:39:47 +0100 Subject: Revert "ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux" From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> This reverts commit c86bfc7b7b01c4b98c29a39bd60e61fa8e337ebf which was commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream. The backport merged incorrectly, so I'm dropping it. Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> Cc: Adam Ford <aford173(a)gmail.com> Cc: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 -------- 1 file changed, 8 deletions(-) --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi @@ -90,8 +90,6 @@ }; &i2c1 { - pinctrl-names = "default"; - pinctrl-0 = <&i2c1_pins>; clock-frequency = <2600000>; twl: twl@48 { @@ -148,12 +146,6 @@ OMAP3630_CORE2_IOPAD(0x25da, PIN_INPUT_PULLUP | MUX_MODE2) /* etk_ctl.sdmmc3_cmd */ >; }; - i2c1_pins: pinmux_i2c1_pins { - pinctrl-single,pins = < - OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */ - OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */ - >; - }; }; #include "twl4030.dtsi" Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are queue-4.4/tc358743-fix-register-i2c_rd-wr-function-fix.patch queue-4.4/netfilter-add-back-stackpointer-size-checks.patch queue-4.4/watchdog-hpwdt-fix-unused-variable-warning.patch queue-4.4/scsi-qla2xxx-fix-null-pointer-crash-due-to-active-timer-for-abts.patch queue-4.4/watchdog-hpwdt-smbios-check.patch queue-4.4/drm-amdgpu-notify-sbios-device-ready-before-send-request.patch queue-4.4/workqueue-allow-retrieval-of-current-task-s-work-struct.patch queue-4.4/loop-fix-lost-writes-caused-by-missing-flag.patch queue-4.4/rdma-ucma-limit-possible-option-size.patch queue-4.4/alsa-seq-don-t-allow-resizing-pool-in-use.patch queue-4.4/netfilter-x_tables-pack-percpu-counter-allocations.patch queue-4.4/revert-arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch queue-4.4/arm-omap2-hide-omap3_save_secure_ram-on-non-omap3-builds.patch queue-4.4/x86-mce-serialize-sysfs-changes.patch queue-4.4/alsa-hda-add-dock-and-led-support-for-hp-probook-640-g2.patch queue-4.4/netfilter-idletimer-be-syzkaller-friendly.patch queue-4.4/netfilter-use-skb_to_full_sk-in-ip_route_me_harder.patch queue-4.4/drm-radeon-fix-kv-harvesting.patch queue-4.4/ubi-fix-race-condition-between-ubi-volume-creation-and-udev.patch queue-4.4/drm-radeon-fix-deadlock-on-runtime-suspend.patch queue-4.4/scsi-qla2xxx-replace-fcport-alloc-with-qla2x00_alloc_fcport.patch queue-4.4/alsa-hda-add-dock-and-led-support-for-hp-elitebook-820-g3.patch queue-4.4/watchdog-hpwdt-check-source-of-nmi.patch queue-4.4/netfilter-ipv6-fix-use-after-free-write-in-nf_nat_ipv6_manip_pkt.patch queue-4.4/mips-bmips-do-not-mask-ipis-during-suspend.patch queue-4.4/netfilter-x_tables-pass-xt_counters-struct-instead-of-packet-counter.patch queue-4.4/rdma-ucma-check-that-user-doesn-t-overflow-qp-state.patch queue-4.4/nospec-include-asm-barrier.h-dependency.patch queue-4.4/netfilter-ebtables-config_compat-don-t-trust-userland-offsets.patch queue-4.4/drm-amdgpu-fix-deadlock-on-runtime-suspend.patch queue-4.4/alsa-seq-more-protection-for-concurrent-write-and-ioctl-races.patch queue-4.4/nfs-fix-an-incorrect-type-in-struct-nfs_direct_req.patch queue-4.4/netfilter-nfnetlink_queue-fix-timestamp-attribute.patch queue-4.4/mips-ath25-check-for-kzalloc-allocation-failure.patch queue-4.4/bcache-don-t-attach-backing-with-duplicate-uuid.patch queue-4.4/kbuild-handle-builtin-dtb-file-names-containing-hyphens.patch queue-4.4/drm-allow-determining-if-current-task-is-output-poll-worker.patch queue-4.4/netfilter-bridge-ebt_among-add-missing-match-size-checks.patch queue-4.4/netfilter-nat-cope-with-negative-port-range.patch queue-4.4/netfilter-x_tables-fix-missing-timer-initialization-in-xt_led.patch queue-4.4/ext4-inplace-xattr-block-update-fails-to-deduplicate-blocks.patch queue-4.4/input-tca8418_keypad-remove-double-read-of-key-event-register.patch queue-4.4/alsa-hda-realtek-fix-dock-line-out-volume-on-dell-precision-7520.patch queue-4.4/drm-amdgpu-fix-kv-harvesting.patch queue-4.4/drm-nouveau-fix-deadlock-on-runtime-suspend.patch queue-4.4/input-matrix_keypad-fix-race-when-disabling-interrupts.patch queue-4.4/mips-octeon-irq-check-for-null-return-on-kzalloc-allocation.patch queue-4.4/netfilter-x_tables-pass-xt_counters-struct-to-counter-allocator.patch queue-4.4/rdma-mlx5-fix-integer-overflow-while-resizing-cq.patch

7 years, 3 months

1
0
0 0

Patch "net: phy: fix resume handling" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: phy: fix resume handling to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-phy-fix-resume-handling.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Russell King <rmk+kernel(a)armlinux.org.uk> Date: Tue, 12 Dec 2017 10:45:36 +0000 Subject: net: phy: fix resume handling From: Russell King <rmk+kernel(a)armlinux.org.uk> [ Upstream commit f5e64032a799d4f54decc7eb6aafcdffb67f9ad9 ] When a PHY has the BMCR_PDOWN bit set, it may decide to ignore writes to other registers, or reset the registers to power-on defaults. Micrel PHYs do this for their interrupt registers. The current structure of phylib tries to enable interrupts before resuming (and releasing) the BMCR_PDOWN bit. This fails, causing Micrel PHYs to stop working after a suspend/resume sequence if they are using interrupts. Fix this by ensuring that the PHY driver resume methods do not take the phydev->lock mutex themselves, but the callers of phy_resume() take that lock. This then allows us to move the call to phy_resume() before we enable interrupts in phy_start(). Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew(a)lunn.ch> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/phy/at803x.c | 4 ---- drivers/net/phy/phy.c | 9 +++------ drivers/net/phy/phy_device.c | 10 ++++++---- 3 files changed, 9 insertions(+), 14 deletions(-) --- a/drivers/net/phy/at803x.c +++ b/drivers/net/phy/at803x.c @@ -239,14 +239,10 @@ static int at803x_resume(struct phy_devi { int value; - mutex_lock(&phydev->lock); - value = phy_read(phydev, MII_BMCR); value &= ~(BMCR_PDOWN | BMCR_ISOLATE); phy_write(phydev, MII_BMCR, value); - mutex_unlock(&phydev->lock); - return 0; } --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -828,7 +828,6 @@ EXPORT_SYMBOL(phy_stop); */ void phy_start(struct phy_device *phydev) { - bool do_resume = false; int err = 0; mutex_lock(&phydev->lock); @@ -841,6 +840,9 @@ void phy_start(struct phy_device *phydev phydev->state = PHY_UP; break; case PHY_HALTED: + /* if phy was suspended, bring the physical link up again */ + phy_resume(phydev); + /* make sure interrupts are re-enabled for the PHY */ if (phydev->irq != PHY_POLL) { err = phy_enable_interrupts(phydev); @@ -849,17 +851,12 @@ void phy_start(struct phy_device *phydev } phydev->state = PHY_RESUMING; - do_resume = true; break; default: break; } mutex_unlock(&phydev->lock); - /* if phy was suspended, bring the physical link up again */ - if (do_resume) - phy_resume(phydev); - phy_trigger_machine(phydev, true); } EXPORT_SYMBOL(phy_start); --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -135,7 +135,9 @@ static int mdio_bus_phy_resume(struct de if (!mdio_bus_phy_may_suspend(phydev)) goto no_resume; + mutex_lock(&phydev->lock); ret = phy_resume(phydev); + mutex_unlock(&phydev->lock); if (ret < 0) return ret; @@ -1026,7 +1028,9 @@ int phy_attach_direct(struct net_device if (err) goto error; + mutex_lock(&phydev->lock); phy_resume(phydev); + mutex_unlock(&phydev->lock); phy_led_triggers_register(phydev); return err; @@ -1157,6 +1161,8 @@ int phy_resume(struct phy_device *phydev struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver); int ret = 0; + WARN_ON(!mutex_is_locked(&phydev->lock)); + if (phydev->drv && phydrv->resume) ret = phydrv->resume(phydev); @@ -1639,13 +1645,9 @@ int genphy_resume(struct phy_device *phy { int value; - mutex_lock(&phydev->lock); - value = phy_read(phydev, MII_BMCR); phy_write(phydev, MII_BMCR, value & ~BMCR_PDOWN); - mutex_unlock(&phydev->lock); - return 0; } EXPORT_SYMBOL(genphy_resume); Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are queue-4.14/arm-8731-1-fix-csum_partial_copy_from_user-stack-mismatch.patch queue-4.14/net-phy-fix-resume-handling.patch

7 years, 3 months

3
3
0 0

Patch "net: phy: Restore phy_resume() locking assumption" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: phy: Restore phy_resume() locking assumption to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-phy-restore-phy_resume-locking-assumption.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 9c2c2e62df3fa30fb13fbeb7512a4eede729383b Mon Sep 17 00:00:00 2001 From: Andrew Lunn <andrew(a)lunn.ch> Date: Tue, 27 Feb 2018 01:56:06 +0100 Subject: net: phy: Restore phy_resume() locking assumption From: Andrew Lunn <andrew(a)lunn.ch> commit 9c2c2e62df3fa30fb13fbeb7512a4eede729383b upstream. commit f5e64032a799 ("net: phy: fix resume handling") changes the locking semantics for phy_resume() such that the caller now needs to hold the phy mutex. Not all call sites were adopted to this new semantic, resulting in warnings from the added WARN_ON(!mutex_is_locked(&phydev->lock)). Rather than change the semantics, add a __phy_resume() and restore the old behavior of phy_resume(). Reported-by: Heiner Kallweit <hkallweit1(a)gmail.com> Fixes: f5e64032a799 ("net: phy: fix resume handling") Signed-off-by: Andrew Lunn <andrew(a)lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/phy/phy.c | 2 +- drivers/net/phy/phy_device.c | 18 +++++++++++++----- include/linux/phy.h | 1 + 3 files changed, 15 insertions(+), 6 deletions(-) --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -841,7 +841,7 @@ void phy_start(struct phy_device *phydev break; case PHY_HALTED: /* if phy was suspended, bring the physical link up again */ - phy_resume(phydev); + __phy_resume(phydev); /* make sure interrupts are re-enabled for the PHY */ if (phy_interrupt_is_valid(phydev)) { --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -135,9 +135,7 @@ static int mdio_bus_phy_resume(struct de if (!mdio_bus_phy_may_suspend(phydev)) goto no_resume; - mutex_lock(&phydev->lock); ret = phy_resume(phydev); - mutex_unlock(&phydev->lock); if (ret < 0) return ret; @@ -1028,9 +1026,7 @@ int phy_attach_direct(struct net_device if (err) goto error; - mutex_lock(&phydev->lock); phy_resume(phydev); - mutex_unlock(&phydev->lock); phy_led_triggers_register(phydev); return err; @@ -1156,7 +1152,7 @@ int phy_suspend(struct phy_device *phyde } EXPORT_SYMBOL(phy_suspend); -int phy_resume(struct phy_device *phydev) +int __phy_resume(struct phy_device *phydev) { struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver); int ret = 0; @@ -1173,6 +1169,18 @@ int phy_resume(struct phy_device *phydev return ret; } +EXPORT_SYMBOL(__phy_resume); + +int phy_resume(struct phy_device *phydev) +{ + int ret; + + mutex_lock(&phydev->lock); + ret = __phy_resume(phydev); + mutex_unlock(&phydev->lock); + + return ret; +} EXPORT_SYMBOL(phy_resume); int phy_loopback(struct phy_device *phydev, bool enable) --- a/include/linux/phy.h +++ b/include/linux/phy.h @@ -817,6 +817,7 @@ void phy_device_remove(struct phy_device int phy_init_hw(struct phy_device *phydev); int phy_suspend(struct phy_device *phydev); int phy_resume(struct phy_device *phydev); +int __phy_resume(struct phy_device *phydev); int phy_loopback(struct phy_device *phydev, bool enable); struct phy_device *phy_attach(struct net_device *dev, const char *bus_id, phy_interface_t interface); Patches currently in stable-queue which might be from andrew(a)lunn.ch are queue-4.14/net-phy-fix-resume-handling.patch queue-4.14/net-phy-restore-phy_resume-locking-assumption.patch

7 years, 3 months

1
0
0 0

Patch "[PATCH] net: phy: fix resume handling" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled [PATCH] net: phy: fix resume handling to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-phy-fix-resume-handling.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6aae7a6232c6444941de8e5a1e0cc42442ab9bce Mon Sep 17 00:00:00 2001 From: Russell King <rmk+kernel(a)armlinux.org.uk> Date: Tue, 12 Dec 2017 10:45:36 +0000 Subject: [PATCH] net: phy: fix resume handling From: Russell King <rmk+kernel(a)armlinux.org.uk> [ Upstream commit f5e64032a799d4f54decc7eb6aafcdffb67f9ad9 ] When a PHY has the BMCR_PDOWN bit set, it may decide to ignore writes to other registers, or reset the registers to power-on defaults. Micrel PHYs do this for their interrupt registers. The current structure of phylib tries to enable interrupts before resuming (and releasing) the BMCR_PDOWN bit. This fails, causing Micrel PHYs to stop working after a suspend/resume sequence if they are using interrupts. Fix this by ensuring that the PHY driver resume methods do not take the phydev->lock mutex themselves, but the callers of phy_resume() take that lock. This then allows us to move the call to phy_resume() before we enable interrupts in phy_start(). Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew(a)lunn.ch> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/phy/at803x.c | 4 ---- drivers/net/phy/phy.c | 9 +++------ drivers/net/phy/phy_device.c | 10 ++++++---- 3 files changed, 9 insertions(+), 14 deletions(-) --- a/drivers/net/phy/at803x.c +++ b/drivers/net/phy/at803x.c @@ -239,14 +239,10 @@ static int at803x_resume(struct phy_devi { int value; - mutex_lock(&phydev->lock); - value = phy_read(phydev, MII_BMCR); value &= ~(BMCR_PDOWN | BMCR_ISOLATE); phy_write(phydev, MII_BMCR, value); - mutex_unlock(&phydev->lock); - return 0; } --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -828,7 +828,6 @@ EXPORT_SYMBOL(phy_stop); */ void phy_start(struct phy_device *phydev) { - bool do_resume = false; int err = 0; mutex_lock(&phydev->lock); @@ -841,6 +840,9 @@ void phy_start(struct phy_device *phydev phydev->state = PHY_UP; break; case PHY_HALTED: + /* if phy was suspended, bring the physical link up again */ + phy_resume(phydev); + /* make sure interrupts are re-enabled for the PHY */ if (phy_interrupt_is_valid(phydev)) { err = phy_enable_interrupts(phydev); @@ -849,17 +851,12 @@ void phy_start(struct phy_device *phydev } phydev->state = PHY_RESUMING; - do_resume = true; break; default: break; } mutex_unlock(&phydev->lock); - /* if phy was suspended, bring the physical link up again */ - if (do_resume) - phy_resume(phydev); - phy_trigger_machine(phydev, true); } EXPORT_SYMBOL(phy_start); --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -135,7 +135,9 @@ static int mdio_bus_phy_resume(struct de if (!mdio_bus_phy_may_suspend(phydev)) goto no_resume; + mutex_lock(&phydev->lock); ret = phy_resume(phydev); + mutex_unlock(&phydev->lock); if (ret < 0) return ret; @@ -1026,7 +1028,9 @@ int phy_attach_direct(struct net_device if (err) goto error; + mutex_lock(&phydev->lock); phy_resume(phydev); + mutex_unlock(&phydev->lock); phy_led_triggers_register(phydev); return err; @@ -1157,6 +1161,8 @@ int phy_resume(struct phy_device *phydev struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver); int ret = 0; + WARN_ON(!mutex_is_locked(&phydev->lock)); + if (phydev->drv && phydrv->resume) ret = phydrv->resume(phydev); @@ -1639,13 +1645,9 @@ int genphy_resume(struct phy_device *phy { int value; - mutex_lock(&phydev->lock); - value = phy_read(phydev, MII_BMCR); phy_write(phydev, MII_BMCR, value & ~BMCR_PDOWN); - mutex_unlock(&phydev->lock); - return 0; } EXPORT_SYMBOL(genphy_resume); Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are queue-4.14/net-phy-fix-resume-handling.patch

7 years, 3 months

1
0
0 0

Re: 4.14.27: "Cannot use CONFIG_STACK_VALIDATION, please install libelf-dev, libelf-devel or elfutils-libelf-devel"

by Greg KH

On Fri, Mar 16, 2018 at 10:31:16AM +0100, Rainer Fiebig wrote: > Hi! > > When building 4.14.27 I got the a/m message. Same for 4.16-rc5. > Building the kernel is OK, however. Same for Spectre- ect. mitigation. > > As I'm not sure whether this is a bug or a feature (and where to get libelf-devel from), any hint would be welcome. It should be part of your Linux distribution, the help message says the major different forms it is called, have you tried searching for those? What Linux distro do you use? thanks, greg k-h

7 years, 3 months

1
0
0 0

patch "siox: fix possible buffer overflow in device_add_store" added to char-misc-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled siox: fix possible buffer overflow in device_add_store to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From f87deada80fe483e2286e29cd866dc66ddc2b6bc Mon Sep 17 00:00:00 2001 From: Gavin Schenk <g.schenk(a)eckelmann.de> Date: Wed, 14 Feb 2018 15:25:02 +0100 Subject: siox: fix possible buffer overflow in device_add_store MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Width 20 given in format string is larger than destination buffer 'type[20]', use %19s to prevent overflowing it. Fixes: bbecb07fa0af ("siox: new driver framework for eckelmann SIOX") Cc: stable <stable(a)vger.kernel.org> Reported-by: David Binderman <dcb314(a)hotmail.com> Signed-off-by: Gavin Schenk <g.schenk(a)eckelmann.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/siox/siox-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/siox/siox-core.c b/drivers/siox/siox-core.c index fdfcdea25867..16590dfaafa4 100644 --- a/drivers/siox/siox-core.c +++ b/drivers/siox/siox-core.c @@ -594,7 +594,7 @@ static ssize_t device_add_store(struct device *dev, size_t inbytes = 0, outbytes = 0; u8 statustype = 0; - ret = sscanf(buf, "%20s %zu %zu %hhu", type, &inbytes, + ret = sscanf(buf, "%19s %zu %zu %hhu", type, &inbytes, &outbytes, &statustype); if (ret != 3 && ret != 4) return -EINVAL; -- 2.16.2

7 years, 3 months

1
0
0 0

patch "Revert "base: arch_topology: fix section mismatch build warnings"" added to driver-core-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Revert "base: arch_topology: fix section mismatch build warnings" to my driver-core git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git in the driver-core-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 9de9a449482677a75f1edd2049268a7efc40fc96 Mon Sep 17 00:00:00 2001 From: Gaku Inami <gaku.inami.xh(a)renesas.com> Date: Tue, 13 Feb 2018 11:06:40 +0900 Subject: Revert "base: arch_topology: fix section mismatch build warnings" This reverts commit 452562abb5b7 ("base: arch_topology: fix section mismatch build warnings"). It causes the notifier call hangs in some use-cases. In some cases with using maxcpus, some of cpus are booted first and then the remaining cpus are booted. As an example, some users who want to realize fast boot up often use the following procedure. 1) Define all CPUs on device tree (CA57x4 + CA53x4) 2) Add "maxcpus=4" in bootargs 3) Kernel boot up with CA57x4 4) After kernel boot up, CA53x4 is booted from user When kernel init was finished, CPUFREQ_POLICY_NOTIFIER was not still unregisterd. This means that "__init init_cpu_capacity_callback()" will be called after kernel init sequence. To avoid this problem, it needs to remove __init{,data} annotations by reverting this commit. Also, this commit was needed to fix kernel compile issue below. However, this issue was also fixed by another patch: commit 82d8ba717ccb ("arch_topology: Fix section miss match warning due to free_raw_capacity()") in v4.15 as well. Whereas commit 452562abb5b7 added all the missing __init annotations, commit 82d8ba717ccb removed it from free_raw_capacity(). WARNING: vmlinux.o(.text+0x548f24): Section mismatch in reference from the function init_cpu_capacity_callback() to the variable .init.text:$x The function init_cpu_capacity_callback() references the variable __init $x. This is often because init_cpu_capacity_callback lacks a __init annotation or the annotation of $x is wrong. Fixes: 82d8ba717ccb ("arch_topology: Fix section miss match warning due to free_raw_capacity()") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Gaku Inami <gaku.inami.xh(a)renesas.com> Reviewed-by: Dietmar Eggemann <dietmar.eggemann(a)arm.com> Tested-by: Dietmar Eggemann <dietmar.eggemann(a)arm.com> Acked-by: Sudeep Holla <sudeep.holla(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/base/arch_topology.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index 52ec5174bcb1..e7cb0c6ade81 100644 --- a/drivers/base/arch_topology.c +++ b/drivers/base/arch_topology.c @@ -169,11 +169,11 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu) } #ifdef CONFIG_CPU_FREQ -static cpumask_var_t cpus_to_visit __initdata; -static void __init parsing_done_workfn(struct work_struct *work); -static __initdata DECLARE_WORK(parsing_done_work, parsing_done_workfn); +static cpumask_var_t cpus_to_visit; +static void parsing_done_workfn(struct work_struct *work); +static DECLARE_WORK(parsing_done_work, parsing_done_workfn); -static int __init +static int init_cpu_capacity_callback(struct notifier_block *nb, unsigned long val, void *data) @@ -209,7 +209,7 @@ init_cpu_capacity_callback(struct notifier_block *nb, return 0; } -static struct notifier_block init_cpu_capacity_notifier __initdata = { +static struct notifier_block init_cpu_capacity_notifier = { .notifier_call = init_cpu_capacity_callback, }; @@ -242,7 +242,7 @@ static int __init register_cpufreq_notifier(void) } core_initcall(register_cpufreq_notifier); -static void __init parsing_done_workfn(struct work_struct *work) +static void parsing_done_workfn(struct work_struct *work) { cpufreq_unregister_notifier(&init_cpu_capacity_notifier, CPUFREQ_POLICY_NOTIFIER); -- 2.16.2

7 years, 3 months

1
0
0 0

v4.15.10 build: 2 failures 0 warnings (v4.15.10)

by Build bot for Mark Brown

Tree/Branch: v4.15.10 Git describe: v4.15.10 Commit: df57458873 Linux 4.15.10 Build Time: 86 min 3 sec Passed: 7 / 9 ( 77.78 %) Failed: 2 / 9 ( 22.22 %) Errors: 0 Warnings: 0 Section Mismatches: 0 Failed defconfigs: Errors: ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years, 3 months

2
1
0 0

[PATCH] perf-probe: Fix to convert array type collectly

by Masami Hiramatsu

Fix to convert array element type collectly. Current perf-probe converts the type of array-elements incorrectly. It always converts the types as a pointer of array. This passes the "array" type DIE to the type converter so that it can get correct "element of array" type DIE from it. E.g. ==== $ cat hello.c #include <stdio.h> void foo(int a[]) { printf("%d\n", a[1]); } void main() { int a[3] = {4, 5, 6}; printf("%d\n", a[0]); foo(a); } $ gcc -g hello.c -o hello $ perf probe -x ./hello -D "foo a[1]" ==== Without this fix, above outputs ==== p:probe_hello/foo /tmp/hello:0x4d3 a=+4(-8(%bp)):u64 ==== The "u64" means "int *", but a[1] is "int". With this, ==== p:probe_hello/foo /tmp/hello:0x4d3 a=+4(-8(%bp)):s32 ==== So, "int" correctly converted to "s32" Fixes: b2a3c12b7442 ("perf probe: Support tracing an entry of array") Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: stable(a)vger.kernel.org --- tools/perf/util/probe-finder.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c index a5731de0e5eb..c37fbef1711d 100644 --- a/tools/perf/util/probe-finder.c +++ b/tools/perf/util/probe-finder.c @@ -423,20 +423,20 @@ static int convert_variable_fields(Dwarf_Die *vr_die, const char *varname, pr_warning("Failed to get the type of %s.\n", varname); return -ENOENT; } - pr_debug2("Var real type: (%x)\n", (unsigned)dwarf_dieoffset(&type)); + pr_debug2("Var real type: %s (%x)\n", dwarf_diename(&type), + (unsigned)dwarf_dieoffset(&type)); tag = dwarf_tag(&type); if (field->name[0] == '[' && (tag == DW_TAG_array_type || tag == DW_TAG_pointer_type)) { - if (field->next) - /* Save original type for next field */ - memcpy(die_mem, &type, sizeof(*die_mem)); + /* Save original type for next field or type */ + memcpy(die_mem, &type, sizeof(*die_mem)); /* Get the type of this array */ if (die_get_real_type(&type, &type) == NULL) { pr_warning("Failed to get the type of %s.\n", varname); return -ENOENT; } - pr_debug2("Array real type: (%x)\n", + pr_debug2("Array real type: %s (%x)\n", dwarf_diename(&type), (unsigned)dwarf_dieoffset(&type)); if (tag == DW_TAG_pointer_type) { ref = zalloc(sizeof(struct probe_trace_arg_ref)); @@ -448,9 +448,6 @@ static int convert_variable_fields(Dwarf_Die *vr_die, const char *varname, *ref_ptr = ref; } ref->offset += dwarf_bytesize(&type) * field->index; - if (!field->next) - /* Save vr_die for converting types */ - memcpy(die_mem, vr_die, sizeof(*die_mem)); goto next; } else if (tag == DW_TAG_pointer_type) { /* Check the pointer and dereference */

7 years, 3 months

1
0
0 0

+ mm-thp-do-not-wait-for-lock_page-in-deferred_split_scan.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/thp: do not wait for lock_page() in deferred_split_scan() has been added to the -mm tree. Its filename is mm-thp-do-not-wait-for-lock_page-in-deferred_split_scan.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-thp-do-not-wait-for-lock_page-i… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-thp-do-not-wait-for-lock_page-i… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Subject: mm/thp: do not wait for lock_page() in deferred_split_scan() deferred_split_scan() gets called from reclaim path. Waiting for page lock may lead to deadlock there. Replace lock_page() with trylock_page() and skip the page if we failed to lock it. We will get to the page on the next scan. Link: http://lkml.kernel.org/r/20180315150747.31945-1-kirill.shutemov@linux.intel… Fixes: 9a982250f773 ("thp: introduce deferred_split_huge_page()") Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/huge_memory.c~mm-thp-do-not-wait-for-lock_page-in-deferred_split_scan mm/huge_memory.c --- a/mm/huge_memory.c~mm-thp-do-not-wait-for-lock_page-in-deferred_split_scan +++ a/mm/huge_memory.c @@ -2783,11 +2783,13 @@ static unsigned long deferred_split_scan list_for_each_safe(pos, next, &list) { page = list_entry((void *)pos, struct page, mapping); - lock_page(page); + if (!trylock_page(page)) + goto next; /* split_huge_page() removes page from list on success */ if (!split_huge_page(page)) split++; unlock_page(page); +next: put_page(page); } _ Patches currently in -mm which might be from kirill.shutemov(a)linux.intel.com are mm-khugepaged-convert-vm_bug_on-to-collapse-fail.patch mm-thp-do-not-wait-for-lock_page-in-deferred_split_scan.patch

7 years, 3 months

1
0
0 0

[PATCH] mm/page_alloc: fix boot hang in memmap_init_zone

by Daniel Vacek

On some architectures (reported on arm64) commit 864b75f9d6b01 ("mm/page_alloc: fix memmap_init_zone pageblock alignment") causes a boot hang. This patch fixes the hang making sure the alignment never steps back. Link: http://lkml.kernel.org/r/0485727b2e82da7efbce5f6ba42524b429d0391a.152001194… Fixes: 864b75f9d6b01 ("mm/page_alloc: fix memmap_init_zone pageblock alignment") Signed-off-by: Daniel Vacek <neelx(a)redhat.com> Tested-by: Sudeep Holla <sudeep.holla(a)arm.com> Tested-by: Naresh Kamboju <naresh.kamboju(a)linaro.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Paul Burton <paul.burton(a)imgtec.com> Cc: Pavel Tatashin <pasha.tatashin(a)oracle.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> --- mm/page_alloc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 3d974cb2a1a1..e033a6895c6f 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5364,9 +5364,14 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone, * is not. move_freepages_block() can shift ahead of * the valid region but still depends on correct page * metadata. + * Also make sure we never step back. */ - pfn = (memblock_next_valid_pfn(pfn, end_pfn) & + unsigned long next_pfn; + + next_pfn = (memblock_next_valid_pfn(pfn, end_pfn) & ~(pageblock_nr_pages-1)) - 1; + if (next_pfn > pfn) + pfn = next_pfn; #endif continue; } -- 2.16.2

7 years, 3 months

3
7
0 0

+ mm-vmscan-wake-up-flushers-for-legacy-cgroups-too.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/vmscan: wake up flushers for legacy cgroups too has been added to the -mm tree. Its filename is mm-vmscan-wake-up-flushers-for-legacy-cgroups-too.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-vmscan-wake-up-flushers-for-leg… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-vmscan-wake-up-flushers-for-leg… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Subject: mm/vmscan: wake up flushers for legacy cgroups too Commit 726d061fbd36 ("mm: vmscan: kick flushers when we encounter dirty pages on the LRU") added flusher invocation to shrink_inactive_list() when many dirty pages on the LRU are encountered. However, shrink_inactive_list() doesn't wake up flushers for legacy cgroup reclaim, so the next commit bbef938429f5 ("mm: vmscan: remove old flusher wakeup from direct reclaim path") removed the only source of flusher's wake up in legacy mem cgroup reclaim path. This leads to premature OOM if there is too many dirty pages in cgroup: # mkdir /sys/fs/cgroup/memory/test # echo $$ > /sys/fs/cgroup/memory/test/tasks # echo 50M > /sys/fs/cgroup/memory/test/memory.limit_in_bytes # dd if=/dev/zero of=tmp_file bs=1M count=100 Killed dd invoked oom-killer: gfp_mask=0x14000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=0 Call Trace: dump_stack+0x46/0x65 dump_header+0x6b/0x2ac oom_kill_process+0x21c/0x4a0 out_of_memory+0x2a5/0x4b0 mem_cgroup_out_of_memory+0x3b/0x60 mem_cgroup_oom_synchronize+0x2ed/0x330 pagefault_out_of_memory+0x24/0x54 __do_page_fault+0x521/0x540 page_fault+0x45/0x50 Task in /test killed as a result of limit of /test memory: usage 51200kB, limit 51200kB, failcnt 73 memory+swap: usage 51200kB, limit 9007199254740988kB, failcnt 0 kmem: usage 296kB, limit 9007199254740988kB, failcnt 0 Memory cgroup stats for /test: cache:49632KB rss:1056KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:49500KB writeback:0KB swap:0KB inactive_anon:0KB active_anon:1168KB inactive_file:24760KB active_file:24960KB unevictable:0KB Memory cgroup out of memory: Kill process 3861 (bash) score 88 or sacrifice child Killed process 3876 (dd) total-vm:8484kB, anon-rss:1052kB, file-rss:1720kB, shmem-rss:0kB oom_reaper: reaped process 3876 (dd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Wake up flushers in legacy cgroup reclaim too. Link: http://lkml.kernel.org/r/20180315164553.17856-1-aryabinin@virtuozzo.com Fixes: bbef938429f5 ("mm: vmscan: remove old flusher wakeup from direct reclaim path") Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Tested-by: Shakeel Butt <shakeelb(a)google.com> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Tejun Heo <tj(a)kernel.org> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/vmscan.c~mm-vmscan-wake-up-flushers-for-legacy-cgroups-too mm/vmscan.c --- a/mm/vmscan.c~mm-vmscan-wake-up-flushers-for-legacy-cgroups-too +++ a/mm/vmscan.c @@ -1772,6 +1772,20 @@ shrink_inactive_list(unsigned long nr_to set_bit(PGDAT_WRITEBACK, &pgdat->flags); /* + * If dirty pages are scanned that are not queued for IO, it + * implies that flushers are not doing their job. This can + * happen when memory pressure pushes dirty pages to the end of + * the LRU before the dirty limits are breached and the dirty + * data has expired. It can also happen when the proportion of + * dirty pages grows not through writes but through memory + * pressure reclaiming all the clean cache. And in some cases, + * the flushers simply cannot keep up with the allocation + * rate. Nudge the flusher threads in case they are asleep. + */ + if (stat.nr_unqueued_dirty == nr_taken) + wakeup_flusher_threads(WB_REASON_VMSCAN); + + /* * Legacy memcg will stall in page writeback so avoid forcibly * stalling here. */ @@ -1783,22 +1797,9 @@ shrink_inactive_list(unsigned long nr_to if (stat.nr_dirty && stat.nr_dirty == stat.nr_congested) set_bit(PGDAT_CONGESTED, &pgdat->flags); - /* - * If dirty pages are scanned that are not queued for IO, it - * implies that flushers are not doing their job. This can - * happen when memory pressure pushes dirty pages to the end of - * the LRU before the dirty limits are breached and the dirty - * data has expired. It can also happen when the proportion of - * dirty pages grows not through writes but through memory - * pressure reclaiming all the clean cache. And in some cases, - * the flushers simply cannot keep up with the allocation - * rate. Nudge the flusher threads in case they are asleep, but - * also allow kswapd to start writing pages during reclaim. - */ - if (stat.nr_unqueued_dirty == nr_taken) { - wakeup_flusher_threads(WB_REASON_VMSCAN); + /* Allow kswapd to start writing pages during reclaim. */ + if (stat.nr_unqueued_dirty == nr_taken) set_bit(PGDAT_DIRTY, &pgdat->flags); - } /* * If kswapd scans pages marked marked for immediate _ Patches currently in -mm which might be from aryabinin(a)virtuozzo.com are mm-vmscan-wake-up-flushers-for-legacy-cgroups-too.patch mm-vmscan-update-stale-comments.patch mm-vmscan-replace-mm_vmscan_lru_shrink_inactive-with-shrink_page_list-tracepoint.patch mm-vmscan-remove-redundant-current_may_throttle-check.patch mm-vmscan-dont-change-pgdat-state-on-base-of-a-single-lru-list-state.patch mm-vmscan-dont-mess-with-pgdat-flags-in-memcg-reclaim.patch mm-kasan-dont-vfree-nonexistent-vm_area.patch

7 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror