Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

209 participants
124029 discussions

Start a nNew thread

stable-rc 4.14.181-rc1/ad4fc99d1989: no regressions found in project stable v4.14.y

by Naresh Kamboju

5 years, 7 months

stable-rc 4.9.224-rc1/6dfb25040a46: no regressions found in project stable v4.9.y

by Naresh Kamboju

5 years, 7 months

Please apply Revert "serial/8250: Add support for NI-Serial PXI/PXIe+485 devices

by Linus Walleij

Hi Stable folks, please apply commit 27ed14d0ecb38516b6f3c6fdcd62c25c9454f979 Revert "serial/8250: Add support for NI-Serial PXI/PXIe+485 devices" also to the stable tree. My Fedora cannot switch baudrate or write to my serial port and that makes me so sad. I have this problem with kernel v5.6.11. Thanks! Linus Walleij

5 years, 7 months

[PATCH 5.4.33 0/2] Fix for long operation cmds busy detection

by Sowjanya Komatineni

This series is to backport the upstream patches that fixes busy detection for long operation mmc commands by implementing Tegra specific timeout callback to switch between finite and infinite HW busy detection wait modes. Sowjanya Komatineni (2): sdhci: tegra: Implement Tegra specific set_timeout callback sdhci: tegra: Enable MMC_CAP_WAIT_WHILE_BUSY host capability drivers/mmc/host/sdhci-tegra.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) -- 2.7.4

5 years, 7 months

stable-rc 4.4.224-rc1/e6bc7c5d4464: no regressions found in project stable v4.4.y

by Naresh Kamboju

Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary ------------------------------------------------------------------------ kernel: 4.4.224-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: e6bc7c5d44642105766e5b29c57be37c6319c772 git describe: v4.4.223-17-ge6bc7c5d4464 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.223-17… No regressions (compared to build v4.4.223) No fixes (compared to build v4.4.223) Ran 20346 total tests in the following environments and test suites. Environments -------------- - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - x15 - arm - x86_64 - x86-kasan Test Suites ----------- * build * kselftest * kselftest/drivers * kselftest/filesystems * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * network-basic-tests * perf * v4l2-compliance * kvm-unit-tests * install-android-platform-tools-r2600 * install-android-platform-tools-r2800 * kselftest/net * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems Summary ------------------------------------------------------------------------ kernel: 4.4.224-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.224-rc1-hikey-20200512-720 git commit: 55c9d63788c49cf307f7cad2e830681578e6a7f6 git describe: 4.4.224-rc1-hikey-20200512-720 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.… No regressions (compared to build 4.4.223-rc3-hikey-20200509-718) No fixes (compared to build 4.4.223-rc3-hikey-20200509-718) Ran 1814 total tests in the following environments and test suites. Environments -------------- - hi6220-hikey - arm64 Test Suites ----------- * build * install-android-platform-tools-r2600 * kselftest * kselftest/drivers * kselftest/filesystems * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * spectre-meltdown-checker-test * v4l2-compliance -- Linaro LKFT https://lkft.linaro.org

5 years, 7 months

[PATCH] net: handle no dst on skb in icmp6_send

by Nobuhiro Iwamatsu

From: David Ahern <dsa(a)cumulusnetworks.com> commit 79dc7e3f1cd323be4c81aa1a94faa1b3ed987fb2 upstream. Andrey reported the following while fuzzing the kernel with syzkaller: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN Modules linked in: CPU: 0 PID: 3859 Comm: a.out Not tainted 4.9.0-rc6+ #429 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff8800666d4200 task.stack: ffff880067348000 RIP: 0010:[<ffffffff833617ec>] [<ffffffff833617ec>] icmp6_send+0x5fc/0x1e30 net/ipv6/icmp.c:451 RSP: 0018:ffff88006734f2c0 EFLAGS: 00010206 RAX: ffff8800666d4200 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000000018 RBP: ffff88006734f630 R08: ffff880064138418 R09: 0000000000000003 R10: dffffc0000000000 R11: 0000000000000005 R12: 0000000000000000 R13: ffffffff84e7e200 R14: ffff880064138484 R15: ffff8800641383c0 FS: 00007fb3887a07c0(0000) GS:ffff88006cc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 000000006b040000 CR4: 00000000000006f0 Stack: ffff8800666d4200 ffff8800666d49f8 ffff8800666d4200 ffffffff84c02460 ffff8800666d4a1a 1ffff1000ccdaa2f ffff88006734f498 0000000000000046 ffff88006734f440 ffffffff832f4269 ffff880064ba7456 0000000000000000 Call Trace: [<ffffffff83364ddc>] icmpv6_param_prob+0x2c/0x40 net/ipv6/icmp.c:557 [< inline >] ip6_tlvopt_unknown net/ipv6/exthdrs.c:88 [<ffffffff83394405>] ip6_parse_tlv+0x555/0x670 net/ipv6/exthdrs.c:157 [<ffffffff8339a759>] ipv6_parse_hopopts+0x199/0x460 net/ipv6/exthdrs.c:663 [<ffffffff832ee773>] ipv6_rcv+0xfa3/0x1dc0 net/ipv6/ip6_input.c:191 ... icmp6_send / icmpv6_send is invoked for both rx and tx paths. In both cases the dst->dev should be preferred for determining the L3 domain if the dst has been set on the skb. Fallback to the skb->dev if it has not. This covers the case reported here where icmp6_send is invoked on Rx before the route lookup. Fixes: 5d41ce29e ("net: icmp6_send should use dst dev to determine L3 domain") Reported-by: Andrey Konovalov <andreyknvl(a)google.com> Signed-off-by: David Ahern <dsa(a)cumulusnetworks.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu(a)toshiba.co.jp> --- net/ipv6/icmp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c index d21e81cd6120e..fa96e05cf22be 100644 --- a/net/ipv6/icmp.c +++ b/net/ipv6/icmp.c @@ -445,8 +445,10 @@ static void icmp6_send(struct sk_buff *skb, u8 type, u8 code, __u32 info) if (__ipv6_addr_needs_scope_id(addr_type)) iif = skb->dev->ifindex; - else - iif = l3mdev_master_ifindex(skb_dst(skb)->dev); + else { + dst = skb_dst(skb); + iif = l3mdev_master_ifindex(dst ? dst->dev : skb->dev); + } /* * Must not send error if the source does not uniquely -- 2.26.0

5 years, 7 months

[PATCH for 4.4, 4.9] binfmt_elf: Do not move brk for INTERP-less ET_EXEC

by Nobuhiro Iwamatsu

From: Kees Cook <keescook(a)chromium.org> commit 7be3cb019db1cbd5fd5ffe6d64a23fefa4b6f229 upstream. When brk was moved for binaries without an interpreter, it should have been limited to ET_DYN only. In other words, the special case was an ET_DYN that lacks an INTERP, not just an executable that lacks INTERP. The bug manifested for giant static executables, where the brk would end up in the middle of the text area on 32-bit architectures. Reported-and-tested-by: Richard Kojedzinszky <richard(a)kojedz.in> Fixes: bbdc6076d2e5 ("binfmt_elf: move brk out of mmap when doing direct loader exec") Cc: stable(a)vger.kernel.org Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu(a)toshiba.co.jp> --- fs/binfmt_elf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index a6857e9bd4460..164e5fedd7b6a 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -1104,7 +1104,8 @@ static int load_elf_binary(struct linux_binprm *bprm) * (since it grows up, and may collide early with the stack * growing down), and into the unused ELF_ET_DYN_BASE region. */ - if (IS_ENABLED(CONFIG_ARCH_HAS_ELF_RANDOMIZE) && !interpreter) + if (IS_ENABLED(CONFIG_ARCH_HAS_ELF_RANDOMIZE) && + loc->elf_ex.e_type == ET_DYN && !interpreter) current->mm->brk = current->mm->start_brk = ELF_ET_DYN_BASE; -- 2.26.0

5 years, 7 months

[PATCH V5 02/15] KVM: MIPS: Fix VPN2_MASK definition for variable cpu_vmbits

by Huacai Chen

From: Xing Li <lixing(a)loongson.cn> If a CPU support more than 32bit vmbits (which is true for 64bit CPUs), VPN2_MASK set to fixed 0xffffe000 will lead to a wrong EntryHi in some functions such as _kvm_mips_host_tlb_inv(). The cpu_vmbits definition of 32bit CPU in cpu-features.h is 31, so we still use the old definition. Cc: stable(a)vger.kernel.org Reviewed-by: Aleksandar Markovic <aleksandar.qemu.devel(a)gmail.com> Signed-off-by: Xing Li <lixing(a)loongson.cn> [Huacai: Improve commit messages] Signed-off-by: Huacai Chen <chenhc(a)lemote.com> --- arch/mips/include/asm/kvm_host.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h index a01cee9..caa2b936 100644 --- a/arch/mips/include/asm/kvm_host.h +++ b/arch/mips/include/asm/kvm_host.h @@ -274,7 +274,11 @@ enum emulation_result { #define MIPS3_PG_SHIFT 6 #define MIPS3_PG_FRAME 0x3fffffc0 +#if defined(CONFIG_64BIT) +#define VPN2_MASK GENMASK(cpu_vmbits - 1, 13) +#else #define VPN2_MASK 0xffffe000 +#endif #define KVM_ENTRYHI_ASID cpu_asid_mask(&boot_cpu_data) #define TLB_IS_GLOBAL(x) ((x).tlb_lo[0] & (x).tlb_lo[1] & ENTRYLO_G) #define TLB_VPN2(x) ((x).tlb_hi & VPN2_MASK) -- 2.7.0

5 years, 7 months

stable-rc/linux-4.14.y boot: 101 boots: 2 failed, 90 passed with 7 offline, 2 untried/unknown (v4.14.180-37-gad4fc99d1989)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 101 boots: 2 failed, 90 passed with 7 offline, 2 untried/unknown (v4.14.180-37-gad4fc99d1989) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.180-3… Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.180-37-gad4fc99d1989 Git Commit: ad4fc99d19898b966c3fa74c7adaaee8d12da3a9 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 66 unique boards, 18 SoC families, 17 builds out of 201 Boot Regressions Detected: arm: davinci_all_defconfig: gcc-8: da850-evm: lab-baylibre-seattle: new failure (last pass: v4.14.180) dm365evm,legacy: lab-baylibre-seattle: new failure (last pass: v4.14.180) qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: new failure (last pass: v4.14.180) Boot Failures Detected: arm64: defconfig: gcc-8: meson-gxbb-p200: 1 failed lab meson-gxm-q200: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab stih410-b2120: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 7 months

[PATCH 12/62] mtd: rawnand: diskonchip: Fix the probe error path

by Miquel Raynal

Not sure nand_cleanup() is the right function to call here but in any case it is not nand_release(). Indeed, even a comment says that calling nand_release() is a bit of a hack as there is no MTD device to unregister. So switch to nand_cleanup() for now and drop this comment. There is no Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if it did not intruce any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> Cc: stable(a)vger.kernel.org --- drivers/mtd/nand/raw/diskonchip.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/nand/raw/diskonchip.c b/drivers/mtd/nand/raw/diskonchip.c index c2a391ad2c35..baabc6633557 100644 --- a/drivers/mtd/nand/raw/diskonchip.c +++ b/drivers/mtd/nand/raw/diskonchip.c @@ -1609,13 +1609,10 @@ static int __init doc_probe(unsigned long physadr) numchips = doc2001_init(mtd); if ((ret = nand_scan(nand, numchips)) || (ret = doc->late_init(mtd))) { - /* DBB note: i believe nand_release is necessary here, as + /* DBB note: i believe nand_cleanup is necessary here, as buffers may have been allocated in nand_base. Check with Thomas. FIX ME! */ - /* nand_release will call mtd_device_unregister, but we - haven't yet added it. This is handled without incident by - mtd_device_unregister, as far as I can tell. */ - nand_release(nand); + nand_cleanup(nand); goto fail; } -- 2.20.1

5 years, 7 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror