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

[Linux-stable-mirror] Patch "scsi: use dma_get_cache_alignment() as minimum DMA alignment" 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 scsi: use dma_get_cache_alignment() as minimum DMA alignment 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: scsi-use-dma_get_cache_alignment-as-minimum-dma-alignment.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 90addc6b3c9cda0146fbd62a08e234c2b224a80c Mon Sep 17 00:00:00 2001 From: Huacai Chen <chenhc(a)lemote.com> Date: Tue, 21 Nov 2017 14:23:38 +0100 Subject: scsi: use dma_get_cache_alignment() as minimum DMA alignment From: Huacai Chen <chenhc(a)lemote.com> commit 90addc6b3c9cda0146fbd62a08e234c2b224a80c upstream. In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so scsi's block queue should be aligned to the value returned by dma_get_cache_alignment(). Otherwise, If a DMA buffer and a kernel structure share a same cache line, and if the kernel structure has dirty data, cache_invalidate (no writeback) will cause data corruption. Signed-off-by: Huacai Chen <chenhc(a)lemote.com> [hch: rebased and updated the comment and changelog] Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/scsi_lib.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -2126,11 +2126,13 @@ void __scsi_init_queue(struct Scsi_Host q->limits.cluster = 0; /* - * set a reasonable default alignment on word boundaries: the - * host and device may alter it using - * blk_queue_update_dma_alignment() later. + * Set a reasonable default alignment: The larger of 32-byte (dword), + * which is a common minimum for HBAs, and the minimum DMA alignment, + * which is set by the platform. + * + * Devices that require a bigger alignment can increase it later. */ - blk_queue_dma_alignment(q, 0x03); + blk_queue_dma_alignment(q, max(4, dma_get_cache_alignment()) - 1); } EXPORT_SYMBOL_GPL(__scsi_init_queue); Patches currently in stable-queue which might be from chenhc(a)lemote.com are queue-4.14/scsi-use-dma_get_cache_alignment-as-minimum-dma-alignment.patch queue-4.14/scsi-libsas-align-sata_device-s-rps_resp-on-a-cacheline.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: libsas: align sata_device's rps_resp on a cacheline" 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 scsi: libsas: align sata_device's rps_resp on a cacheline 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: scsi-libsas-align-sata_device-s-rps_resp-on-a-cacheline.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 c2e8fbf908afd81ad502b567a6639598f92c9b9d Mon Sep 17 00:00:00 2001 From: Huacai Chen <chenhc(a)lemote.com> Date: Tue, 21 Nov 2017 14:23:39 +0100 Subject: scsi: libsas: align sata_device's rps_resp on a cacheline From: Huacai Chen <chenhc(a)lemote.com> commit c2e8fbf908afd81ad502b567a6639598f92c9b9d upstream. The rps_resp buffer in ata_device is a DMA target, but it isn't explicitly cacheline aligned. Due to this, adjacent fields can be overwritten with stale data from memory on non-coherent architectures. As a result, the kernel is sometimes unable to communicate with an SATA device behind a SAS expander. Fix this by ensuring that the rps_resp buffer is cacheline aligned. This issue is similar to that fixed by Commit 84bda12af31f93 ("libata: align ap->sector_buf") and Commit 4ee34ea3a12396f35b26 ("libata: Align ata_device's id on a cacheline"). Signed-off-by: Huacai Chen <chenhc(a)lemote.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/scsi/libsas.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/include/scsi/libsas.h +++ b/include/scsi/libsas.h @@ -165,11 +165,11 @@ struct expander_device { struct sata_device { unsigned int class; - struct smp_resp rps_resp; /* report_phy_sata_resp */ u8 port_no; /* port number, if this is a PM (Port) */ struct ata_port *ap; struct ata_host ata_host; + struct smp_resp rps_resp ____cacheline_aligned; /* report_phy_sata_resp */ u8 fis[ATA_RESP_FIS_SIZE]; }; Patches currently in stable-queue which might be from chenhc(a)lemote.com are queue-4.14/scsi-use-dma_get_cache_alignment-as-minimum-dma-alignment.patch queue-4.14/scsi-libsas-align-sata_device-s-rps_resp-on-a-cacheline.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: dma-mapping: always provide dma_get_cache_alignment" 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 scsi: dma-mapping: always provide dma_get_cache_alignment 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: scsi-dma-mapping-always-provide-dma_get_cache_alignment.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 860dd4424f344400b491b212ee4acb3a358ba9d9 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig <hch(a)lst.de> Date: Tue, 21 Nov 2017 14:23:37 +0100 Subject: scsi: dma-mapping: always provide dma_get_cache_alignment From: Christoph Hellwig <hch(a)lst.de> commit 860dd4424f344400b491b212ee4acb3a358ba9d9 upstream. Provide the dummy version of dma_get_cache_alignment that always returns 1 even if CONFIG_HAS_DMA is not set, so that drivers and subsystems can use it without ifdefs. Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -697,7 +697,6 @@ static inline void *dma_zalloc_coherent( return ret; } -#ifdef CONFIG_HAS_DMA static inline int dma_get_cache_alignment(void) { #ifdef ARCH_DMA_MINALIGN @@ -705,7 +704,6 @@ static inline int dma_get_cache_alignmen #endif return 1; } -#endif /* flags for the coherent memory api */ #define DMA_MEMORY_EXCLUSIVE 0x01 Patches currently in stable-queue which might be from hch(a)lst.de are queue-4.14/scsi-use-dma_get_cache_alignment-as-minimum-dma-alignment.patch queue-4.14/scsi-dma-mapping-always-provide-dma_get_cache_alignment.patch queue-4.14/scsi-libsas-align-sata_device-s-rps_resp-on-a-cacheline.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "s390/mm: fix off-by-one bug in 5-level page table 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 s390/mm: fix off-by-one bug in 5-level page table 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: s390-mm-fix-off-by-one-bug-in-5-level-page-table-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 8d306f53b63099fec2d56300149e400d181ba4f5 Mon Sep 17 00:00:00 2001 From: Heiko Carstens <heiko.carstens(a)de.ibm.com> Date: Mon, 4 Dec 2017 09:42:45 +0100 Subject: s390/mm: fix off-by-one bug in 5-level page table handling From: Heiko Carstens <heiko.carstens(a)de.ibm.com> commit 8d306f53b63099fec2d56300149e400d181ba4f5 upstream. Martin Cermak reported that setting a uprobe doesn't work. Reason for this is that the common uprobes code tries to get an unmapped area at the last possible page within an address space. This broke with commit 1aea9b3f9210 ("s390/mm: implement 5 level pages tables") which introduced an off-by-one bug which prevents to map anything at the last possible page within an address space. The check with the off-by-one bug however can be removed since with commit 8ab867cb0806 ("s390/mm: fix BUG_ON in crst_table_upgrade") the necessary check is done at both call sites. Reported-by: Martin Cermak <mcermak(a)redhat.com> Bisected-by: Thomas Richter <tmricht(a)linux.vnet.ibm.com> Fixes: 1aea9b3f9210 ("s390/mm: implement 5 level pages tables") Reviewed-by: Hendrik Brueckner <brueckner(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: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/mm/pgalloc.c | 2 -- 1 file changed, 2 deletions(-) --- a/arch/s390/mm/pgalloc.c +++ b/arch/s390/mm/pgalloc.c @@ -85,8 +85,6 @@ int crst_table_upgrade(struct mm_struct /* upgrade should only happen from 3 to 4, 3 to 5, or 4 to 5 levels */ VM_BUG_ON(mm->context.asce_limit < _REGION2_SIZE); - if (end >= TASK_SIZE_MAX) - return -ENOMEM; rc = 0; notify = 0; while (mm->context.asce_limit < end) { Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are queue-4.14/s390-always-save-and-restore-all-registers-on-context-switch.patch queue-4.14/s390-fix-compat-system-call-table.patch queue-4.14/s390-mm-fix-off-by-one-bug-in-5-level-page-table-handling.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "s390: fix compat system call table" 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 s390: fix compat system call table 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: s390-fix-compat-system-call-table.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 e779498df587dd2189b30fe5b9245aefab870eb8 Mon Sep 17 00:00:00 2001 From: Heiko Carstens <heiko.carstens(a)de.ibm.com> Date: Wed, 6 Dec 2017 16:11:27 +0100 Subject: s390: fix compat system call table From: Heiko Carstens <heiko.carstens(a)de.ibm.com> commit e779498df587dd2189b30fe5b9245aefab870eb8 upstream. When wiring up the socket system calls the compat entries were incorrectly set. Not all of them point to the corresponding compat wrapper functions, which clear the upper 33 bits of user space pointers, like it is required. Fixes: 977108f89c989 ("s390: wire up separate socketcalls system calls") Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/kernel/syscalls.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/s390/kernel/syscalls.S +++ b/arch/s390/kernel/syscalls.S @@ -370,10 +370,10 @@ SYSCALL(sys_recvmmsg,compat_sys_recvmmsg SYSCALL(sys_sendmmsg,compat_sys_sendmmsg) SYSCALL(sys_socket,sys_socket) SYSCALL(sys_socketpair,compat_sys_socketpair) /* 360 */ -SYSCALL(sys_bind,sys_bind) -SYSCALL(sys_connect,sys_connect) +SYSCALL(sys_bind,compat_sys_bind) +SYSCALL(sys_connect,compat_sys_connect) SYSCALL(sys_listen,sys_listen) -SYSCALL(sys_accept4,sys_accept4) +SYSCALL(sys_accept4,compat_sys_accept4) SYSCALL(sys_getsockopt,compat_sys_getsockopt) /* 365 */ SYSCALL(sys_setsockopt,compat_sys_setsockopt) SYSCALL(sys_getsockname,compat_sys_getsockname) Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are queue-4.14/s390-always-save-and-restore-all-registers-on-context-switch.patch queue-4.14/s390-fix-compat-system-call-table.patch queue-4.14/s390-mm-fix-off-by-one-bug-in-5-level-page-table-handling.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "s390: always save and restore all registers on context switch" 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 s390: always save and restore all registers on context switch 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: s390-always-save-and-restore-all-registers-on-context-switch.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 fbbd7f1a51965b50dd12924841da0d478f3da71b Mon Sep 17 00:00:00 2001 From: Heiko Carstens <heiko.carstens(a)de.ibm.com> Date: Mon, 20 Nov 2017 12:38:44 +0100 Subject: s390: always save and restore all registers on context switch From: Heiko Carstens <heiko.carstens(a)de.ibm.com> commit fbbd7f1a51965b50dd12924841da0d478f3da71b upstream. The switch_to() macro has an optimization to avoid saving and restoring register contents that aren't needed for kernel threads. There is however the possibility that a kernel thread execve's a user space program. In such a case the execve'd process can partially see the contents of the previous process, which shouldn't be allowed. To avoid this, simply always save and restore register contents on context switch. Fixes: fdb6d070effba ("switch_to: dont restore/save access & fpu regs for kernel threads") Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/include/asm/switch_to.h | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) --- a/arch/s390/include/asm/switch_to.h +++ b/arch/s390/include/asm/switch_to.h @@ -30,21 +30,20 @@ static inline void restore_access_regs(u asm volatile("lam 0,15,%0" : : "Q" (*(acrstype *)acrs)); } -#define switch_to(prev,next,last) do { \ - if (prev->mm) { \ - save_fpu_regs(); \ - save_access_regs(&prev->thread.acrs[0]); \ - save_ri_cb(prev->thread.ri_cb); \ - save_gs_cb(prev->thread.gs_cb); \ - } \ +#define switch_to(prev, next, last) do { \ + /* save_fpu_regs() sets the CIF_FPU flag, which enforces \ + * a restore of the floating point / vector registers as \ + * soon as the next task returns to user space \ + */ \ + save_fpu_regs(); \ + save_access_regs(&prev->thread.acrs[0]); \ + save_ri_cb(prev->thread.ri_cb); \ + save_gs_cb(prev->thread.gs_cb); \ update_cr_regs(next); \ - if (next->mm) { \ - set_cpu_flag(CIF_FPU); \ - restore_access_regs(&next->thread.acrs[0]); \ - restore_ri_cb(next->thread.ri_cb, prev->thread.ri_cb); \ - restore_gs_cb(next->thread.gs_cb); \ - } \ - prev = __switch_to(prev,next); \ + restore_access_regs(&next->thread.acrs[0]); \ + restore_ri_cb(next->thread.ri_cb, prev->thread.ri_cb); \ + restore_gs_cb(next->thread.gs_cb); \ + prev = __switch_to(prev, next); \ } while (0) #endif /* __ASM_SWITCH_TO_H */ Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are queue-4.14/s390-always-save-and-restore-all-registers-on-context-switch.patch queue-4.14/s390-fix-compat-system-call-table.patch queue-4.14/s390-mm-fix-off-by-one-bug-in-5-level-page-table-handling.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "Revert "powerpc: Do not call ppc_md.panic in fadump panic notifier"" 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 Revert "powerpc: Do not call ppc_md.panic in fadump panic notifier" 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: revert-powerpc-do-not-call-ppc_md.panic-in-fadump-panic-notifier.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 ab9dbf771ff9b6b7e814e759213ed01d7f0de320 Mon Sep 17 00:00:00 2001 From: David Gibson <david(a)gibson.dropbear.id.au> Date: Mon, 4 Dec 2017 16:27:25 +1100 Subject: Revert "powerpc: Do not call ppc_md.panic in fadump panic notifier" From: David Gibson <david(a)gibson.dropbear.id.au> commit ab9dbf771ff9b6b7e814e759213ed01d7f0de320 upstream. This reverts commit a3b2cb30f252b21a6f962e0dd107c8b897ca65e4. That commit tried to fix problems with panic on powerpc in certain circumstances, where some output from the generic panic code was being dropped. Unfortunately, it breaks things worse in other circumstances. In particular when running a PAPR guest, it will now attempt to reboot instead of informing the hypervisor (KVM or PowerVM) that the guest has crashed. The crash notification is important to some virtualization management layers. Revert it for now until we can come up with a better solution. Fixes: a3b2cb30f252 ("powerpc: Do not call ppc_md.panic in fadump panic notifier") Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> [mpe: Tweak change log a bit] Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/include/asm/machdep.h | 1 + arch/powerpc/include/asm/setup.h | 1 + arch/powerpc/kernel/fadump.c | 22 ---------------------- arch/powerpc/kernel/setup-common.c | 27 +++++++++++++++++++++++++++ arch/powerpc/platforms/ps3/setup.c | 15 +++++++++++++++ arch/powerpc/platforms/pseries/setup.c | 1 + 6 files changed, 45 insertions(+), 22 deletions(-) --- a/arch/powerpc/include/asm/machdep.h +++ b/arch/powerpc/include/asm/machdep.h @@ -76,6 +76,7 @@ struct machdep_calls { void __noreturn (*restart)(char *cmd); void __noreturn (*halt)(void); + void (*panic)(char *str); void (*cpu_die)(void); long (*time_init)(void); /* Optional, may be NULL */ --- a/arch/powerpc/include/asm/setup.h +++ b/arch/powerpc/include/asm/setup.h @@ -24,6 +24,7 @@ extern void reloc_got2(unsigned long); void check_for_initrd(void); void initmem_init(void); +void setup_panic(void); #define ARCH_PANIC_TIMEOUT 180 #ifdef CONFIG_PPC_PSERIES --- a/arch/powerpc/kernel/fadump.c +++ b/arch/powerpc/kernel/fadump.c @@ -1453,25 +1453,6 @@ static void fadump_init_files(void) return; } -static int fadump_panic_event(struct notifier_block *this, - unsigned long event, void *ptr) -{ - /* - * If firmware-assisted dump has been registered then trigger - * firmware-assisted dump and let firmware handle everything - * else. If this returns, then fadump was not registered, so - * go through the rest of the panic path. - */ - crash_fadump(NULL, ptr); - - return NOTIFY_DONE; -} - -static struct notifier_block fadump_panic_block = { - .notifier_call = fadump_panic_event, - .priority = INT_MIN /* may not return; must be done last */ -}; - /* * Prepare for firmware-assisted dump. */ @@ -1504,9 +1485,6 @@ int __init setup_fadump(void) init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start); fadump_init_files(); - atomic_notifier_chain_register(&panic_notifier_list, - &fadump_panic_block); - return 1; } subsys_initcall(setup_fadump); --- a/arch/powerpc/kernel/setup-common.c +++ b/arch/powerpc/kernel/setup-common.c @@ -704,6 +704,30 @@ int check_legacy_ioport(unsigned long ba } EXPORT_SYMBOL(check_legacy_ioport); +static int ppc_panic_event(struct notifier_block *this, + unsigned long event, void *ptr) +{ + /* + * If firmware-assisted dump has been registered then trigger + * firmware-assisted dump and let firmware handle everything else. + */ + crash_fadump(NULL, ptr); + ppc_md.panic(ptr); /* May not return */ + return NOTIFY_DONE; +} + +static struct notifier_block ppc_panic_block = { + .notifier_call = ppc_panic_event, + .priority = INT_MIN /* may not return; must be done last */ +}; + +void __init setup_panic(void) +{ + if (!ppc_md.panic) + return; + atomic_notifier_chain_register(&panic_notifier_list, &ppc_panic_block); +} + #ifdef CONFIG_CHECK_CACHE_COHERENCY /* * For platforms that have configurable cache-coherency. This function @@ -848,6 +872,9 @@ void __init setup_arch(char **cmdline_p) /* Probe the machine type, establish ppc_md. */ probe_machine(); + /* Setup panic notifier if requested by the platform. */ + setup_panic(); + /* * Configure ppc_md.power_save (ppc32 only, 64-bit machines do * it from their respective probe() function. --- a/arch/powerpc/platforms/ps3/setup.c +++ b/arch/powerpc/platforms/ps3/setup.c @@ -104,6 +104,20 @@ static void __noreturn ps3_halt(void) ps3_sys_manager_halt(); /* never returns */ } +static void ps3_panic(char *str) +{ + DBG("%s:%d %s\n", __func__, __LINE__, str); + + smp_send_stop(); + printk("\n"); + printk(" System does not reboot automatically.\n"); + printk(" Please press POWER button.\n"); + printk("\n"); + + while(1) + lv1_pause(1); +} + #if defined(CONFIG_FB_PS3) || defined(CONFIG_FB_PS3_MODULE) || \ defined(CONFIG_PS3_FLASH) || defined(CONFIG_PS3_FLASH_MODULE) static void __init prealloc(struct ps3_prealloc *p) @@ -255,6 +269,7 @@ define_machine(ps3) { .probe = ps3_probe, .setup_arch = ps3_setup_arch, .init_IRQ = ps3_init_IRQ, + .panic = ps3_panic, .get_boot_time = ps3_get_boot_time, .set_dabr = ps3_set_dabr, .calibrate_decr = ps3_calibrate_decr, --- a/arch/powerpc/platforms/pseries/setup.c +++ b/arch/powerpc/platforms/pseries/setup.c @@ -726,6 +726,7 @@ define_machine(pseries) { .pcibios_fixup = pSeries_final_fixup, .restart = rtas_restart, .halt = rtas_halt, + .panic = rtas_os_term, .get_boot_time = rtas_get_boot_time, .get_rtc_time = rtas_get_rtc_time, .set_rtc_time = rtas_set_rtc_time, Patches currently in stable-queue which might be from david(a)gibson.dropbear.id.au are queue-4.14/revert-powerpc-do-not-call-ppc_md.panic-in-fadump-panic-notifier.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "Revert "ARM: dts: imx53: add srtc node"" 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 Revert "ARM: dts: imx53: add srtc node" 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: revert-arm-dts-imx53-add-srtc-node.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 e501506d3ea00eefa64463ebd9e5c13ee70990bd Mon Sep 17 00:00:00 2001 From: Fabio Estevam <fabio.estevam(a)nxp.com> Date: Wed, 15 Nov 2017 10:03:53 -0200 Subject: Revert "ARM: dts: imx53: add srtc node" From: Fabio Estevam <fabio.estevam(a)nxp.com> commit e501506d3ea00eefa64463ebd9e5c13ee70990bd upstream. This reverts commit 5b725054147deaf966b3919e10a86c6bfe946a18. The rtc block on i.MX53 is a completely different hardware than the one found on i.MX25. Reported-by: Noel Vellemans <Noel.Vellemans(a)visionbms.com> Suggested-by: Juergen Borleis <jbe(a)pengutronix.de> Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com> Signed-off-by: Shawn Guo <shawnguo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/imx53.dtsi | 9 --------- 1 file changed, 9 deletions(-) --- a/arch/arm/boot/dts/imx53.dtsi +++ b/arch/arm/boot/dts/imx53.dtsi @@ -433,15 +433,6 @@ clock-names = "ipg", "per"; }; - srtc: srtc@53fa4000 { - compatible = "fsl,imx53-rtc", "fsl,imx25-rtc"; - reg = <0x53fa4000 0x4000>; - interrupts = <24>; - interrupt-parent = <&tzic>; - clocks = <&clks IMX5_CLK_SRTC_GATE>; - clock-names = "ipg"; - }; - iomuxc: iomuxc@53fa8000 { compatible = "fsl,imx53-iomuxc"; reg = <0x53fa8000 0x4000>; Patches currently in stable-queue which might be from fabio.estevam(a)nxp.com are queue-4.14/revert-arm-dts-imx53-add-srtc-node.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/64s: Initialize ISAv3 MMU registers before setting partition table" 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 powerpc/64s: Initialize ISAv3 MMU registers before setting partition table 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: powerpc-64s-initialize-isav3-mmu-registers-before-setting-partition-table.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 371b80447ff33ddac392c189cf884a5a3e18faeb Mon Sep 17 00:00:00 2001 From: Nicholas Piggin <npiggin(a)gmail.com> Date: Wed, 6 Dec 2017 18:21:14 +1000 Subject: powerpc/64s: Initialize ISAv3 MMU registers before setting partition table From: Nicholas Piggin <npiggin(a)gmail.com> commit 371b80447ff33ddac392c189cf884a5a3e18faeb upstream. kexec can leave MMU registers set when booting into a new kernel, the PIDR (Process Identification Register) in particular. The boot sequence does not zero PIDR, so it only gets set when CPUs first switch to a userspace processes (until then it's running a kernel thread with effective PID = 0). This leaves a window where a process table entry and page tables are set up due to user processes running on other CPUs, that happen to match with a stale PID. The CPU with that PID may cause speculative accesses that address quadrant 0 (aka userspace addresses), which will result in cached translations and PWC (Page Walk Cache) for that process, on a CPU which is not in the mm_cpumask and so they will not be invalidated properly. The most common result is the kernel hanging in infinite page fault loops soon after kexec (usually in schedule_tail, which is usually the first non-speculative quadrant 0 access to a new PID) due to a stale PWC. However being a stale translation error, it could result in anything up to security and data corruption problems. Fix this by zeroing out PIDR at boot and kexec. Fixes: 7e381c0ff618 ("powerpc/mm/radix: Add mmu context handling callback for radix") Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kernel/cpu_setup_power.S | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/powerpc/kernel/cpu_setup_power.S +++ b/arch/powerpc/kernel/cpu_setup_power.S @@ -102,6 +102,7 @@ _GLOBAL(__setup_cpu_power9) li r0,0 mtspr SPRN_PSSCR,r0 mtspr SPRN_LPID,r0 + mtspr SPRN_PID,r0 mfspr r3,SPRN_LPCR LOAD_REG_IMMEDIATE(r4, LPCR_PECEDH | LPCR_PECE_HVEE | LPCR_HVICE | LPCR_HEIC) or r3, r3, r4 @@ -126,6 +127,7 @@ _GLOBAL(__restore_cpu_power9) li r0,0 mtspr SPRN_PSSCR,r0 mtspr SPRN_LPID,r0 + mtspr SPRN_PID,r0 mfspr r3,SPRN_LPCR LOAD_REG_IMMEDIATE(r4, LPCR_PECEDH | LPCR_PECE_HVEE | LPCR_HVICE | LPCR_HEIC) or r3, r3, r4 Patches currently in stable-queue which might be from npiggin(a)gmail.com are queue-4.14/powerpc-64s-initialize-isav3-mmu-registers-before-setting-partition-table.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "pinctrl: armada-37xx: Fix direction_output() callback behavior" 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 pinctrl: armada-37xx: Fix direction_output() callback behavior 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: pinctrl-armada-37xx-fix-direction_output-callback-behavior.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 6702abb3bf2394f250af0ee04070227bb5dda788 Mon Sep 17 00:00:00 2001 From: Gregory CLEMENT <gregory.clement(a)free-electrons.com> Date: Tue, 14 Nov 2017 17:51:50 +0100 Subject: pinctrl: armada-37xx: Fix direction_output() callback behavior From: Gregory CLEMENT <gregory.clement(a)free-electrons.com> commit 6702abb3bf2394f250af0ee04070227bb5dda788 upstream. The direction_output callback of the gpio_chip structure is supposed to set the output direction but also to set the value of the gpio. For the armada-37xx driver this callback acted as the gpio_set_direction callback for the pinctrl. This patch fixes the behavior of the direction_output callback by also applying the value received as parameter. Fixes: 5715092a458c ("pinctrl: armada-37xx: Add gpio support") Reported-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement(a)free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c +++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c @@ -408,12 +408,21 @@ static int armada_37xx_gpio_direction_ou { struct armada_37xx_pinctrl *info = gpiochip_get_data(chip); unsigned int reg = OUTPUT_EN; - unsigned int mask; + unsigned int mask, val, ret; armada_37xx_update_reg(&reg, offset); mask = BIT(offset); - return regmap_update_bits(info->regmap, reg, mask, mask); + ret = regmap_update_bits(info->regmap, reg, mask, mask); + + if (ret) + return ret; + + reg = OUTPUT_VAL; + val = value ? mask : 0; + regmap_update_bits(info->regmap, reg, mask, val); + + return 0; } static int armada_37xx_gpio_get(struct gpio_chip *chip, unsigned int offset) Patches currently in stable-queue which might be from gregory.clement(a)free-electrons.com are queue-4.14/pinctrl-armada-37xx-fix-direction_output-callback-behavior.patch

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror