linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the tip tree with Linus' tree
@ 2014-05-21  4:12 Stephen Rothwell
  2014-05-21  4:24 ` H. Peter Anvin
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2014-05-21  4:12 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Linus

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/kernel/ldt.c between commit fa81511bb0bb ("x86-64, modify_ldt:
Make support for 16-bit segments a runtime option") from Linus' tree
and commit 34273f41d57e ("x86, espfix: Make it possible to disable
16-bit support") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/kernel/ldt.c
index dcbbaa165bde,c37886d759cc..000000000000
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@@ -231,12 -229,7 +231,7 @@@ static int write_ldt(void __user *ptr, 
  		}
  	}
  
- 	/*
- 	 * On x86-64 we do not support 16-bit segments due to
- 	 * IRET leaking the high bits of the kernel stack address.
- 	 */
- #ifdef CONFIG_X86_64
- 	if (!ldt_info.seg_32bit && !sysctl_ldt16) {
 -	if (!IS_ENABLED(CONFIG_X86_16BIT) && !ldt_info.seg_32bit) {
++	if (!IS_ENABLED(CONFIG_X86_16BIT) && !ldt_info.seg_32bit && !sysctl_ldt16) {
  		error = -EINVAL;
  		goto out_unlock;
  	}

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2024-02-08  1:30 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2024-02-08  1:30 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Ard Biesheuvel, Borislav Petkov (AMD),
	Kevin Loughlin, Linux Kernel Mailing List,
	Linux Next Mailing List, Nathan Chancellor, Paolo Bonzini

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/include/asm/coco.h

between commit:

  e45964771007 ("x86/coco: Define cc_vendor without CONFIG_ARCH_HAS_CC_PLATFORM")

from Linus' tree and commit:

  1c811d403afd ("x86/sev: Fix position dependent variable references in startup code")

from the tip 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/include/asm/coco.h
index 76c310b19b11,21940ef8d290..000000000000
--- a/arch/x86/include/asm/coco.h
+++ b/arch/x86/include/asm/coco.h
@@@ -10,9 -11,15 +11,15 @@@ enum cc_vendor 
  	CC_VENDOR_INTEL,
  };
  
 -extern enum cc_vendor cc_vendor;
+ extern u64 cc_mask;
+ 
  #ifdef CONFIG_ARCH_HAS_CC_PLATFORM
 +extern enum cc_vendor cc_vendor;
- void cc_set_mask(u64 mask);
+ static inline void cc_set_mask(u64 mask)
+ {
+ 	RIP_REL_REF(cc_mask) = mask;
+ }
+ 
  u64 cc_mkenc(u64 val);
  u64 cc_mkdec(u64 val);
  #else

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2023-10-16  1:38 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2023-10-16  1:38 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linus Torvalds, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/kernel/smpboot.c

between commit:

  fbe1bf1e5ff1 ("Revert "x86/smp: Put CPUs into INIT on shutdown if possible"")

from Linus' tree and commit:

  8aa2a4178dc5 ("x86/apic: Use u32 for cpu_present_to_apicid()")

from the tip tree.

I fixed it up (I just used the former which removed the function updated
by the latter) 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

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2023-08-09  2:15 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2023-08-09  2:15 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Arnd Bergmann, Borislav Petkov (AMD),
	Linux Kernel Mailing List, Linux Next Mailing List, Petr Pavlu

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

Hi all,

Today's linux-next merge of the tip tree got conflicts in:

  arch/x86/include/asm/processor.h
  arch/x86/kernel/vmlinux.lds.S
  arch/x86/lib/retpoline.S

between commits:

  fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
  3bbbe97ad83d ("x86/srso: Add a forgotten NOENDBR annotation")

from Linus' tree and commits:

  566ffa3ae964 ("x86/cpu: Fix amd_check_microcode() declaration")
  973ab2d61f33 ("x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANG")
  029239c5b0e6 ("x86/retpoline,kprobes: Skip optprobe check for indirect jumps with retpolines and IBT")

from the tip tree.

I fixed it up (I think - 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/include/asm/processor.h
index 7c67db7c9f53,36d52075fdad..000000000000
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@@ -682,11 -682,11 +682,13 @@@ extern u16 get_llc_id(unsigned int cpu)
  #ifdef CONFIG_CPU_SUP_AMD
  extern u32 amd_get_nodes_per_socket(void);
  extern u32 amd_get_highest_perf(void);
 +extern bool cpu_has_ibpb_brtype_microcode(void);
+ extern void amd_check_microcode(void);
  #else
  static inline u32 amd_get_nodes_per_socket(void)	{ return 0; }
  static inline u32 amd_get_highest_perf(void)		{ return 0; }
 +static inline bool cpu_has_ibpb_brtype_microcode(void)	{ return false; }
+ static inline void amd_check_microcode(void)		{ }
  #endif
  
  extern unsigned long arch_align_stack(unsigned long sp);
diff --cc arch/x86/kernel/vmlinux.lds.S
index e76813230192,dd5b0a68cf84..000000000000
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@@ -133,28 -133,12 +133,26 @@@ SECTION
  		KPROBES_TEXT
  		SOFTIRQENTRY_TEXT
  #ifdef CONFIG_RETPOLINE
- 		__indirect_thunk_start = .;
- 		*(.text.__x86.indirect_thunk)
- 		*(.text.__x86.return_thunk)
- 		__indirect_thunk_end = .;
 -		*(.text..__x86.*)
++		*(.text..__x86.indirect_thunk)
++		*(.text..__x86.return_thunk)
  #endif
  		STATIC_CALL_TEXT
  
  		ALIGN_ENTRY_TEXT_BEGIN
 +#ifdef CONFIG_CPU_SRSO
- 		*(.text.__x86.rethunk_untrain)
++		*(.text..__x86.rethunk_untrain)
 +#endif
 +
  		ENTRY_TEXT
 +
 +#ifdef CONFIG_CPU_SRSO
 +		/*
 +		 * See the comment above srso_untrain_ret_alias()'s
 +		 * definition.
 +		 */
 +		. = srso_untrain_ret_alias | (1 << 2) | (1 << 8) | (1 << 14) | (1 << 20);
- 		*(.text.__x86.rethunk_safe)
++		*(.text..__x86.rethunk_safe)
 +#endif
  		ALIGN_ENTRY_TEXT_END
  		*(.gnu.warning)
  
diff --cc arch/x86/lib/retpoline.S
index 2cff585f22f2,3bea96341d00..000000000000
--- a/arch/x86/lib/retpoline.S
+++ b/arch/x86/lib/retpoline.S
@@@ -11,9 -11,8 +11,9 @@@
  #include <asm/unwind_hints.h>
  #include <asm/percpu.h>
  #include <asm/frame.h>
 +#include <asm/nops.h>
  
- 	.section .text.__x86.indirect_thunk
+ 	.section .text..__x86.indirect_thunk
  
  
  .macro POLINE reg
@@@ -132,47 -131,7 +132,47 @@@ SYM_CODE_END(__x86_indirect_jump_thunk_
   */
  #ifdef CONFIG_RETHUNK
  
 +/*
 + * srso_untrain_ret_alias() and srso_safe_ret_alias() are placed at
 + * special addresses:
 + *
 + * - srso_untrain_ret_alias() is 2M aligned
 + * - srso_safe_ret_alias() is also in the same 2M page but bits 2, 8, 14
 + * and 20 in its virtual address are set (while those bits in the
 + * srso_untrain_ret_alias() function are cleared).
 + *
 + * This guarantees that those two addresses will alias in the branch
 + * target buffer of Zen3/4 generations, leading to any potential
 + * poisoned entries at that BTB slot to get evicted.
 + *
 + * As a result, srso_safe_ret_alias() becomes a safe return.
 + */
 +#ifdef CONFIG_CPU_SRSO
- 	.section .text.__x86.rethunk_untrain
++	.section .text..__x86.rethunk_untrain
 +
 +SYM_START(srso_untrain_ret_alias, SYM_L_GLOBAL, SYM_A_NONE)
 +	ANNOTATE_NOENDBR
 +	ASM_NOP2
 +	lfence
 +	jmp __x86_return_thunk
 +SYM_FUNC_END(srso_untrain_ret_alias)
 +__EXPORT_THUNK(srso_untrain_ret_alias)
 +
- 	.section .text.__x86.rethunk_safe
++	.section .text..__x86.rethunk_safe
 +#endif
 +
 +/* Needs a definition for the __x86_return_thunk alternative below. */
 +SYM_START(srso_safe_ret_alias, SYM_L_GLOBAL, SYM_A_NONE)
 +#ifdef CONFIG_CPU_SRSO
 +	add $8, %_ASM_SP
 +	UNWIND_HINT_FUNC
 +#endif
 +	ANNOTATE_UNRET_SAFE
 +	ret
 +	int3
 +SYM_FUNC_END(srso_safe_ret_alias)
 +
- 	.section .text.__x86.return_thunk
+ 	.section .text..__x86.return_thunk
  
  /*
   * Safety details here pertain to the AMD Zen{1,2} microarchitecture:

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2023-02-15  1:08 Stephen Rothwell
  2023-02-15 11:15 ` Ingo Molnar
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2023-02-15  1:08 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Borislav Petkov (AMD),
	Kim Phillips, Linux Kernel Mailing List, Linux Next Mailing List,
	Paolo Bonzini, Tom Lendacky

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/kernel/cpu/common.c

between commit:

  be8de49bea50 ("x86/speculation: Identify processors vulnerable to SMT RSB predictions")

from Linus' tree and commit:

  e7862eda309e ("x86/cpu: Support AMD Automatic IBRS")

from the tip 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/common.c
index f3cc7699e1e1,38646f1b5f14..000000000000
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@@ -1403,14 -1412,6 +1414,9 @@@ static void __init cpu_set_bug_bits(str
  			setup_force_cpu_bug(X86_BUG_RETBLEED);
  	}
  
- 	if (cpu_has(c, X86_FEATURE_IBRS_ENHANCED) &&
- 	    !cpu_matches(cpu_vuln_whitelist, NO_EIBRS_PBRSB) &&
- 	    !(ia32_cap & ARCH_CAP_PBRSB_NO))
- 		setup_force_cpu_bug(X86_BUG_EIBRS_PBRSB);
- 
 +	if (cpu_matches(cpu_vuln_blacklist, SMT_RSB))
 +		setup_force_cpu_bug(X86_BUG_SMT_RSB);
 +
  	if (cpu_matches(cpu_vuln_whitelist, NO_MELTDOWN))
  		return;
  

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2022-07-13  5:08 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2022-07-13  5:08 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Borislav Petkov, Chang S. Bae, Dave Hansen,
	Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/idle/intel_idle.c

between commit:

  bf5835bcdb96 ("intel_idle: Disable IBRS during long idle")

from Linus' tree and commit:

  f08ef9057b7b ("intel_idle: Add a new flag to initialize the AMX state")

from the tip 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/idle/intel_idle.c
index f5c6802aa6c3,8a19ba1c2c1b..000000000000
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@@ -53,9 -52,9 +53,10 @@@
  #include <linux/moduleparam.h>
  #include <asm/cpu_device_id.h>
  #include <asm/intel-family.h>
 +#include <asm/nospec-branch.h>
  #include <asm/mwait.h>
  #include <asm/msr.h>
+ #include <asm/fpu/api.h>
  
  #define INTEL_IDLE_VERSION "0.5.1"
  
@@@ -107,12 -106,11 +108,17 @@@ static unsigned int mwait_substates __i
   */
  #define CPUIDLE_FLAG_ALWAYS_ENABLE	BIT(15)
  
 +/*
 + * Disable IBRS across idle (when KERNEL_IBRS), is exclusive vs IRQ_ENABLE
 + * above.
 + */
 +#define CPUIDLE_FLAG_IBRS		BIT(16)
 +
+ /*
+  * Initialize large xstate for the C6-state entrance.
+  */
 -#define CPUIDLE_FLAG_INIT_XSTATE	BIT(16)
++#define CPUIDLE_FLAG_INIT_XSTATE	BIT(17)
+ 
  /*
   * MWAIT takes an 8-bit "hint" in EAX "suggesting"
   * the C-state (top nibble) and sub-state (bottom nibble)
@@@ -167,24 -165,13 +173,31 @@@ static __cpuidle int intel_idle_irq(str
  	return ret;
  }
  
 +static __cpuidle int intel_idle_ibrs(struct cpuidle_device *dev,
 +				     struct cpuidle_driver *drv, int index)
 +{
 +	bool smt_active = sched_smt_active();
 +	u64 spec_ctrl = spec_ctrl_current();
 +	int ret;
 +
 +	if (smt_active)
 +		wrmsrl(MSR_IA32_SPEC_CTRL, 0);
 +
 +	ret = __intel_idle(dev, drv, index);
 +
 +	if (smt_active)
 +		wrmsrl(MSR_IA32_SPEC_CTRL, spec_ctrl);
 +
 +	return ret;
 +}
 +
+ static __cpuidle int intel_idle_xstate(struct cpuidle_device *dev,
+ 				       struct cpuidle_driver *drv, int index)
+ {
+ 	fpu_idle_fpregs();
+ 	return __intel_idle(dev, drv, index);
+ }
+ 
  /**
   * intel_idle_s2idle - Ask the processor to enter the given idle state.
   * @dev: cpuidle device of the target CPU.
@@@ -1845,12 -1837,9 +1863,15 @@@ static void __init intel_idle_init_csta
  		if (cpuidle_state_table[cstate].flags & CPUIDLE_FLAG_IRQ_ENABLE)
  			drv->states[drv->state_count].enter = intel_idle_irq;
  
 +		if (cpu_feature_enabled(X86_FEATURE_KERNEL_IBRS) &&
 +		    cpuidle_state_table[cstate].flags & CPUIDLE_FLAG_IBRS) {
 +			WARN_ON_ONCE(cpuidle_state_table[cstate].flags & CPUIDLE_FLAG_IRQ_ENABLE);
 +			drv->states[drv->state_count].enter = intel_idle_ibrs;
 +		}
 +
+ 		if (cpuidle_state_table[cstate].flags & CPUIDLE_FLAG_INIT_XSTATE)
+ 			drv->states[drv->state_count].enter = intel_idle_xstate;
+ 
  		if ((disabled_states_mask & BIT(drv->state_count)) ||
  		    ((icpu->use_acpi || force_use_acpi) &&
  		     intel_idle_off_by_default(mwait_hint) &&

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2022-05-09  3:59 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2022-05-09  3:59 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Paolo Bonzini, Sandipan Das

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/kvm/cpuid.c

between commit:

  5a1bde46f98b ("kvm: x86/cpuid: Only provide CPUID leaf 0xA if host has architectural PMU")

from Linus' tree and commit:

  202c3484768b ("kvm: x86/cpuid: Fix CPUID leaf 0xA")

from the tip tree.

I fixed it up (I (arbitrarily) chose to use the latter) 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

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2022-01-04  2:45 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2022-01-04  2:45 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Nitesh Narayan Lal, Saeed Mahameed, Shay Drory

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c

between commit:

  26a7993c93a7 ("net/mlx5: Use first online CPU instead of hard coded CPU")

from Linus' tree and commit:

  7451e9ea8e20 ("net/mlx5: Use irq_set_affinity_and_hint()")

from the tip 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/net/ethernet/mellanox/mlx5/core/pci_irq.c
index 163e01fe500e,54fb67cec544..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c
@@@ -398,8 -398,8 +398,8 @@@ irq_pool_request_vector(struct mlx5_irq
  	cpumask_copy(irq->mask, affinity);
  	if (!irq_pool_is_sf_pool(pool) && !pool->xa_num_irqs.max &&
  	    cpumask_empty(irq->mask))
 -		cpumask_set_cpu(0, irq->mask);
 +		cpumask_set_cpu(cpumask_first(cpu_online_mask), irq->mask);
- 	irq_set_affinity_hint(irq->irqn, irq->mask);
+ 	irq_set_affinity_and_hint(irq->irqn, irq->mask);
  unlock:
  	mutex_unlock(&pool->lock);
  	return irq;

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2021-10-11  2:21 Stephen Rothwell
  2021-10-11 20:48 ` Borislav Petkov
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2021-10-11  2:21 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Borislav Petkov, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/kernel/fpu/signal.c

between commit:

  d298b03506d3 ("x86/fpu: Restore the masking out of reserved MXCSR bits")

from Linus' tree and commits:

  052adee66828 ("x86/fpu/signal: Change return type of copy_fpstate_to_sigframe() to boolean")
  908d969f88bf ("x86/fpu: Restore the masking out of reserved MXCSR bits")

from the tip tree.

I fixed it up (I just used the version form Linus' tree, but with the
changed return type - 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/fpu/signal.c
index fa17a27390ab,ae51e50f25e8..000000000000
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@@ -377,16 -382,10 +382,16 @@@ static bool __fpu_restore_sig(void __us
  	} else {
  		if (__copy_from_user(&fpu->state.fxsave, buf_fx,
  				     sizeof(fpu->state.fxsave)))
- 			return -EFAULT;
+ 			return false;
  
 -		/* Mask out reserved MXCSR bits. */
 -		fpu->state.fxsave.mxcsr &= mxcsr_feature_mask;
 +		if (IS_ENABLED(CONFIG_X86_64)) {
 +			/* Reject invalid MXCSR values. */
 +			if (fpu->state.fxsave.mxcsr & ~mxcsr_feature_mask)
- 				return -EINVAL;
++				return false;
 +		} else {
 +			/* Mask invalid bits out for historical reasons (broken hardware). */
 +			fpu->state.fxsave.mxcsr &= ~mxcsr_feature_mask;
 +		}
  
  		/* Enforce XFEATURE_MASK_FPSSE when XSAVE is enabled */
  		if (use_xsave())

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2020-11-06  2:39 Stephen Rothwell
  2020-11-06  2:46 ` Steven Rostedt
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2020-11-06  2:39 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Ingo Molnar, Linux Kernel Mailing List, Linux Next Mailing List,
	Masami Hiramatsu, Steven Rostedt (VMware)

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  kernel/kprobes.c

between commit:

  645f224e7ba2 ("kprobes: Tell lockdep about kprobe nesting")

from Linus' tree and commits:

  d741bf41d7c7 ("kprobes: Remove kretprobe hash")
  6e426e0fcd20 ("kprobes: Replace rp->free_instance with freelist")

from the tip tree.

I fixed it up (the latter removed the code updated by the former, so I
just used the latter) 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

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2020-08-12  1:21 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2020-08-12  1:21 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Ahmed S. Darwish

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  kernel/time/timekeeping.c

between commit:

  025e82bcbc34 ("timekeeping: Use sequence counter with associated raw spinlock")

from Linus' tree and commit:

  19d0070a2792 ("timekeeping/vsyscall: Provide vdso_update_begin/end()")

from the tip 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/time/timekeeping.c
index 406306b33452,4c7212f3c603..000000000000
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@@ -39,8 -39,6 +39,8 @@@ enum timekeeping_adv_mode 
  	TK_ADV_FREQ
  };
  
- static DEFINE_RAW_SPINLOCK(timekeeper_lock);
++DEFINE_RAW_SPINLOCK(timekeeper_lock);
 +
  /*
   * The most important data for readout fits into a single 64 byte
   * cache line.

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2020-06-11  1:00 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2020-06-11  1:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Will Deacon

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  include/linux/compiler_types.h

between commits:

  a5dead405f6b ("compiler_types.h: Optimize __unqual_scalar_typeof compilation time")

from Linus' tree and commits:

  1fd76043ecb0 ("compiler_types.h: Optimize __unqual_scalar_typeof compilation time")

from the tip tree.

I fixed it up (I just used the version from Linus' tree) 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

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2020-06-11  0:52 Stephen Rothwell
  2020-06-11 10:43 ` Thomas Gleixner
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2020-06-11  0:52 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Will Deacon

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

Hi all,

Today's linux-next merge of the tip tree got conflicts in:

  include/linux/compiler.h

between commits:

  dee081bf8f82 ("READ_ONCE: Drop pointer qualifiers when reading from scalar types")
  9e343b467c70 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses")
  a5460b5e5fb8 ("READ_ONCE: Simplify implementations of {READ,WRITE}_ONCE()")

from Linus' tree and commits:

  2ab3a0a02905 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses")
  7b364f0949ae ("READ_ONCE: Drop pointer qualifiers when reading from scalar types")
  bbfa112b46bd ("READ_ONCE: Simplify implementations of {READ,WRITE}_ONCE()")
(and maybe others)

from the tip tree.

I fixed it up (I think - please check the final result when I release it)
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

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2020-06-10  1:49 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2020-06-10  1:49 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Mike Rapoport, Andrew Morton, Will Deacon

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/sparc/include/asm/pgtable_32.h

because commits

  3408974d0533 ("sparc32: mm: Restructure sparc32 MMU page-table layout")
  c95be5b549d6 ("sparc32: mm: Change pgtable_t type to pte_t * instead of struct page *")

from the tip tree also exist in Linus' tree as different commits followed
by other changes.

I fixed it up (I just used Linus' version) 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

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2020-06-10  1:42 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2020-06-10  1:42 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Mark Gross,
	Balbir Singh

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  Documentation/admin-guide/hw-vuln/index.rst

between commit:

  7222a1b5b874 ("x86/speculation: Add SRBDS vulnerability and mitigation documentation")

from Linus' tree and commit:

  0fcfdf55db9e ("Documentation: Add L1D flushing Documentation")

from the tip 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 Documentation/admin-guide/hw-vuln/index.rst
index ca4dbdd9016d,35633b299d45..000000000000
--- a/Documentation/admin-guide/hw-vuln/index.rst
+++ b/Documentation/admin-guide/hw-vuln/index.rst
@@@ -14,4 -14,4 +14,5 @@@ are configurable at compile, boot or ru
     mds
     tsx_async_abort
     multihit.rst
 +   special-register-buffer-data-sampling.rst
+    l1d_flush

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2020-05-18  5:10 Stephen Rothwell
  2020-05-18  7:12 ` Borislav Petkov
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2020-05-18  5:10 UTC (permalink / raw)
  To: 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: 745 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  include/linux/compiler.h

between commit:

  a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")

from Linus' tree and commit:

  f670269a42bf ("x86: Fix early boot crash on gcc-10, next try")

from the tip tree.

I fixed it up (I just used Linus' tree version) 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

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2020-01-06  2:17 Stephen Rothwell
  2020-01-06  6:53 ` Ingo Molnar
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2020-01-06  2:17 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Dominik Brodowski, Marco Elver, Paul E. McKenney

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  init/main.c

between commit:

  74f1a299107b ("Revert "fs: remove ksys_dup()"")

from Linus' tree and commit:

  dfd402a4c4ba ("kcsan: Add Kernel Concurrency Sanitizer infrastructure")

from the tip 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 init/main.c
index 2cd736059416,919f65faeb7e..000000000000
--- a/init/main.c
+++ b/init/main.c
@@@ -93,6 -93,8 +93,7 @@@
  #include <linux/rodata_test.h>
  #include <linux/jump_label.h>
  #include <linux/mem_encrypt.h>
 -#include <linux/file.h>
+ #include <linux/kcsan.h>
  
  #include <asm/io.h>
  #include <asm/bugs.h>

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2019-12-20  1:53 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2019-12-20  1:53 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Changbin Du,
	Andrew Morton, Marco Elver, Paul E. McKenney

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  lib/Kconfig.debug

between commit:

  045f6d7942be ("lib/Kconfig.debug: fix some messed up configurations")

from Linus' tree and commit:

  dfd402a4c4ba ("kcsan: Add Kernel Concurrency Sanitizer infrastructure")

from the tip 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 lib/Kconfig.debug
index 5ffe144c9794,bee08ed4a139..000000000000
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@@ -447,6 -447,6 +447,8 @@@ source "lib/Kconfig.kgdb
  
  source "lib/Kconfig.ubsan"
  
++source "lib/Kconfig.kcsan"
++
  endmenu
  
  config DEBUG_KERNEL
@@@ -2175,8 -2130,55 +2177,6 @@@ config MEMTES
  	        memtest=17, mean do 17 test patterns.
  	  If you are unsure how to answer this question, answer N.
  
 -source "samples/Kconfig"
 -
 -source "lib/Kconfig.kcsan"
 -
 -config ARCH_HAS_DEVMEM_IS_ALLOWED
 -	bool
 -
 -config STRICT_DEVMEM
 -	bool "Filter access to /dev/mem"
 -	depends on MMU && DEVMEM
 -	depends on ARCH_HAS_DEVMEM_IS_ALLOWED
 -	default y if PPC || X86 || ARM64
 -	---help---
 -	  If this option is disabled, you allow userspace (root) access to all
 -	  of memory, including kernel and userspace memory. Accidental
 -	  access to this is obviously disastrous, but specific access can
 -	  be used by people debugging the kernel. Note that with PAT support
 -	  enabled, even in this case there are restrictions on /dev/mem
 -	  use due to the cache aliasing requirements.
 -
 -	  If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem
 -	  file only allows userspace access to PCI space and the BIOS code and
 -	  data regions.  This is sufficient for dosemu and X and all common
 -	  users of /dev/mem.
 -
 -	  If in doubt, say Y.
 -
 -config IO_STRICT_DEVMEM
 -	bool "Filter I/O access to /dev/mem"
 -	depends on STRICT_DEVMEM
 -	---help---
 -	  If this option is disabled, you allow userspace (root) access to all
 -	  io-memory regardless of whether a driver is actively using that
 -	  range.  Accidental access to this is obviously disastrous, but
 -	  specific access can be used by people debugging kernel drivers.
 -
 -	  If this option is switched on, the /dev/mem file only allows
 -	  userspace access to *idle* io-memory ranges (see /proc/iomem) This
 -	  may break traditional users of /dev/mem (dosemu, legacy X, etc...)
 -	  if the driver using a given range cannot be disabled.
 -
 -	  If in doubt, say Y.
 -
 -menu "$(SRCARCH) Debugging"
 -
 -source "arch/$(SRCARCH)/Kconfig.debug"
--
 -endmenu
--
  config HYPERV_TESTING
  	bool "Microsoft Hyper-V driver testing"
  	default n

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2019-12-16  2:43 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2019-12-16  2:43 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Dominik Brodowski, Marco Elver, Paul E. McKenney

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  init/main.c

between commit:

  8243186f0cc7 ("fs: remove ksys_dup()")

from Linus' tree and commit:

  dfd402a4c4ba ("kcsan: Add Kernel Concurrency Sanitizer infrastructure")

from the tip 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 init/main.c
index ec3a1463ac69,4d814de017ee..000000000000
--- a/init/main.c
+++ b/init/main.c
@@@ -93,7 -93,7 +93,8 @@@
  #include <linux/rodata_test.h>
  #include <linux/jump_label.h>
  #include <linux/mem_encrypt.h>
 +#include <linux/file.h>
+ #include <linux/kcsan.h>
  
  #include <asm/io.h>
  #include <asm/bugs.h>

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2019-12-03  2:10 Stephen Rothwell
  2019-12-03  6:57 ` Ingo Molnar
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2019-12-03  2:10 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/mm/pat_interval.c

between commit:

  91298f1a302d ("x86/mm/pat: Fix off-by-one bugs in interval tree search")

from Linus' tree and commits:

  70bfed57a6de ("x86/mm/pat: Move the memtype related files to arch/x86/mm/pat/")

from the tip tree.

I fixed it up (I just removed the file - there may be further updates
required) 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

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2019-09-02  7:31 Stephen Rothwell
  2019-09-02 18:07 ` Ingo Molnar
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2019-09-02  7:31 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Len Brown,
	Zhang Rui, Rajneesh Bhardwaj

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  tools/power/x86/turbostat/turbostat.c

between commit:

  cd188af5282d ("tools/power turbostat: Fix Haswell Core systems")
  b62b3184576b ("tools/power turbostat: add Jacobsville support")
  d93ea567fc4e ("tools/power turbostat: Add Ice Lake NNPI support")

from Linus' tree and commit:

  c66f78a6de4d ("x86/intel: Aggregate big core client naming")
  af239c44e3f9 ("x86/intel: Aggregate big core mobile naming")
  5e741407eab7 ("x86/intel: Aggregate big core graphics naming")
  5ebb34edbefa ("x86/intel: Aggregate microserver naming")

from the tip 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 tools/power/x86/turbostat/turbostat.c
index b2a86438f074,6eef0cee6d75..000000000000
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@@ -3234,15 -3207,14 +3234,15 @@@ int probe_nhm_msrs(unsigned int family
  		pkg_cstate_limits = snb_pkg_cstate_limits;
  		has_misc_feature_control = 1;
  		break;
- 	case INTEL_FAM6_HASWELL_CORE:	/* HSW */
+ 	case INTEL_FAM6_HASWELL:	/* HSW */
  	case INTEL_FAM6_HASWELL_X:	/* HSX */
- 	case INTEL_FAM6_HASWELL_ULT:	/* HSW */
- 	case INTEL_FAM6_HASWELL_GT3E:	/* HSW */
- 	case INTEL_FAM6_BROADWELL_CORE:	/* BDW */
- 	case INTEL_FAM6_BROADWELL_GT3E:	/* BDW */
++	case INTEL_FAM6_HASWELL_L:	/* HSW */
+ 	case INTEL_FAM6_HASWELL_G:	/* HSW */
+ 	case INTEL_FAM6_BROADWELL:	/* BDW */
+ 	case INTEL_FAM6_BROADWELL_G:	/* BDW */
  	case INTEL_FAM6_BROADWELL_X:	/* BDX */
- 	case INTEL_FAM6_SKYLAKE_MOBILE:	/* SKL */
- 	case INTEL_FAM6_CANNONLAKE_MOBILE:	/* CNL */
+ 	case INTEL_FAM6_SKYLAKE_L:	/* SKL */
+ 	case INTEL_FAM6_CANNONLAKE_L:	/* CNL */
  		pkg_cstate_limits = hsw_pkg_cstate_limits;
  		has_misc_feature_control = 1;
  		break;
@@@ -3431,15 -3403,14 +3431,15 @@@ int has_config_tdp(unsigned int family
  
  	switch (model) {
  	case INTEL_FAM6_IVYBRIDGE:	/* IVB */
- 	case INTEL_FAM6_HASWELL_CORE:	/* HSW */
+ 	case INTEL_FAM6_HASWELL:	/* HSW */
  	case INTEL_FAM6_HASWELL_X:	/* HSX */
- 	case INTEL_FAM6_HASWELL_ULT:	/* HSW */
- 	case INTEL_FAM6_HASWELL_GT3E:	/* HSW */
- 	case INTEL_FAM6_BROADWELL_CORE:	/* BDW */
- 	case INTEL_FAM6_BROADWELL_GT3E:	/* BDW */
++	case INTEL_FAM6_HASWELL_L:	/* HSW */
+ 	case INTEL_FAM6_HASWELL_G:	/* HSW */
+ 	case INTEL_FAM6_BROADWELL:	/* BDW */
+ 	case INTEL_FAM6_BROADWELL_G:	/* BDW */
  	case INTEL_FAM6_BROADWELL_X:	/* BDX */
- 	case INTEL_FAM6_SKYLAKE_MOBILE:	/* SKL */
- 	case INTEL_FAM6_CANNONLAKE_MOBILE:	/* CNL */
+ 	case INTEL_FAM6_SKYLAKE_L:	/* SKL */
+ 	case INTEL_FAM6_CANNONLAKE_L:	/* CNL */
  	case INTEL_FAM6_SKYLAKE_X:	/* SKX */
  
  	case INTEL_FAM6_XEON_PHI_KNL:	/* Knights Landing */
@@@ -3870,11 -3840,10 +3870,11 @@@ void rapl_probe_intel(unsigned int fami
  	switch (model) {
  	case INTEL_FAM6_SANDYBRIDGE:
  	case INTEL_FAM6_IVYBRIDGE:
- 	case INTEL_FAM6_HASWELL_CORE:	/* HSW */
- 	case INTEL_FAM6_HASWELL_ULT:	/* HSW */
- 	case INTEL_FAM6_HASWELL_GT3E:	/* HSW */
- 	case INTEL_FAM6_BROADWELL_CORE:	/* BDW */
- 	case INTEL_FAM6_BROADWELL_GT3E:	/* BDW */
+ 	case INTEL_FAM6_HASWELL:	/* HSW */
++	case INTEL_FAM6_HASWELL_L:	/* HSW */
+ 	case INTEL_FAM6_HASWELL_G:	/* HSW */
+ 	case INTEL_FAM6_BROADWELL:	/* BDW */
+ 	case INTEL_FAM6_BROADWELL_G:	/* BDW */
  		do_rapl = RAPL_PKG | RAPL_CORES | RAPL_CORE_POLICY | RAPL_GFX | RAPL_PKG_POWER_INFO;
  		if (rapl_joules) {
  			BIC_PRESENT(BIC_Pkg_J);
@@@ -4063,9 -4031,8 +4063,9 @@@ void perf_limit_reasons_probe(unsigned 
  		return;
  
  	switch (model) {
- 	case INTEL_FAM6_HASWELL_CORE:	/* HSW */
- 	case INTEL_FAM6_HASWELL_ULT:	/* HSW */
- 	case INTEL_FAM6_HASWELL_GT3E:	/* HSW */
+ 	case INTEL_FAM6_HASWELL:	/* HSW */
++	case INTEL_FAM6_HASWELL_L:	/* HSW */
+ 	case INTEL_FAM6_HASWELL_G:	/* HSW */
  		do_gfx_perf_limit_reasons = 1;
  	case INTEL_FAM6_HASWELL_X:	/* HSX */
  		do_core_perf_limit_reasons = 1;
@@@ -4282,15 -4249,14 +4282,15 @@@ int has_snb_msrs(unsigned int family, u
  	case INTEL_FAM6_SANDYBRIDGE_X:
  	case INTEL_FAM6_IVYBRIDGE:	/* IVB */
  	case INTEL_FAM6_IVYBRIDGE_X:	/* IVB Xeon */
- 	case INTEL_FAM6_HASWELL_CORE:	/* HSW */
+ 	case INTEL_FAM6_HASWELL:	/* HSW */
  	case INTEL_FAM6_HASWELL_X:	/* HSW */
- 	case INTEL_FAM6_HASWELL_ULT:	/* HSW */
- 	case INTEL_FAM6_HASWELL_GT3E:	/* HSW */
- 	case INTEL_FAM6_BROADWELL_CORE:	/* BDW */
- 	case INTEL_FAM6_BROADWELL_GT3E:	/* BDW */
++	case INTEL_FAM6_HASWELL_L:	/* HSW */
+ 	case INTEL_FAM6_HASWELL_G:	/* HSW */
+ 	case INTEL_FAM6_BROADWELL:	/* BDW */
+ 	case INTEL_FAM6_BROADWELL_G:	/* BDW */
  	case INTEL_FAM6_BROADWELL_X:	/* BDX */
- 	case INTEL_FAM6_SKYLAKE_MOBILE:	/* SKL */
- 	case INTEL_FAM6_CANNONLAKE_MOBILE:	/* CNL */
+ 	case INTEL_FAM6_SKYLAKE_L:	/* SKL */
+ 	case INTEL_FAM6_CANNONLAKE_L:	/* CNL */
  	case INTEL_FAM6_SKYLAKE_X:	/* SKX */
  	case INTEL_FAM6_ATOM_GOLDMONT:	/* BXT */
  	case INTEL_FAM6_ATOM_GOLDMONT_PLUS:
@@@ -4318,10 -4284,10 +4318,10 @@@ int has_c8910_msrs(unsigned int family
  		return 0;
  
  	switch (model) {
- 	case INTEL_FAM6_HASWELL_ULT:	/* HSW */
- 	case INTEL_FAM6_BROADWELL_CORE:	/* BDW */
- 	case INTEL_FAM6_SKYLAKE_MOBILE:	/* SKL */
- 	case INTEL_FAM6_CANNONLAKE_MOBILE:	/* CNL */
 -	case INTEL_FAM6_HASWELL:
++	case INTEL_FAM6_HASWELL_L:	/* HSW */
+ 	case INTEL_FAM6_BROADWELL:	/* BDW */
+ 	case INTEL_FAM6_SKYLAKE_L:	/* SKL */
+ 	case INTEL_FAM6_CANNONLAKE_L:	/* CNL */
  	case INTEL_FAM6_ATOM_GOLDMONT:	/* BXT */
  	case INTEL_FAM6_ATOM_GOLDMONT_PLUS:
  		return 1;
@@@ -4602,22 -4568,21 +4602,22 @@@ unsigned int intel_model_duplicates(uns
  	case INTEL_FAM6_XEON_PHI_KNM:
  		return INTEL_FAM6_XEON_PHI_KNL;
  
 -	case INTEL_FAM6_HASWELL_L:
 -		return INTEL_FAM6_HASWELL;
 -
  	case INTEL_FAM6_BROADWELL_X:
- 	case INTEL_FAM6_BROADWELL_XEON_D:	/* BDX-DE */
+ 	case INTEL_FAM6_BROADWELL_D:	/* BDX-DE */
  		return INTEL_FAM6_BROADWELL_X;
  
- 	case INTEL_FAM6_SKYLAKE_MOBILE:
- 	case INTEL_FAM6_SKYLAKE_DESKTOP:
- 	case INTEL_FAM6_KABYLAKE_MOBILE:
- 	case INTEL_FAM6_KABYLAKE_DESKTOP:
- 		return INTEL_FAM6_SKYLAKE_MOBILE;
+ 	case INTEL_FAM6_SKYLAKE_L:
+ 	case INTEL_FAM6_SKYLAKE:
+ 	case INTEL_FAM6_KABYLAKE_L:
+ 	case INTEL_FAM6_KABYLAKE:
+ 		return INTEL_FAM6_SKYLAKE_L;
  
- 	case INTEL_FAM6_ICELAKE_MOBILE:
+ 	case INTEL_FAM6_ICELAKE_L:
 +	case INTEL_FAM6_ICELAKE_NNPI:
- 		return INTEL_FAM6_CANNONLAKE_MOBILE;
+ 		return INTEL_FAM6_CANNONLAKE_L;
 +
- 	case INTEL_FAM6_ATOM_TREMONT_X:
- 		return INTEL_FAM6_ATOM_GOLDMONT_X;
++	case INTEL_FAM6_ATOM_TREMONT_D:
++		return INTEL_FAM6_ATOM_GOLDMONT_D;
  	}
  	return model;
  }

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2019-07-29  2:00 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2019-07-29  2:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Masahiro Yamada, Greg Kroah-Hartman

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/include/uapi/asm/types.h

between commit:

  d9c525229521 ("treewide: add "WITH Linux-syscall-note" to SPDX tag of uapi headers")

from Linus' tree and commit:

  701010532164 ("x86/build: Remove unneeded uapi asm-generic wrappers")

from the tip tree.

I fixed it up (I removed the file) 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

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2019-03-06  5:53 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2019-03-06  5:53 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Yury Norov,
	Borislav Petkov

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/um/Kconfig

between commit:

  eac616557050 ("x86: Deprecate a.out support")

from Linus' tree and commit:

  942fa985e9f1 ("32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option")

from the tip 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/um/Kconfig
index 494eeb51e4e1,ab14e6f73ca4..a9e80e44178c
--- a/arch/x86/um/Kconfig
+++ b/arch/x86/um/Kconfig
@@@ -16,6 -16,8 +16,7 @@@ config 64BI
  
  config X86_32
  	def_bool !64BIT
 -	select HAVE_AOUT
+ 	select ARCH_32BIT_OFF_T
  	select ARCH_WANT_IPC_PARSE_VERSION
  	select MODULES_USE_ELF_REL
  	select CLONE_BACKWARDS

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2018-10-12  2:14 Stephen Rothwell
  2018-10-12  2:18 ` Kees Cook
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2018-10-12  2:14 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Kees Cook,
	Arnd Bergmann

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/mm/pgtable.c

between commit:

  184d47f0fd36 ("x86/mm: Avoid VLA in pgd_alloc()")

from Linus' tree and commit:

  1be3f247c288 ("x86/mm: Avoid VLA in pgd_alloc()")

from the tip tree.

I fixed it up (I used the version from Linus' tree) 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

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2018-06-07  1:53 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2018-06-07  1:53 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Mathieu Desnoyers, Alexandre Belloni, Shuah Khan (Samsung OSG)

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  tools/testing/selftests/Makefile

between commit:

  a12ab9e125f1 ("selftests: move RTC tests to rtc subfolder")

from Linus' tree and commit:

  ccba8b64452b ("rseq/selftests: Provide Makefile, scripts, gitignore")

from the tip 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 tools/testing/selftests/Makefile
index 4cd339b5366a,593fb44c9cd4..000000000000
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@@ -29,7 -28,7 +29,8 @@@ TARGETS += powerp
  TARGETS += proc
  TARGETS += pstore
  TARGETS += ptrace
+ TARGETS += rseq
 +TARGETS += rtc
  TARGETS += seccomp
  TARGETS += sigaltstack
  TARGETS += size

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2018-02-12  1:27 Stephen Rothwell
  2018-02-12  7:19 ` Ingo Molnar
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2018-02-12  1:27 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	KarimAllah Ahmed, David Woodhouse, Paolo Bonzini,
	Radim Krčmář

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/kvm/vmx.c

between commit:

  c992384bde84 ("KVM: vmx: speed up MSR bitmap merge")

from Linus' tree and commit:

  ff37dc0cd96c ("KVM/nVMX: Set the CPU_BASED_USE_MSR_BITMAPS if we have a valid L02 MSR bitmap")

from the tip tree.

I fixed it up (I think - 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/kvm/vmx.c
index f427723dc7db,91e3539cba02..000000000000
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@@ -10136,7 -10127,12 +10136,10 @@@ static void nested_get_vmcs12_pages(str
  			(unsigned long)(vmcs12->posted_intr_desc_addr &
  			(PAGE_SIZE - 1)));
  	}
- 	if (!nested_vmx_prepare_msr_bitmap(vcpu, vmcs12))
 -	if (cpu_has_vmx_msr_bitmap() &&
 -	    nested_cpu_has(vmcs12, CPU_BASED_USE_MSR_BITMAPS) &&
 -	    nested_vmx_merge_msr_bitmap(vcpu, vmcs12))
++	if (nested_vmx_prepare_msr_bitmap(vcpu, vmcs12))
+ 		vmcs_set_bits(CPU_BASED_VM_EXEC_CONTROL,
+ 			      CPU_BASED_USE_MSR_BITMAPS);
+ 	else
  		vmcs_clear_bits(CPU_BASED_VM_EXEC_CONTROL,
  				CPU_BASED_USE_MSR_BITMAPS);
  }
@@@ -10224,14 -10220,9 +10227,14 @@@ static inline bool nested_vmx_prepare_m
  	 *    updated to reflect this when L1 (or its L2s) actually write to
  	 *    the MSR.
  	 */
- 	bool pred_cmd = msr_write_intercepted_l01(vcpu, MSR_IA32_PRED_CMD);
- 	bool spec_ctrl = msr_write_intercepted_l01(vcpu, MSR_IA32_SPEC_CTRL);
+ 	bool pred_cmd = !msr_write_intercepted_l01(vcpu, MSR_IA32_PRED_CMD);
+ 	bool spec_ctrl = !msr_write_intercepted_l01(vcpu, MSR_IA32_SPEC_CTRL);
  
 +	/* Nothing to do if the MSR bitmap is not in use.  */
 +	if (!cpu_has_vmx_msr_bitmap() ||
 +	    !nested_cpu_has(vmcs12, CPU_BASED_USE_MSR_BITMAPS))
 +		return false;
 +
  	if (!nested_cpu_has_virt_x2apic_mode(vmcs12) &&
  	    !pred_cmd && !spec_ctrl)
  		return false;

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2018-02-06  0:54 Stephen Rothwell
  2018-02-06  9:14 ` Peter Zijlstra
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2018-02-06  0:54 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Andrew Morton, Mathieu Desnoyers

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  include/linux/sched/mm.h

between commit:

  d70f2a14b72a ("include/linux/sched/mm.h: uninline mmdrop_async(), etc")

from Linus' tree and commit:

  306e060435d7 ("membarrier: Document scheduler barrier requirements")

from the tip tree.

I fixed it up (I used the former version ofinclude/linux/sched/mm.h
and adde the following merge fix patch) 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.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 6 Feb 2018 11:51:34 +1100
Subject: [PATCH] membarrier: fix up for mmdrop move

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 kernel/fork.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/kernel/fork.c b/kernel/fork.c
index 5c372c954f3b..c7c112391d79 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -606,6 +606,11 @@ static void __mmdrop(struct mm_struct *mm)
 
 void mmdrop(struct mm_struct *mm)
 {
+	/*
+	 * The implicit full barrier implied by atomic_dec_and_test() is
+	 * required by the membarrier system call before returning to
+	 * user-space, after storing to rq->curr.
+	 */
 	if (unlikely(atomic_dec_and_test(&mm->mm_count)))
 		__mmdrop(mm);
 }
-- 
2.15.1

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply related	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2018-02-06  0:44 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2018-02-06  0:44 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, Mathieu Desnoyers

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/Kconfig

between commit:

  ea8c64ace866 ("dma-mapping: move swiotlb arch helpers to a new header")

from Linus' tree and commit:

  10bcc80e9dbc ("membarrier/x86: Provide core serializing command")

from the tip 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/Kconfig
index b0771ceabb4b,e095bdb9afdf..000000000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -54,7 -54,7 +54,8 @@@ config X8
  	select ARCH_HAS_FORTIFY_SOURCE
  	select ARCH_HAS_GCOV_PROFILE_ALL
  	select ARCH_HAS_KCOV			if X86_64
+ 	select ARCH_HAS_MEMBARRIER_SYNC_CORE
 +	select ARCH_HAS_PHYS_TO_DMA
  	select ARCH_HAS_PMEM_API		if X86_64
  	select ARCH_HAS_REFCOUNT
  	select ARCH_HAS_UACCESS_FLUSHCACHE	if X86_64

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2018-02-06  0:40 Stephen Rothwell
  2018-02-06 12:52 ` Mathieu Desnoyers
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2018-02-06  0:40 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Mathieu Desnoyers, Will Deacon

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/arm64/kernel/entry.S

between commit:

  4bf3286d29f3 ("arm64: entry: Hook up entry trampoline to exception vectors")

from Linus' tree and commit:

  f1e3a12b6543 ("membarrier/arm64: Provide core serializing command")

from the tip tree.

I fixed it up (probably not completely - 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/arm64/kernel/entry.S
index b34e717d7597,5edde1c2e93e..000000000000
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@@ -324,21 -302,11 +324,25 @@@ alternative_else_nop_endi
  	ldp	x28, x29, [sp, #16 * 14]
  	ldr	lr, [sp, #S_LR]
  	add	sp, sp, #S_FRAME_SIZE		// restore sp
 +
 +	.if	\el == 0
 +alternative_insn eret, nop, ARM64_UNMAP_KERNEL_AT_EL0
 +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
 +	bne	4f
 +	msr	far_el1, x30
 +	tramp_alias	x30, tramp_exit_native
 +	br	x30
 +4:
 +	tramp_alias	x30, tramp_exit_compat
 +	br	x30
 +#endif
 +	.else
+ 	/*
+ 	 * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
+ 	 * when returning from IPI handler, and when returning to user-space.
+ 	 */
 -	eret					// return to kernel
 +	eret
 +	.endif
  	.endm
  
  	.macro	irq_stack_entry

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2017-11-10  1:27 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2017-11-10  1:27 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Tom Lendacky

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/mm/mem_encrypt.c

between commit:

  87df26175e67 ("x86/mm: Unbreak modules that rely on external PAGE_KERNEL availability")

from Linus' tree and commit:

  606b21d4a649 ("x86/io: Unroll string I/O when SEV is active")

from the tip 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/mem_encrypt.c
index 0286327e65fa,d247c14469de..000000000000
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@@ -40,7 -42,11 +42,11 @@@ static char sme_cmdline_off[] __initdat
   * section is later cleared.
   */
  u64 sme_me_mask __section(.data) = 0;
 -EXPORT_SYMBOL_GPL(sme_me_mask);
 +EXPORT_SYMBOL(sme_me_mask);
+ DEFINE_STATIC_KEY_FALSE(sev_enable_key);
+ EXPORT_SYMBOL_GPL(sev_enable_key);
+ 
+ static bool sev_enabled __section(.data);
  
  /* Buffer used for early in-place encryption by BSP, no locking needed */
  static char sme_early_buffer[PAGE_SIZE] __aligned(PAGE_SIZE);

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2017-05-22  3:27 Stephen Rothwell
  2017-05-22  8:32 ` Mark Rutland
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2017-05-22  3:27 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mark Rutland,
	Catalin Marinas

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/arm64/include/asm/cpufeature.h

between commit:

  63a1e1c95e60 ("arm64/cpufeature: don't use mutex in bringup path")

from Linus' tree and commit:

  d54bb72551b9 ("arm64/cpufeature: Use static_branch_enable_cpuslocked()")

from the tip tree.

I have no idea what the correct resolution is here, so I have just gone
with the former for now (i.e. removed the
static_branch_enable_cpuslocked() call).  This will probably need a
better (or even correct :-)) fix.

I fixed it up (see above) 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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2016-02-03  0:09 Stephen Rothwell
  2016-02-03  0:32 ` Toshi Kani
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2016-02-03  0:09 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Dan Williams, Toshi Kani, Borislav Petkov

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  kernel/memremap.c

between commit:

  eb7d78c9e7f6 ("devm_memremap_pages: fix vmem_altmap lifetime + alignment handling")

from Linus' tree and commit:

  1c29f25bf5d6 ("memremap: Change region_intersects() to take @flags and @desc")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/memremap.c
index 70ee3775de24,293309cac061..000000000000
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@@ -269,8 -267,8 +270,8 @@@ void *devm_memremap_pages(struct devic
  		struct percpu_ref *ref, struct vmem_altmap *altmap)
  {
  	int is_ram = region_intersects(res->start, resource_size(res),
- 			"System RAM");
+ 				       IORESOURCE_SYSTEM_RAM, IORES_DESC_NONE);
 -	resource_size_t key, align_start, align_size;
 +	resource_size_t key, align_start, align_size, align_end;
  	struct dev_pagemap *pgmap;
  	struct page_map *page_map;
  	unsigned long pfn;

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2015-09-18  1:12 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2015-09-18  1:12 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Wang Nan, Arnaldo Carvalho de Melo, Kan Liang

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  tools/perf/ui/browsers/hists.c

between commit:

  bd315aab8a3a ("perf top: Fix segfault pressing -> with no hist entries")

from Linus' tree and commit:

  84734b06b630 ("perf hists browser: Zoom in/out for processor socket")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc tools/perf/ui/browsers/hists.c
index c04c60d4863c,380e9080991e..000000000000
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@@ -1968,9 -2017,10 +2017,11 @@@ skip_annotation
  					  &options[nr_options], dso);
  		nr_options += add_map_opt(browser, &actions[nr_options],
  					  &options[nr_options],
 -					  browser->selection->map);
 +					  browser->selection ?
 +						browser->selection->map : NULL);
- 
+ 		nr_options += add_socket_opt(browser, &actions[nr_options],
+ 					     &options[nr_options],
+ 					     socked_id);
  		/* perf script support */
  		if (browser->he_selection) {
  			nr_options += add_script_opt(browser,

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2015-08-17  5:57 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2015-08-17  5:57 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linus Torvalds
  Cc: linux-next, linux-kernel, Denys Vlasenko

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/entry/entry_64_compat.S

between commit:

  cd88ec231701 ("x86: fix error handling for 32-bit compat out-of-range system call numbers")

from Linus' tree and commit:

  c73e36b775a7 ("x86/asm/entry/32: Replace RESTORE_RSI_RDI with open-coded 32-bit reads")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/entry/entry_64_compat.S
index a7e257d9cb90,8997383ba170..000000000000
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@@ -140,8 -140,8 +140,9 @@@ sysexit_from_sys_call
  	 */
  	andl	$~TS_COMPAT, ASM_THREAD_INFO(TI_status, %rsp, SIZEOF_PTREGS)
  	movl	RIP(%rsp), %ecx		/* User %eip */
 +	movq    RAX(%rsp), %rax
- 	RESTORE_RSI_RDI
+ 	movl	RSI(%rsp), %esi
+ 	movl	RDI(%rsp), %edi
  	xorl	%edx, %edx		/* Do not leak kernel information */
  	xorq	%r8, %r8
  	xorq	%r9, %r9
@@@ -365,10 -366,11 +366,12 @@@ cstar_dispatch
  
  sysretl_from_sys_call:
  	andl	$~TS_COMPAT, ASM_THREAD_INFO(TI_status, %rsp, SIZEOF_PTREGS)
- 	RESTORE_RSI_RDI_RDX
+ 	movl	RDX(%rsp), %edx
+ 	movl	RSI(%rsp), %esi
+ 	movl	RDI(%rsp), %edi
  	movl	RIP(%rsp), %ecx
  	movl	EFLAGS(%rsp), %r11d
 +	movq    RAX(%rsp), %rax
  	xorq	%r10, %r10
  	xorq	%r9, %r9
  	xorq	%r8, %r8

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2015-07-06  0:08 Stephen Rothwell
  2015-07-06  7:49 ` Paolo Bonzini
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2015-07-06  0:08 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Paolo Bonzini

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  kernel/sched/core.c

between commit:

  2ecd9d29abb1 ("sched, preempt_notifier: separate notifier registration from static_key inc/dec")

from Linus' tree and commit:

  6efde1d3716b ("sched/preempt, kvm: Fix KVM preempt_notifier usage")

from the tip tree.

I fixed it up (maybe - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/sched/core.c
index 78b4bad10081,850e54b89a11..000000000000
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@@ -2338,10 -2326,13 +2338,15 @@@ EXPORT_SYMBOL_GPL(preempt_notifier_dec)
   */
  void preempt_notifier_register(struct preempt_notifier *notifier)
  {
 -	static_key_slow_inc(&preempt_notifier_key);
 +	if (!static_key_false(&preempt_notifier_key))
 +		WARN(1, "registering preempt_notifier while notifiers disabled\n");
 +
+ 	/*
+ 	 * Avoid preemption while changing the preempt notifier list.
+ 	 */
+ 	preempt_disable();
  	hlist_add_head(&notifier->link, &current->preempt_notifiers);
+ 	preempt_enable();
  }
  EXPORT_SYMBOL_GPL(preempt_notifier_register);
  
@@@ -2353,7 -2344,14 +2358,12 @@@
   */
  void preempt_notifier_unregister(struct preempt_notifier *notifier)
  {
+ 	/*
+ 	 * Avoid preemption while changing the preempt notifier list.
+ 	 */
+ 	preempt_disable();
  	hlist_del(&notifier->link);
+ 	preempt_enable();
 -
 -	static_key_slow_dec(&preempt_notifier_key);
  }
  EXPORT_SYMBOL_GPL(preempt_notifier_unregister);
  

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

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2014-05-21  4:12 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2014-05-21  4:12 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Linus, Andy Lutomirski

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/vdso/vdso32-setup.c between commit fa81511bb0bb ("x86-64,
modify_ldt: Make support for 16-bit segments a runtime option") from
Linus' tree and commit 18d0a6fd2271 ("x86, vdso: Move the 32-bit vdso
special pages after the text") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/vdso/vdso32-setup.c
index e1f220e3ca68,c3ed708e50f4..000000000000
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@@ -36,12 -21,6 +21,10 @@@
  #define VDSO_DEFAULT	1
  #endif
  
 +#ifdef CONFIG_X86_64
- #define vdso_enabled			sysctl_vsyscall32
- #define arch_setup_additional_pages	syscall32_setup_pages
 +extern int sysctl_ldt16;
 +#endif
 +
  /*
   * Should the kernel map a VDSO page into processes and pass its
   * address down to glibc upon exec()?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2014-03-21  4:23 Stephen Rothwell
  2014-03-21  8:47 ` Srivatsa S. Bhat
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2014-03-21  4:23 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Srivatsa S. Bhat, Rafael J. Wysocki,
	Stephane Eranian

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/kernel/cpu/perf_event_intel_uncore.c between commit 2c666adacc9e
("x86, intel, uncore: Fix CPU hotplug callback registration") from Linus'
tree and commit 411cf180fa00 ("perf/x86/uncore: fix initialization of
cpumask") from the tip tree.

I fixed it up (maybe incorrectly - see below) and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 28922f62eb29,bd2253d40cff..000000000000
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@@ -3868,6 -4234,41 +4234,41 @@@ static int __init uncore_pmus_register(
  	return 0;
  }
  
+ static void __init uncore_cpumask_init(void)
+ {
+ 	int cpu;
+ 
+ 	/*
+ 	 * ony invoke once from msr or pci init code
+ 	 */
+ 	if (!cpumask_empty(&uncore_cpu_mask))
+ 		return;
+ 
 -	get_online_cpus();
++	cpu_notifier_register_begin();
+ 
+ 	for_each_online_cpu(cpu) {
+ 		int i, phys_id = topology_physical_package_id(cpu);
+ 
+ 		for_each_cpu(i, &uncore_cpu_mask) {
+ 			if (phys_id == topology_physical_package_id(i)) {
+ 				phys_id = -1;
+ 				break;
+ 			}
+ 		}
+ 		if (phys_id < 0)
+ 			continue;
+ 
+ 		uncore_cpu_prepare(cpu, phys_id);
+ 		uncore_event_init_cpu(cpu);
+ 	}
+ 	on_each_cpu(uncore_cpu_setup, NULL, 1);
+ 
 -	register_cpu_notifier(&uncore_cpu_nb);
++	__register_cpu_notifier(&uncore_cpu_nb);
+ 
 -	put_online_cpus();
++	cpu_notifier_register_done();
+ }
+ 
+ 
  static int __init intel_uncore_init(void)
  {
  	int ret;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2014-02-18  3:09 Stephen Rothwell
  2014-02-18  8:06 ` Hans-Christian Egtvedt
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2014-02-18  3:09 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Chen Gang, Hans-Christian Egtvedt, Tim Chen

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/avr32/include/asm/Kbuild between commit d7668f9d448a ("avr32: add
generic vga.h to Kbuild") from the  tree and commit b119fa61d440
("locking/mcs: Order the header files in Kbuild of each architecture in
alphabetical order") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/avr32/include/asm/Kbuild
index c7c64a63c29f,8b398ff96974..000000000000
--- a/arch/avr32/include/asm/Kbuild
+++ b/arch/avr32/include/asm/Kbuild
@@@ -1,22 -1,22 +1,23 @@@
  
- generic-y	+= clkdev.h
- generic-y       += cputime.h
- generic-y       += delay.h
- generic-y       += device.h
- generic-y       += div64.h
- generic-y       += emergency-restart.h
- generic-y	+= exec.h
- generic-y       += futex.h
- generic-y	+= preempt.h
- generic-y       += irq_regs.h
- generic-y	+= param.h
- generic-y       += local.h
- generic-y       += local64.h
- generic-y       += percpu.h
- generic-y       += scatterlist.h
- generic-y       += sections.h
- generic-y       += topology.h
- generic-y	+= trace_clock.h
+ generic-y += clkdev.h
+ generic-y += cputime.h
+ generic-y += delay.h
+ generic-y += device.h
+ generic-y += div64.h
+ generic-y += emergency-restart.h
+ generic-y += exec.h
+ generic-y += futex.h
+ generic-y += hash.h
+ generic-y += irq_regs.h
+ generic-y += local.h
+ generic-y += local64.h
+ generic-y += mcs_spinlock.h
+ generic-y += param.h
+ generic-y += percpu.h
+ generic-y += preempt.h
+ generic-y += scatterlist.h
+ generic-y += sections.h
+ generic-y += topology.h
+ generic-y += trace_clock.h
 +generic-y += vga.h
- generic-y       += xor.h
- generic-y	+= hash.h
+ generic-y += xor.h

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2014-01-30  1:42 Stephen Rothwell
  2014-01-30  1:49 ` Andi Kleen
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2014-01-30  1:42 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Andi Kleen, Andrew Morton, Rik van Riel

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
kernel/sysctl.c between commit 54a43d54988a ("numa: add a sysctl for
numa_balancing") from Linus' tree and commit 52bf84aa206c ("sched/numa,
mm: Remove p->numa_migrate_deferred") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/sysctl.c
index 096db7452cbd,2a4a4fc89cd1..000000000000
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@@ -383,22 -386,6 +385,15 @@@ static struct ctl_table kern_table[] = 
  		.mode		= 0644,
  		.proc_handler	= proc_dointvec,
  	},
 +	{
- 		.procname       = "numa_balancing_migrate_deferred",
- 		.data           = &sysctl_numa_balancing_migrate_deferred,
- 		.maxlen         = sizeof(unsigned int),
- 		.mode           = 0644,
- 		.proc_handler   = proc_dointvec,
- 	},
- 	{
 +		.procname	= "numa_balancing",
 +		.data		= NULL, /* filled in by handler */
 +		.maxlen		= sizeof(unsigned int),
 +		.mode		= 0644,
 +		.proc_handler	= sysctl_numa_balancing,
 +		.extra1		= &zero,
 +		.extra2		= &one,
 +	},
  #endif /* CONFIG_NUMA_BALANCING */
  #endif /* CONFIG_SCHED_DEBUG */
  	{

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2014-01-28  0:43 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2014-01-28  0:43 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Kees Cook, Aaron Tomlin

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
Documentation/sysctl/kernel.txt between commit 7984754b99b6 ("kexec: add
sysctl to disable kexec_load") from Linus' tree and commit 270750dbc18a
("hung_task: Display every hung task warning") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc Documentation/sysctl/kernel.txt
index ee9a2f983b99,4205f3c05cbe..000000000000
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@@ -33,7 -33,10 +33,11 @@@ show up in /proc/sys/kernel
  - domainname
  - hostname
  - hotplug
+ - hung_task_panic
+ - hung_task_check_count
+ - hung_task_timeout_secs
+ - hung_task_warnings
 +- kexec_load_disabled
  - kptr_restrict
  - kstack_depth_to_print       [ X86 only ]
  - l2cr                        [ PPC only ]
@@@ -288,18 -291,44 +292,56 @@@ Default value is "/sbin/hotplug"
  
  ==============================================================
  
+ hung_task_panic:
+ 
+ Controls the kernel's behavior when a hung task is detected.
+ This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
+ 
+ 0: continue operation. This is the default behavior.
+ 
+ 1: panic immediately.
+ 
+ ==============================================================
+ 
+ hung_task_check_count:
+ 
+ The upper bound on the number of tasks that are checked.
+ This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
+ 
+ ==============================================================
+ 
+ hung_task_timeout_secs:
+ 
+ Check interval. When a task in D state did not get scheduled
+ for more than this value report a warning.
+ This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
+ 
+ 0: means infinite timeout - no checking done.
+ 
+ ==============================================================
+ 
+ hung_task_warning:
+ 
+ The maximum number of warnings to report. During a check interval
+ When this value is reached, no more the warnings will be reported.
+ This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
+ 
+ -1: report an infinite number of warnings.
+ 
+ ==============================================================
+ 
 +kexec_load_disabled:
 +
 +A toggle indicating if the kexec_load syscall has been disabled. This
 +value defaults to 0 (false: kexec_load enabled), but can be set to 1
 +(true: kexec_load disabled). Once true, kexec can no longer be used, and
 +the toggle cannot be set back to false. This allows a kexec image to be
 +loaded before disabling the syscall, allowing a system to set up (and
 +later use) an image without it being altered. Generally used together
 +with the "modules_disabled" sysctl.
 +
 +==============================================================
 +
  kptr_restrict:
  
  This toggle indicates whether restrictions are placed on

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2014-01-17  3:30 Stephen Rothwell
  2014-01-17 17:27 ` Sören Brinkmann
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2014-01-17  3:30 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Soren Brinkmann, Daniel Lezcano, Stephen Boyd

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
drivers/clocksource/cadence_ttc_timer.c between commit c1dcc927dae0
("clocksource: cadence_ttc: Fix mutex taken inside interrupt context")
from Linus' tree and commit dfded00902d7 ("clocksource:
cadence_ttc_timer: Switch to sched_clock_register()") from the tip tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/clocksource/cadence_ttc_timer.c
index a92350b55d32,8c7382bf260c..000000000000
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@@ -308,7 -306,8 +308,8 @@@ static void __init ttc_setup_clocksourc
  	}
  
  	ttc_sched_clock_val_reg = base + TTC_COUNT_VAL_OFFSET;
- 	setup_sched_clock(ttc_sched_clock_read, 16, ttccs->ttc.freq / PRESCALE);
+ 	sched_clock_register(ttc_sched_clock_read, 16,
 -			clk_get_rate(ttccs->ttc.clk) / PRESCALE);
++			     ttccs->ttc.freq / PRESCALE);
  }
  
  static int ttc_rate_change_clockevent_cb(struct notifier_block *nb,

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2013-12-16  3:18 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2013-12-16  3:18 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Matthew Garrett, Borislav Petkov, Matt Fleming

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/platform/efi/efi.c between commit 04bf9ba720fc ("x86, efi: Don't
use (U)EFI time services on 32 bit") from Linus' tree and commit
f4fccac05f7f ("x86/efi: Simplify EFI_DEBUG") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell <sfr@canb.auug.org.au>

diff --cc arch/x86/platform/efi/efi.c
index cceb813044ef,f8ec4dafc74e..000000000000
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@@ -690,9 -692,13 +692,7 @@@ void __init efi_init(void
  
  	set_bit(EFI_MEMMAP, &x86_efi_facility);
  
- #if EFI_DEBUG
 -#ifdef CONFIG_X86_32
 -	if (efi_is_native()) {
 -		x86_platform.get_wallclock = efi_get_time;
 -		x86_platform.set_wallclock = efi_set_rtc_mmss;
 -	}
 -#endif
  	print_efi_memmap();
- #endif
  }
  
  void __init efi_late_init(void)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2013-09-04  4:24 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2013-09-04  4:24 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Linus Torvalds, Jeremy Fitzhardinge

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/include/asm/spinlock.h between commit bc08b449ee14 ("lockref:
implement lockless reference count updates using cmpxchg()") from Linus'
tree and commit 545ac13892ab ("x86, spinlock: Replace pv spinlocks with
pv ticketlocks") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/include/asm/spinlock.h
index e0e6684,8963bfe..0000000
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@@ -34,11 -37,31 +37,36 @@@
  # define UNLOCK_LOCK_PREFIX
  #endif
  
 +static __always_inline int arch_spin_value_unlocked(arch_spinlock_t lock)
 +{
 +	return lock.tickets.head == lock.tickets.tail;
 +}
 +
+ /* How long a lock should spin before we consider blocking */
+ #define SPIN_THRESHOLD	(1 << 15)
+ 
+ extern struct static_key paravirt_ticketlocks_enabled;
+ static __always_inline bool static_key_false(struct static_key *key);
+ 
+ #ifdef CONFIG_PARAVIRT_SPINLOCKS
+ 
+ static inline void __ticket_enter_slowpath(arch_spinlock_t *lock)
+ {
+ 	set_bit(0, (volatile unsigned long *)&lock->tickets.tail);
+ }
+ 
+ #else  /* !CONFIG_PARAVIRT_SPINLOCKS */
+ static __always_inline void __ticket_lock_spinning(arch_spinlock_t *lock,
+ 							__ticket_t ticket)
+ {
+ }
+ static inline void __ticket_unlock_kick(arch_spinlock_t *lock,
+ 							__ticket_t ticket)
+ {
+ }
+ 
+ #endif /* CONFIG_PARAVIRT_SPINLOCKS */
+ 
  /*
   * Ticket locks are conceptually two parts, one indicating the current head of
   * the queue, and the other indicating the current tail. The lock is acquired

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2013-07-09  4:36 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2013-07-09  4:36 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Axel Lin, Grant Likely

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
kernel/irq/generic-chip.c between commit 1aa0dd94ca07 ("irqdomain:
Eliminate revmap type") from Linus' tree and commit 002fca5df168
("genirq: generic chip: Use DIV_ROUND_UP to calculate numchips") from the
tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/irq/generic-chip.c
index 10e663a,2f274f3..0000000
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@@ -275,7 -275,10 +275,7 @@@ int irq_alloc_domain_generic_chips(stru
  	if (d->gc)
  		return -EBUSY;
  
- 	numchips = d->revmap_size / irqs_per_chip;
 -	if (d->revmap_type != IRQ_DOMAIN_MAP_LINEAR)
 -		return -EINVAL;
 -
 -	numchips = DIV_ROUND_UP(d->revmap_data.linear.size, irqs_per_chip);
++	numchips = DIV_ROUND_UP(d->revmap_size, irqs_per_chip);
  	if (!numchips)
  		return -EINVAL;
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2012-12-03  4:19 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2012-12-03  4:19 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, David Howells, Jiri Olsa

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
tools/perf/Makefile between commit d2709c7ce4c5 ("perf: Make perf build
for x86 with UAPI disintegration applied") from Linus' tree and commit
945aea220bb8 ("perf tests: Move test objects into 'tests' directory")
from the tip tree.

I just used the version from Linus' tree (since it seems to be a superset
of the latter - see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc tools/perf/Makefile
index 0a619af,cca5bb8..0000000
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@@ -169,36 -169,16 +169,43 @@@ endi
  
  ### --- END CONFIGURATION SECTION ---
  
 -BASIC_CFLAGS = -Iutil/include -Iarch/$(ARCH)/include -I$(OUTPUT)util -Iutil -I. -I$(TRACE_EVENT_DIR) -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
 +ifeq ($(srctree),)
 +srctree := $(patsubst %/,%,$(dir $(shell pwd)))
 +srctree := $(patsubst %/,%,$(dir $(srctree)))
 +#$(info Determined 'srctree' to be $(srctree))
 +endif
 +
 +ifneq ($(objtree),)
 +#$(info Determined 'objtree' to be $(objtree))
 +endif
 +
 +ifneq ($(OUTPUT),)
 +#$(info Determined 'OUTPUT' to be $(OUTPUT))
 +endif
 +
 +BASIC_CFLAGS = \
 +	-Iutil/include \
 +	-Iarch/$(ARCH)/include \
 +	$(if $(objtree),-I$(objtree)/arch/$(ARCH)/include/generated/uapi) \
 +	-I$(srctree)/arch/$(ARCH)/include/uapi \
 +	-I$(srctree)/arch/$(ARCH)/include \
 +	$(if $(objtree),-I$(objtree)/include/generated/uapi) \
 +	-I$(srctree)/include/uapi \
 +	-I$(srctree)/include \
 +	-I$(OUTPUT)util \
 +	-Iutil \
 +	-I. \
 +	-I$(TRACE_EVENT_DIR) \
 +	-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
  BASIC_LDFLAGS =
  
+ ifeq ($(call try-cc,$(SOURCE_BIONIC),$(CFLAGS),bionic),y)
+ 	BIONIC := 1
+ 	EXTLIBS := $(filter-out -lrt,$(EXTLIBS))
+ 	EXTLIBS := $(filter-out -lpthread,$(EXTLIBS))
+ 	BASIC_CFLAGS += -I.
+ endif
+ 
  # Guard against environment variables
  BUILTIN_OBJS =
  LIB_H =

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2012-10-16  1:00 Stephen Rothwell
  2012-10-21 16:29 ` Ingo Molnar
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2012-10-16  1:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Ralf Baechle

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
mm/huge_memory.c between commit 325adeb55e32 ("mm: huge_memory: Fix build
error") from Linus' tree and commit 39d6cb39a817 ("mm/mpol: Use special
PROT_NONE to migrate pages") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

diff --cc mm/huge_memory.c
index 40f17c3,d14c8b2..0000000
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -17,7 -17,7 +17,8 @@@
  #include <linux/khugepaged.h>
  #include <linux/freezer.h>
  #include <linux/mman.h>
 +#include <linux/pagemap.h>
+ #include <linux/migrate.h>
  #include <asm/tlb.h>
  #include <asm/pgalloc.h>
  #include "internal.h"
@@@ -1347,59 -1428,55 +1418,54 @@@ static int __split_huge_page_map(struc
  	spin_lock(&mm->page_table_lock);
  	pmd = page_check_address_pmd(page, mm, address,
  				     PAGE_CHECK_ADDRESS_PMD_SPLITTING_FLAG);
- 	if (pmd) {
- 		pgtable = pgtable_trans_huge_withdraw(mm);
- 		pmd_populate(mm, &_pmd, pgtable);
- 
- 		haddr = address;
- 		for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
- 			pte_t *pte, entry;
- 			BUG_ON(PageCompound(page+i));
- 			entry = mk_pte(page + i, vma->vm_page_prot);
- 			entry = maybe_mkwrite(pte_mkdirty(entry), vma);
- 			if (!pmd_write(*pmd))
- 				entry = pte_wrprotect(entry);
- 			else
- 				BUG_ON(page_mapcount(page) != 1);
- 			if (!pmd_young(*pmd))
- 				entry = pte_mkold(entry);
- 			pte = pte_offset_map(&_pmd, haddr);
- 			BUG_ON(!pte_none(*pte));
- 			set_pte_at(mm, haddr, pte, entry);
- 			pte_unmap(pte);
- 		}
+ 	if (!pmd)
+ 		goto unlock;
  
- 		smp_wmb(); /* make pte visible before pmd */
- 		/*
- 		 * Up to this point the pmd is present and huge and
- 		 * userland has the whole access to the hugepage
- 		 * during the split (which happens in place). If we
- 		 * overwrite the pmd with the not-huge version
- 		 * pointing to the pte here (which of course we could
- 		 * if all CPUs were bug free), userland could trigger
- 		 * a small page size TLB miss on the small sized TLB
- 		 * while the hugepage TLB entry is still established
- 		 * in the huge TLB. Some CPU doesn't like that. See
- 		 * http://support.amd.com/us/Processor_TechDocs/41322.pdf,
- 		 * Erratum 383 on page 93. Intel should be safe but is
- 		 * also warns that it's only safe if the permission
- 		 * and cache attributes of the two entries loaded in
- 		 * the two TLB is identical (which should be the case
- 		 * here). But it is generally safer to never allow
- 		 * small and huge TLB entries for the same virtual
- 		 * address to be loaded simultaneously. So instead of
- 		 * doing "pmd_populate(); flush_tlb_range();" we first
- 		 * mark the current pmd notpresent (atomically because
- 		 * here the pmd_trans_huge and pmd_trans_splitting
- 		 * must remain set at all times on the pmd until the
- 		 * split is complete for this pmd), then we flush the
- 		 * SMP TLB and finally we write the non-huge version
- 		 * of the pmd entry with pmd_populate.
- 		 */
- 		pmdp_invalidate(vma, address, pmd);
- 		pmd_populate(mm, pmd, pgtable);
- 		ret = 1;
+ 	prot = pmd_pgprot(*pmd);
 -	pgtable = get_pmd_huge_pte(mm);
++	pgtable = pgtable_trans_huge_withdraw(mm);
+ 	pmd_populate(mm, &_pmd, pgtable);
+ 
+ 	for (i = 0, haddr = address; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
+ 		pte_t *pte, entry;
+ 
+ 		BUG_ON(PageCompound(page+i));
+ 		entry = mk_pte(page + i, prot);
+ 		entry = pte_mkdirty(entry);
+ 		if (!pmd_young(*pmd))
+ 			entry = pte_mkold(entry);
+ 		pte = pte_offset_map(&_pmd, haddr);
+ 		BUG_ON(!pte_none(*pte));
+ 		set_pte_at(mm, haddr, pte, entry);
+ 		pte_unmap(pte);
  	}
+ 
+ 	smp_wmb(); /* make ptes visible before pmd, see __pte_alloc */
+ 	/*
+ 	 * Up to this point the pmd is present and huge.
+ 	 *
+ 	 * If we overwrite the pmd with the not-huge version, we could trigger
+ 	 * a small page size TLB miss on the small sized TLB while the hugepage
+ 	 * TLB entry is still established in the huge TLB.
+ 	 *
+ 	 * Some CPUs don't like that. See
+ 	 * http://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum 383
+ 	 * on page 93.
+ 	 *
+ 	 * Thus it is generally safer to never allow small and huge TLB entries
+ 	 * for overlapping virtual addresses to be loaded. So we first mark the
+ 	 * current pmd not present, then we flush the TLB and finally we write
+ 	 * the non-huge version of the pmd entry with pmd_populate.
+ 	 *
+ 	 * The above needs to be done under the ptl because pmd_trans_huge and
+ 	 * pmd_trans_splitting must remain set on the pmd until the split is
+ 	 * complete. The ptl also protects against concurrent faults due to
+ 	 * making the pmd not-present.
+ 	 */
 -	set_pmd_at(mm, address, pmd, pmd_mknotpresent(*pmd));
 -	flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
++	pmdp_invalidate(vma, address, pmd);
+ 	pmd_populate(mm, pmd, pgtable);
+ 	ret = 1;
+ 
+ unlock:
  	spin_unlock(&mm->page_table_lock);
  
  	return ret;
@@@ -2280,23 -2300,30 +2346,21 @@@ static int khugepaged_has_work(void
  static int khugepaged_wait_event(void)
  {
  	return !list_empty(&khugepaged_scan.mm_head) ||
 -		!khugepaged_enabled();
 +		kthread_should_stop();
  }
  
 -static void khugepaged_do_scan(struct page **hpage)
 +static void khugepaged_do_scan(void)
  {
 +	struct page *hpage = NULL;
  	unsigned int progress = 0, pass_through_head = 0;
- 	unsigned int pages = khugepaged_pages_to_scan;
+ 	unsigned int pages = ACCESS_ONCE(khugepaged_pages_to_scan);
 +	bool wait = true;
  
- 	barrier(); /* write khugepaged_pages_to_scan to local stack */
- 
  	while (progress < pages) {
 -		cond_resched();
 -
 -#ifndef CONFIG_NUMA
 -		if (!*hpage) {
 -			*hpage = alloc_hugepage(khugepaged_defrag());
 -			if (unlikely(!*hpage)) {
 -				count_vm_event(THP_COLLAPSE_ALLOC_FAILED);
 -				break;
 -			}
 -			count_vm_event(THP_COLLAPSE_ALLOC);
 -		}
 -#else
 -		if (IS_ERR(*hpage))
 +		if (!khugepaged_prealloc_page(&hpage, &wait))
  			break;
 -#endif
 +
 +		cond_resched();
  
  		if (unlikely(kthread_should_stop() || freezing(current)))
  			break;

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2012-10-15  0:32 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2012-10-15  0:32 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, David Howells, Lee Schermerhorn

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
include/linux/mempolicy.h between commit 607ca46e97a1 ("UAPI: (Scripted)
Disintegrate include/linux") from Linus' tree and commits 6f98f92971e9
("mm/mpol: Make MPOL_LOCAL a real policy"), 84e3a981648d ("mm/mpol: Add
MPOL_MF_LAZY ..."), 0719b9688bfe ("mm/mpol: Add MPOL_MF_NOOP"),
4d58c795f691 ("mm/mpol: Check for misplaced page") and fa74ef9e42df
("sched/numa: Implement per task memory placement for 'big' processes")
from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

I also added this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 15 Oct 2012 11:14:21 +1100
Subject: [PATCH] mm/pol: fixups for UAPI include files split

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/uapi/linux/mempolicy.h |   18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/mempolicy.h b/include/uapi/linux/mempolicy.h
index 23e62e0..0c774c6 100644
--- a/include/uapi/linux/mempolicy.h
+++ b/include/uapi/linux/mempolicy.h
@@ -20,6 +20,8 @@ enum {
 	MPOL_PREFERRED,
 	MPOL_BIND,
 	MPOL_INTERLEAVE,
+	MPOL_LOCAL,
+	MPOL_NOOP,		/* retain existing policy for range */
 	MPOL_MAX,	/* always last member of enum */
 };
 
@@ -47,9 +49,16 @@ enum mpol_rebind_step {
 
 /* Flags for mbind */
 #define MPOL_MF_STRICT	(1<<0)	/* Verify existing pages in the mapping */
-#define MPOL_MF_MOVE	(1<<1)	/* Move pages owned by this process to conform to mapping */
-#define MPOL_MF_MOVE_ALL (1<<2)	/* Move every page to conform to mapping */
-#define MPOL_MF_INTERNAL (1<<3)	/* Internal flags start here */
+#define MPOL_MF_MOVE	 (1<<1)	/* Move pages owned by this process to conform
+				   to policy */
+#define MPOL_MF_MOVE_ALL (1<<2)	/* Move every page to conform to policy */
+#define MPOL_MF_LAZY	 (1<<3)	/* Modifies '_MOVE:  lazy migrate on fault */
+#define MPOL_MF_INTERNAL (1<<4)	/* Internal flags start here */
+
+#define MPOL_MF_VALID	(MPOL_MF_STRICT   | 	\
+			 MPOL_MF_MOVE     | 	\
+			 MPOL_MF_MOVE_ALL |	\
+			 MPOL_MF_LAZY)
 
 /*
  * Internal flags that share the struct mempolicy flags word with
@@ -59,6 +68,7 @@ enum mpol_rebind_step {
 #define MPOL_F_SHARED  (1 << 0)	/* identify shared policies */
 #define MPOL_F_LOCAL   (1 << 1)	/* preferred local allocation */
 #define MPOL_F_REBINDING (1 << 2)	/* identify policies in rebinding */
-
+#define MPOL_F_MOF	(1 << 3) /* this policy wants migrate on fault */
+#define MPOL_F_HOME	(1 << 4) /* this is the home-node policy */
 
 #endif /* _UAPI_LINUX_MEMPOLICY_H */
-- 
1.7.10.280.gaa39

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/mempolicy.h
index e5ccb9d,67c9734..0000000
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@@ -2,10 -7,72 +2,9 @@@
   * NUMA memory policies for Linux.
   * Copyright 2003,2004 Andi Kleen SuSE Labs
   */
 -
 -/*
 - * Both the MPOL_* mempolicy mode and the MPOL_F_* optional mode flags are
 - * passed by the user to either set_mempolicy() or mbind() in an 'int' actual.
 - * The MPOL_MODE_FLAGS macro determines the legal set of optional mode flags.
 - */
 -
 -/* Policies */
 -enum {
 -	MPOL_DEFAULT,
 -	MPOL_PREFERRED,
 -	MPOL_BIND,
 -	MPOL_INTERLEAVE,
 -	MPOL_LOCAL,
 -	MPOL_NOOP,		/* retain existing policy for range */
 -	MPOL_MAX,	/* always last member of enum */
 -};
 -
 -enum mpol_rebind_step {
 -	MPOL_REBIND_ONCE,	/* do rebind work at once(not by two step) */
 -	MPOL_REBIND_STEP1,	/* first step(set all the newly nodes) */
 -	MPOL_REBIND_STEP2,	/* second step(clean all the disallowed nodes)*/
 -	MPOL_REBIND_NSTEP,
 -};
 -
 -/* Flags for set_mempolicy */
 -#define MPOL_F_STATIC_NODES	(1 << 15)
 -#define MPOL_F_RELATIVE_NODES	(1 << 14)
 -
 -/*
 - * MPOL_MODE_FLAGS is the union of all possible optional mode flags passed to
 - * either set_mempolicy() or mbind().
 - */
 -#define MPOL_MODE_FLAGS	(MPOL_F_STATIC_NODES | MPOL_F_RELATIVE_NODES)
 -
 -/* Flags for get_mempolicy */
 -#define MPOL_F_NODE	(1<<0)	/* return next IL mode instead of node mask */
 -#define MPOL_F_ADDR	(1<<1)	/* look up vma using address */
 -#define MPOL_F_MEMS_ALLOWED (1<<2) /* return allowed memories */
 -
 -/* Flags for mbind */
 -#define MPOL_MF_STRICT	(1<<0)	/* Verify existing pages in the mapping */
 -#define MPOL_MF_MOVE	 (1<<1)	/* Move pages owned by this process to conform
 -				   to policy */
 -#define MPOL_MF_MOVE_ALL (1<<2)	/* Move every page to conform to policy */
 -#define MPOL_MF_LAZY	 (1<<3)	/* Modifies '_MOVE:  lazy migrate on fault */
 -#define MPOL_MF_INTERNAL (1<<4)	/* Internal flags start here */
 -
 -#define MPOL_MF_VALID	(MPOL_MF_STRICT   | 	\
 -			 MPOL_MF_MOVE     | 	\
 -			 MPOL_MF_MOVE_ALL |	\
 -			 MPOL_MF_LAZY)
 -
 -/*
 - * Internal flags that share the struct mempolicy flags word with
 - * "mode flags".  These flags are allocated from bit 0 up, as they
 - * are never OR'ed into the mode in mempolicy API arguments.
 - */
 -#define MPOL_F_SHARED  (1 << 0)	/* identify shared policies */
 -#define MPOL_F_LOCAL   (1 << 1)	/* preferred local allocation */
 -#define MPOL_F_REBINDING (1 << 2)	/* identify policies in rebinding */
 -#define MPOL_F_MOF	(1 << 3) /* this policy wants migrate on fault */
 -#define MPOL_F_HOME	(1 << 4) /* this is the home-node policy */
 -
 -#ifdef __KERNEL__
 +#ifndef _LINUX_MEMPOLICY_H
 +#define _LINUX_MEMPOLICY_H 1
  
- 
  #include <linux/mmzone.h>
  #include <linux/slab.h>
  #include <linux/rbtree.h>
@@@ -323,5 -393,13 +326,11 @@@ static inline int mpol_to_str(char *buf
  	return 0;
  }
  
+ static inline int mpol_misplaced(struct page *page, struct vm_area_struct *vma,
+ 				 unsigned long address)
+ {
+ 	return -1; /* no node preference */
+ }
+ 
  #endif /* CONFIG_NUMA */
 -#endif /* __KERNEL__ */
 -
  #endif

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2012-10-10  2:51 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2012-10-10  2:51 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, KOSAKI Motohiro, Andrew Morton,
	Mel Gorman, Lee Schermerhorn

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in mm/mempolicy.c
between commit 63f74ca21f1f ("mempolicy: fix refcount leak in
mpol_set_shared_policy()") from Linus' tree and commit 4d58c795f691
("mm/mpol: Check for misplaced page") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/mempolicy.c
index 0b78fb9,3360a8d..0000000
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@@ -2170,12 -2168,116 +2203,122 @@@ mpol_shared_policy_lookup(struct shared
  	return pol;
  }
  
 +static void sp_free(struct sp_node *n)
 +{
 +	mpol_put(n->policy);
 +	kmem_cache_free(sn_cache, n);
 +}
 +
+ /**
+  * mpol_misplaced - check whether current page node is valid in policy
+  *
+  * @page   - page to be checked
+  * @vma    - vm area where page mapped
+  * @addr   - virtual address where page mapped
+  * @multi  - use multi-stage node binding
+  *
+  * Lookup current policy node id for vma,addr and "compare to" page's
+  * node id.
+  *
+  * Returns:
+  *	-1	- not misplaced, page is in the right node
+  *	node	- node id where the page should be
+  *
+  * Policy determination "mimics" alloc_page_vma().
+  * Called from fault path where we know the vma and faulting address.
+  */
+ int mpol_misplaced(struct page *page, struct vm_area_struct *vma,
+ 		   unsigned long addr, int multi)
+ {
+ 	struct mempolicy *pol;
+ 	struct zone *zone;
+ 	int curnid = page_to_nid(page);
+ 	unsigned long pgoff;
+ 	int polnid = -1;
+ 	int ret = -1;
+ 
+ 	BUG_ON(!vma);
+ 
+ 	pol = get_vma_policy(current, vma, addr);
+ 	if (!(pol->flags & MPOL_F_MOF))
+ 		goto out;
+ 
+ 	switch (pol->mode) {
+ 	case MPOL_INTERLEAVE:
+ 		BUG_ON(addr >= vma->vm_end);
+ 		BUG_ON(addr < vma->vm_start);
+ 
+ 		pgoff = vma->vm_pgoff;
+ 		pgoff += (addr - vma->vm_start) >> PAGE_SHIFT;
+ 		polnid = offset_il_node(pol, vma, pgoff);
+ 		break;
+ 
+ 	case MPOL_PREFERRED:
+ 		if (pol->flags & MPOL_F_LOCAL)
+ 			polnid = numa_node_id();
+ 		else
+ 			polnid = pol->v.preferred_node;
+ 		break;
+ 
+ 	case MPOL_BIND:
+ 		/*
+ 		 * allows binding to multiple nodes.
+ 		 * use current page if in policy nodemask,
+ 		 * else select nearest allowed node, if any.
+ 		 * If no allowed nodes, use current [!misplaced].
+ 		 */
+ 		if (node_isset(curnid, pol->v.nodes))
+ 			goto out;
+ 		(void)first_zones_zonelist(
+ 				node_zonelist(numa_node_id(), GFP_HIGHUSER),
+ 				gfp_zone(GFP_HIGHUSER),
+ 				&pol->v.nodes, &zone);
+ 		polnid = zone->node;
+ 		break;
+ 
+ 	default:
+ 		BUG();
+ 	}
+ 
+ 	/*
+ 	 * Multi-stage node selection is used in conjunction with a periodic
+ 	 * migration fault to build a temporal task<->page relation. By
+ 	 * using a two-stage filter we remove short/unlikely relations.
+ 	 *
+ 	 * Using P(p) ~ n_p / n_t as per frequentist probability, we can
+ 	 * equate a task's usage of a particular page (n_p) per total usage
+ 	 * of this page (n_t) (in a given time-span) to a probability.
+ 	 *
+ 	 * Our periodic faults will then sample this probability and getting
+ 	 * the same result twice in a row, given these samples are fully
+ 	 * independent, is then given by P(n)^2, provided our sample period
+ 	 * is sufficiently short compared to the usage pattern.
+ 	 *
+ 	 * This quadric squishes small probabilities, making it less likely
+ 	 * we act on an unlikely task<->page relation.
+ 	 *
+ 	 * NOTE: effectively we're using task-home-node<->page-node relations
+ 	 * since those are the only thing we can affect.
+ 	 *
+ 	 * NOTE: we're using task-home-node as opposed to the current node
+ 	 * the task might be running on, since the task-home-node is the
+ 	 * long-term node of this task, further reducing noise. Also see
+ 	 * task_tick_numa().
+ 	 */
+ 	if (multi && (pol->flags & MPOL_F_HOME)) {
+ 		int last_nid = page_xchg_last_nid(page, polnid);
+ 		if (last_nid != polnid)
+ 			goto out;
+ 	}
+ 
+ 	if (curnid != polnid)
+ 		ret = polnid;
+ out:
+ 	mpol_cond_put(pol);
+ 
+ 	return ret;
+ }
+ 
  static void sp_delete(struct shared_policy *sp, struct sp_node *n)
  {
  	pr_debug("deleting %lx-l%lx\n", n->start, n->end);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2012-10-10  2:45 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2012-10-10  2:45 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Andrew Morton, Gerald Schaefer, Xiao Guangrong

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
mm/huge_memory.c between commits d516904bd239 ("thp: merge page pre-alloc
in khugepaged_loop into khugepaged_do_scan"), e3ebcf643811 ("thp: remove
assumptions on pgtable_t type") and 46dcde735c9d ("thp: introduce
pmdp_invalidate()") from Linus' tree and commit 93c9d633bd9e ("mm/thp:
Preserve pgprot across huge page split") from the tip tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/huge_memory.c
index a863af2,5b9ab25..0000000
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -1346,59 -1428,55 +1417,54 @@@ static int __split_huge_page_map(struc
  	spin_lock(&mm->page_table_lock);
  	pmd = page_check_address_pmd(page, mm, address,
  				     PAGE_CHECK_ADDRESS_PMD_SPLITTING_FLAG);
- 	if (pmd) {
- 		pgtable = pgtable_trans_huge_withdraw(mm);
- 		pmd_populate(mm, &_pmd, pgtable);
- 
- 		haddr = address;
- 		for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
- 			pte_t *pte, entry;
- 			BUG_ON(PageCompound(page+i));
- 			entry = mk_pte(page + i, vma->vm_page_prot);
- 			entry = maybe_mkwrite(pte_mkdirty(entry), vma);
- 			if (!pmd_write(*pmd))
- 				entry = pte_wrprotect(entry);
- 			else
- 				BUG_ON(page_mapcount(page) != 1);
- 			if (!pmd_young(*pmd))
- 				entry = pte_mkold(entry);
- 			pte = pte_offset_map(&_pmd, haddr);
- 			BUG_ON(!pte_none(*pte));
- 			set_pte_at(mm, haddr, pte, entry);
- 			pte_unmap(pte);
- 		}
+ 	if (!pmd)
+ 		goto unlock;
  
- 		smp_wmb(); /* make pte visible before pmd */
- 		/*
- 		 * Up to this point the pmd is present and huge and
- 		 * userland has the whole access to the hugepage
- 		 * during the split (which happens in place). If we
- 		 * overwrite the pmd with the not-huge version
- 		 * pointing to the pte here (which of course we could
- 		 * if all CPUs were bug free), userland could trigger
- 		 * a small page size TLB miss on the small sized TLB
- 		 * while the hugepage TLB entry is still established
- 		 * in the huge TLB. Some CPU doesn't like that. See
- 		 * http://support.amd.com/us/Processor_TechDocs/41322.pdf,
- 		 * Erratum 383 on page 93. Intel should be safe but is
- 		 * also warns that it's only safe if the permission
- 		 * and cache attributes of the two entries loaded in
- 		 * the two TLB is identical (which should be the case
- 		 * here). But it is generally safer to never allow
- 		 * small and huge TLB entries for the same virtual
- 		 * address to be loaded simultaneously. So instead of
- 		 * doing "pmd_populate(); flush_tlb_range();" we first
- 		 * mark the current pmd notpresent (atomically because
- 		 * here the pmd_trans_huge and pmd_trans_splitting
- 		 * must remain set at all times on the pmd until the
- 		 * split is complete for this pmd), then we flush the
- 		 * SMP TLB and finally we write the non-huge version
- 		 * of the pmd entry with pmd_populate.
- 		 */
- 		pmdp_invalidate(vma, address, pmd);
- 		pmd_populate(mm, pmd, pgtable);
- 		ret = 1;
+ 	prot = pmd_pgprot(*pmd);
 -	pgtable = get_pmd_huge_pte(mm);
++	pgtable = pgtable_trans_huge_withdraw(mm);
+ 	pmd_populate(mm, &_pmd, pgtable);
+ 
+ 	for (i = 0, haddr = address; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
+ 		pte_t *pte, entry;
+ 
+ 		BUG_ON(PageCompound(page+i));
+ 		entry = mk_pte(page + i, prot);
+ 		entry = pte_mkdirty(entry);
+ 		if (!pmd_young(*pmd))
+ 			entry = pte_mkold(entry);
+ 		pte = pte_offset_map(&_pmd, haddr);
+ 		BUG_ON(!pte_none(*pte));
+ 		set_pte_at(mm, haddr, pte, entry);
+ 		pte_unmap(pte);
  	}
+ 
+ 	smp_wmb(); /* make ptes visible before pmd, see __pte_alloc */
+ 	/*
+ 	 * Up to this point the pmd is present and huge.
+ 	 *
+ 	 * If we overwrite the pmd with the not-huge version, we could trigger
+ 	 * a small page size TLB miss on the small sized TLB while the hugepage
+ 	 * TLB entry is still established in the huge TLB.
+ 	 *
+ 	 * Some CPUs don't like that. See
+ 	 * http://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum 383
+ 	 * on page 93.
+ 	 *
+ 	 * Thus it is generally safer to never allow small and huge TLB entries
+ 	 * for overlapping virtual addresses to be loaded. So we first mark the
+ 	 * current pmd not present, then we flush the TLB and finally we write
+ 	 * the non-huge version of the pmd entry with pmd_populate.
+ 	 *
+ 	 * The above needs to be done under the ptl because pmd_trans_huge and
+ 	 * pmd_trans_splitting must remain set on the pmd until the split is
+ 	 * complete. The ptl also protects against concurrent faults due to
+ 	 * making the pmd not-present.
+ 	 */
 -	set_pmd_at(mm, address, pmd, pmd_mknotpresent(*pmd));
 -	flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
++	pmdp_invalidate(vma, address, pmd);
+ 	pmd_populate(mm, pmd, pgtable);
+ 	ret = 1;
+ 
+ unlock:
  	spin_unlock(&mm->page_table_lock);
  
  	return ret;
@@@ -2279,23 -2300,30 +2345,21 @@@ static int khugepaged_has_work(void
  static int khugepaged_wait_event(void)
  {
  	return !list_empty(&khugepaged_scan.mm_head) ||
 -		!khugepaged_enabled();
 +		kthread_should_stop();
  }
  
 -static void khugepaged_do_scan(struct page **hpage)
 +static void khugepaged_do_scan(void)
  {
 +	struct page *hpage = NULL;
  	unsigned int progress = 0, pass_through_head = 0;
- 	unsigned int pages = khugepaged_pages_to_scan;
+ 	unsigned int pages = ACCESS_ONCE(khugepaged_pages_to_scan);
 +	bool wait = true;
  
- 	barrier(); /* write khugepaged_pages_to_scan to local stack */
- 
  	while (progress < pages) {
 -		cond_resched();
 -
 -#ifndef CONFIG_NUMA
 -		if (!*hpage) {
 -			*hpage = alloc_hugepage(khugepaged_defrag());
 -			if (unlikely(!*hpage)) {
 -				count_vm_event(THP_COLLAPSE_ALLOC_FAILED);
 -				break;
 -			}
 -			count_vm_event(THP_COLLAPSE_ALLOC);
 -		}
 -#else
 -		if (IS_ERR(*hpage))
 +		if (!khugepaged_prealloc_page(&hpage, &wait))
  			break;
 -#endif
 +
 +		cond_resched();
  
  		if (unlikely(kthread_should_stop() || freezing(current)))
  			break;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2012-06-26  4:36 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2012-06-26  4:36 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Paul Mundt, Fengguang Wu, Randy Dunlap

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
include/asm-generic/bug.h between commit 09682c1dd382 ("bug.h: Fix up
CONFIG_BUG=n implicit function declarations") from Linus' tree and commit
7b37393f13d5 ("bug.h: Fix x86 !CONFIG_BUG build regression") from the tip
tree.

These are trying to do the same thing, so I used the version from Linus'
tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2012-06-22  5:01 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2012-06-22  5:01 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, David Rientjes, Linus Torvalds,
	Andrew Morton, Lee Schermerhorn

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in mm/mempolicy.c
between commit c4c0e9e544a0 ("mm, mempolicy: fix mbind() to do
synchronous migration") from Linus' tree and various commits from the tip
tree.

The latter rewrote bits of this file, so I used it and effectively
reapplied the former patch (see below).  I hope it came out right.

The diff of this file from the tip tree version looks like this (the
second hunk comes from the slab tree):

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 2218157..aeb58da 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1146,7 +1146,7 @@ long mpol_do_mbind(unsigned long start, unsigned long len,
 		else {
 			nr_failed = migrate_pages(&pagelist, new_vma_page,
 					(unsigned long)vma,
-					false, true);
+					false, MIGRATE_SYNC);
 		}
 	}
 
@@ -1702,8 +1702,14 @@ static struct zonelist *policy_zonelist(gfp_t gfp, struct mempolicy *policy,
  * task can change it's policy.  The system default policy requires no
  * such protection.
  */
-unsigned slab_node(struct mempolicy *policy)
+unsigned slab_node(void)
 {
+	struct mempolicy *policy;
+
+	if (in_interrupt())
+		return numa_node_id();
+
+	policy = current->mempolicy;
 	if (!policy || policy->flags & MPOL_F_LOCAL)
 		return numa_node_id();
 

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/mempolicy.c
index bd92431,2218157..0000000
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@@ -1097,6 -1085,81 +1085,81 @@@ static struct page *new_vma_page(struc
  }
  #endif
  
+ long mpol_do_mbind(unsigned long start, unsigned long len,
+ 		struct mempolicy *new, unsigned long mode,
+ 		nodemask_t *nmask, unsigned long flags)
+ {
+ 	struct mm_struct *mm = current->mm;
+ 	struct vm_area_struct *vma;
+ 	int err, nr_failed = 0;
+ 	unsigned long end;
+ 	LIST_HEAD(pagelist);
+ 
+ 	len = (len + PAGE_SIZE - 1) & PAGE_MASK;
+ 	end = start + len;
+ 
+ 	if (end < start) {
+ 		err = -EINVAL;
+ 		goto mpol_out;
+ 	}
+ 
+ 	if (end == start) {
+ 		err = 0;
+ 		goto mpol_out;
+ 	}
+ 
+ 	if (flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)) {
+ 		err = migrate_prep();
+ 		if (err)
+ 			goto mpol_out;
+ 	}
+ 
+ 	if (mode != MPOL_NOOP) {
+ 		NODEMASK_SCRATCH(scratch);
+ 		err = -ENOMEM;
+ 		if (scratch) {
+ 			task_lock(current);
+ 			err = mpol_set_nodemask(new, nmask, scratch);
+ 			task_unlock(current);
+ 		}
+ 		NODEMASK_SCRATCH_FREE(scratch);
+ 		if (err)
+ 			goto mpol_out;
+ 	}
+ 
+ 	vma = check_range(mm, start, end, nmask,
+ 			  flags | MPOL_MF_INVERT, &pagelist);
+ 
+ 	err = PTR_ERR(vma);	/* maybe ... */
+ 	if (IS_ERR(vma))
+ 		goto mpol_out_putback;
+ 
+ 	if (mode != MPOL_NOOP) {
+ 		err = mbind_range(mm, start, end, new);
+ 		if (err)
+ 			goto mpol_out_putback;
+ 	}
+ 
+ 	if (!list_empty(&pagelist)) {
+ 		if (flags & MPOL_MF_LAZY)
+ 			nr_failed = migrate_pages_unmap_only(&pagelist);
+ 		else {
+ 			nr_failed = migrate_pages(&pagelist, new_vma_page,
+ 					(unsigned long)vma,
 -					false, true);
++					false, MIGRATE_SYNC);
+ 		}
+ 	}
+ 
+ 	if (nr_failed && (flags & MPOL_MF_STRICT))
+ 		err = -EIO;
+ 
+ mpol_out_putback:
+ 	putback_lru_pages(&pagelist);
+ 
+ mpol_out:
+ 	return err;
+ }
+ 
  static long do_mbind(unsigned long start, unsigned long len,
  		     unsigned short mode, unsigned short mode_flags,
  		     nodemask_t *nmask, unsigned long flags)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2012-06-04  3:52 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2012-06-04  3:52 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Cyrill Gorcunov, Andrew Morton

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/syscalls/syscall_32.tbl arch/x86/syscalls/syscall_64.tbl between
commit d97b46a64674 ("syscalls, x86: add __NR_kcmp syscall") from Linus'
tree and commit a2dae61eb839 ("sched/numa: Introduce sys_numa_{t,m}bind()")
from the tip tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/syscalls/syscall_32.tbl
index 7a35a6e,38954c5..0000000
--- a/arch/x86/syscalls/syscall_32.tbl
+++ b/arch/x86/syscalls/syscall_32.tbl
@@@ -355,4 -355,5 +355,6 @@@
  346	i386	setns			sys_setns
  347	i386	process_vm_readv	sys_process_vm_readv		compat_sys_process_vm_readv
  348	i386	process_vm_writev	sys_process_vm_writev		compat_sys_process_vm_writev
 -349	i386	numa_mbind		sys_numa_mbind			compat_sys_numa_mbind
 -350	i386	numa_tbind		sys_numa_tbind			compat_sys_numa_tbind
 +349	i386	kcmp			sys_kcmp
++350	i386	numa_mbind		sys_numa_mbind			compat_sys_numa_mbind
++351	i386	numa_tbind		sys_numa_tbind			compat_sys_numa_tbind
diff --cc arch/x86/syscalls/syscall_64.tbl
index 51171ae,63c5285..0000000
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@@ -318,8 -318,8 +318,10 @@@
  309	common	getcpu			sys_getcpu
  310	64	process_vm_readv	sys_process_vm_readv
  311	64	process_vm_writev	sys_process_vm_writev
 -312	64	numa_mbind		sys_numa_mbind
 -313	64	numa_tbind		sys_numa_tbind
 +312	64	kcmp			sys_kcmp
++313	64	numa_mbind		sys_numa_mbind
++314	64	numa_tbind		sys_numa_tbind
 +
  #
  # x32-specific system call numbers start at 512 to avoid cache impact
  # for native 64-bit operation.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2012-05-22  5:44 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2012-05-22  5:44 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Linus, Andrew Morton

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in mm/memory.c
between commit 4f74d2c8e827 ("vm: remove 'nr_accounted' calculations from
the unmap_vmas() interfaces") from Linus' tree and commit cbc91f71b51b
("uprobes/core: Decrement uprobe count before the pages are unmapped")
from the tip tree.

Following discussion between Linus and Andred, I fixed it up as below for
now.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/memory.c
index 1e77da6,84427aa..0000000
--- a/mm/memory.c
+++ b/mm/memory.c
@@@ -1307,6 -1309,12 +1309,9 @@@ static void unmap_single_vma(struct mmu
  	if (end <= vma->vm_start)
  		return;
  
+ 	if (vma->vm_file)
+ 		uprobe_munmap(vma, start, end);
+ 
 -	if (vma->vm_flags & VM_ACCOUNT)
 -		*nr_accounted += (end - start) >> PAGE_SHIFT;
 -
  	if (unlikely(is_pfn_mapping(vma)))
  		untrack_pfn_vma(vma, 0, 0);
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2012-01-03  5:16 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2012-01-03  5:16 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Andreas Schwab, Martin Schwidefsky

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

Hi all,

Today's linux-next merge of the tip tree got conflicts in
arch/ia64/include/asm/cputime.h and include/asm-generic/cputime.h between
commit 34845636a184 ("procfs: do not confuse jiffies with cputime64_t")
from Linus' tree and commit 648616343cdb ("[S390] cputime: add sparse
checking and cleanup") from the tip tree.

I did the obvious fix up (see below) which may not be completely correct.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/ia64/include/asm/cputime.h
index 5a274af,461e52f..0000000
--- a/arch/ia64/include/asm/cputime.h
+++ b/arch/ia64/include/asm/cputime.h
@@@ -58,9 -46,10 +46,11 @@@ typedef u64 __nocast cputime64_t
  /*
   * Convert cputime <-> microseconds
   */
- #define cputime_to_usecs(__ct)		((__ct) / NSEC_PER_USEC)
- #define usecs_to_cputime(__usecs)	((__usecs) * NSEC_PER_USEC)
+ #define cputime_to_usecs(__ct)		\
+ 	((__force u64)(__ct) / NSEC_PER_USEC)
+ #define usecs_to_cputime(__usecs)	\
+ 	(__force cputime_t)((__usecs) * NSEC_PER_USEC)
 +#define usecs_to_cputime64(__usecs)	usecs_to_cputime(__usecs)
  
  /*
   * Convert cputime <-> seconds
diff --cc include/asm-generic/cputime.h
index 12a1764,77202e2..0000000
--- a/include/asm-generic/cputime.h
+++ b/include/asm-generic/cputime.h
@@@ -38,9 -23,10 +23,11 @@@ typedef u64 __nocast cputime64_t
  /*
   * Convert cputime to microseconds and back.
   */
- #define cputime_to_usecs(__ct)		jiffies_to_usecs(__ct)
- #define usecs_to_cputime(__msecs)	usecs_to_jiffies(__msecs)
+ #define cputime_to_usecs(__ct)		\
+ 	jiffies_to_usecs(cputime_to_jiffies(__ct));
+ #define usecs_to_cputime(__msecs)	\
+ 	jiffies_to_cputime(usecs_to_jiffies(__msecs));
 +#define usecs_to_cputime64(__msecs)	nsecs_to_jiffies64((__msecs) * 1000)
  
  /*
   * Convert cputime to seconds and back.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2012-01-03  5:08 Stephen Rothwell
  2012-01-03  8:06 ` Ingo Molnar
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2012-01-03  5:08 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Hugh Dickins

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in kernel/futex.c
between commit e6780f7243ed ("futex: Fix uninterruptible loop due to
gate_area") from the  tree and commit ab69f41ef93d ("futex: Fix
uninterruptible loop due to gate_area") from the tip tree.

OK, so these appear to be 2 different versions of the same fix.  I cannot
figure out which to use, so I just used the version from the tip
tree ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2011-04-14  3:14 Stephen Rothwell
  2011-04-14  9:02 ` Peter Zijlstra
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2011-04-14  3:14 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

Hi all,

Today's linux-next merge of the tip tree got a conflict in kernel/sched.c
between commit 6631e635c65d ("block: don't flush plugged IO on forced
preemtion scheduling") from Linus' tree and commits 098247b90a9e ("sched:
Provide p->on_rq") and a3380736e4b3 ("sched: Also serialize ttwu_local()
with p->pi_lock") from the tip tree.

I fixed them up (hopefully - see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/sched.c
index a187c3f,3e99c42..0000000
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@@ -4103,30 -4184,31 +4184,31 @@@ need_resched
  			 * task to maintain concurrency.  If so, wake
  			 * up the task.
  			 */
- 			if (prev->flags & PF_WQ_WORKER) {
- 				struct task_struct *to_wakeup;
- 
+ 			if (prev->flags & PF_WQ_WORKER)
  				to_wakeup = wq_worker_sleeping(prev, cpu);
- 				if (to_wakeup)
- 					try_to_wake_up_local(to_wakeup);
- 			}
  			deactivate_task(rq, prev, DEQUEUE_SLEEP);
+ 			prev->on_rq = 0;
 +
 +			/*
 +			 * If we are going to sleep and we have plugged IO queued, make
 +			 * sure to submit it to avoid deadlocks.
 +			 */
 +			if (blk_needs_flush_plug(prev)) {
 +				raw_spin_unlock(&rq->lock);
 +				blk_flush_plug(prev);
 +				raw_spin_lock(&rq->lock);
 +			}
  		}
  		switch_count = &prev->nvcsw;
  	}
  
+ 	/*
 -	 * If we are going to sleep and we have plugged IO queued, make
 -	 * sure to submit it to avoid deadlocks.
 -	 */
 -	if (prev->state != TASK_RUNNING && blk_needs_flush_plug(prev)) {
 -		raw_spin_unlock(&rq->lock);
 -		blk_flush_plug(prev);
 -		raw_spin_lock(&rq->lock);
 -	}
 -
 -	/*
+ 	 * All three: try_to_wake_up_local(), pre_schedule() and idle_balance()
+ 	 * can drop rq->lock.
+ 	 */
+ 	if (to_wakeup)
+ 		try_to_wake_up_local(to_wakeup);
  	pre_schedule(rq, prev);
- 
  	if (unlikely(!rq->nr_running))
  		idle_balance(cpu, rq);
  

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2011-04-08  5:02 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2011-04-08  5:02 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Lucas De Marchi, John Stultz

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/ia64/kernel/cyclone.c between commit 25985edcedea ("Fix common
misspellings") from Linus' tree and commit d60c3041778c ("ia64: convert
to clocksource_register_hz/khz") from the tip tree.

The latter removes the line modified by the former, so I did that.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2011-03-16  5:08 Stephen Rothwell
  2011-03-16  8:50 ` Sebastian Andrzej Siewior
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2011-03-16  5:08 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Sebastian Andrzej Siewior

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/platform/ce4100/ce4100.c between commit 03150171dcf9 ("x86:
ce4100: Set pci ops via callback instead of module init") from Linus'
tree and commit 1fa4163bdc19 ("x86: ce4100: Use OF to setup devices")
from the tip tree.

I fixed it up (see below) and can carry the fix as necessary.  However, I
have no idea if the final setup of x86_init.pci.init_irq is correct.
Hopefully this will be fixed up in the tip tree before it is sent to
Linus.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/platform/ce4100/ce4100.c
index cd6f184,68c0dbc..0000000
--- a/arch/x86/platform/ce4100/ce4100.c
+++ b/arch/x86/platform/ce4100/ce4100.c
@@@ -15,9 -15,11 +15,12 @@@
  #include <linux/serial_reg.h>
  #include <linux/serial_8250.h>
  
 +#include <asm/ce4100.h>
+ #include <asm/prom.h>
  #include <asm/setup.h>
+ #include <asm/i8259.h>
  #include <asm/io.h>
+ #include <asm/io_apic.h>
  
  static int ce4100_i8042_detect(void)
  {

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2010-10-22  2:08 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2010-10-22  2:08 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Shaohua Li, Alexander van Heukelum

Hi all,

Today's linux-next merge of the tip tree got a conflict in
include/linux/percpu-defs.h between commit
c957ef2c59e952803766ddc22e89981ab534606f ("percpu: Introduce a
read-mostly percpu API") from Linus',  tree and commit
fe8e0c25cad28e8858ecfa5863333c70685a6811 ("x86, 32-bit: Align percpu area
and irq stacks to THREAD_SIZE") from the tip tree.

Just overlapping additions.  I fixed it up (see below) and can carry the
fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/percpu-defs.h
index 27ef6b1,ab20d11..0000000
--- a/include/linux/percpu-defs.h
+++ b/include/linux/percpu-defs.h
@@@ -139,15 -139,18 +139,27 @@@
  	__aligned(PAGE_SIZE)
  
  /*
 + * Declaration/definition used for per-CPU variables that must be read mostly.
 + */
 +#define DECLARE_PER_CPU_READ_MOSTLY(type, name)			\
 +	DECLARE_PER_CPU_SECTION(type, name, "..readmostly")
 +
 +#define DEFINE_PER_CPU_READ_MOSTLY(type, name)				\
 +	DEFINE_PER_CPU_SECTION(type, name, "..readmostly")
 +
 +/*
+  * Declaration/definition used for large per-CPU variables that must be
+  * aligned to something larger than the pagesize.
+  */
+ #define DECLARE_PER_CPU_MULTIPAGE_ALIGNED(type, name, size)		\
+ 	DECLARE_PER_CPU_SECTION(type, name, "..page_aligned")		\
+ 	__aligned(size)
+ 
+ #define DEFINE_PER_CPU_MULTIPAGE_ALIGNED(type, name, size)		\
+ 	DEFINE_PER_CPU_SECTION(type, name, "..page_aligned")		\
+ 	__aligned(size)
+ 
+ /*
   * Intermodule exports for per-CPU variables.  sparse forgets about
   * address space across EXPORT_SYMBOL(), change EXPORT_SYMBOL() to
   * noop if __CHECKER__.

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2010-10-06  2:47 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2010-10-06  2:47 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Linus Torvalds, Jason Baron

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/kernel/module.c between commit
5336377d6225959624146629ce3fc88ee8ecda3d ("modules: Fix module_bug_list
list corruption race") from Linus' tree and commit
d9f5ab7b1c0a520867af389bab5d5fcdbd0e407e ("jump label: x86 support") from
the tip tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/kernel/module.c
index 1c355c5,5399f58..0000000
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@@ -239,7 -239,10 +239,10 @@@ int module_finalize(const Elf_Ehdr *hdr
  		apply_paravirt(pseg, pseg + para->sh_size);
  	}
  
+ 	/* make jump label nops */
+ 	jump_label_apply_nops(me);
+ 
 -	return module_bug_finalize(hdr, sechdrs, me);
 +	return 0;
  }
  
  void module_arch_cleanup(struct module *mod)

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2010-09-23  3:32 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2010-09-23  3:32 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, David S. Miller

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/sparc/kernel/perf_event.c between commit
b343ae51c116dffaef07a8596661774c12212b66 ("sparc64: Support RAW perf
events") from Linus' tree and commit
b0a873ebbf87bf38bf70b5e39a7cadc96099fa13 ("perf: Register PMU
implementations") from the tip tree.

I fixed it up (I think - see below) and can carry the fix for a while.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/sparc/kernel/perf_event.c
index 6318e62,f9a7067..0000000
--- a/arch/sparc/kernel/perf_event.c
+++ b/arch/sparc/kernel/perf_event.c
@@@ -1038,8 -1062,8 +1062,9 @@@ static int sparc_pmu_event_init(struct 
  	if (atomic_read(&nmi_active) < 0)
  		return -ENODEV;
  
 +	pmap = NULL;
- 	if (attr->type == PERF_TYPE_HARDWARE) {
+ 	switch (attr->type) {
+ 	case PERF_TYPE_HARDWARE:
  		if (attr->config >= sparc_pmu->max_events)
  			return -EINVAL;
  		pmap = sparc_pmu->event_map(attr->config);
@@@ -1047,18 -1073,16 +1074,25 @@@
  		pmap = sparc_map_cache_event(attr->config);
  		if (IS_ERR(pmap))
  			return PTR_ERR(pmap);
- 	} else if (attr->type != PERF_TYPE_RAW)
- 		return -EOPNOTSUPP;
+ 		break;
+ 
+ 	case PERF_TYPE_RAW:
 -		return -EOPNOTSUPP;
++		break;
+ 
+ 	default:
+ 		return -ENOENT;
+ 
+ 	}
  
 +	if (pmap) {
 +		hwc->event_base = perf_event_encode(pmap);
 +	} else {
 +		/* User gives us "(encoding << 16) | pic_mask" for
 +		 * PERF_TYPE_RAW events.
 +		 */
 +		hwc->event_base = attr->config;
 +	}
 +
  	/* We save the enable bits in the config_base.  */
  	hwc->config_base = sparc_pmu->irq_bit;
  	if (!attr->exclude_user)

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2010-07-26  3:39 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2010-07-26  3:39 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Conny Seidel

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
tools/perf/Makefile between commit
8a4fd31e0e8dc33f00b8949a12ac56310bac57bc ("perf tools: Fix fallback to
cplus_demangle() when bfd_demangle() is not available") from Linus' tree
and commit 167a58f10d9cd1bdf6a911aa1eecbdff596de156 ("perf tools: Fix
fallback to cplus_demangle() when bfd_demangle() is not available") from
the tip tree.

I assumed that these commits were meant to have the same affect (I only
got a conflict because of earlier changes in the tip tree) and so used
the version form the tip tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2010-01-18  7:08 Stephen Rothwell
  2010-01-18  7:50 ` Ingo Molnar
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2010-01-18  7:08 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Jan Kiszka, Steven Rostedt, Wolfram Sang

Hi all,

Today's linux-next merge of the tip tree got a conflict in
scripts/recordmcount.pl between commit
b82a4045f7962483a78a874343dc6e31b79c96c1 ("tracing/x86: Derive arch from
bits argument in recordmcount.pl") from Linus' tree and commit
dfaa9e2c5707b2c217c0121aac796e0fa3051482 ("tracing: Use appropriate perl
constructs in recordmcount.pl") from the tip tree.

I fixed it up (see below) and can carry the fix for a while.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc scripts/recordmcount.pl
index ea6f6e3,545fe71..0000000
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@@ -194,12 -195,8 +195,8 @@@ sub check_objcop
      }
  }
  
 -if ($arch eq 'x86') {
 +if ($arch =~ /(x86(_64)?)|(i386)/) {
-     if ($bits == 64) {
- 	$arch = "x86_64";
-     } else {
- 	$arch = "i386";
-     }
+     $arch = ($bits == 64) ? 'x86_64' : 'i386';
  }
  
  #

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2009-12-09  4:06 Stephen Rothwell
  0 siblings, 0 replies; 122+ messages in thread
From: Stephen Rothwell @ 2009-12-09  4:06 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

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

Hi all,

Today's linux-next merge of the tip tree got conflicts in
arch/x86/include/asm/x86_init.h and arch/x86/kernel/x86_init.c between a
merge in Linus' tree and a merge in the tip tree.

Two fields of a structure just ended up in a different order after the
two merges.  I used the version from Linus' tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2009-09-24  4:07 Stephen Rothwell
  2009-09-24  8:33 ` Ingo Molnar
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2009-09-24  4:07 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Heiko Carstens, Stefani Seibold

Hi all,

Today's linux-next merge of the tip tree got a conflict in
fs/proc/array.c between commit d899bf7b55f503ba7d3d07ed27c3a37e270fa7db
("procfs: provide stack information for threads") from Linus' tree and
commit d01d4827858cdc2e1c437c87ab65ec0a00fd40f8 ("sched: Always show
Cpus_allowed field in /proc/<pid>/status") from the tip tree.

Just overlapping additions.  I fixed it up (see below) and can cay the
fix for a while. This appears to be fixed the same way in tip:master.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/proc/array.c
index 0c6bc60,762aea9..0000000
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@@ -322,87 -321,16 +322,97 @@@ static inline void task_context_switch_
  			p->nivcsw);
  }
  
 +struct stack_stats {
 +	struct vm_area_struct *vma;
 +	unsigned long	startpage;
 +	unsigned long	usage;
 +};
 +
 +static int stack_usage_pte_range(pmd_t *pmd, unsigned long addr,
 +				unsigned long end, struct mm_walk *walk)
 +{
 +	struct stack_stats *ss = walk->private;
 +	struct vm_area_struct *vma = ss->vma;
 +	pte_t *pte, ptent;
 +	spinlock_t *ptl;
 +	int ret = 0;
 +
 +	pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
 +	for (; addr != end; pte++, addr += PAGE_SIZE) {
 +		ptent = *pte;
 +
 +#ifdef CONFIG_STACK_GROWSUP
 +		if (pte_present(ptent) || is_swap_pte(ptent))
 +			ss->usage = addr - ss->startpage + PAGE_SIZE;
 +#else
 +		if (pte_present(ptent) || is_swap_pte(ptent)) {
 +			ss->usage = ss->startpage - addr + PAGE_SIZE;
 +			pte++;
 +			ret = 1;
 +			break;
 +		}
 +#endif
 +	}
 +	pte_unmap_unlock(pte - 1, ptl);
 +	cond_resched();
 +	return ret;
 +}
 +
 +static inline unsigned long get_stack_usage_in_bytes(struct vm_area_struct *vma,
 +				struct task_struct *task)
 +{
 +	struct stack_stats ss;
 +	struct mm_walk stack_walk = {
 +		.pmd_entry = stack_usage_pte_range,
 +		.mm = vma->vm_mm,
 +		.private = &ss,
 +	};
 +
 +	if (!vma->vm_mm || is_vm_hugetlb_page(vma))
 +		return 0;
 +
 +	ss.vma = vma;
 +	ss.startpage = task->stack_start & PAGE_MASK;
 +	ss.usage = 0;
 +
 +#ifdef CONFIG_STACK_GROWSUP
 +	walk_page_range(KSTK_ESP(task) & PAGE_MASK, vma->vm_end,
 +		&stack_walk);
 +#else
 +	walk_page_range(vma->vm_start, (KSTK_ESP(task) & PAGE_MASK) + PAGE_SIZE,
 +		&stack_walk);
 +#endif
 +	return ss.usage;
 +}
 +
 +static inline void task_show_stack_usage(struct seq_file *m,
 +						struct task_struct *task)
 +{
 +	struct vm_area_struct	*vma;
 +	struct mm_struct	*mm = get_task_mm(task);
 +
 +	if (mm) {
 +		down_read(&mm->mmap_sem);
 +		vma = find_vma(mm, task->stack_start);
 +		if (vma)
 +			seq_printf(m, "Stack usage:\t%lu kB\n",
 +				get_stack_usage_in_bytes(vma, task) >> 10);
 +
 +		up_read(&mm->mmap_sem);
 +		mmput(mm);
 +	}
 +}
 +
+ static void task_cpus_allowed(struct seq_file *m, struct task_struct *task)
+ {
+ 	seq_printf(m, "Cpus_allowed:\t");
+ 	seq_cpumask(m, &task->cpus_allowed);
+ 	seq_printf(m, "\n");
+ 	seq_printf(m, "Cpus_allowed_list:\t");
+ 	seq_cpumask_list(m, &task->cpus_allowed);
+ 	seq_printf(m, "\n");
+ }
+ 
  int proc_pid_status(struct seq_file *m, struct pid_namespace *ns,
  			struct pid *pid, struct task_struct *task)
  {

^ permalink raw reply	[flat|nested] 122+ messages in thread
* linux-next: manual merge of the tip tree with Linus' tree
@ 2009-08-19  6:07 Stephen Rothwell
  2009-08-19 10:37 ` Ingo Molnar
  0 siblings, 1 reply; 122+ messages in thread
From: Stephen Rothwell @ 2009-08-19  6:07 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
kernel/irq/manage.c between commit
69ab849439b506cd8dd2879527fdb64d95dd5211 ("genirq: Wake up irq thread
after action has been installed") from Linus' tree and commit
3c26caa7409ad5367b257de3d7943551d4a959ee ("genirq: Do not wakeup irq
thread from __setup_irq() and set action->irq") from the tip tree.

I used the version from Linus' tree (as seems to have been done in
tip:master).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 122+ messages in thread
end of thread, other threads:[~2024-02-08  1:30 UTC | newest]

Thread overview: 122+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-21  4:12 linux-next: manual merge of the tip tree with Linus' tree Stephen Rothwell
2014-05-21  4:24 ` H. Peter Anvin
2014-05-21  6:01   ` Ingo Molnar
2014-05-21  6:02     ` H. Peter Anvin
2014-05-21  6:05       ` Ingo Molnar
2014-05-21  6:10     ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2024-02-08  1:30 Stephen Rothwell
2023-10-16  1:38 Stephen Rothwell
2023-08-09  2:15 Stephen Rothwell
2023-02-15  1:08 Stephen Rothwell
2023-02-15 11:15 ` Ingo Molnar
2022-07-13  5:08 Stephen Rothwell
2022-05-09  3:59 Stephen Rothwell
2022-01-04  2:45 Stephen Rothwell
2021-10-11  2:21 Stephen Rothwell
2021-10-11 20:48 ` Borislav Petkov
2020-11-06  2:39 Stephen Rothwell
2020-11-06  2:46 ` Steven Rostedt
2020-08-12  1:21 Stephen Rothwell
2020-06-11  1:00 Stephen Rothwell
2020-06-11  0:52 Stephen Rothwell
2020-06-11 10:43 ` Thomas Gleixner
2020-06-11 11:03   ` Stephen Rothwell
2020-06-10  1:49 Stephen Rothwell
2020-06-10  1:42 Stephen Rothwell
2020-05-18  5:10 Stephen Rothwell
2020-05-18  7:12 ` Borislav Petkov
2020-01-06  2:17 Stephen Rothwell
2020-01-06  6:53 ` Ingo Molnar
2019-12-20  1:53 Stephen Rothwell
2019-12-16  2:43 Stephen Rothwell
2019-12-03  2:10 Stephen Rothwell
2019-12-03  6:57 ` Ingo Molnar
2019-12-03  8:56   ` Stephen Rothwell
2019-09-02  7:31 Stephen Rothwell
2019-09-02 18:07 ` Ingo Molnar
2019-07-29  2:00 Stephen Rothwell
2019-03-06  5:53 Stephen Rothwell
2018-10-12  2:14 Stephen Rothwell
2018-10-12  2:18 ` Kees Cook
2018-10-12 10:47   ` Ingo Molnar
2018-10-12 18:56     ` Kees Cook
2018-06-07  1:53 Stephen Rothwell
2018-02-12  1:27 Stephen Rothwell
2018-02-12  7:19 ` Ingo Molnar
2018-02-06  0:54 Stephen Rothwell
2018-02-06  9:14 ` Peter Zijlstra
2018-02-06  0:44 Stephen Rothwell
2018-02-06  0:40 Stephen Rothwell
2018-02-06 12:52 ` Mathieu Desnoyers
2018-02-06 13:55   ` Will Deacon
2018-02-06 14:06     ` Mathieu Desnoyers
2018-02-06 14:11       ` Will Deacon
2018-02-06 17:05         ` Mathieu Desnoyers
2018-02-06 17:21           ` Will Deacon
2018-02-08  7:03         ` Ingo Molnar
2018-02-08 18:56           ` Will Deacon
2018-02-08 19:04             ` Mathieu Desnoyers
2018-02-09 18:25               ` Will Deacon
2018-02-09 20:35                 ` Mathieu Desnoyers
2017-11-10  1:27 Stephen Rothwell
2017-05-22  3:27 Stephen Rothwell
2017-05-22  8:32 ` Mark Rutland
2017-05-22 21:44   ` Stephen Rothwell
2017-05-23  8:37     ` Mark Rutland
2016-02-03  0:09 Stephen Rothwell
2016-02-03  0:32 ` Toshi Kani
2015-09-18  1:12 Stephen Rothwell
2015-08-17  5:57 Stephen Rothwell
2015-07-06  0:08 Stephen Rothwell
2015-07-06  7:49 ` Paolo Bonzini
2015-07-06 21:34   ` Stephen Rothwell
2014-05-21  4:12 Stephen Rothwell
2014-03-21  4:23 Stephen Rothwell
2014-03-21  8:47 ` Srivatsa S. Bhat
2014-02-18  3:09 Stephen Rothwell
2014-02-18  8:06 ` Hans-Christian Egtvedt
2014-02-18 14:15   ` Chen Gang
2014-01-30  1:42 Stephen Rothwell
2014-01-30  1:49 ` Andi Kleen
2014-01-30  1:58   ` Stephen Rothwell
2014-01-30  2:05     ` Andi Kleen
2014-01-28  0:43 Stephen Rothwell
2014-01-17  3:30 Stephen Rothwell
2014-01-17 17:27 ` Sören Brinkmann
2013-12-16  3:18 Stephen Rothwell
2013-09-04  4:24 Stephen Rothwell
2013-07-09  4:36 Stephen Rothwell
2012-12-03  4:19 Stephen Rothwell
2012-10-16  1:00 Stephen Rothwell
2012-10-21 16:29 ` Ingo Molnar
2012-10-15  0:32 Stephen Rothwell
2012-10-10  2:51 Stephen Rothwell
2012-10-10  2:45 Stephen Rothwell
2012-06-26  4:36 Stephen Rothwell
2012-06-22  5:01 Stephen Rothwell
2012-06-04  3:52 Stephen Rothwell
2012-05-22  5:44 Stephen Rothwell
2012-01-03  5:16 Stephen Rothwell
2012-01-03  5:08 Stephen Rothwell
2012-01-03  8:06 ` Ingo Molnar
2012-01-03  8:36   ` Stephen Rothwell
2011-04-14  3:14 Stephen Rothwell
2011-04-14  9:02 ` Peter Zijlstra
2011-04-14  9:25   ` Ingo Molnar
2011-04-08  5:02 Stephen Rothwell
2011-03-16  5:08 Stephen Rothwell
2011-03-16  8:50 ` Sebastian Andrzej Siewior
2011-03-16 11:02   ` Stephen Rothwell
2010-10-22  2:08 Stephen Rothwell
2010-10-06  2:47 Stephen Rothwell
2010-09-23  3:32 Stephen Rothwell
2010-07-26  3:39 Stephen Rothwell
2010-01-18  7:08 Stephen Rothwell
2010-01-18  7:50 ` Ingo Molnar
2010-01-18  8:59   ` Stephen Rothwell
2009-12-09  4:06 Stephen Rothwell
2009-09-24  4:07 Stephen Rothwell
2009-09-24  8:33 ` Ingo Molnar
2009-09-24  9:23   ` Stephen Rothwell
2009-08-19  6:07 Stephen Rothwell
2009-08-19 10:37 ` Ingo Molnar

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