From: Greg Kroah-Hartman Date: Sat, 10 Nov 2018 18:44:53 +0000 (-0800) Subject: 4.4-stable patches X-Git-Tag: v4.19.2~74 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=b366663668f33e40538d6090a22e99067c80a234;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: alsa-ca0106-disable-izd-on-sb0570-dac-to-fix-audio-pops.patch alsa-hda-add-mic-quirk-for-the-lenovo-g50-30-17aa-3905.patch parisc-fix-address-in-hpmc-iva.patch parisc-fix-map_pages-to-not-overwrite-existing-pte-entries.patch x86-corruption-check-fix-panic-in-memory_corruption_check-when-boot-option-without-value-is-provided.patch x86-kconfig-fall-back-to-ticket-spinlocks.patch --- diff --git a/queue-4.4/alsa-ca0106-disable-izd-on-sb0570-dac-to-fix-audio-pops.patch b/queue-4.4/alsa-ca0106-disable-izd-on-sb0570-dac-to-fix-audio-pops.patch new file mode 100644 index 00000000000..84ec205a382 --- /dev/null +++ b/queue-4.4/alsa-ca0106-disable-izd-on-sb0570-dac-to-fix-audio-pops.patch @@ -0,0 +1,51 @@ +From ac237c28d5ac1b241d58b1b7b4b9fa10efb22fb5 Mon Sep 17 00:00:00 2001 +From: Alex Stanoev +Date: Sun, 28 Oct 2018 16:55:12 +0000 +Subject: ALSA: ca0106: Disable IZD on SB0570 DAC to fix audio pops + +From: Alex Stanoev + +commit ac237c28d5ac1b241d58b1b7b4b9fa10efb22fb5 upstream. + +The Creative Audigy SE (SB0570) card currently exhibits an audible pop +whenever playback is stopped or resumed, or during silent periods of an +audio stream. Initialise the IZD bit to the 0 to eliminate these pops. + +The Infinite Zero Detection (IZD) feature on the DAC causes the output +to be shunted to Vcap after 2048 samples of silence. This discharges the +AC coupling capacitor through the output and causes the aforementioned +pop/click noise. + +The behaviour of the IZD bit is described on page 15 of the WM8768GEDS +datasheet: "With IZD=1, applying MUTE for 1024 consecutive input samples +will cause all outputs to be connected directly to VCAP. This also +happens if 2048 consecutive zero input samples are applied to all 6 +channels, and IZD=0. It will be removed as soon as any channel receives +a non-zero input". I believe the second sentence might be referring to +IZD=1 instead of IZD=0 given the observed behaviour of the card. + +This change should make the DAC initialisation consistent with +Creative's Windows driver, as this popping persists when initialising +the card in Linux and soft rebooting into Windows, but is not present on +a cold boot to Windows. + +Signed-off-by: Alex Stanoev +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/ca0106/ca0106.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/pci/ca0106/ca0106.h ++++ b/sound/pci/ca0106/ca0106.h +@@ -582,7 +582,7 @@ + #define SPI_PL_BIT_R_R (2<<7) /* right channel = right */ + #define SPI_PL_BIT_R_C (3<<7) /* right channel = (L+R)/2 */ + #define SPI_IZD_REG 2 +-#define SPI_IZD_BIT (1<<4) /* infinite zero detect */ ++#define SPI_IZD_BIT (0<<4) /* infinite zero detect */ + + #define SPI_FMT_REG 3 + #define SPI_FMT_BIT_RJ (0<<0) /* right justified mode */ diff --git a/queue-4.4/alsa-hda-add-mic-quirk-for-the-lenovo-g50-30-17aa-3905.patch b/queue-4.4/alsa-hda-add-mic-quirk-for-the-lenovo-g50-30-17aa-3905.patch new file mode 100644 index 00000000000..e8d57f94cb2 --- /dev/null +++ b/queue-4.4/alsa-hda-add-mic-quirk-for-the-lenovo-g50-30-17aa-3905.patch @@ -0,0 +1,34 @@ +From e7bb6ad5685f05685dd8a6a5eda7bfcd14d5f95b Mon Sep 17 00:00:00 2001 +From: Jeremy Cline +Date: Thu, 11 Oct 2018 15:49:17 -0400 +Subject: ALSA: hda - Add mic quirk for the Lenovo G50-30 (17aa:3905) + +From: Jeremy Cline + +commit e7bb6ad5685f05685dd8a6a5eda7bfcd14d5f95b upstream. + +The Lenovo G50-30, like other G50 models, has a Conexant codec that +requires a quirk for its inverted stereo dmic. + +Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1249364 +Reported-by: Alexander Ploumistos +Tested-by: Alexander Ploumistos +Cc: stable@vger.kernel.org +Signed-off-by: Jeremy Cline +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_conexant.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/hda/patch_conexant.c ++++ b/sound/pci/hda/patch_conexant.c +@@ -867,6 +867,7 @@ static const struct snd_pci_quirk cxt506 + SND_PCI_QUIRK(0x17aa, 0x21da, "Lenovo X220", CXT_PINCFG_LENOVO_TP410), + SND_PCI_QUIRK(0x17aa, 0x21db, "Lenovo X220-tablet", CXT_PINCFG_LENOVO_TP410), + SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo IdeaPad Z560", CXT_FIXUP_MUTE_LED_EAPD), ++ SND_PCI_QUIRK(0x17aa, 0x3905, "Lenovo G50-30", CXT_FIXUP_STEREO_DMIC), + SND_PCI_QUIRK(0x17aa, 0x390b, "Lenovo G50-80", CXT_FIXUP_STEREO_DMIC), + SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s", CXT_FIXUP_STEREO_DMIC), + SND_PCI_QUIRK(0x17aa, 0x3977, "Lenovo IdeaPad U310", CXT_FIXUP_STEREO_DMIC), diff --git a/queue-4.4/parisc-fix-address-in-hpmc-iva.patch b/queue-4.4/parisc-fix-address-in-hpmc-iva.patch new file mode 100644 index 00000000000..2af0217b23b --- /dev/null +++ b/queue-4.4/parisc-fix-address-in-hpmc-iva.patch @@ -0,0 +1,93 @@ +From 1138b6718ff74d2a934459643e3754423d23b5e2 Mon Sep 17 00:00:00 2001 +From: John David Anglin +Date: Sat, 6 Oct 2018 13:11:30 -0400 +Subject: parisc: Fix address in HPMC IVA + +From: John David Anglin + +commit 1138b6718ff74d2a934459643e3754423d23b5e2 upstream. + +Helge noticed that the address of the os_hpmc handler was not being +correctly calculated in the hpmc macro. As a result, PDCE_CHECK would +fail to call os_hpmc: + + e800009802e00000 0000000000000000 CC_ERR_CHECK_HPMC + 37000f7302e00000 8040004000000000 CC_ERR_CPU_CHECK_SUMMARY + f600105e02e00000 fffffff0f0c00000 CC_MC_HPMC_MONARCH_SELECTED + 140003b202e00000 000000000000000b CC_ERR_HPMC_STATE_ENTRY + 5600100b02e00000 00000000000001a0 CC_MC_OS_HPMC_LEN_ERR + 5600106402e00000 fffffff0f0438e70 CC_MC_BR_TO_OS_HPMC_FAILED + e800009802e00000 0000000000000000 CC_ERR_CHECK_HPMC + 37000f7302e00000 8040004000000000 CC_ERR_CPU_CHECK_SUMMARY + 4000109f02e00000 0000000000000000 CC_MC_HPMC_INITIATED + 4000101902e00000 0000000000000000 CC_MC_MULTIPLE_HPMCS + 030010d502e00000 0000000000000000 CC_CPU_STOP + +The address problem can be seen by dumping the fault vector: + +0000000040159000 : + 40159000: 63 6f 77 73 stb r15,-2447(dp) + 40159004: 20 63 61 6e ldil L%b747000,r3 + 40159008: 20 66 6c 79 ldil L%-1c3b3000,r3 + ... + 40159020: 08 00 02 40 nop + 40159024: 20 6e 60 02 ldil L%15d000,r3 + 40159028: 34 63 00 00 ldo 0(r3),r3 + 4015902c: e8 60 c0 02 bv,n r0(r3) + 40159030: 08 00 02 40 nop + 40159034: 00 00 00 00 break 0,0 + 40159038: c0 00 70 00 bb,*< r0,sar,40159840 + 4015903c: 00 00 00 00 break 0,0 + +Location 40159038 should contain the physical address of os_hpmc: + +000000004015d000 : + 4015d000: 08 1a 02 43 copy r26,r3 + 4015d004: 01 c0 08 a4 mfctl iva,r4 + 4015d008: 48 85 00 68 ldw 34(r4),r5 + +This patch moves the address setup into initialize_ivt to resolve the +above problem. I tested the change by dumping the HPMC entry after setup: + +0000000040209020: 8000240 +0000000040209024: 206a2004 +0000000040209028: 34630ac0 +000000004020902c: e860c002 +0000000040209030: 8000240 +0000000040209034: 1bdddce6 +0000000040209038: 15d000 +000000004020903c: 1a0 + +Signed-off-by: John David Anglin +Cc: +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman + +--- + arch/parisc/kernel/entry.S | 2 +- + arch/parisc/kernel/traps.c | 3 ++- + 2 files changed, 3 insertions(+), 2 deletions(-) + +--- a/arch/parisc/kernel/entry.S ++++ b/arch/parisc/kernel/entry.S +@@ -185,7 +185,7 @@ + bv,n 0(%r3) + nop + .word 0 /* checksum (will be patched) */ +- .word PA(os_hpmc) /* address of handler */ ++ .word 0 /* address of handler */ + .word 0 /* length of handler */ + .endm + +--- a/arch/parisc/kernel/traps.c ++++ b/arch/parisc/kernel/traps.c +@@ -829,7 +829,8 @@ void __init initialize_ivt(const void *i + for (i = 0; i < 8; i++) + *ivap++ = 0; + +- /* Compute Checksum for HPMC handler */ ++ /* Setup IVA and compute checksum for HPMC handler */ ++ ivap[6] = (u32)__pa(os_hpmc); + length = os_hpmc_size; + ivap[7] = length; + diff --git a/queue-4.4/parisc-fix-map_pages-to-not-overwrite-existing-pte-entries.patch b/queue-4.4/parisc-fix-map_pages-to-not-overwrite-existing-pte-entries.patch new file mode 100644 index 00000000000..3b5a5dec46b --- /dev/null +++ b/queue-4.4/parisc-fix-map_pages-to-not-overwrite-existing-pte-entries.patch @@ -0,0 +1,41 @@ +From 3c229b3f2dd8133f61bb81d3cb018be92f4bba39 Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Fri, 12 Oct 2018 22:37:46 +0200 +Subject: parisc: Fix map_pages() to not overwrite existing pte entries + +From: Helge Deller + +commit 3c229b3f2dd8133f61bb81d3cb018be92f4bba39 upstream. + +Fix a long-existing small nasty bug in the map_pages() implementation which +leads to overwriting already written pte entries with zero, *if* map_pages() is +called a second time with an end address which isn't aligned on a pmd boundry. +This happens for example if we want to remap only the text segment read/write +in order to run alternative patching on the code. Exiting the loop when we +reach the end address fixes this. + +Cc: stable@vger.kernel.org +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman + +--- + arch/parisc/mm/init.c | 8 ++------ + 1 file changed, 2 insertions(+), 6 deletions(-) + +--- a/arch/parisc/mm/init.c ++++ b/arch/parisc/mm/init.c +@@ -491,12 +491,8 @@ static void __init map_pages(unsigned lo + pte = pte_mkhuge(pte); + } + +- if (address >= end_paddr) { +- if (force) +- break; +- else +- pte_val(pte) = 0; +- } ++ if (address >= end_paddr) ++ break; + + set_pte(pg_table, pte); + diff --git a/queue-4.4/series b/queue-4.4/series index 7a754e5644e..c91074abcee 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -4,3 +4,9 @@ jffs2-free-jffs2_sb_info-through-jffs2_kill_sb.patch pcmcia-implement-clkrun-protocol-disabling-for-ricoh-bridges.patch acpica-aml-interpreter-add-region-addresses-in-global-list-during-initialization.patch ipmi-fix-timer-race-with-module-unload.patch +parisc-fix-address-in-hpmc-iva.patch +parisc-fix-map_pages-to-not-overwrite-existing-pte-entries.patch +alsa-hda-add-mic-quirk-for-the-lenovo-g50-30-17aa-3905.patch +alsa-ca0106-disable-izd-on-sb0570-dac-to-fix-audio-pops.patch +x86-corruption-check-fix-panic-in-memory_corruption_check-when-boot-option-without-value-is-provided.patch +x86-kconfig-fall-back-to-ticket-spinlocks.patch diff --git a/queue-4.4/x86-corruption-check-fix-panic-in-memory_corruption_check-when-boot-option-without-value-is-provided.patch b/queue-4.4/x86-corruption-check-fix-panic-in-memory_corruption_check-when-boot-option-without-value-is-provided.patch new file mode 100644 index 00000000000..a64239f4fcb --- /dev/null +++ b/queue-4.4/x86-corruption-check-fix-panic-in-memory_corruption_check-when-boot-option-without-value-is-provided.patch @@ -0,0 +1,87 @@ +From ccde460b9ae5c2bd5e4742af0a7f623c2daad566 Mon Sep 17 00:00:00 2001 +From: He Zhe +Date: Tue, 14 Aug 2018 23:33:42 +0800 +Subject: x86/corruption-check: Fix panic in memory_corruption_check() when boot option without value is provided + +From: He Zhe + +commit ccde460b9ae5c2bd5e4742af0a7f623c2daad566 upstream. + +memory_corruption_check[{_period|_size}]()'s handlers do not check input +argument before passing it to kstrtoul() or simple_strtoull(). The argument +would be a NULL pointer if each of the kernel parameters, without its +value, is set in command line and thus cause the following panic. + +PANIC: early exception 0xe3 IP 10:ffffffff73587c22 error 0 cr2 0x0 +[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.18-rc8+ #2 +[ 0.000000] RIP: 0010:kstrtoull+0x2/0x10 +... +[ 0.000000] Call Trace +[ 0.000000] ? set_corruption_check+0x21/0x49 +[ 0.000000] ? do_early_param+0x4d/0x82 +[ 0.000000] ? parse_args+0x212/0x330 +[ 0.000000] ? rdinit_setup+0x26/0x26 +[ 0.000000] ? parse_early_options+0x20/0x23 +[ 0.000000] ? rdinit_setup+0x26/0x26 +[ 0.000000] ? parse_early_param+0x2d/0x39 +[ 0.000000] ? setup_arch+0x2f7/0xbf4 +[ 0.000000] ? start_kernel+0x5e/0x4c2 +[ 0.000000] ? load_ucode_bsp+0x113/0x12f +[ 0.000000] ? secondary_startup_64+0xa5/0xb0 + +This patch adds checks to prevent the panic. + +Signed-off-by: He Zhe +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: gregkh@linuxfoundation.org +Cc: kstewart@linuxfoundation.org +Cc: pombredanne@nexb.com +Cc: stable@vger.kernel.org +Link: http://lkml.kernel.org/r/1534260823-87917-1-git-send-email-zhe.he@windriver.com +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/check.c | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +--- a/arch/x86/kernel/check.c ++++ b/arch/x86/kernel/check.c +@@ -30,6 +30,11 @@ static __init int set_corruption_check(c + ssize_t ret; + unsigned long val; + ++ if (!arg) { ++ pr_err("memory_corruption_check config string not provided\n"); ++ return -EINVAL; ++ } ++ + ret = kstrtoul(arg, 10, &val); + if (ret) + return ret; +@@ -44,6 +49,11 @@ static __init int set_corruption_check_p + ssize_t ret; + unsigned long val; + ++ if (!arg) { ++ pr_err("memory_corruption_check_period config string not provided\n"); ++ return -EINVAL; ++ } ++ + ret = kstrtoul(arg, 10, &val); + if (ret) + return ret; +@@ -58,6 +68,11 @@ static __init int set_corruption_check_s + char *end; + unsigned size; + ++ if (!arg) { ++ pr_err("memory_corruption_check_size config string not provided\n"); ++ return -EINVAL; ++ } ++ + size = memparse(arg, &end); + + if (*end == '\0') diff --git a/queue-4.4/x86-kconfig-fall-back-to-ticket-spinlocks.patch b/queue-4.4/x86-kconfig-fall-back-to-ticket-spinlocks.patch new file mode 100644 index 00000000000..84aef90f1a5 --- /dev/null +++ b/queue-4.4/x86-kconfig-fall-back-to-ticket-spinlocks.patch @@ -0,0 +1,136 @@ +From wagi@monom.org Sat Nov 10 10:41:00 2018 +From: Daniel Wagner +Date: Wed, 31 Oct 2018 09:14:58 +0100 +Subject: x86/kconfig: Fall back to ticket spinlocks +To: stable@vger.kernel.org, linux-kernel@vger.kernel.org +Cc: Greg Kroah-Hartman , Daniel Wagner , Sebastian Andrzej Siewior , Peter Zijlstra , Thomas Gleixner +Message-ID: <20181031081458.13996-1-wagi@monom.org> + +From: Daniel Wagner + +Sebastian writes: + +""" +We reproducibly observe cache line starvation on a Core2Duo E6850 (2 +cores), a i5-6400 SKL (4 cores) and on a NXP LS2044A ARM Cortex-A72 (4 +cores). + +The problem can be triggered with a v4.9-RT kernel by starting + + cyclictest -S -p98 -m -i2000 -b 200 + +and as "load" + + stress-ng --ptrace 4 + +The reported maximal latency is usually less than 60us. If the problem +triggers then values around 400us, 800us or even more are reported. The +upperlimit is the -i parameter. + +Reproduction with 4.9-RT is almost immediate on Core2Duo, ARM64 and SKL, +but it took 7.5 hours to trigger on v4.14-RT on the Core2Duo. + +Instrumentation show always the picture: + +CPU0 CPU1 +=> do_syscall_64 => do_syscall_64 +=> SyS_ptrace => syscall_slow_exit_work +=> ptrace_check_attach => ptrace_do_notify / rt_read_unlock +=> wait_task_inactive rt_spin_lock_slowunlock() + -> while task_running() __rt_mutex_unlock_common() + / check_task_state() mark_wakeup_next_waiter() + | raw_spin_lock_irq(&p->pi_lock); raw_spin_lock(¤t->pi_lock); + | . . + | raw_spin_unlock_irq(&p->pi_lock); . + \ cpu_relax() . + - . + *IRQ* + +In the error case we observe that the while() loop is repeated more than +5000 times which indicates that the pi_lock can be acquired. CPU1 on the +other side does not make progress waiting for the same lock with interrupts +disabled. + +This continues until an IRQ hits CPU0. Once CPU0 starts processing the IRQ +the other CPU is able to acquire pi_lock and the situation relaxes. +""" + +This matches with the observeration for v4.4-rt on a Core2Duo E6850: + +CPU 0: + +- no progress for a very long time in rt_mutex_dequeue_pi): + +stress-n-1931 0d..11 5060.891219: function: __try_to_take_rt_mutex +stress-n-1931 0d..11 5060.891219: function: rt_mutex_dequeue +stress-n-1931 0d..21 5060.891220: function: rt_mutex_enqueue_pi +stress-n-1931 0....2 5060.891220: signal_generate: sig=17 errno=0 code=262148 comm=stress-ng-ptrac pid=1928 grp=1 res=1 +stress-n-1931 0d..21 5060.894114: function: rt_mutex_dequeue_pi +stress-n-1931 0d.h11 5060.894115: local_timer_entry: vector=239 + +CPU 1: + +- IRQ at 5060.894114 on CPU 1 followed by the IRQ on CPU 0 + +stress-n-1928 1....0 5060.891215: sys_enter: NR 101 (18, 78b, 0, 0, 17, 788) +stress-n-1928 1d..11 5060.891216: function: __try_to_take_rt_mutex +stress-n-1928 1d..21 5060.891216: function: rt_mutex_enqueue_pi +stress-n-1928 1d..21 5060.891217: function: rt_mutex_dequeue_pi +stress-n-1928 1....1 5060.891217: function: rt_mutex_adjust_prio +stress-n-1928 1d..11 5060.891218: function: __rt_mutex_adjust_prio +stress-n-1928 1d.h10 5060.894114: local_timer_entry: vector=239 + +Thomas writes: + +""" +This has nothing to do with RT. RT is merily exposing the +problem in an observable way. The same issue happens with upstream, it's +harder to trigger and it's harder to observe for obvious reasons. + +If you read through the discussions [see the links below] then you +really see that there is an upstream issue with the x86 qrlock +implementation and Peter has posted fixes which resolve it, both at +the practical and the theoretical level. +""" + +Backporting all qspinlock related patches is very likely to introduce +regressions on v4.4. Therefore, the recommended solution by Peter and +Thomas is to drop back to ticket spinlocks for v4.4. + +Link :https://lkml.kernel.org/r/20180921120226.6xjgr4oiho22ex75@linutronix.de +Link: https://lkml.kernel.org/r/20180926110117.405325143@infradead.org +Cc: Sebastian Andrzej Siewior +Acked-by: Peter Zijlstra +Acked-by: Thomas Gleixner +Signed-off-by: Daniel Wagner +Signed-off-by: Greg Kroah-Hartman +--- + +Thomas suggest following plan for fixing the issues on the varous +stable trees: + + 4.4: Trivial by switching back to ticket locks. + + 4.9: Decide whether bringing back ticket locks or backporting all qrlock + fixes. Sebastian has done the latter already and it's probably the + right solution + + 4.14: + 4.18: Backporting the qrlock fixes + + 4.19: Either the fix ends up in 4.19 final or it needs to be backported + + + arch/x86/Kconfig | 1 - + 1 file changed, 1 deletion(-) + +--- a/arch/x86/Kconfig ++++ b/arch/x86/Kconfig +@@ -41,7 +41,6 @@ config X86 + select ARCH_USE_BUILTIN_BSWAP + select ARCH_USE_CMPXCHG_LOCKREF if X86_64 + select ARCH_USE_QUEUED_RWLOCKS +- select ARCH_USE_QUEUED_SPINLOCKS + select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH + select ARCH_WANTS_DYNAMIC_TASK_STRUCT + select ARCH_WANT_FRAME_POINTERS