Re: linux-next: manual merge of the nvdimm tree with the tip tree
Hi all,
On Tue, 26 Jun 2018 12:18:53 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the nvdimm tree got a conflict in:
>
> arch/x86/kernel/cpu/mcheck/mce.c
>
> between commit:
>
> d3d6923cd1ae ("x86/mce: Carve out the crashing_cpu check")
>
> from the tip tree and commit:
>
> f6785eac562b ("x86/memory_failure: Introduce {set,clear}_mce_nospec()")
>
> from the nvdimm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/x86/kernel/cpu/mcheck/mce.c
> index 9a16f15f79eb,a0fbf0a8b7e6..
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@@ -1076,129 -1070,6 +1072,100 @@@ static int do_memory_failure(struct mc
> return ret;
> }
>
> - #ifndef mce_unmap_kpfn
> - static void mce_unmap_kpfn(unsigned long pfn)
> - {
> - unsigned long decoy_addr;
> -
> - /*
> - * Unmap this page from the kernel 1:1 mappings to make sure
> - * we don't log more errors because of speculative access to
> - * the page.
> - * We would like to just call:
> - * set_memory_np((unsigned long)pfn_to_kaddr(pfn), 1);
> - * but doing that would radically increase the odds of a
> - * speculative access to the poison page because we'd have
> - * the virtual address of the kernel 1:1 mapping sitting
> - * around in registers.
> - * Instead we get tricky. We create a non-canonical address
> - * that looks just like the one we want, but has bit 63 flipped.
> - * This relies on set_memory_np() not checking whether we passed
> - * a legal address.
> - */
> -
> - decoy_addr = (pfn << PAGE_SHIFT) + (PAGE_OFFSET ^ BIT(63));
> -
> - if (set_memory_np(decoy_addr, 1))
> - pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn);
> - }
> - #endif
> -
> -
> +/*
> + * Cases where we avoid rendezvous handler timeout:
> + * 1) If this CPU is offline.
> + *
> + * 2) If crashing_cpu was set, e.g. we're entering kdump and we need to
> + * skip those CPUs which remain looping in the 1st kernel - see
> + * crash_nmi_callback().
> + *
> + * Note: there still is a small window between kexec-ing and the new,
> + * kdump kernel establishing a new #MC handler where a broadcasted MCE
> + * might not get handled properly.
> + */
> +static bool __mc_check_crashing_cpu(int cpu)
> +{
> +if (cpu_is_offline(cpu) ||
> +(crashing_cpu != -1 && crashing_cpu != cpu)) {
> +u64 mcgstatus;
> +
> +mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
> +if (mcgstatus & MCG_STATUS_RIPV) {
> +mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
> +return true;
> +}
> +}
> +return false;
> +}
> +
> +static void __mc_scan_banks(struct mce *m, struct mce *final,
> +unsigned long *toclear, unsigned long *valid_banks,
> +int no_way_out, int *worst)
> +{
> +struct mca_config *cfg = _cfg;
> +int severity, i;
> +
> +for (i = 0; i < cfg->banks; i++) {
> +__clear_bit(i, toclear);
> +if (!test_bit(i, valid_banks))
> +continue;
> +
> +if (!mce_banks[i].ctl)
> +continue;
> +
> +m->misc = 0;
> +m->addr = 0;
> +m->bank = i;
> +
> +m->status = mce_rdmsrl(msr_ops.status(i));
> +if (!(m->status & MCI_STATUS_VAL))
> +continue;
> +
> +/*
> + * Corrected or non-signaled errors are handled by
> + * machine_check_poll(). Leave them alone, unless this panics.
> + */
> +if (!(m->status & (cfg->ser ? MCI_STATUS_S : MCI_STATUS_UC)) &&
> +!no_way_out)
> +continue;
> +
> +/* Set taint even when machine check was not enabled. */
> +add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
> +
> +severity = mce_severity(m, cfg->tolerant, NULL, true);
> +
> +/*
> + * When machine check was for corrected/deferred handler don't
> + * touch, unless we're panicking.
> + */
> +if ((severity == MCE_KEEP_SEVERITY ||
> + severity == MCE_UCNA_SEVERITY) && !no_way_out)
> +continue;
> +
> +__set_bit(i, toclear);
> +
> +/* Machine check event was not enabled. Clear, but ignore. */
> +if (severity == MCE_NO_SEVERITY)
> +
Re: linux-next: manual merge of the nvdimm tree with the tip tree
Hi all,
On Tue, 26 Jun 2018 12:18:53 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the nvdimm tree got a conflict in:
>
> arch/x86/kernel/cpu/mcheck/mce.c
>
> between commit:
>
> d3d6923cd1ae ("x86/mce: Carve out the crashing_cpu check")
>
> from the tip tree and commit:
>
> f6785eac562b ("x86/memory_failure: Introduce {set,clear}_mce_nospec()")
>
> from the nvdimm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/x86/kernel/cpu/mcheck/mce.c
> index 9a16f15f79eb,a0fbf0a8b7e6..
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@@ -1076,129 -1070,6 +1072,100 @@@ static int do_memory_failure(struct mc
> return ret;
> }
>
> - #ifndef mce_unmap_kpfn
> - static void mce_unmap_kpfn(unsigned long pfn)
> - {
> - unsigned long decoy_addr;
> -
> - /*
> - * Unmap this page from the kernel 1:1 mappings to make sure
> - * we don't log more errors because of speculative access to
> - * the page.
> - * We would like to just call:
> - * set_memory_np((unsigned long)pfn_to_kaddr(pfn), 1);
> - * but doing that would radically increase the odds of a
> - * speculative access to the poison page because we'd have
> - * the virtual address of the kernel 1:1 mapping sitting
> - * around in registers.
> - * Instead we get tricky. We create a non-canonical address
> - * that looks just like the one we want, but has bit 63 flipped.
> - * This relies on set_memory_np() not checking whether we passed
> - * a legal address.
> - */
> -
> - decoy_addr = (pfn << PAGE_SHIFT) + (PAGE_OFFSET ^ BIT(63));
> -
> - if (set_memory_np(decoy_addr, 1))
> - pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn);
> - }
> - #endif
> -
> -
> +/*
> + * Cases where we avoid rendezvous handler timeout:
> + * 1) If this CPU is offline.
> + *
> + * 2) If crashing_cpu was set, e.g. we're entering kdump and we need to
> + * skip those CPUs which remain looping in the 1st kernel - see
> + * crash_nmi_callback().
> + *
> + * Note: there still is a small window between kexec-ing and the new,
> + * kdump kernel establishing a new #MC handler where a broadcasted MCE
> + * might not get handled properly.
> + */
> +static bool __mc_check_crashing_cpu(int cpu)
> +{
> +if (cpu_is_offline(cpu) ||
> +(crashing_cpu != -1 && crashing_cpu != cpu)) {
> +u64 mcgstatus;
> +
> +mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
> +if (mcgstatus & MCG_STATUS_RIPV) {
> +mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
> +return true;
> +}
> +}
> +return false;
> +}
> +
> +static void __mc_scan_banks(struct mce *m, struct mce *final,
> +unsigned long *toclear, unsigned long *valid_banks,
> +int no_way_out, int *worst)
> +{
> +struct mca_config *cfg = _cfg;
> +int severity, i;
> +
> +for (i = 0; i < cfg->banks; i++) {
> +__clear_bit(i, toclear);
> +if (!test_bit(i, valid_banks))
> +continue;
> +
> +if (!mce_banks[i].ctl)
> +continue;
> +
> +m->misc = 0;
> +m->addr = 0;
> +m->bank = i;
> +
> +m->status = mce_rdmsrl(msr_ops.status(i));
> +if (!(m->status & MCI_STATUS_VAL))
> +continue;
> +
> +/*
> + * Corrected or non-signaled errors are handled by
> + * machine_check_poll(). Leave them alone, unless this panics.
> + */
> +if (!(m->status & (cfg->ser ? MCI_STATUS_S : MCI_STATUS_UC)) &&
> +!no_way_out)
> +continue;
> +
> +/* Set taint even when machine check was not enabled. */
> +add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
> +
> +severity = mce_severity(m, cfg->tolerant, NULL, true);
> +
> +/*
> + * When machine check was for corrected/deferred handler don't
> + * touch, unless we're panicking.
> + */
> +if ((severity == MCE_KEEP_SEVERITY ||
> + severity == MCE_UCNA_SEVERITY) && !no_way_out)
> +continue;
> +
> +__set_bit(i, toclear);
> +
> +/* Machine check event was not enabled. Clear, but ignore. */
> +if (severity == MCE_NO_SEVERITY)
> +
Re: linux-next: manual merge of the nvdimm tree with the tip tree
On Tue, Jun 26, 2018 at 3:21 AM, Thomas Gleixner wrote:
> On Tue, 26 Jun 2018, Stephen Rothwell wrote:
>> Today's linux-next merge of the nvdimm tree got a conflict in:
>>
>> arch/x86/kernel/cpu/mcheck/mce.c
>>
>> between commit:
>>
>> d3d6923cd1ae ("x86/mce: Carve out the crashing_cpu check")
>>
>> from the tip tree and commit:
>>
>> f6785eac562b ("x86/memory_failure: Introduce {set,clear}_mce_nospec()")
>>
>> from the nvdimm tree.
>
> Dan, we have rules how to deal with that stuff and there is no excuse for
> you to collect random patches and apply them as you see fit. Stop this
> please.
>
Yes, it was stale from the merge window when I was getting late 0day
and -next testing coverage. I held them back from the merge window
precisely due to lack of acks and review comments. My mistake was not
immediately pulling them down from my -next branch when it was clear
that I needed to circle back and try again for 4.19.
> MCE/RAS patches have a well established and working route and if something
> in your tree really depends on this, which I'm not seeing at all, then
> there are well documented and established procedures to do that.
Sorry, again I had no intention of bypassing x86 and the offending
patches have been pulled from my -next branch.
I need them for teaching memory_failure() how to handle DAX and
persistent memory. The primary challenge DAX and PMEM pose to the
existing error handling flow is that the errors can be repaired and
that the same poison pages can be accessed safely through the
device-driver with memcpy_mcsafe().
Re: linux-next: manual merge of the nvdimm tree with the tip tree
On Tue, Jun 26, 2018 at 3:21 AM, Thomas Gleixner wrote:
> On Tue, 26 Jun 2018, Stephen Rothwell wrote:
>> Today's linux-next merge of the nvdimm tree got a conflict in:
>>
>> arch/x86/kernel/cpu/mcheck/mce.c
>>
>> between commit:
>>
>> d3d6923cd1ae ("x86/mce: Carve out the crashing_cpu check")
>>
>> from the tip tree and commit:
>>
>> f6785eac562b ("x86/memory_failure: Introduce {set,clear}_mce_nospec()")
>>
>> from the nvdimm tree.
>
> Dan, we have rules how to deal with that stuff and there is no excuse for
> you to collect random patches and apply them as you see fit. Stop this
> please.
>
Yes, it was stale from the merge window when I was getting late 0day
and -next testing coverage. I held them back from the merge window
precisely due to lack of acks and review comments. My mistake was not
immediately pulling them down from my -next branch when it was clear
that I needed to circle back and try again for 4.19.
> MCE/RAS patches have a well established and working route and if something
> in your tree really depends on this, which I'm not seeing at all, then
> there are well documented and established procedures to do that.
Sorry, again I had no intention of bypassing x86 and the offending
patches have been pulled from my -next branch.
I need them for teaching memory_failure() how to handle DAX and
persistent memory. The primary challenge DAX and PMEM pose to the
existing error handling flow is that the errors can be repaired and
that the same poison pages can be accessed safely through the
device-driver with memcpy_mcsafe().
Re: linux-next: manual merge of the nvdimm tree with the tip tree
On Tue, 26 Jun 2018, Stephen Rothwell wrote:
> Today's linux-next merge of the nvdimm tree got a conflict in:
>
> arch/x86/kernel/cpu/mcheck/mce.c
>
> between commit:
>
> d3d6923cd1ae ("x86/mce: Carve out the crashing_cpu check")
>
> from the tip tree and commit:
>
> f6785eac562b ("x86/memory_failure: Introduce {set,clear}_mce_nospec()")
>
> from the nvdimm tree.
Dan, we have rules how to deal with that stuff and there is no excuse for
you to collect random patches and apply them as you see fit. Stop this
please.
MCE/RAS patches have a well established and working route and if something
in your tree really depends on this, which I'm not seeing at all, then
there are well documented and established procedures to do that.
Thanks,
tglx
Re: linux-next: manual merge of the nvdimm tree with the tip tree
On Tue, 26 Jun 2018, Stephen Rothwell wrote:
> Today's linux-next merge of the nvdimm tree got a conflict in:
>
> arch/x86/kernel/cpu/mcheck/mce.c
>
> between commit:
>
> d3d6923cd1ae ("x86/mce: Carve out the crashing_cpu check")
>
> from the tip tree and commit:
>
> f6785eac562b ("x86/memory_failure: Introduce {set,clear}_mce_nospec()")
>
> from the nvdimm tree.
Dan, we have rules how to deal with that stuff and there is no excuse for
you to collect random patches and apply them as you see fit. Stop this
please.
MCE/RAS patches have a well established and working route and if something
in your tree really depends on this, which I'm not seeing at all, then
there are well documented and established procedures to do that.
Thanks,
tglx
linux-next: manual merge of the nvdimm tree with the tip tree
Hi all,
Today's linux-next merge of the nvdimm tree got a conflict in:
arch/x86/kernel/cpu/mcheck/mce.c
between commit:
d3d6923cd1ae ("x86/mce: Carve out the crashing_cpu check")
from the tip tree and commit:
f6785eac562b ("x86/memory_failure: Introduce {set,clear}_mce_nospec()")
from the nvdimm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/kernel/cpu/mcheck/mce.c
index 9a16f15f79eb,a0fbf0a8b7e6..
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@@ -1076,129 -1070,6 +1072,100 @@@ static int do_memory_failure(struct mc
return ret;
}
- #ifndef mce_unmap_kpfn
- static void mce_unmap_kpfn(unsigned long pfn)
- {
- unsigned long decoy_addr;
-
- /*
-* Unmap this page from the kernel 1:1 mappings to make sure
-* we don't log more errors because of speculative access to
-* the page.
-* We would like to just call:
-* set_memory_np((unsigned long)pfn_to_kaddr(pfn), 1);
-* but doing that would radically increase the odds of a
-* speculative access to the poison page because we'd have
-* the virtual address of the kernel 1:1 mapping sitting
-* around in registers.
-* Instead we get tricky. We create a non-canonical address
-* that looks just like the one we want, but has bit 63 flipped.
-* This relies on set_memory_np() not checking whether we passed
-* a legal address.
-*/
-
- decoy_addr = (pfn << PAGE_SHIFT) + (PAGE_OFFSET ^ BIT(63));
-
- if (set_memory_np(decoy_addr, 1))
- pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn);
- }
- #endif
-
-
+/*
+ * Cases where we avoid rendezvous handler timeout:
+ * 1) If this CPU is offline.
+ *
+ * 2) If crashing_cpu was set, e.g. we're entering kdump and we need to
+ * skip those CPUs which remain looping in the 1st kernel - see
+ * crash_nmi_callback().
+ *
+ * Note: there still is a small window between kexec-ing and the new,
+ * kdump kernel establishing a new #MC handler where a broadcasted MCE
+ * might not get handled properly.
+ */
+static bool __mc_check_crashing_cpu(int cpu)
+{
+ if (cpu_is_offline(cpu) ||
+ (crashing_cpu != -1 && crashing_cpu != cpu)) {
+ u64 mcgstatus;
+
+ mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
+ if (mcgstatus & MCG_STATUS_RIPV) {
+ mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
+ return true;
+ }
+ }
+ return false;
+}
+
+static void __mc_scan_banks(struct mce *m, struct mce *final,
+ unsigned long *toclear, unsigned long *valid_banks,
+ int no_way_out, int *worst)
+{
+ struct mca_config *cfg = _cfg;
+ int severity, i;
+
+ for (i = 0; i < cfg->banks; i++) {
+ __clear_bit(i, toclear);
+ if (!test_bit(i, valid_banks))
+ continue;
+
+ if (!mce_banks[i].ctl)
+ continue;
+
+ m->misc = 0;
+ m->addr = 0;
+ m->bank = i;
+
+ m->status = mce_rdmsrl(msr_ops.status(i));
+ if (!(m->status & MCI_STATUS_VAL))
+ continue;
+
+ /*
+ * Corrected or non-signaled errors are handled by
+ * machine_check_poll(). Leave them alone, unless this panics.
+ */
+ if (!(m->status & (cfg->ser ? MCI_STATUS_S : MCI_STATUS_UC)) &&
+ !no_way_out)
+ continue;
+
+ /* Set taint even when machine check was not enabled. */
+ add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
+
+ severity = mce_severity(m, cfg->tolerant, NULL, true);
+
+ /*
+ * When machine check was for corrected/deferred handler don't
+ * touch, unless we're panicking.
+ */
+ if ((severity == MCE_KEEP_SEVERITY ||
+ severity == MCE_UCNA_SEVERITY) && !no_way_out)
+ continue;
+
+ __set_bit(i, toclear);
+
+ /* Machine check event was not enabled. Clear, but ignore. */
+ if (severity == MCE_NO_SEVERITY)
+ continue;
+
+ mce_read_aux(m, i);
+
+ /* assuming valid severity level != 0 */
+ m->severity = severity;
+
+ mce_log(m);
+
+
linux-next: manual merge of the nvdimm tree with the tip tree
Hi all,
Today's linux-next merge of the nvdimm tree got a conflict in:
arch/x86/kernel/cpu/mcheck/mce.c
between commit:
d3d6923cd1ae ("x86/mce: Carve out the crashing_cpu check")
from the tip tree and commit:
f6785eac562b ("x86/memory_failure: Introduce {set,clear}_mce_nospec()")
from the nvdimm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/kernel/cpu/mcheck/mce.c
index 9a16f15f79eb,a0fbf0a8b7e6..
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@@ -1076,129 -1070,6 +1072,100 @@@ static int do_memory_failure(struct mc
return ret;
}
- #ifndef mce_unmap_kpfn
- static void mce_unmap_kpfn(unsigned long pfn)
- {
- unsigned long decoy_addr;
-
- /*
-* Unmap this page from the kernel 1:1 mappings to make sure
-* we don't log more errors because of speculative access to
-* the page.
-* We would like to just call:
-* set_memory_np((unsigned long)pfn_to_kaddr(pfn), 1);
-* but doing that would radically increase the odds of a
-* speculative access to the poison page because we'd have
-* the virtual address of the kernel 1:1 mapping sitting
-* around in registers.
-* Instead we get tricky. We create a non-canonical address
-* that looks just like the one we want, but has bit 63 flipped.
-* This relies on set_memory_np() not checking whether we passed
-* a legal address.
-*/
-
- decoy_addr = (pfn << PAGE_SHIFT) + (PAGE_OFFSET ^ BIT(63));
-
- if (set_memory_np(decoy_addr, 1))
- pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn);
- }
- #endif
-
-
+/*
+ * Cases where we avoid rendezvous handler timeout:
+ * 1) If this CPU is offline.
+ *
+ * 2) If crashing_cpu was set, e.g. we're entering kdump and we need to
+ * skip those CPUs which remain looping in the 1st kernel - see
+ * crash_nmi_callback().
+ *
+ * Note: there still is a small window between kexec-ing and the new,
+ * kdump kernel establishing a new #MC handler where a broadcasted MCE
+ * might not get handled properly.
+ */
+static bool __mc_check_crashing_cpu(int cpu)
+{
+ if (cpu_is_offline(cpu) ||
+ (crashing_cpu != -1 && crashing_cpu != cpu)) {
+ u64 mcgstatus;
+
+ mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
+ if (mcgstatus & MCG_STATUS_RIPV) {
+ mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
+ return true;
+ }
+ }
+ return false;
+}
+
+static void __mc_scan_banks(struct mce *m, struct mce *final,
+ unsigned long *toclear, unsigned long *valid_banks,
+ int no_way_out, int *worst)
+{
+ struct mca_config *cfg = _cfg;
+ int severity, i;
+
+ for (i = 0; i < cfg->banks; i++) {
+ __clear_bit(i, toclear);
+ if (!test_bit(i, valid_banks))
+ continue;
+
+ if (!mce_banks[i].ctl)
+ continue;
+
+ m->misc = 0;
+ m->addr = 0;
+ m->bank = i;
+
+ m->status = mce_rdmsrl(msr_ops.status(i));
+ if (!(m->status & MCI_STATUS_VAL))
+ continue;
+
+ /*
+ * Corrected or non-signaled errors are handled by
+ * machine_check_poll(). Leave them alone, unless this panics.
+ */
+ if (!(m->status & (cfg->ser ? MCI_STATUS_S : MCI_STATUS_UC)) &&
+ !no_way_out)
+ continue;
+
+ /* Set taint even when machine check was not enabled. */
+ add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
+
+ severity = mce_severity(m, cfg->tolerant, NULL, true);
+
+ /*
+ * When machine check was for corrected/deferred handler don't
+ * touch, unless we're panicking.
+ */
+ if ((severity == MCE_KEEP_SEVERITY ||
+ severity == MCE_UCNA_SEVERITY) && !no_way_out)
+ continue;
+
+ __set_bit(i, toclear);
+
+ /* Machine check event was not enabled. Clear, but ignore. */
+ if (severity == MCE_NO_SEVERITY)
+ continue;
+
+ mce_read_aux(m, i);
+
+ /* assuming valid severity level != 0 */
+ m->severity = severity;
+
+ mce_log(m);
+
+
linux-next: manual merge of the nvdimm tree with the tip tree
Hi all,
Today's linux-next merge of the nvdimm tree got a conflict in:
kernel/Makefile
between commit:
d7822b1e24f2 ("rseq: Introduce restartable sequences system call")
from the tip tree and commit:
5981690ddb8f ("memremap: split devm_memremap_pages() and memremap()
infrastructure")
from the nvdimm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/Makefile
index 7085c841c413,9b9241361311..
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@@ -112,8 -112,8 +112,9 @@@ obj-$(CONFIG_JUMP_LABEL) += jump_label.
obj-$(CONFIG_CONTEXT_TRACKING) += context_tracking.o
obj-$(CONFIG_TORTURE_TEST) += torture.o
- obj-$(CONFIG_HAS_IOMEM) += memremap.o
+ obj-$(CONFIG_HAS_IOMEM) += iomem.o
+ obj-$(CONFIG_ZONE_DEVICE) += memremap.o
+obj-$(CONFIG_RSEQ) += rseq.o
$(obj)/configs.o: $(obj)/config_data.h
pgphsiKSy5d3l.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the nvdimm tree with the tip tree
Hi all,
Today's linux-next merge of the nvdimm tree got a conflict in:
kernel/Makefile
between commit:
d7822b1e24f2 ("rseq: Introduce restartable sequences system call")
from the tip tree and commit:
5981690ddb8f ("memremap: split devm_memremap_pages() and memremap()
infrastructure")
from the nvdimm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/Makefile
index 7085c841c413,9b9241361311..
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@@ -112,8 -112,8 +112,9 @@@ obj-$(CONFIG_JUMP_LABEL) += jump_label.
obj-$(CONFIG_CONTEXT_TRACKING) += context_tracking.o
obj-$(CONFIG_TORTURE_TEST) += torture.o
- obj-$(CONFIG_HAS_IOMEM) += memremap.o
+ obj-$(CONFIG_HAS_IOMEM) += iomem.o
+ obj-$(CONFIG_ZONE_DEVICE) += memremap.o
+obj-$(CONFIG_RSEQ) += rseq.o
$(obj)/configs.o: $(obj)/config_data.h
pgphsiKSy5d3l.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the nvdimm tree with the tip tree
Hi all,
Today's linux-next merge of the nvdimm tree got a conflict in:
arch/x86/mm/init_64.c
between commit:
91f606a8fa68 ("x86/mm: Replace compile-time checks for 5-level paging with
runtime-time checks")
from the tip tree and commit:
a7e6c7015bf3 ("x86, memremap: fix altmap accounting at free")
from the nvdimm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/mm/init_64.c
index 9bbc51ae54a6,af11a2890235..
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@@ -1099,8 -1089,8 +1095,8 @@@ remove_p4d_table(p4d_t *p4d_start, unsi
* 5-level case we should free them. This code will have to
change
* to adapt for boot-time switching between 4 and 5 level page
tables.
*/
- if (CONFIG_PGTABLE_LEVELS == 5)
+ if (pgtable_l5_enabled)
- free_pud_table(pud_base, p4d, altmap);
+ free_pud_table(pud_base, p4d);
}
if (direct)
pgp4MhEZAO68H.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the nvdimm tree with the tip tree
Hi all,
Today's linux-next merge of the nvdimm tree got a conflict in:
arch/x86/mm/init_64.c
between commit:
91f606a8fa68 ("x86/mm: Replace compile-time checks for 5-level paging with
runtime-time checks")
from the tip tree and commit:
a7e6c7015bf3 ("x86, memremap: fix altmap accounting at free")
from the nvdimm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/mm/init_64.c
index 9bbc51ae54a6,af11a2890235..
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@@ -1099,8 -1089,8 +1095,8 @@@ remove_p4d_table(p4d_t *p4d_start, unsi
* 5-level case we should free them. This code will have to
change
* to adapt for boot-time switching between 4 and 5 level page
tables.
*/
- if (CONFIG_PGTABLE_LEVELS == 5)
+ if (pgtable_l5_enabled)
- free_pud_table(pud_base, p4d, altmap);
+ free_pud_table(pud_base, p4d);
}
if (direct)
pgp4MhEZAO68H.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the nvdimm tree with the tip tree
Hi Dan,
Today's linux-next merge of the nvdimm tree got a conflict in:
drivers/nvdimm/pmem.c
between commit:
71389703839e ("mm, zone_device: Replace {get, put}_zone_device_page() with a
single reference to fix pmem crash")
from the tip tree and commit:
c1d6e828a35d ("pmem: add dax_operations support")
from the nvdimm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/nvdimm/pmem.c
index fbc640bf06b0,58db813e7b7b..
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@@ -232,15 -243,14 +244,19 @@@ static void pmem_release_queue(void *q
blk_cleanup_queue(q);
}
+static void pmem_freeze_queue(void *q)
+{
+ blk_freeze_queue_start(q);
+}
+
- static void pmem_release_disk(void *disk)
+ static void pmem_release_disk(void *__pmem)
{
- del_gendisk(disk);
- put_disk(disk);
+ struct pmem_device *pmem = __pmem;
+
+ kill_dax(pmem->dax_dev);
+ put_dax(pmem->dax_dev);
+ del_gendisk(pmem->disk);
+ put_disk(pmem->disk);
}
static int pmem_attach_disk(struct device *dev,
linux-next: manual merge of the nvdimm tree with the tip tree
Hi Dan,
Today's linux-next merge of the nvdimm tree got a conflict in:
drivers/nvdimm/pmem.c
between commit:
71389703839e ("mm, zone_device: Replace {get, put}_zone_device_page() with a
single reference to fix pmem crash")
from the tip tree and commit:
c1d6e828a35d ("pmem: add dax_operations support")
from the nvdimm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/nvdimm/pmem.c
index fbc640bf06b0,58db813e7b7b..
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@@ -232,15 -243,14 +244,19 @@@ static void pmem_release_queue(void *q
blk_cleanup_queue(q);
}
+static void pmem_freeze_queue(void *q)
+{
+ blk_freeze_queue_start(q);
+}
+
- static void pmem_release_disk(void *disk)
+ static void pmem_release_disk(void *__pmem)
{
- del_gendisk(disk);
- put_disk(disk);
+ struct pmem_device *pmem = __pmem;
+
+ kill_dax(pmem->dax_dev);
+ put_dax(pmem->dax_dev);
+ del_gendisk(pmem->disk);
+ put_disk(pmem->disk);
}
static int pmem_attach_disk(struct device *dev,
