linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the nvdimm tree with the tip tree
@ 2017-05-02  5:37 Stephen Rothwell
  0 siblings, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2017-05-02  5:37 UTC (permalink / raw)
  To: Dan Williams, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

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..000000000000
--- 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,

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: linux-next: manual merge of the nvdimm tree with the tip tree
  2018-06-26  2:18 Stephen Rothwell
  2018-06-26 10:21 ` Thomas Gleixner
@ 2018-08-19  0:34 ` Stephen Rothwell
  1 sibling, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2018-08-19  0:34 UTC (permalink / raw)
  To: Dan Williams
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Borislav Petkov

[-- Attachment #1: Type: text/plain, Size: 5229 bytes --]

Hi all,

On Tue, 26 Jun 2018 12:18:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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..000000000000
> --- 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 = &mca_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);
>  +
>  +		if (severity > *worst) {
>  +			*final = *m;
>  +			*worst = severity;
>  +		}
>  +	}
>  +
>  +	/* mce_clear_state will clear *final, save locally for use later */
>  +	*m = *final;
>  +}
>  +
>   /*
>    * The actual machine check handler. This only handles real
>    * exceptions when something got corrupted coming in through int 18.

This is now a conflict between Linus' tree and the nvdimm tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: linux-next: manual merge of the nvdimm tree with the tip tree
  2018-06-26 10:21 ` Thomas Gleixner
@ 2018-06-26 16:06   ` Dan Williams
  0 siblings, 0 replies; 7+ messages in thread
From: Dan Williams @ 2018-06-26 16:06 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Borislav Petkov

On Tue, Jun 26, 2018 at 3:21 AM, Thomas Gleixner <tglx@linutronix.de> 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().

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: linux-next: manual merge of the nvdimm tree with the tip tree
  2018-06-26  2:18 Stephen Rothwell
@ 2018-06-26 10:21 ` Thomas Gleixner
  2018-06-26 16:06   ` Dan Williams
  2018-08-19  0:34 ` Stephen Rothwell
  1 sibling, 1 reply; 7+ messages in thread
From: Thomas Gleixner @ 2018-06-26 10:21 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Dan Williams, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Borislav Petkov

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* linux-next: manual merge of the nvdimm tree with the tip tree
@ 2018-06-26  2:18 Stephen Rothwell
  2018-06-26 10:21 ` Thomas Gleixner
  2018-08-19  0:34 ` Stephen Rothwell
  0 siblings, 2 replies; 7+ messages in thread
From: Stephen Rothwell @ 2018-06-26  2:18 UTC (permalink / raw)
  To: Dan Williams, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Borislav Petkov

[-- Attachment #1: Type: text/plain, Size: 4724 bytes --]

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..000000000000
--- 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 = &mca_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);
 +
 +		if (severity > *worst) {
 +			*final = *m;
 +			*worst = severity;
 +		}
 +	}
 +
 +	/* mce_clear_state will clear *final, save locally for use later */
 +	*m = *final;
 +}
 +
  /*
   * The actual machine check handler. This only handles real
   * exceptions when something got corrupted coming in through int 18.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* linux-next: manual merge of the nvdimm tree with the tip tree
@ 2018-06-07  4:19 Stephen Rothwell
  0 siblings, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2018-06-07  4:19 UTC (permalink / raw)
  To: Dan Williams, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mathieu Desnoyers

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

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..000000000000
--- 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
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* linux-next: manual merge of the nvdimm tree with the tip tree
@ 2018-03-15  8:06 Stephen Rothwell
  0 siblings, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2018-03-15  8:06 UTC (permalink / raw)
  To: Dan Williams, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Kirill A. Shutemov

[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

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..000000000000
--- 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)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2018-08-19  0:34 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-02  5:37 linux-next: manual merge of the nvdimm tree with the tip tree Stephen Rothwell
2018-03-15  8:06 Stephen Rothwell
2018-06-07  4:19 Stephen Rothwell
2018-06-26  2:18 Stephen Rothwell
2018-06-26 10:21 ` Thomas Gleixner
2018-06-26 16:06   ` Dan Williams
2018-08-19  0:34 ` Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).