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

[PATCH AUTOSEL 4.9 01/26] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware

by Sasha Levin

From: Masahiro Yamada <masahiroy(a)kernel.org> [ Upstream commit 63b903dfebdea92aa92ad337d8451a6fbfeabf9d ] As far as I understood from the Kconfig help text, this build rule is used to rebuild the driver firmware, which runs on an old m68k-based chip. So, you need m68k tools for the firmware rebuild. wanxl.c is a PCI driver, but CONFIG_M68K does not select CONFIG_HAVE_PCI. So, you cannot enable CONFIG_WANXL_BUILD_FIRMWARE for ARCH=m68k. In other words, ifeq ($(ARCH),m68k) is false here. I am keeping the dead code for now, but rebuilding the firmware requires 'as68k' and 'ld68k', which I do not have in hand. Instead, the kernel.org m68k GCC [1] successfully built it. Allowing a user to pass in CROSS_COMPILE_M68K= is handier. [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/9.2.0/… Suggested-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/wan/Kconfig | 2 +- drivers/net/wan/Makefile | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig index 4e9fe75d70675..21190dfbabb16 100644 --- a/drivers/net/wan/Kconfig +++ b/drivers/net/wan/Kconfig @@ -199,7 +199,7 @@ config WANXL_BUILD_FIRMWARE depends on WANXL && !PREVENT_FIRMWARE_BUILD help Allows you to rebuild firmware run by the QUICC processor. - It requires as68k, ld68k and hexdump programs. + It requires m68k toolchains and hexdump programs. You should never need this option, say N. diff --git a/drivers/net/wan/Makefile b/drivers/net/wan/Makefile index 73c2326603fcc..fbe8b2815a87c 100644 --- a/drivers/net/wan/Makefile +++ b/drivers/net/wan/Makefile @@ -40,17 +40,17 @@ $(obj)/wanxl.o: $(obj)/wanxlfw.inc ifeq ($(CONFIG_WANXL_BUILD_FIRMWARE),y) ifeq ($(ARCH),m68k) - AS68K = $(AS) - LD68K = $(LD) + M68KAS = $(AS) + M68KLD = $(LD) else - AS68K = as68k - LD68K = ld68k + M68KAS = $(CROSS_COMPILE_M68K)as + M68KLD = $(CROSS_COMPILE_M68K)ld endif quiet_cmd_build_wanxlfw = BLD FW $@ cmd_build_wanxlfw = \ - $(CPP) -D__ASSEMBLY__ -Wp,-MD,$(depfile) -I$(srctree)/include/uapi $< | $(AS68K) -m68360 -o $(obj)/wanxlfw.o; \ - $(LD68K) --oformat binary -Ttext 0x1000 $(obj)/wanxlfw.o -o $(obj)/wanxlfw.bin; \ + $(CPP) -D__ASSEMBLY__ -Wp,-MD,$(depfile) -I$(srctree)/include/uapi $< | $(M68KAS) -m68360 -o $(obj)/wanxlfw.o; \ + $(M68KLD) --oformat binary -Ttext 0x1000 $(obj)/wanxlfw.o -o $(obj)/wanxlfw.bin; \ hexdump -ve '"\n" 16/1 "0x%02X,"' $(obj)/wanxlfw.bin | sed 's/0x ,//g;1s/^/static const u8 firmware[]={/;$$s/,$$/\n};\n/' >$(obj)/wanxlfw.inc; \ rm -f $(obj)/wanxlfw.bin $(obj)/wanxlfw.o -- 2.20.1

5 years, 7 months

9
72
0 0

Re: [PATCH] uapi: fix userspace breakage, use __BITS_PER_LONG for swap

by 李义

> QEMU has a funny new build error message when I use the upstream kernel headers: > > CC block/file-posix.o > In file included from /home/cborntra/REPOS/qemu/include/qemu/timer.h:4, > from /home/cborntra/REPOS/qemu/include/qemu/timed-average.h:29, > from /home/cborntra/REPOS/qemu/include/block/accounting.h:28, > from /home/cborntra/REPOS/qemu/include/block/block_int.h:27, > from /home/cborntra/REPOS/qemu/block/file-posix.c:30: > /usr/include/linux/swab.h: In function ‘__swab’: > /home/cborntra/REPOS/qemu/include/qemu/bitops.h:20:34: error: "sizeof" is not defined, evaluates to 0 [-Werror=undef] > 20 | #define BITS_PER_LONG (sizeof (unsigned long) * BITS_PER_BYTE) > | ^~~~~~ > /home/cborntra/REPOS/qemu/include/qemu/bitops.h:20:41: error: missing binary operator before token "(" > 20 | #define BITS_PER_LONG (sizeof (unsigned long) * BITS_PER_BYTE) > | ^ > cc1: all warnings being treated as errors > make: *** [/home/cborntra/REPOS/qemu/rules.mak:69: block/file-posix.o] Error 1 > rm tests/qemu-iotests/socket_scm_helper.o > > This was triggered by commit d5767057c9a ("uapi: rename ext2_swab() to swab() and share globally in swab.h") > This patch is doing > +#include <asm/bitsperlong.h> > but it uses BITS_PER_LONG. > > The kernel file asm/bitsperlong.h provide only __BITS_PER_LONG. > > Let us use the __ variant in swap.h > Fixes: d5767057c9a ("uapi: rename ext2_swab() to swab() and share globally in swab.h") > Cc: Yury Norov <yury.norov(a)gmail.com> > Cc: Allison Randal <allison(a)lohutok.net> > Cc: Joe Perches <joe(a)perches.com> > Cc: Thomas Gleixner <tglx(a)linutronix.de> > Cc: William Breathitt Gray <vilhelm.gray(a)gmail.com> > Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com> > --- > include/uapi/linux/swab.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h > index fa7f97da5b76..7272f85d6d6a 100644 > --- a/include/uapi/linux/swab.h > +++ b/include/uapi/linux/swab.h > @@ -135,9 +135,9 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val) > > static __always_inline unsigned long __swab(const unsigned long y) > { > -#if BITS_PER_LONG == 64 > +#if __BITS_PER_LONG == 64 > return __swab64(y); > -#else /* BITS_PER_LONG == 32 */ > +#else /* __BITS_PER_LONG == 32 */ > return __swab32(y); > #endif > } Cc: <stable(a)vger.kernel.org> # 4.19.x: 467d12f5: include/uapi/linux/swab.h: fix userspace breakage

5 years, 7 months

1
0
0 0

[patch 15/15] tools/vm: fix cross-compile build

by Andrew Morton

From: Lucas Stach <l.stach(a)pengutronix.de> Subject: tools/vm: fix cross-compile build 7ed1c1901fe5 (tools: fix cross-compile var clobbering) moved the setup of the CC variable to tools/scripts/Makefile.include to make the behavior consistent across all the tools Makefiles. As the vm tools missed the include we end up with the wrong CC in a cross-compiling evironment. Link: http://lkml.kernel.org/r/20200416104748.25243-1-l.stach@pengutronix.de Fixes: 7ed1c1901fe5 (tools: fix cross-compile var clobbering) Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> Cc: Martin Kelly <martin(a)martingkelly.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/vm/Makefile | 2 ++ 1 file changed, 2 insertions(+) --- a/tools/vm/Makefile~tools-vm-fix-cross-compile-build +++ a/tools/vm/Makefile @@ -1,6 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 # Makefile for vm tools # +include ../scripts/Makefile.include + TARGETS=page-types slabinfo page_owner_sort LIB_DIR = ../lib/api _

5 years, 7 months

1
0
0 0

[patch 14/15] coredump: fix null pointer dereference on coredump

by Andrew Morton

From: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com> Subject: coredump: fix null pointer dereference on coredump If the core_pattern is set to "|" and any process segfaults then we get a null pointer derefernce while trying to coredump. The call stack shows: [ 108.212680] RIP: 0010:do_coredump+0x628/0x11c0 When the core_pattern has only "|" there is no use of trying the coredump and we can check that while formating the corename and exit with an error. After this change I get: [ 48.453756] format_corename failed [ 48.453758] Aborting core Link: http://lkml.kernel.org/r/20200416194612.21418-1-sudipm.mukherjee@gmail.com Fixes: 315c69261dd3 ("coredump: split pipe command whitespace before expanding template") Signed-off-by: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com> Reported-by: Matthew Ruffell <matthew.ruffell(a)canonical.com> Cc: Paul Wise <pabs3(a)bonedaddy.net> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: Neil Horman <nhorman(a)tuxdriver.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/coredump.c | 2 ++ 1 file changed, 2 insertions(+) --- a/fs/coredump.c~coredump-fix-null-pointer-dereference-on-coredump +++ a/fs/coredump.c @@ -211,6 +211,8 @@ static int format_corename(struct core_n return -ENOMEM; (*argv)[(*argc)++] = 0; ++pat_ptr; + if (!(*pat_ptr)) + return -ENOMEM; } /* Repeat as long as we have more pattern to process and more output _

5 years, 7 months

1
0
0 0

[patch 09/15] mm/ksm: fix NULL pointer dereference when KSM zero page is enabled

by Andrew Morton

From: Muchun Song <songmuchun(a)bytedance.com> Subject: mm/ksm: fix NULL pointer dereference when KSM zero page is enabled find_mergeable_vma() can return NULL. In this case, it leads to a crash when we access vm_mm(its offset is 0x40) later in write_protect_page. And this case did happen on our server. The following call trace is captured in kernel 4.19 with the following patch applied and KSM zero page enabled on our server. commit e86c59b1b12d ("mm/ksm: improve deduplication of zero pages with colouring") So add a vma check to fix it. -------------------------------------------------------------------------- BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 Oops: 0000 [#1] SMP NOPTI CPU: 9 PID: 510 Comm: ksmd Kdump: loaded Tainted: G OE 4.19.36.bsk.9-amd64 #4.19.36.bsk.9 RIP: 0010:try_to_merge_one_page+0xc7/0x760 Code: 24 58 65 48 33 34 25 28 00 00 00 89 e8 0f 85 a3 06 00 00 48 83 c4 60 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 8b 46 08 a8 01 75 b8 <49> 8b 44 24 40 4c 8d 7c 24 20 b9 07 00 00 00 4c 89 e6 4c 89 ff 48 RSP: 0018:ffffadbdd9fffdb0 EFLAGS: 00010246 RAX: ffffda83ffd4be08 RBX: ffffda83ffd4be40 RCX: 0000002c6e800000 RDX: 0000000000000000 RSI: ffffda83ffd4be40 RDI: 0000000000000000 RBP: ffffa11939f02ec0 R08: 0000000094e1a447 R09: 00000000abe76577 R10: 0000000000000962 R11: 0000000000004e6a R12: 0000000000000000 R13: ffffda83b1e06380 R14: ffffa18f31f072c0 R15: ffffda83ffd4be40 FS: 0000000000000000(0000) GS:ffffa0da43b80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000040 CR3: 0000002c77c0a003 CR4: 00000000007626e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? follow_page_pte+0x36d/0x5e0 ksm_scan_thread+0x115e/0x1960 ? remove_wait_queue+0x60/0x60 kthread+0xf5/0x130 ? try_to_merge_with_ksm_page+0x90/0x90 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x1f/0x30 -------------------------------------------------------------------------- [songmuchun(a)bytedance.com: if the vma is out of date, just exit] Link: http://lkml.kernel.org/r/20200416025034.29780-1-songmuchun@bytedance.com [akpm(a)linux-foundation.org: add the conventional braces, replace /** with /*] Link: http://lkml.kernel.org/r/20200416025034.29780-1-songmuchun@bytedance.com Link: http://lkml.kernel.org/r/20200414132905.83819-1-songmuchun@bytedance.com Fixes: e86c59b1b12d ("mm/ksm: improve deduplication of zero pages with colouring") Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Co-developed-by: Xiongchun Duan <duanxiongchun(a)bytedance.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Kirill Tkhai <ktkhai(a)virtuozzo.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Yang Shi <yang.shi(a)linux.alibaba.com> Cc: Claudio Imbrenda <imbrenda(a)linux.vnet.ibm.com> Cc: Markus Elfring <Markus.Elfring(a)web.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/ksm.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/mm/ksm.c~mm-ksm-fix-null-pointer-dereference-when-ksm-zero-page-is-enabled +++ a/mm/ksm.c @@ -2112,8 +2112,16 @@ static void cmp_and_merge_page(struct pa down_read(&mm->mmap_sem); vma = find_mergeable_vma(mm, rmap_item->address); - err = try_to_merge_one_page(vma, page, - ZERO_PAGE(rmap_item->address)); + if (vma) { + err = try_to_merge_one_page(vma, page, + ZERO_PAGE(rmap_item->address)); + } else { + /* + * If the vma is out of date, we do not need to + * continue. + */ + err = 0; + } up_read(&mm->mmap_sem); /* * In case of failure, the page was not really empty, so we _

5 years, 7 months

1
0
0 0

[patch 05/15] mm/hugetlb: fix a addressing exception caused by huge_pte_offset

by Andrew Morton

From: Longpeng <longpeng2(a)huawei.com> Subject: mm/hugetlb: fix a addressing exception caused by huge_pte_offset Our machine encountered a panic(addressing exception) after run for a long time and the calltrace is: RIP: 0010:[<ffffffff9dff0587>] [<ffffffff9dff0587>] hugetlb_fault+0x307/0xbe0 RSP: 0018:ffff9567fc27f808 EFLAGS: 00010286 RAX: e800c03ff1258d48 RBX: ffffd3bb003b69c0 RCX: e800c03ff1258d48 RDX: 17ff3fc00eda72b7 RSI: 00003ffffffff000 RDI: e800c03ff1258d48 RBP: ffff9567fc27f8c8 R08: e800c03ff1258d48 R09: 0000000000000080 R10: ffffaba0704c22a8 R11: 0000000000000001 R12: ffff95c87b4b60d8 R13: 00005fff00000000 R14: 0000000000000000 R15: ffff9567face8074 FS: 00007fe2d9ffb700(0000) GS:ffff956900e40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffd3bb003b69c0 CR3: 000000be67374000 CR4: 00000000003627e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: [<ffffffff9df9b71b>] ? unlock_page+0x2b/0x30 [<ffffffff9dff04a2>] ? hugetlb_fault+0x222/0xbe0 [<ffffffff9dff1405>] follow_hugetlb_page+0x175/0x540 [<ffffffff9e15b825>] ? cpumask_next_and+0x35/0x50 [<ffffffff9dfc7230>] __get_user_pages+0x2a0/0x7e0 [<ffffffff9dfc648d>] __get_user_pages_unlocked+0x15d/0x210 [<ffffffffc068cfc5>] __gfn_to_pfn_memslot+0x3c5/0x460 [kvm] [<ffffffffc06b28be>] try_async_pf+0x6e/0x2a0 [kvm] [<ffffffffc06b4b41>] tdp_page_fault+0x151/0x2d0 [kvm] ... [<ffffffffc06a6f90>] kvm_arch_vcpu_ioctl_run+0x330/0x490 [kvm] [<ffffffffc068d919>] kvm_vcpu_ioctl+0x309/0x6d0 [kvm] [<ffffffff9deaa8c2>] ? dequeue_signal+0x32/0x180 [<ffffffff9deae34d>] ? do_sigtimedwait+0xcd/0x230 [<ffffffff9e03aed0>] do_vfs_ioctl+0x3f0/0x540 [<ffffffff9e03b0c1>] SyS_ioctl+0xa1/0xc0 [<ffffffff9e53879b>] system_call_fastpath+0x22/0x27 For 1G hugepages, huge_pte_offset() wants to return NULL or pudp, but it may return a wrong 'pmdp' if there is a race. Please look at the following code snippet: ... pud = pud_offset(p4d, addr); if (sz != PUD_SIZE && pud_none(*pud)) return NULL; /* hugepage or swap? */ if (pud_huge(*pud) || !pud_present(*pud)) return (pte_t *)pud; pmd = pmd_offset(pud, addr); if (sz != PMD_SIZE && pmd_none(*pmd)) return NULL; /* hugepage or swap? */ if (pmd_huge(*pmd) || !pmd_present(*pmd)) return (pte_t *)pmd; ... The following sequence would trigger this bug: 1. CPU0: sz = PUD_SIZE and *pud = 0 , continue 1. CPU0: "pud_huge(*pud)" is false 2. CPU1: calling hugetlb_no_page and set *pud to xxxx8e7(PRESENT) 3. CPU0: "!pud_present(*pud)" is false, continue 4. CPU0: pmd = pmd_offset(pud, addr) and maybe return a wrong pmdp However, we want CPU0 to return NULL or pudp in this case. We must make sure there is exactly one dereference of pud and pmd. Link: http://lkml.kernel.org/r/20200413010342.771-1-longpeng2@huawei.com Signed-off-by: Longpeng <longpeng2(a)huawei.com> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Reviewed-by: Jason Gunthorpe <jgg(a)mellanox.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Sean Christopherson <sean.j.christopherson(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/mm/hugetlb.c~mm-hugetlb-fix-a-addressing-exception-caused-by-huge_pte_offset +++ a/mm/hugetlb.c @@ -5365,8 +5365,8 @@ pte_t *huge_pte_offset(struct mm_struct { pgd_t *pgd; p4d_t *p4d; - pud_t *pud; - pmd_t *pmd; + pud_t *pud, pud_entry; + pmd_t *pmd, pmd_entry; pgd = pgd_offset(mm, addr); if (!pgd_present(*pgd)) @@ -5376,17 +5376,19 @@ pte_t *huge_pte_offset(struct mm_struct return NULL; pud = pud_offset(p4d, addr); - if (sz != PUD_SIZE && pud_none(*pud)) + pud_entry = READ_ONCE(*pud); + if (sz != PUD_SIZE && pud_none(pud_entry)) return NULL; /* hugepage or swap? */ - if (pud_huge(*pud) || !pud_present(*pud)) + if (pud_huge(pud_entry) || !pud_present(pud_entry)) return (pte_t *)pud; pmd = pmd_offset(pud, addr); - if (sz != PMD_SIZE && pmd_none(*pmd)) + pmd_entry = READ_ONCE(*pmd); + if (sz != PMD_SIZE && pmd_none(pmd_entry)) return NULL; /* hugepage or swap? */ - if (pmd_huge(*pmd) || !pmd_present(*pmd)) + if (pmd_huge(pmd_entry) || !pmd_present(pmd_entry)) return (pte_t *)pmd; return NULL; _

5 years, 7 months

1
0
0 0

stable-rc/linux-5.4.y boot: 144 boots: 1 failed, 133 passed with 6 offline, 4 untried/unknown (v5.4.33-61-gf969422316c7)

by kernelci.org bot

stable-rc/linux-5.4.y boot: 144 boots: 1 failed, 133 passed with 6 offline, 4 untried/unknown (v5.4.33-61-gf969422316c7) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.4.y/kernel/v5.4.33-61-g… Tree: stable-rc Branch: linux-5.4.y Git Describe: v5.4.33-61-gf969422316c7 Git Commit: f969422316c773400cbec8d7fe672db7d4bb97af Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 97 unique boards, 25 SoC families, 22 builds out of 200 Boot Regressions Detected: arc: hsdk_defconfig: gcc-8: hsdk: lab-baylibre: new failure (last pass: v5.4.33-48-g8661e77d45ae) arm: davinci_all_defconfig: gcc-8: da850-evm: lab-baylibre-seattle: failing since 5 days (last pass: v5.4.30-81-gf163418797b9 - first fail: v5.4.31-258-gd88fa8738f21) dm365evm,legacy: lab-baylibre-seattle: failing since 5 days (last pass: v5.4.30-81-gf163418797b9 - first fail: v5.4.31-258-gd88fa8738f21) qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 72 days (last pass: v5.4.17-99-gbd0c6624a110 - first fail: v5.4.17-238-gbffcaa93483d) sama5_defconfig: gcc-8: at91-sama5d4_xplained: lab-baylibre: failing since 12 days (last pass: v5.4.30-37-g40da5db79b55 - first fail: v5.4.30-39-g23c04177b89f) arm64: defconfig: gcc-8: meson-axg-s400: lab-baylibre-seattle: new failure (last pass: v5.4.33-48-g8661e77d45ae) Boot Failure Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab Offline Platforms: arm: 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 multi_v7_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab stih410-b2120: 1 offline lab arm64: defconfig: gcc-8 meson-axg-s400: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 7 months

1
0
0 0

stable-rc/linux-4.19.y boot: 150 boots: 2 failed, 134 passed with 7 offline, 7 untried/unknown (v4.19.116-41-gdf86600ce713)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 150 boots: 2 failed, 134 passed with 7 offline, 7 untried/unknown (v4.19.116-41-gdf86600ce713) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.116-4… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.116-41-gdf86600ce713 Git Commit: df86600ce71383e8c73aad9f536cb0dccdf840be Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 87 unique boards, 23 SoC families, 20 builds out of 206 Boot Regressions Detected: arc: hsdk_defconfig: gcc-8: hsdk: lab-baylibre: new failure (last pass: v4.19.116-25-ga501871d59fd) arm: davinci_all_defconfig: gcc-8: da850-evm: lab-baylibre-seattle: new failure (last pass: v4.19.116-25-ga501871d59fd) dm365evm,legacy: lab-baylibre-seattle: new failure (last pass: v4.19.116-25-ga501871d59fd) qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 72 days (last pass: v4.19.101 - first fail: v4.19.102-96-g0632821fe218) sama5_defconfig: gcc-8: at91-sama5d4_xplained: lab-baylibre: failing since 38 days (last pass: v4.19.108-87-g624c124960e8 - first fail: v4.19.109) versatile_defconfig: gcc-8: versatile-pb: lab-collabora: new failure (last pass: v4.19.116-25-ga501871d59fd) arm64: defconfig: gcc-8: meson-axg-s400: lab-baylibre-seattle: new failure (last pass: v4.19.116-25-ga501871d59fd) sun50i-a64-pine64-plus: lab-baylibre: new failure (last pass: v4.19.116-25-ga501871d59fd) Boot Failures Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab multi_v7_defconfig: gcc-8: stih410-b2120: 1 failed lab Offline Platforms: arm: 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 multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab arm64: defconfig: gcc-8 meson-axg-s400: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 7 months

1
0
0 0

+ fs-binfmt_elfc-allocate-initialized-memory-in-fill_thread_core_info.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info() has been added to the -mm tree. Its filename is fs-binfmt_elfc-allocate-initialized-memory-in-fill_thread_core_info.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/fs-binfmt_elfc-allocate-initialize… and later at http://ozlabs.org/~akpm/mmotm/broken-out/fs-binfmt_elfc-allocate-initialize… 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/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Alexander Potapenko <glider(a)google.com> Subject: fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info() KMSAN reported uninitialized data being written to disk when dumping core. As a result, several kilobytes of kmalloc memory may be written to the core file and then read by a non-privileged user. Link: http://lkml.kernel.org/r/20200419100848.63472-1-glider@google.com Link: https://github.com/google/kmsan/issues/76 Signed-off-by: Alexander Potapenko <glider(a)google.com> Reported-by: sam <sunhaoyl(a)outlook.com> Cc: Alexey Dobriyan <adobriyan(a)gmail.com> Cc: Kees Cook <keescook(a)chromium.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/binfmt_elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/binfmt_elf.c~fs-binfmt_elfc-allocate-initialized-memory-in-fill_thread_core_info +++ a/fs/binfmt_elf.c @@ -1733,7 +1733,7 @@ static int fill_thread_core_info(struct (!regset->active || regset->active(t->task, regset) > 0)) { int ret; size_t size = regset_size(t->task, regset); - void *data = kmalloc(size, GFP_KERNEL); + void *data = kzalloc(size, GFP_KERNEL); if (unlikely(!data)) return 0; ret = regset->get(t->task, regset, _ Patches currently in -mm which might be from glider(a)google.com are fs-binfmt_elfc-allocate-initialized-memory-in-fill_thread_core_info.patch

5 years, 7 months

1
0
0 0

stable-rc/linux-4.9.y boot: 103 boots: 1 failed, 92 passed with 5 offline, 5 untried/unknown (v4.9.219-84-gd7b7a33b0609)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 103 boots: 1 failed, 92 passed with 5 offline, 5 untried/unknown (v4.9.219-84-gd7b7a33b0609) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.219-84-… Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.219-84-gd7b7a33b0609 Git Commit: d7b7a33b0609424e2b4fe31199b4ee6e570f504c Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 56 unique boards, 18 SoC families, 18 builds out of 197 Boot Regressions Detected: arm: davinci_all_defconfig: gcc-8: da850-evm: lab-baylibre-seattle: new failure (last pass: v4.9.219-79-ge4f3ca7a34da) dm365evm,legacy: lab-baylibre-seattle: new failure (last pass: v4.9.219-79-ge4f3ca7a34da) qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 72 days (last pass: v4.9.213 - first fail: v4.9.213-37-g860ec95da9ad) versatile_defconfig: gcc-8: versatile-pb: lab-collabora: new failure (last pass: v4.9.219-79-ge4f3ca7a34da) Boot Failure Detected: arm: multi_v7_defconfig: gcc-8: stih410-b2120: 1 failed lab Offline Platforms: arm: 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 multi_v7_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror