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

[merged] x86-purgatory-add-missing-force-to-makefile-target.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: x86/purgatory: add missing FORCE to Makefile target has been removed from the -mm tree. Its filename was x86-purgatory-add-missing-force-to-makefile-target.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Philipp Rudo <prudo(a)linux.ibm.com> Subject: x86/purgatory: add missing FORCE to Makefile target - Build the kernel without the fix - Add some flag to the purgatories KBUILD_CFLAGS,I used -fno-asynchronous-unwind-tables - Re-build the kernel When you look at makes output you see that sha256.o is not re-build in the last step. Also readelf -S still shows the .eh_frame section for sha256.o. With the fix sha256.o is rebuilt in the last step. Without FORCE make does not detect changes only made to the command line options. So object files might not be re-built even when they should be. Fix this by adding FORCE where it is missing. Link: http://lkml.kernel.org/r/20180704110044.29279-2-prudo@linux.ibm.com Fixes: df6f2801f511 ("kernel/kexec_file.c: move purgatories sha256 to common code") Signed-off-by: Philipp Rudo <prudo(a)linux.ibm.com> Acked-by: Dave Young <dyoung(a)redhat.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: <stable(a)vger.kernel.org> [4.17+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/x86/purgatory/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN arch/x86/purgatory/Makefile~x86-purgatory-add-missing-force-to-makefile-target arch/x86/purgatory/Makefile --- a/arch/x86/purgatory/Makefile~x86-purgatory-add-missing-force-to-makefile-target +++ a/arch/x86/purgatory/Makefile @@ -6,7 +6,7 @@ purgatory-y := purgatory.o stack.o setup targets += $(purgatory-y) PURGATORY_OBJS = $(addprefix $(obj)/,$(purgatory-y)) -$(obj)/sha256.o: $(srctree)/lib/sha256.c +$(obj)/sha256.o: $(srctree)/lib/sha256.c FORCE $(call if_changed_rule,cc_o_c) LDFLAGS_purgatory.ro := -e purgatory_start -r --no-undefined -nostdlib -z nodefaultlib _ Patches currently in -mm which might be from prudo(a)linux.ibm.com are

7 years

1
0
0 0

[merged] mm-fix-locked-field-in-proc-pid-smaps.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: fs/proc/task_mmu.c: fix Locked field in /proc/pid/smaps* has been removed from the -mm tree. Its filename was mm-fix-locked-field-in-proc-pid-smaps.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Vlastimil Babka <vbabka(a)suse.cz> Subject: fs/proc/task_mmu.c: fix Locked field in /proc/pid/smaps* Thomas reports: : While looking around in /proc on my v4.14.52 system I noticed that : all processes got a lot of "Locked" memory in /proc/*/smaps. A lot : more memory than a regular user can usually lock with mlock(). : : commit 493b0e9d945fa9dfe96be93ae41b4ca4b6fdb317 (v4.14-rc1) seems : to have changed the behavior of "Locked". : : Before that commit the code was like this. Notice the VM_LOCKED : check. : : (vma->vm_flags & VM_LOCKED) ? : (unsigned long)(mss.pss >> (10 + PSS_SHIFT)) : 0); : : After that commit Locked is now the same as Pss. This looks like a : mistake. : : (unsigned long)(mss->pss >> (10 + PSS_SHIFT))); Indeed, the commit has added mss->pss_locked with the correct value that depends on VM_LOCKED, but forgot to actually use it. Fix it. Link: http://lkml.kernel.org/r/ebf6c7fb-fec3-6a26-544f-710ed193c154@suse.cz Fixes: 493b0e9d945f ("mm: add /proc/pid/smaps_rollup") Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Reported-by: Thomas Lindroth <thomas.lindroth(a)gmail.com> Cc: Alexey Dobriyan <adobriyan(a)gmail.com> Cc: Daniel Colascione <dancol(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/task_mmu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN fs/proc/task_mmu.c~mm-fix-locked-field-in-proc-pid-smaps fs/proc/task_mmu.c --- a/fs/proc/task_mmu.c~mm-fix-locked-field-in-proc-pid-smaps +++ a/fs/proc/task_mmu.c @@ -831,7 +831,8 @@ static int show_smap(struct seq_file *m, SEQ_PUT_DEC(" kB\nSwap: ", mss->swap); SEQ_PUT_DEC(" kB\nSwapPss: ", mss->swap_pss >> PSS_SHIFT); - SEQ_PUT_DEC(" kB\nLocked: ", mss->pss >> PSS_SHIFT); + SEQ_PUT_DEC(" kB\nLocked: ", + mss->pss_locked >> PSS_SHIFT); seq_puts(m, " kB\n"); } if (!rollup_mode) { _ Patches currently in -mm which might be from vbabka(a)suse.cz are mm-page_alloc-actually-ignore-mempolicies-for-high-priority-allocations.patch

7 years

1
0
0 0

[merged] mm-do-not-drop-unused-pages-when-userfaultd-is-running.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: do not drop unused pages when userfaultd is running has been removed from the -mm tree. Its filename was mm-do-not-drop-unused-pages-when-userfaultd-is-running.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Christian Borntraeger <borntraeger(a)de.ibm.com> Subject: mm: do not drop unused pages when userfaultd is running KVM guests on s390 can notify the host of unused pages. This can result in pte_unused callbacks to be true for KVM guest memory. If a page is unused (checked with pte_unused) we might drop this page instead of paging it. This can have side-effects on userfaultd, when the page in question was already migrated: The next access of that page will trigger a fault and a user fault instead of faulting in a new and empty zero page. As QEMU does not expect a userfault on an already migrated page this migration will fail. The most straightforward solution is to ignore the pte_unused hint if a userfault context is active for this VMA. Link: http://lkml.kernel.org/r/20180703171854.63981-1-borntraeger@de.ibm.com Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Cc: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Mike Rapoport <rppt(a)linux.vnet.ibm.com> Cc: Janosch Frank <frankja(a)linux.ibm.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Cornelia Huck <cohuck(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/rmap.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff -puN mm/rmap.c~mm-do-not-drop-unused-pages-when-userfaultd-is-running mm/rmap.c --- a/mm/rmap.c~mm-do-not-drop-unused-pages-when-userfaultd-is-running +++ a/mm/rmap.c @@ -64,6 +64,7 @@ #include <linux/backing-dev.h> #include <linux/page_idle.h> #include <linux/memremap.h> +#include <linux/userfaultfd_k.h> #include <asm/tlbflush.h> @@ -1481,11 +1482,16 @@ static bool try_to_unmap_one(struct page set_pte_at(mm, address, pvmw.pte, pteval); } - } else if (pte_unused(pteval)) { + } else if (pte_unused(pteval) && !userfaultfd_armed(vma)) { /* * The guest indicated that the page content is of no * interest anymore. Simply discard the pte, vmscan * will take care of the rest. + * A future reference will then fault in a new zero + * page. When userfaultfd is active, we must not drop + * this page though, as its main user (postcopy + * migration) will not expect userfaults on already + * copied pages. */ dec_mm_counter(mm, mm_counter(page)); /* We have to invalidate as we cleared the pte */ _ Patches currently in -mm which might be from borntraeger(a)de.ibm.com are

7 years

1
0
0 0

[PATCH] perf kvm: Fix subcommands on s390

by Thomas Richter

With commit eca0fa28cd0d ("perf record: Provide detailed information on s390 CPU") s390 platform provides detailed type/model/capacitiy information in the CPU indentifier string instead of just "IBM/S390". This breaks perf kvm support which uses hard coded string IBM/S390 to compare with the CPU identifier string. Fix this by changing the comparison. Fixes: eca0fa28cd0d ("perf record: Provide detailed information on s390 CPU") Cc: Stefan Raspl <raspl(a)linux.ibm.com> Cc: <stable(a)vger.kernel.org> # 4.17 Signed-off-by: Thomas Richter <tmricht(a)linux.ibm.com> Reviewed-by: Hendrik Brueckner <brueckner(a)linux.ibm.com> --- tools/perf/arch/s390/util/kvm-stat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/arch/s390/util/kvm-stat.c b/tools/perf/arch/s390/util/kvm-stat.c index d233e2eb9592..aaabab5e2830 100644 --- a/tools/perf/arch/s390/util/kvm-stat.c +++ b/tools/perf/arch/s390/util/kvm-stat.c @@ -102,7 +102,7 @@ const char * const kvm_skip_events[] = { int cpu_isa_init(struct perf_kvm_stat *kvm, const char *cpuid) { - if (strstr(cpuid, "IBM/S390")) { + if (strstr(cpuid, "IBM")) { kvm->exit_reasons = sie_exit_reasons; kvm->exit_reasons_isa = "SIE"; } else -- 2.14.3

7 years

4
3
0 0

[PATCH 4.4.y 051/101] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen

by Srivatsa S. Bhat

From: David Woodhouse <dwmw(a)amazon.co.uk> commit def9331a12977770cc6132d79f8e6565871e8e38 upstream When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set on AMD cpus. This bug/feature bit is kind of special as it will be used very early when switching threads. Setting the bit and clearing it a little bit later leaves a critical window where things can go wrong. This time window has enlarged a little bit by using setup_clear_cpu_cap() instead of the hypervisor's set_cpu_features callback. It seems this larger window now makes it rather easy to hit the problem. The proper solution is to never set the bit in case of Xen. Signed-off-by: Juergen Gross <jgross(a)suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Acked-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Srivatsa S. Bhat <srivatsa(a)csail.mit.edu> Reviewed-by: Matt Helsley (VMware) <matt.helsley(a)gmail.com> Reviewed-by: Alexey Makhalov <amakhalov(a)vmware.com> Reviewed-by: Bo Gan <ganb(a)vmware.com> --- arch/x86/kernel/cpu/amd.c | 5 +++-- arch/x86/xen/enlighten.c | 4 +--- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index f4fb8f5..9b29414 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -791,8 +791,9 @@ static void init_amd(struct cpuinfo_x86 *c) if (cpu_has(c, X86_FEATURE_3DNOW) || cpu_has(c, X86_FEATURE_LM)) set_cpu_cap(c, X86_FEATURE_3DNOWPREFETCH); - /* AMD CPUs don't reset SS attributes on SYSRET */ - set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS); + /* AMD CPUs don't reset SS attributes on SYSRET, Xen does. */ + if (!cpu_has(c, X86_FEATURE_XENPV)) + set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS); } #ifdef CONFIG_X86_32 diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 2d7ab4e..82fd84d 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -462,10 +462,8 @@ static void __init xen_init_cpuid_mask(void) static void __init xen_init_capabilities(void) { - if (xen_pv_domain()) { - setup_clear_cpu_cap(X86_BUG_SYSRET_SS_ATTRS); + if (xen_pv_domain()) setup_force_cpu_cap(X86_FEATURE_XENPV); - } } static void xen_set_debugreg(int reg, unsigned long val)

7 years

2
2
0 0

Re: [PATCH 4.17 62/67] kvm: vmx: Nested VM-entry prereqs for event inj.

by Marc Orr

On Mon, Jul 16, 2018 at 12:39 AM Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> wrote: > > 4.17-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Marc Orr <marcorr(a)google.com> > > commit 0447378a4a793da008451fad50bc0f93e9675ae6 upstream. > > This patch extends the checks done prior to a nested VM entry. > Specifically, it extends the check_vmentry_prereqs function with checks > for fields relevant to the VM-entry event injection information, as > described in the Intel SDM, volume 3. > > This patch is motivated by a syzkaller bug, where a bad VM-entry > interruption information field is generated in the VMCS02, which causes > the nested VM launch to fail. Then, KVM fails to resume L1. > > While KVM should be improved to correctly resume L1 execution after a > failed nested launch, this change is justified because the existing code > to resume L1 is flaky/ad-hoc and the test coverage for resuming L1 is > sparse. > > Reported-by: syzbot <syzkaller(a)googlegroups.com> > Signed-off-by: Marc Orr <marcorr(a)google.com> > [Removed comment whose parts were describing previous revisions and the > rest was obvious from function/variable naming. - Radim] > Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > > --- > arch/x86/include/asm/vmx.h | 3 ++ > arch/x86/kvm/vmx.c | 67 +++++++++++++++++++++++++++++++++++++++++++++ > arch/x86/kvm/x86.h | 9 ++++++ > 3 files changed, 79 insertions(+) > > --- a/arch/x86/include/asm/vmx.h > +++ b/arch/x86/include/asm/vmx.h > @@ -114,6 +114,7 @@ > #define VMX_MISC_PREEMPTION_TIMER_RATE_MASK 0x0000001f > #define VMX_MISC_SAVE_EFER_LMA 0x00000020 > #define VMX_MISC_ACTIVITY_HLT 0x00000040 > +#define VMX_MISC_ZERO_LEN_INS 0x40000000 > > /* VMFUNC functions */ > #define VMX_VMFUNC_EPTP_SWITCHING 0x00000001 > @@ -349,11 +350,13 @@ enum vmcs_field { > #define VECTORING_INFO_VALID_MASK INTR_INFO_VALID_MASK > > #define INTR_TYPE_EXT_INTR (0 << 8) /* external interrupt */ > +#define INTR_TYPE_RESERVED (1 << 8) /* reserved */ > #define INTR_TYPE_NMI_INTR (2 << 8) /* NMI */ > #define INTR_TYPE_HARD_EXCEPTION (3 << 8) /* processor exception */ > #define INTR_TYPE_SOFT_INTR (4 << 8) /* software interrupt */ > #define INTR_TYPE_PRIV_SW_EXCEPTION (5 << 8) /* ICE breakpoint - undocumented */ > #define INTR_TYPE_SOFT_EXCEPTION (6 << 8) /* software exception */ > +#define INTR_TYPE_OTHER_EVENT (7 << 8) /* other event */ > > /* GUEST_INTERRUPTIBILITY_INFO flags. */ > #define GUEST_INTR_STATE_STI 0x00000001 > --- a/arch/x86/kvm/vmx.c > +++ b/arch/x86/kvm/vmx.c > @@ -1510,6 +1510,17 @@ static inline unsigned nested_cpu_vmx_mi > return vmx_misc_cr3_count(to_vmx(vcpu)->nested.msrs.misc_low); > } > > +static inline bool nested_cpu_has_zero_length_injection(struct kvm_vcpu *vcpu) > +{ > + return to_vmx(vcpu)->nested.msrs.misc_low & VMX_MISC_ZERO_LEN_INS; > +} > + > +static inline bool nested_cpu_supports_monitor_trap_flag(struct kvm_vcpu *vcpu) > +{ > + return to_vmx(vcpu)->nested.msrs.procbased_ctls_high & > + CPU_BASED_MONITOR_TRAP_FLAG; > +} > + > static inline bool nested_cpu_has(struct vmcs12 *vmcs12, u32 bit) > { > return vmcs12->cpu_based_vm_exec_control & bit; > @@ -11364,6 +11375,62 @@ static int check_vmentry_prereqs(struct > !nested_cr3_valid(vcpu, vmcs12->host_cr3)) > return VMXERR_ENTRY_INVALID_HOST_STATE_FIELD; > > + /* > + * From the Intel SDM, volume 3: > + * Fields relevant to VM-entry event injection must be set properly. > + * These fields are the VM-entry interruption-information field, the > + * VM-entry exception error code, and the VM-entry instruction length. > + */ > + if (vmcs12->vm_entry_intr_info_field & INTR_INFO_VALID_MASK) { > + u32 intr_info = vmcs12->vm_entry_intr_info_field; > + u8 vector = intr_info & INTR_INFO_VECTOR_MASK; > + u32 intr_type = intr_info & INTR_INFO_INTR_TYPE_MASK; > + bool has_error_code = intr_info & INTR_INFO_DELIVER_CODE_MASK; > + bool should_have_error_code; > + bool urg = nested_cpu_has2(vmcs12, > + SECONDARY_EXEC_UNRESTRICTED_GUEST); > + bool prot_mode = !urg || vmcs12->guest_cr0 & X86_CR0_PE; > + > + /* VM-entry interruption-info field: interruption type */ > + if (intr_type == INTR_TYPE_RESERVED || > + (intr_type == INTR_TYPE_OTHER_EVENT && > + !nested_cpu_supports_monitor_trap_flag(vcpu))) > + return VMXERR_ENTRY_INVALID_CONTROL_FIELD; > + > + /* VM-entry interruption-info field: vector */ > + if ((intr_type == INTR_TYPE_NMI_INTR && vector != NMI_VECTOR) || > + (intr_type == INTR_TYPE_HARD_EXCEPTION && vector > 31) || > + (intr_type == INTR_TYPE_OTHER_EVENT && vector != 0)) > + return VMXERR_ENTRY_INVALID_CONTROL_FIELD; > + > + /* VM-entry interruption-info field: deliver error code */ > + should_have_error_code = > + intr_type == INTR_TYPE_HARD_EXCEPTION && prot_mode && > + x86_exception_has_error_code(vector); > + if (has_error_code != should_have_error_code) > + return VMXERR_ENTRY_INVALID_CONTROL_FIELD; > + > + /* VM-entry exception error code */ > + if (has_error_code && > + vmcs12->vm_entry_exception_error_code & GENMASK(31, 15)) > + return VMXERR_ENTRY_INVALID_CONTROL_FIELD; > + > + /* VM-entry interruption-info field: reserved bits */ > + if (intr_info & INTR_INFO_RESVD_BITS_MASK) > + return VMXERR_ENTRY_INVALID_CONTROL_FIELD; > + > + /* VM-entry instruction length */ > + switch (intr_type) { > + case INTR_TYPE_SOFT_EXCEPTION: > + case INTR_TYPE_SOFT_INTR: > + case INTR_TYPE_PRIV_SW_EXCEPTION: > + if ((vmcs12->vm_entry_instruction_len > 15) || > + (vmcs12->vm_entry_instruction_len == 0 && > + !nested_cpu_has_zero_length_injection(vcpu))) > + return VMXERR_ENTRY_INVALID_CONTROL_FIELD; > + } > + } > + > return 0; > } > > --- a/arch/x86/kvm/x86.h > +++ b/arch/x86/kvm/x86.h > @@ -110,6 +110,15 @@ static inline bool is_la57_mode(struct k > #endif > } > > +static inline bool x86_exception_has_error_code(unsigned int vector) > +{ > + static u32 exception_has_error_code = BIT(DF_VECTOR) | BIT(TS_VECTOR) | > + BIT(NP_VECTOR) | BIT(SS_VECTOR) | BIT(GP_VECTOR) | > + BIT(PF_VECTOR) | BIT(AC_VECTOR); > + > + return (1U << vector) & exception_has_error_code; > +} > + > static inline bool mmu_is_nested(struct kvm_vcpu *vcpu) > { > return vcpu->arch.walk_mmu == &vcpu->arch.nested_mmu; > > Reviewed-by: Marc Orr <marcorr(a)google.com>

7 years

1
0
0 0

[PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

by Bart Van Assche

The macro __is_constexpr() causes sparse to report the following: warning: expression using sizeof(void) Avoid this by using __builtin_constant_p() instead. Fixes: 3c8ba0d61d04 ("kernel.h: Retain constant expression output for max()/min()") Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Martin Uecker <Martin.Uecker(a)med.uni-goettingen.de> Cc: Kees Cook <keescook(a)chromium.org> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Miguel Ojeda <miguel.ojeda.sandonis(a)gmail.com> Cc: <stable(a)vger.kernel.org> --- include/linux/kernel.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/include/linux/kernel.h b/include/linux/kernel.h index d23123238534..a9f0d0d48971 100644 --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -811,13 +811,19 @@ static inline void ftrace_dump(enum ftrace_dump_mode oops_dump_mode) { } #define __typecheck(x, y) \ (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) +#ifndef __CHECKER__ /* * This returns a constant expression while determining if an argument is * a constant expression, most importantly without evaluating the argument. - * Glory to Martin Uecker <Martin.Uecker(a)med.uni-goettingen.de> + * Glory to Martin Uecker <Martin.Uecker(a)med.uni-goettingen.de>. However, this + * macro causes sparse to report the warning "expression using sizeof(void)". + * Hence use __builtin_constant_p() instead when using sparse. */ #define __is_constexpr(x) \ (sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8))) +#else +#define __is_constexpr(x) __builtin_constant_p((x)) +#endif #define __no_side_effects(x, y) \ (__is_constexpr(x) && __is_constexpr(y)) -- 2.18.0

7 years

6
7
0 0

Re: mainline/master boot: 177 boots: 2 failed, 174 passed with 1 conflict (v4.18-rc4-160-gf353078f028f)

by Guillaume Tucker

On 15/07/18 01:32, kernelci.org bot wrote: > mainline/master boot: 177 boots: 2 failed, 174 passed with 1 conflict (v4.18-rc4-160-gf353078f028f) > > Full Boot Summary: https://kernelci.org/boot/all/job/mainline/branch/master/kernel/v4.18-rc4-1… > Full Build Summary: https://kernelci.org/build/mainline/branch/master/kernel/v4.18-rc4-160-gf35… > > Tree: mainline > Branch: master > Git Describe: v4.18-rc4-160-gf353078f028f > Git Commit: f353078f028fbfe9acd4b747b4a19c69ef6846cd > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > Tested: 67 unique boards, 25 SoC families, 21 builds out of 199 > > Boot Regressions Detected: [...] > x86: > > i386_defconfig: > x86-celeron: > lab-mhart: new failure (last pass: v4.18-rc4-147-g2db39a2f491a) > x86-pentium4: > lab-mhart: new failure (last pass: v4.18-rc4-147-g2db39a2f491a) Please see below an automated bisection report for this regression. Several bisections were run on other x86 platforms with i386_defconfig on a few revisions up to v4.18-rc5, they all reached the same "bad" commit. Unfortunately there isn't much to learn from the kernelci.org boot logs as the kernel seems to crash very early on: https://kernelci.org/boot/all/job/mainline/branch/master/kernel/v4.18-rc5/ https://storage.kernelci.org/mainline/master/v4.18-rc4-160-gf353078f028f/x8… It looks like stable-rc/linux-4.17.y is also broken with i386_defconfig, which tends to confirm the "bad" commit found by the automated bisection which was applied there as well: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.17.y/kernel/v4.1… The automated bisection on kernelci.org is still quite new, so please take the results with a pinch of salt as the "bad" commit found may not be the actual root cause of the boot failure. Hope this helps! Best wishes, Guillaume --------------------------------------8<-------------------------------------- Bisection result for mainline/master (v4.18-rc4-160-gf353078f028f) on x86-celeron Good: 2db39a2f491a Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Bad: f353078f028f Merge branch 'akpm' (patches from Andrew) Found: e181ae0c5db9 mm: zero unavailable pages before memmap init Checks: revert: PASS verify: PASS Parameters: Tree: mainline URL: http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Branch: master Target: x86-celeron Lab: lab-mhart Config: i386_defconfig Plan: boot Breaking commit found: ------------------------------------------------------------------------------- commit e181ae0c5db9544de9c53239eb22bc012ce75033 Author: Pavel Tatashin <pasha.tatashin(a)oracle.com> Date: Sat Jul 14 09:15:07 2018 -0400 mm: zero unavailable pages before memmap init We must zero struct pages for memory that is not backed by physical memory, or kernel does not have access to. Recently, there was a change which zeroed all memmap for all holes in e820. Unfortunately, it introduced a bug that is discussed here: https://www.spinics.net/lists/linux-mm/msg156764.html Linus, also saw this bug on his machine, and confirmed that reverting commit 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into memblock.reserved") fixes the issue. The problem is that we incorrectly zero some struct pages after they were setup. The fix is to zero unavailable struct pages prior to initializing of struct pages. A more detailed fix should come later that would avoid double zeroing cases: one in __init_single_page(), the other one in zero_resv_unavail(). Fixes: 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into memblock.reserved") Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 1521100f1e63..5d800d61ddb7 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -6847,6 +6847,7 @@ void __init free_area_init_nodes(unsigned long *max_zone_pfn) /* Initialise every node */ mminit_verify_pageflags_layout(); setup_nr_node_ids(); + zero_resv_unavail(); for_each_online_node(nid) { pg_data_t *pgdat = NODE_DATA(nid); free_area_init_node(nid, NULL, @@ -6857,7 +6858,6 @@ void __init free_area_init_nodes(unsigned long *max_zone_pfn) node_set_state(nid, N_MEMORY); check_for_memory(pgdat, nid); } - zero_resv_unavail(); } static int __init cmdline_parse_core(char *p, unsigned long *core, @@ -7033,9 +7033,9 @@ void __init set_dma_reserve(unsigned long new_dma_reserve) void __init free_area_init(unsigned long *zones_size) { + zero_resv_unavail(); free_area_init_node(0, zones_size, __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL); - zero_resv_unavail(); } static int page_alloc_cpu_dead(unsigned int cpu) ------------------------------------------------------------------------------- Git bisection log: ------------------------------------------------------------------------------- git bisect start # good: [2db39a2f491a48ec740e0214a7dd584eefc2137d] Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux git bisect good 2db39a2f491a48ec740e0214a7dd584eefc2137d # bad: [f353078f028fbfe9acd4b747b4a19c69ef6846cd] Merge branch 'akpm' (patches from Andrew) git bisect bad f353078f028fbfe9acd4b747b4a19c69ef6846cd # good: [fa8cbda88db12e632a8987c94b66f5caf25bcec4] x86/purgatory: add missing FORCE to Makefile target git bisect good fa8cbda88db12e632a8987c94b66f5caf25bcec4 # good: [bb177a732c4369bb58a1fe1df8f552b6f0f7db5f] mm: do not bug_on on incorrect length in __mm_populate() git bisect good bb177a732c4369bb58a1fe1df8f552b6f0f7db5f # good: [fe10e398e860955bac4d28ec031b701d358465e4] reiserfs: fix buffer overflow with long warning messages git bisect good fe10e398e860955bac4d28ec031b701d358465e4 # bad: [e181ae0c5db9544de9c53239eb22bc012ce75033] mm: zero unavailable pages before memmap init git bisect bad e181ae0c5db9544de9c53239eb22bc012ce75033 # first bad commit: [e181ae0c5db9544de9c53239eb22bc012ce75033] mm: zero unavailable pages before memmap init -------------------------------------------------------------------------------

7 years

4
5
0 0

editing

by Simon Dike

We can process 400+ images per day. If you need any image editing, please let us know. Photos cut out; Photos clipping path; Photos masking; Photo shadow creation; Photos retouching; Beauty Model retouching on skin, face, body; Glamour retouching; Products retouching. We can give you testing for your photos. Turnaround time is fast Thanks, Simon

7 years

1
0
0 0

editing of your photos

by Simon Dike

We can process 400+ images per day. If you need any image editing, please let us know. Photos cut out; Photos clipping path; Photos masking; Photo shadow creation; Photos retouching; Beauty Model retouching on skin, face, body; Glamour retouching; Products retouching. We can give you testing for your photos. Turnaround time is fast Thanks, Simon

7 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror