Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

291 participants
124124 discussions

FAILED: patch "[PATCH] ARC: mm: do_page_fault fixes #1: relinquish mmap_sem if" failed to apply to 4.20-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.20-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 4d447455e73b47c43dd35fcc38ed823d3182a474 Mon Sep 17 00:00:00 2001 From: Vineet Gupta <vgupta(a)synopsys.com> Date: Mon, 10 Dec 2018 16:56:45 -0800 Subject: [PATCH] ARC: mm: do_page_fault fixes #1: relinquish mmap_sem if signal arrives while handle_mm_fault do_page_fault() forgot to relinquish mmap_sem if a signal came while handling handle_mm_fault() - due to say a ctl+c or oom etc. This would later cause a deadlock by acquiring it twice. This came to light when running libc testsuite tst-tls3-malloc test but is likely also the cause for prior seen LTP failures. Using lockdep clearly showed what the issue was. | # while true; do ./tst-tls3-malloc ; done | Didn't expect signal from child: got `Segmentation fault' | ^C | ============================================ | WARNING: possible recursive locking detected | 4.17.0+ #25 Not tainted | -------------------------------------------- | tst-tls3-malloc/510 is trying to acquire lock: | 606c7728 (&mm->mmap_sem){++++}, at: __might_fault+0x28/0x5c | |but task is already holding lock: |606c7728 (&mm->mmap_sem){++++}, at: do_page_fault+0x9c/0x2a0 | | other info that might help us debug this: | Possible unsafe locking scenario: | | CPU0 | ---- | lock(&mm->mmap_sem); | lock(&mm->mmap_sem); | | *** DEADLOCK *** | ------------------------------------------------------------ What the change does is not obvious (note to myself) prior code was | do_page_fault | | down_read() <-- lock taken | handle_mm_fault <-- signal pending as this runs | if fatal_signal_pending | if VM_FAULT_ERROR | up_read | if user_mode | return <-- lock still held, this was the BUG New code | do_page_fault | | down_read() <-- lock taken | handle_mm_fault <-- signal pending as this runs | if fatal_signal_pending | if VM_FAULT_RETRY | return <-- not same case as above, but still OK since | core mm already relinq lock for FAULT_RETRY | ... | | < Now falls through for bug case above > | | up_read() <-- lock relinquished Cc: stable(a)vger.kernel.org Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com> diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c index a1d723197084..8df1638259f3 100644 --- a/arch/arc/mm/fault.c +++ b/arch/arc/mm/fault.c @@ -141,12 +141,17 @@ void do_page_fault(unsigned long address, struct pt_regs *regs) */ fault = handle_mm_fault(vma, address, flags); - /* If Pagefault was interrupted by SIGKILL, exit page fault "early" */ if (fatal_signal_pending(current)) { - if ((fault & VM_FAULT_ERROR) && !(fault & VM_FAULT_RETRY)) - up_read(&mm->mmap_sem); - if (user_mode(regs)) + + /* + * if fault retry, mmap_sem already relinquished by core mm + * so OK to return to user mode (with signal handled first) + */ + if (fault & VM_FAULT_RETRY) { + if (!user_mode(regs)) + goto no_context; return; + } } perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);

6 years, 11 months

FAILED: patch "[PATCH] ARC: show_regs: lockdep: re-enable preemption" failed to apply to 4.20-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.20-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From f731a8e89f8c78985707c626680f3e24c7a60772 Mon Sep 17 00:00:00 2001 From: Vineet Gupta <vgupta(a)synopsys.com> Date: Tue, 18 Dec 2018 10:39:58 -0800 Subject: [PATCH] ARC: show_regs: lockdep: re-enable preemption signal handling core calls show_regs() with preemption disabled which on ARC takes mmap_sem for mm/vma access, causing lockdep splat. | [ARCLinux]# ./segv-null-ptr | potentially unexpected fatal signal 11. | BUG: sleeping function called from invalid context at kernel/fork.c:1011 | in_atomic(): 1, irqs_disabled(): 0, pid: 70, name: segv-null-ptr | no locks held by segv-null-ptr/70. | CPU: 0 PID: 70 Comm: segv-null-ptr Not tainted 4.18.0+ #69 | | Stack Trace: | arc_unwind_core+0xcc/0x100 | ___might_sleep+0x17a/0x190 | mmput+0x16/0xb8 | show_regs+0x52/0x310 | get_signal+0x5ee/0x610 | do_signal+0x2c/0x218 | resume_user_mode_begin+0x90/0xd8 Workaround by re-enabling preemption temporarily. Note that the preemption disabling in core code around show_regs() was introduced by commit 3a9f84d354ce ("signals, debug: fix BUG: using smp_processor_id() in preemptible code in print_fatal_signal()") to silence a differnt lockdep seen on x86 bakc in 2009. Cc: <stable(a)vger.kernel.org> Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com> diff --git a/arch/arc/kernel/troubleshoot.c b/arch/arc/kernel/troubleshoot.c index 5c6663321e87..215f515442e0 100644 --- a/arch/arc/kernel/troubleshoot.c +++ b/arch/arc/kernel/troubleshoot.c @@ -179,6 +179,12 @@ void show_regs(struct pt_regs *regs) struct task_struct *tsk = current; struct callee_regs *cregs; + /* + * generic code calls us with preemption disabled, but some calls + * here could sleep, so re-enable to avoid lockdep splat + */ + preempt_enable(); + print_task_path_n_nm(tsk); show_regs_print_info(KERN_INFO); @@ -221,6 +227,8 @@ void show_regs(struct pt_regs *regs) cregs = (struct callee_regs *)current->thread.callee_reg; if (cregs) show_callee_regs(cregs); + + preempt_disable(); } void show_kernel_fault_diag(const char *str, struct pt_regs *regs,

6 years, 11 months

FAILED: patch "[PATCH] ARCv2: lib: memeset: fix doing prefetchw outside of buffer" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From e6a72b7daeeb521753803550f0ed711152bb2555 Mon Sep 17 00:00:00 2001 From: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> Date: Mon, 14 Jan 2019 18:16:48 +0300 Subject: [PATCH] ARCv2: lib: memeset: fix doing prefetchw outside of buffer ARCv2 optimized memset uses PREFETCHW instruction for prefetching the next cache line but doesn't ensure that the line is not past the end of the buffer. PRETECHW changes the line ownership and marks it dirty, which can cause issues in SMP config when next line was already owned by other core. Fix the issue by avoiding the PREFETCHW Some more details: The current code has 3 logical loops (ignroing the unaligned part) (a) Big loop for doing aligned 64 bytes per iteration with PREALLOC (b) Loop for 32 x 2 bytes with PREFETCHW (c) any left over bytes loop (a) was already eliding the last 64 bytes, so PREALLOC was safe. The fix was removing PREFETCW from (b). Another potential issue (applicable to configs with 32 or 128 byte L1 cache line) is that PREALLOC assumes 64 byte cache line and may not do the right thing specially for 32b. While it would be easy to adapt, there are no known configs with those lie sizes, so for now, just compile out PREALLOC in such cases. Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> Cc: stable(a)vger.kernel.org #4.4+ Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com> [vgupta: rewrote changelog, used asm .macro vs. "C" macro] diff --git a/arch/arc/lib/memset-archs.S b/arch/arc/lib/memset-archs.S index 62ad4bcb841a..f230bb7092fd 100644 --- a/arch/arc/lib/memset-archs.S +++ b/arch/arc/lib/memset-archs.S @@ -7,11 +7,39 @@ */ #include <linux/linkage.h> +#include <asm/cache.h> -#undef PREALLOC_NOT_AVAIL +/* + * The memset implementation below is optimized to use prefetchw and prealloc + * instruction in case of CPU with 64B L1 data cache line (L1_CACHE_SHIFT == 6) + * If you want to implement optimized memset for other possible L1 data cache + * line lengths (32B and 128B) you should rewrite code carefully checking + * we don't call any prefetchw/prealloc instruction for L1 cache lines which + * don't belongs to memset area. + */ + +#if L1_CACHE_SHIFT == 6 + +.macro PREALLOC_INSTR reg, off + prealloc [\reg, \off] +.endm + +.macro PREFETCHW_INSTR reg, off + prefetchw [\reg, \off] +.endm + +#else + +.macro PREALLOC_INSTR +.endm + +.macro PREFETCHW_INSTR +.endm + +#endif ENTRY_CFI(memset) - prefetchw [r0] ; Prefetch the write location + PREFETCHW_INSTR r0, 0 ; Prefetch the first write location mov.f 0, r2 ;;; if size is zero jz.d [blink] @@ -48,11 +76,8 @@ ENTRY_CFI(memset) lpnz @.Lset64bytes ;; LOOP START -#ifdef PREALLOC_NOT_AVAIL - prefetchw [r3, 64] ;Prefetch the next write location -#else - prealloc [r3, 64] -#endif + PREALLOC_INSTR r3, 64 ; alloc next line w/o fetching + #ifdef CONFIG_ARC_HAS_LL64 std.ab r4, [r3, 8] std.ab r4, [r3, 8] @@ -85,7 +110,6 @@ ENTRY_CFI(memset) lsr.f lp_count, r2, 5 ;Last remaining max 124 bytes lpnz .Lset32bytes ;; LOOP START - prefetchw [r3, 32] ;Prefetch the next write location #ifdef CONFIG_ARC_HAS_LL64 std.ab r4, [r3, 8] std.ab r4, [r3, 8]

6 years, 11 months

v4.20.5 build: 0 failures 4 warnings (v4.20.5)

by Build bot for Mark Brown

Tree/Branch: v4.20.5 Git describe: v4.20.5 Commit: 9f1a389a0b Linux 4.20.5 Build Time: 130 min 15 sec Passed: 11 / 11 (100.00 %) Failed: 0 / 11 ( 0.00 %) Errors: 0 Warnings: 4 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 1 warnings 0 mismatches : arm64-allmodconfig 3 warnings 0 mismatches : arm-allmodconfig ------------------------------------------------------------------------------- Warnings Summary: 4 1 ../drivers/staging/erofs/unzip_vle.c:188:29: warning: array subscript is above array bounds [-Warray-bounds] 1 ../drivers/scsi/myrs.c:821:24: warning: 'sshdr.sense_key' may be used uninitialized in this function [-Wmaybe-uninitialized] 1 ../drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:216:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=] 1 ../drivers/isdn/hardware/eicon/message.c:5985:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/isdn/hardware/eicon/message.c:5985:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] ------------------------------------------------------------------------------- arm-allmodconfig : PASS, 0 errors, 3 warnings, 0 section mismatches Warnings: ../drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:216:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=] ../drivers/staging/erofs/unzip_vle.c:188:29: warning: array subscript is above array bounds [-Warray-bounds] ../drivers/scsi/myrs.c:821:24: warning: 'sshdr.sense_key' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig x86_64-allmodconfig arm64-defconfig

6 years, 11 months

Stable queue: queue-4.20

by CKI

Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 9f1a389a0b5b Linux 4.20.5 The results of these automated tests are provided below. Overall result: PASSED Patch merge: OK Compile: OK Kernel tests: OK Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Merge testing ------------- We cloned this repository and checked out a ref: Repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Ref: 9f1a389a0b5b Linux 4.20.5 We then merged the following patches with `git am`: amd-xgbe-fix-mdio-access-for-non-zero-ports-and-clause-45-phys.patch net-bridge-fix-ethernet-header-pointer-before-check-skb-forwardable.patch net-fix-usage-of-pskb_trim_rcsum.patch net-phy-marvell-errata-for-mv88e6390-internal-phys.patch net-phy-mdio_bus-add-missing-device_del-in-mdiobus_register-error-handling.patch net-phy-phy-driver-features-are-mandatory.patch net-sched-act_tunnel_key-fix-memory-leak-in-case-of-action-replace.patch net_sched-refetch-skb-protocol-for-each-filter.patch openvswitch-avoid-oob-read-when-parsing-flow-nlattrs.patch vhost-log-dirty-page-correctly.patch mlxsw-pci-increase-pci-sw-reset-timeout.patch net-ipv4-fix-memory-leak-in-network-namespace-dismantle.patch mlxsw-spectrum_fid-update-dummy-fid-index.patch mlxsw-pci-ring-cq-s-doorbell-before-rdq-s.patch net-sched-cls_flower-allocate-mask-dynamically-in-fl_change.patch udp-with-udp_segment-release-on-error-path.patch ip6_gre-fix-tunnel-list-corruption-for-x-netns.patch erspan-build-the-header-with-the-right-proto-according-to-erspan_ver.patch net-phy-marvell-fix-deadlock-from-wrong-locking.patch ip6_gre-update-version-related-info-when-changing-link.patch tcp-allow-msg_zerocopy-transmission-also-in-close_wait-state.patch arm-fix-the-cockup-in-the-previous-patch.patch sunrpc-address-kerberos-performance-behavior-regress.patch Compile testing --------------- We compiled the kernel for 4 architectures: s390x: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/s390x/028e11ea85578d0c7bc7132468d5… powerpc64le: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/ppc64le/ec3ea1c67f971c7397dda088a8… aarch64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/aarch64/656836e683c8f8bf81eb206271… x86_64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/x86_64/48d980621d398141252331b80ef… Hardware testing ---------------- We booted each kernel and ran the following tests: s390: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu powerpc: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… arm64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… x86_64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us…

6 years, 11 months

Re: [PATCH v2] usb: dwc3: gadget: Clear req->needs_extra_trb flag on cleanup

by Jack Pham

Hi Sasha, On Wed, Jan 16, 2019 at 01:35:52PM +0000, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: c6267a51639b usb: dwc3: gadget: align transfers to wMaxPacketSize. > > The bot has tested the following trees: v4.20.2, v4.19.15, v4.14.93. > > v4.20.2: Build failed! Errors: > drivers/usb/dwc3/gadget.c:180:5: error: ‘struct dwc3_request’ has no member named ‘needs_extra_trb’ > > v4.19.15: Build failed! Errors: > drivers/usb/dwc3/gadget.c:180:5: error: ‘struct dwc3_request’ has no member named ‘needs_extra_trb’ > > v4.14.93: Build failed! Errors: > drivers/usb/dwc3/gadget.c:185:5: error: ‘struct dwc3_request’ has no member named ‘needs_extra_trb’ > > > How should we proceed with this patch? I mentioned in my "cover" message of the patch that it needs a slight rewrite for -stable since the 'needs_extra_trb' was only introduced in v5.0-rc1. Now that my patch is in Linus's tree, I can send it separately for -stable; I'll fix up the commit text slightly to refer to the variables used before v5.0. Thanks, Jack -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

6 years, 11 months

[PATCH v4.14] mmc: Kconfig: Enable CONFIG_MMC_SDHCI_IO_ACCESSORS

by Georgi Djakov

From: Vijay Viswanath <vviswana(a)codeaurora.org> commit 99d570da309813f67e9c741edeff55bafc6c1d5e upstream. Enable CONFIG_MMC_SDHCI_IO_ACCESSORS so that SDHC controller specific register read and write APIs, if registered, can be used. Signed-off-by: Vijay Viswanath <vviswana(a)codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Cc: Koen Vandeputte <koen.vandeputte(a)ncentric.com> Cc: Loic Poulain <loic.poulain(a)linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov(a)linaro.org> --- We got a report [1] that a specific platform (ipq806x) fails to build, after the following commit in the v4.14 stable kernel: 4abb6960f61c ("mmc: sdhci-msm: Disable CDR function on TX") Let's pick this patch into v4.14.y to automagically select this Kconfig dependency for platforms which have enabled the driver, but not the accessors in their kernel config. [1] https://www.spinics.net/lists/linux-mmc/msg52983.html drivers/mmc/host/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index 8c15637178ff..9ed786935a30 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -429,6 +429,7 @@ config MMC_SDHCI_MSM tristate "Qualcomm SDHCI Controller Support" depends on ARCH_QCOM || (ARM && COMPILE_TEST) depends on MMC_SDHCI_PLTFM + select MMC_SDHCI_IO_ACCESSORS help This selects the Secure Digital Host Controller Interface (SDHCI) support present in Qualcomm SOCs. The controller supports

6 years, 11 months

[stable] ipfrag: really prevent allocation on netns exit

by Ben Hutchings

Please pick this commit for the 4.9 and 4.14 stable branches: commit f6f2a4a2eb92bc73671204198bb2f8ab53ff59fb Author: Paolo Abeni <pabeni(a)redhat.com> Date: Fri Jul 6 12:30:20 2018 +0200 ipfrag: really prevent allocation on netns exit It's not needed on earlier branches unless other commits are also applied. Ben. -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom

6 years, 11 months

Re: Need help debugging NFS issues new to 4.20 kernel

by Schumaker, Anna

On Thu, 2019-01-24 at 19:58 +0000, Trond Myklebust wrote: > On Thu, 2019-01-24 at 11:32 -0600, Jason L Tibbitts III wrote: > > I could use some help figuring out the cause of some serious NFS > > client > > issues I'm having with the 4.20.3 kernel which I did not see under > > 4.19.15. > > > > I have a network of about 130 desktops (plus a bunch of other > > machines, > > VMs and the like) running Fedora 29 connecting to six NFS servers > > running CentOS 7.6 (with the heavily patched vendor kernel > > 3.10.0-957.1.3). All machines involved are x86_64. We use > > kerberized > > NFS4 with generally sec=krb5i. The exports are generally made with > > "(rw,async,sec=krb5i:krb5p)". > > > > Since I booted those clients into 4.20.3 I've started seeing > > processes > > getting stuck in the D state. The system itself will seem OK (except > > for the high load average) as long as I don't touch the hung NFS > > mount. > > Nothing was logged to dmesg or to the journal. So far booting back > > into > > the 4.19.15 kernel has cleared up the problem. I cannot yet > > reproduce > > this on demand; I've tried but it is probably related to some > > specific > > usage pattern. > > > > Has anyone else seen issues like this? Can anyone help me to get > > more > > useful information that might point to the problem? I still haven't > > learned how to debug NFS issues properly. And if there's a stress > > test > > tool I could easily run that might help to reproduce the issue, I'd > > be > > happy to run it. > > > > I note that 4.20.4 is out; I see one sunrpc fix which I guess could > > be > > related (sunrpc: handle ENOMEM in rpcb_getport_async) but the systems > > involved have plenty of free memory so I doubt that's it. I'll > > certainly try it anyway. > > > > Various package versions: > > kernel-4.20.3-200.fc29.x86_64 (the problematic kernel) > > kernel-4.19.15-300.fc29.x86_64 (the functional kernel) > > nfs-utils-2.3.3-1.rc2.fc29.x86_64 > > gssproxy-0.8.0-6.fc29.x86_64 > > krb5-libs-1.16.1-25.fc29.i686 > > > > Thanks in advance for any help or advice, > > > > - J< > > Commit deaa5c96c2f7 ("SUNRPC: Address Kerberos performance/behavior > regression") was supposed to be marked for stable as a fix. Chuck & > Anna? Looks like I missed that, sorry! Stable folks, can you please backport deaa5c96c2f7 ("SUNRPC: Address Kerberos performance/behavior regression") to v4.20? Thanks, Anna > -- > Trond Myklebust > Linux NFS client maintainer, Hammerspace > trond.myklebust(a)hammerspace.com > >

6 years, 11 months

[PATCH 4.20 0/1] Fix regression from arm spectre patch series

by David Long

From: "David A. Long" <dave.long(a)linaro.org> Backport upstream patch for regression introduced from spectre patch series. This was run through kernelci testing. Also the kernel was built with and without BIG_LITTLE and the symbol table was examined to verify the processor tables do not go into .rodata when BIG_LITTLE=n. Russell King (1): ARM: fix the cockup in the previous patch arch/arm/mm/proc-macros.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.17.1

6 years, 11 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror