linux-next: manual merge of the tip tree with Linus' tree

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Thomas Gleixner]

Stephen Rothwell <sfr@canb.auug.org.au> writes:
> 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.

Sorry for that inconveniance. I'm about to get rid of the conflicts on
the tip side.

Thanks,

        tglx

Re: linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

Hi Thomas,

On Thu, 11 Jun 2020 12:43:24 +0200 Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Sorry for that inconveniance. I'm about to get rid of the conflicts on
> the tip side.

Thanks.  I do realise that it can take a little while between when
Linus adds something to his tree and previous versions get purged.  It
doesn't happen to much, thankfully.

-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> 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;

Looks good, thanks Stephen!

A similar resolution will show up in tomorrow's -next as well, via:

   e067248949e3 Merge branch 'linus' into x86/cpu, to resolve conflict

... so the conflict should go away in the next -next.

Thanks,

	Ingo

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Borislav Petkov]

Hi Stephen,

On Mon, Oct 11, 2021 at 01:21:20PM +1100, Stephen Rothwell wrote:
> 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.

Thanks, below is Ingo's merge resolution which is identical to yours,
AFAICT.

tip/master and tip/auto-latest are updated so you should be able to
forget your fixup from now on.

:-)

Cheers!

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

commit 3ab37cc4d1e3889ddbb44d62a4741754689f6184 (refs/remotes/tip/x86/fpu)
Merge: 724fc0248d45 d298b03506d3
Author: Ingo Molnar <mingo@kernel.org>
Date:   Mon Oct 11 08:53:07 2021 +0200

    Merge branch 'x86/urgent' into x86/fpu, to resolve conflict
    
    Resolve the conflict between these two commits:
    
       x86/fpu:      1193f408cd51 ("x86/fpu/signal: Change return type of __fpu_restore_sig() to boolean")
       x86/urgent:   d298b03506d3 ("x86/fpu: Restore the masking out of reserved MXCSR bits")
    
     Conflicts:
            arch/x86/kernel/fpu/signal.c
    
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

diff --cc arch/x86/kernel/fpu/signal.c
index 39c7bae97daf,fa17a27390ab..37dbfed29d75
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@@ -382,11 -377,16 +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;
  
- 		/* Reject invalid MXCSR values. */
- 		if (fpu->state.fxsave.mxcsr & ~mxcsr_feature_mask)
- 			return false;
+ 		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())

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Steven Rostedt]

On Fri, 6 Nov 2020 13:39:02 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

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

Thanks Stephen,

Yeah, updates caused errors that needed to be fixed, which we knew were
just a work around till the next merge window. Which is why that commit
had in the comments: "Nested is a workaround that will soon not be
needed." ;-)

-- Steve

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Borislav Petkov]

On Mon, May 18, 2020 at 03:10:32PM +1000, Stephen Rothwell wrote:
> 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.

That commit is gone in the meantime so you won't have the merge conflict
anymore once tip/master is regenerated.

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

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

I've resolved this conflict in -tip as well, so this should go away on 
the next integration of -next.

Thanks,

	Ingo

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

Hi Ingo,

On Tue, 3 Dec 2019 07:57:09 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> No, the correct resolution is to apply the 91298f1a302d fix to the new 
> file - which is in -tip and which I've now also pushed out to -next, so 
> -next should pick it up tomorrow.

Excellent, thanks for that.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

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

No, the correct resolution is to apply the 91298f1a302d fix to the new 
file - which is in -tip and which I've now also pushed out to -next, so 
-next should pick it up tomorrow.

Thanks,

	Ingo

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

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

Thanks Stephen - I resolved this in -tip too, this conflict should not 
trigger anymore in tomorrow's -next integration.

Thanks,

	Ingo

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Kees Cook]

On Fri, Oct 12, 2018 at 3:47 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Kees Cook <keescook@chromium.org> wrote:
>
>> On Thu, Oct 11, 2018 at 7:14 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > 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.
>
> This is the correct resolution, thanks Stephen!
>
>> Ingo, it looks like that commit needs to be split up again ... Linus's
>> tree still needs the fix for the fix?
>
> -next still had the old commit, I've now refreshed tip:auto-latest so the
> conflict should go away in the next iteration.
>
> Linus's tree has the correct fix.

Ah! Gotcha, okay. I had it backwards. Thanks for checking!

-Kees

-- 
Kees Cook
Pixel Security

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* Kees Cook <keescook@chromium.org> wrote:

> On Thu, Oct 11, 2018 at 7:14 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 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.

This is the correct resolution, thanks Stephen!

> Ingo, it looks like that commit needs to be split up again ... Linus's
> tree still needs the fix for the fix?

-next still had the old commit, I've now refreshed tip:auto-latest so the
conflict should go away in the next iteration.

Linus's tree has the correct fix.

Thanks,

	Ingo

Re: linux-next: manual merge of the tip tree with Linus' tree

[Kees Cook]

On Thu, Oct 11, 2018 at 7:14 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 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.

Ingo, it looks like that commit needs to be split up again ... Linus's
tree still needs the fix for the fix?

-Kees

>
> --
> Cheers,
> Stephen Rothwell



-- 
Kees Cook
Pixel Security

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> 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;

The resolution looks good to me, I did a similar resolution and diffed the 
linux-next version to the tip:msater version.

Thanks,

	Ingo

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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;

Re: linux-next: manual merge of the tip tree with Linus' tree

[Mathieu Desnoyers]

----- On Feb 9, 2018, at 1:25 PM, Will Deacon will.deacon@arm.com wrote:

> On Thu, Feb 08, 2018 at 07:04:56PM +0000, Mathieu Desnoyers wrote:
>> ----- On Feb 8, 2018, at 1:56 PM, Will Deacon will.deacon@arm.com wrote:
>> 
>> > On Thu, Feb 08, 2018 at 08:03:50AM +0100, Ingo Molnar wrote:
>> >> 
>> >> * Will Deacon <will.deacon@arm.com> wrote:
>> >> 
>> >> > For the sake of avoiding the conflict, can we just drop it for now, please?
>> >> 
>> >> Yeah, so I resolved the conflict by merging the (already upstream) bits and
>> >> Linus
>> >> pulled that resolution. From now on the level of comments you want there is up
>> >> to
>> >> you! :-)
>> > 
>> > Haha, ok! Mathieu -- are you still planning to add something under
>> > Documentation/? Regardless of my preference on comments, I think it would
>> > be useful.
>> 
>> I submitted it as RFC a few days ago, and I'm still awaiting feedback:
>> 
>> http://lkml.kernel.org/r/1517936413-19675-1-git-send-email-mathieu.desnoyers@efficios.com
>> 
>> If you guys are OK with the approach, I can submit it again, this time without
>> the RFC
>> tag.
> 
> Yes, please!

Done: https://lkml.kernel.org/r/1518208256-22034-1-git-send-email-mathieu.desnoyers@efficios.com

Let's see what Thomas/Ingo/PeterZ have to say about this approach to documentation.
Ingo, if you are OK with it, this feature documentation patch could go through the scheduler tree.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: linux-next: manual merge of the tip tree with Linus' tree

[Will Deacon]

On Thu, Feb 08, 2018 at 07:04:56PM +0000, Mathieu Desnoyers wrote:
> ----- On Feb 8, 2018, at 1:56 PM, Will Deacon will.deacon@arm.com wrote:
> 
> > On Thu, Feb 08, 2018 at 08:03:50AM +0100, Ingo Molnar wrote:
> >> 
> >> * Will Deacon <will.deacon@arm.com> wrote:
> >> 
> >> > For the sake of avoiding the conflict, can we just drop it for now, please?
> >> 
> >> Yeah, so I resolved the conflict by merging the (already upstream) bits and
> >> Linus
> >> pulled that resolution. From now on the level of comments you want there is up
> >> to
> >> you! :-)
> > 
> > Haha, ok! Mathieu -- are you still planning to add something under
> > Documentation/? Regardless of my preference on comments, I think it would
> > be useful.
> 
> I submitted it as RFC a few days ago, and I'm still awaiting feedback:
> 
> http://lkml.kernel.org/r/1517936413-19675-1-git-send-email-mathieu.desnoyers@efficios.com
> 
> If you guys are OK with the approach, I can submit it again, this time without the RFC
> tag.

Yes, please!

Will

Re: linux-next: manual merge of the tip tree with Linus' tree

[Mathieu Desnoyers]

----- On Feb 8, 2018, at 1:56 PM, Will Deacon will.deacon@arm.com wrote:

> On Thu, Feb 08, 2018 at 08:03:50AM +0100, Ingo Molnar wrote:
>> 
>> * Will Deacon <will.deacon@arm.com> wrote:
>> 
>> > For the sake of avoiding the conflict, can we just drop it for now, please?
>> 
>> Yeah, so I resolved the conflict by merging the (already upstream) bits and
>> Linus
>> pulled that resolution. From now on the level of comments you want there is up
>> to
>> you! :-)
> 
> Haha, ok! Mathieu -- are you still planning to add something under
> Documentation/? Regardless of my preference on comments, I think it would
> be useful.

I submitted it as RFC a few days ago, and I'm still awaiting feedback:

http://lkml.kernel.org/r/1517936413-19675-1-git-send-email-mathieu.desnoyers@efficios.com

If you guys are OK with the approach, I can submit it again, this time without the RFC
tag.

Thanks,

Mathieu

> 
> Will

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: linux-next: manual merge of the tip tree with Linus' tree

[Will Deacon]

On Thu, Feb 08, 2018 at 08:03:50AM +0100, Ingo Molnar wrote:
> 
> * Will Deacon <will.deacon@arm.com> wrote:
> 
> > For the sake of avoiding the conflict, can we just drop it for now, please?
> 
> Yeah, so I resolved the conflict by merging the (already upstream) bits and Linus 
> pulled that resolution. From now on the level of comments you want there is up to 
> you! :-)

Haha, ok! Mathieu -- are you still planning to add something under
Documentation/? Regardless of my preference on comments, I think it would
be useful.

Will

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* Will Deacon <will.deacon@arm.com> wrote:

> For the sake of avoiding the conflict, can we just drop it for now, please?

Yeah, so I resolved the conflict by merging the (already upstream) bits and Linus 
pulled that resolution. From now on the level of comments you want there is up to 
you! :-)

Thanks,

	Ingo

Re: linux-next: manual merge of the tip tree with Linus' tree

[Will Deacon]

On Tue, Feb 06, 2018 at 05:05:52PM +0000, Mathieu Desnoyers wrote:
> ----- On Feb 6, 2018, at 9:11 AM, Will Deacon will.deacon@arm.com wrote:
> 
> > On Tue, Feb 06, 2018 at 02:06:50PM +0000, Mathieu Desnoyers wrote:
> >> ----- On Feb 6, 2018, at 8:55 AM, Will Deacon will.deacon@arm.com wrote:
> >> > On Tue, Feb 06, 2018 at 12:52:34PM +0000, Mathieu Desnoyers wrote:
> >> >> One approach I would consider for this is to duplicate this
> >> >> comment and add it just above the "eret" instruction within the
> >> >> macro:
> >> >> 
> >> >> 	/*
> >> >> 	 * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
> >> >> 	 * when returning from IPI handler, and when returning to user-space.
> >> >> 	 */
> >> >> 
> >> >> Or perhaps Will has something else in mind ?
> >> > 
> >> > To be honest with you, I'd just drop the comment entirely. entry.S is
> >> > terrifying these days and nobody should have to go in there to understand
> >> > why we select ARCH_HAS_MEMBARRIER_SYNC_CORE. If you really feel a justification
> >> > is needed, I'd be happy with a line in the Kconfig file.
> >> 
> >> My concern is that someone wanting to optimize away a few cycles by changing
> >> eret to something else in the future will not be looking at Kconfig: that
> >> person will be staring at entry.S.
> > 
> > That person will probably also be me, or somebody who sits within punching
> > distance. I really wouldn't worry about it. There a bunch of other
> > things that will break if we don't use ERET here and, if it's a real
> > concern, we're making the *huge* assumption that developers actually
> > read and pay attention to comments.
> > 
> >> One alternative presented by PeterZ on irc is to do like ppc: define a
> >> macro for eret, and stick all appropriate comments near the macro. This
> >> way, it won't hurt when reading the code, but at least it keeps the
> >> comments near the instruction being discussed.
> > 
> > For the sake of avoiding the conflict, can we just drop it for now, please?
> > Having an "eret" macro isn't obvious, because people won't realise that it's
> > a macro. Having "exception_return" is cryptic as hell to people familiar
> > with the ISA.
> 
> I'd be OK not adding comments in the assembly provided that we document this
> within the new documentation file as I just posted as RFC:
> 
> http://lkml.kernel.org/r/1517936413-19675-1-git-send-email-mathieu.desnoyers@efficios.com
> 
> Thoughts ?

I certainly think that Documentation/ and probably init/Kconfig are the
right places to describe this, but I defer to Ingo on whether or not
arch-support.txt is ok with free-form text comments.

Will

Re: linux-next: manual merge of the tip tree with Linus' tree

[Mathieu Desnoyers]

----- On Feb 6, 2018, at 9:11 AM, Will Deacon will.deacon@arm.com wrote:

> On Tue, Feb 06, 2018 at 02:06:50PM +0000, Mathieu Desnoyers wrote:
>> ----- On Feb 6, 2018, at 8:55 AM, Will Deacon will.deacon@arm.com wrote:
>> > On Tue, Feb 06, 2018 at 12:52:34PM +0000, Mathieu Desnoyers wrote:
>> >> One approach I would consider for this is to duplicate this
>> >> comment and add it just above the "eret" instruction within the
>> >> macro:
>> >> 
>> >> 	/*
>> >> 	 * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
>> >> 	 * when returning from IPI handler, and when returning to user-space.
>> >> 	 */
>> >> 
>> >> Or perhaps Will has something else in mind ?
>> > 
>> > To be honest with you, I'd just drop the comment entirely. entry.S is
>> > terrifying these days and nobody should have to go in there to understand
>> > why we select ARCH_HAS_MEMBARRIER_SYNC_CORE. If you really feel a justification
>> > is needed, I'd be happy with a line in the Kconfig file.
>> 
>> My concern is that someone wanting to optimize away a few cycles by changing
>> eret to something else in the future will not be looking at Kconfig: that
>> person will be staring at entry.S.
> 
> That person will probably also be me, or somebody who sits within punching
> distance. I really wouldn't worry about it. There a bunch of other
> things that will break if we don't use ERET here and, if it's a real
> concern, we're making the *huge* assumption that developers actually
> read and pay attention to comments.
> 
>> One alternative presented by PeterZ on irc is to do like ppc: define a
>> macro for eret, and stick all appropriate comments near the macro. This
>> way, it won't hurt when reading the code, but at least it keeps the
>> comments near the instruction being discussed.
> 
> For the sake of avoiding the conflict, can we just drop it for now, please?
> Having an "eret" macro isn't obvious, because people won't realise that it's
> a macro. Having "exception_return" is cryptic as hell to people familiar
> with the ISA.

I'd be OK not adding comments in the assembly provided that we document this
within the new documentation file as I just posted as RFC:

http://lkml.kernel.org/r/1517936413-19675-1-git-send-email-mathieu.desnoyers@efficios.com

Thoughts ?

Thanks,

Mathieu


> 
> Will

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: linux-next: manual merge of the tip tree with Linus' tree

[Will Deacon]

On Tue, Feb 06, 2018 at 02:06:50PM +0000, Mathieu Desnoyers wrote:
> ----- On Feb 6, 2018, at 8:55 AM, Will Deacon will.deacon@arm.com wrote:
> > On Tue, Feb 06, 2018 at 12:52:34PM +0000, Mathieu Desnoyers wrote:
> >> One approach I would consider for this is to duplicate this
> >> comment and add it just above the "eret" instruction within the
> >> macro:
> >> 
> >> 	/*
> >> 	 * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
> >> 	 * when returning from IPI handler, and when returning to user-space.
> >> 	 */
> >> 
> >> Or perhaps Will has something else in mind ?
> > 
> > To be honest with you, I'd just drop the comment entirely. entry.S is
> > terrifying these days and nobody should have to go in there to understand
> > why we select ARCH_HAS_MEMBARRIER_SYNC_CORE. If you really feel a justification
> > is needed, I'd be happy with a line in the Kconfig file.
> 
> My concern is that someone wanting to optimize away a few cycles by changing
> eret to something else in the future will not be looking at Kconfig: that
> person will be staring at entry.S.

That person will probably also be me, or somebody who sits within punching
distance. I really wouldn't worry about it. There a bunch of other
things that will break if we don't use ERET here and, if it's a real
concern, we're making the *huge* assumption that developers actually
read and pay attention to comments.

> One alternative presented by PeterZ on irc is to do like ppc: define a
> macro for eret, and stick all appropriate comments near the macro. This
> way, it won't hurt when reading the code, but at least it keeps the
> comments near the instruction being discussed.

For the sake of avoiding the conflict, can we just drop it for now, please?
Having an "eret" macro isn't obvious, because people won't realise that it's
a macro. Having "exception_return" is cryptic as hell to people familiar
with the ISA.

Will

Re: linux-next: manual merge of the tip tree with Linus' tree

[Mathieu Desnoyers]

----- On Feb 6, 2018, at 8:55 AM, Will Deacon will.deacon@arm.com wrote:

> On Tue, Feb 06, 2018 at 12:52:34PM +0000, Mathieu Desnoyers wrote:
>> ----- On Feb 5, 2018, at 7:40 PM, Stephen Rothwell sfr@canb.auug.org.au wrote:
>> 
>> > 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.
>> 
>> The change introduced by 4bf3286d29 "arm64: entry: Hook up entry trampoline
>> to exception vectors" adds a trampoline as mechanism for return:
>> 
>> -       eret                                    // return to kernel
>> +
>> +#ifndef CONFIG_UNMAP_KERNEL_AT_EL0
>> +       eret
>> +#else
>> +       .if     \el == 0
>> +       bne     4f
>> +       msr     far_el1, x30
>> +       tramp_alias     x30, tramp_exit_native
>> +       br      x30
>> +4:
>> +       tramp_alias     x30, tramp_exit_compat
>> +       br      x30
>> +       .else
>> +       eret
>> +       .endif
>> +#endif
>> 
>> Which means that with CONFIG_UNMAP_KERNEL_AT_EL0, for return to EL0,
>> the eret is in the trampoline:
>> 
>>         .macro tramp_exit, regsize = 64
>>         adr     x30, tramp_vectors
>>         msr     vbar_el1, x30
>>         tramp_unmap_kernel      x30
>>         .if     \regsize == 64
>>         mrs     x30, far_el1
>>         .endif
>>         eret
>>         .endm
>> 
>> ENTRY(tramp_exit_native)
>>         tramp_exit
>> END(tramp_exit_native)
>> 
>> ENTRY(tramp_exit_compat)
>>         tramp_exit      32
>> END(tramp_exit_compat)
>> 
>> 
>> One approach I would consider for this is to duplicate this
>> comment and add it just above the "eret" instruction within the
>> macro:
>> 
>> 	/*
>> 	 * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
>> 	 * when returning from IPI handler, and when returning to user-space.
>> 	 */
>> 
>> Or perhaps Will has something else in mind ?
> 
> To be honest with you, I'd just drop the comment entirely. entry.S is
> terrifying these days and nobody should have to go in there to understand
> why we select ARCH_HAS_MEMBARRIER_SYNC_CORE. If you really feel a justification
> is needed, I'd be happy with a line in the Kconfig file.

My concern is that someone wanting to optimize away a few cycles by changing
eret to something else in the future will not be looking at Kconfig: that
person will be staring at entry.S.

One alternative presented by PeterZ on irc is to do like ppc: define a
macro for eret, and stick all appropriate comments near the macro. This
way, it won't hurt when reading the code, but at least it keeps the
comments near the instruction being discussed.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: linux-next: manual merge of the tip tree with Linus' tree

[Will Deacon]

On Tue, Feb 06, 2018 at 12:52:34PM +0000, Mathieu Desnoyers wrote:
> ----- On Feb 5, 2018, at 7:40 PM, Stephen Rothwell sfr@canb.auug.org.au wrote:
> 
> > 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.
> 
> The change introduced by 4bf3286d29 "arm64: entry: Hook up entry trampoline
> to exception vectors" adds a trampoline as mechanism for return:
> 
> -       eret                                    // return to kernel
> +
> +#ifndef CONFIG_UNMAP_KERNEL_AT_EL0
> +       eret
> +#else
> +       .if     \el == 0
> +       bne     4f
> +       msr     far_el1, x30
> +       tramp_alias     x30, tramp_exit_native
> +       br      x30
> +4:
> +       tramp_alias     x30, tramp_exit_compat
> +       br      x30
> +       .else
> +       eret
> +       .endif
> +#endif
> 
> Which means that with CONFIG_UNMAP_KERNEL_AT_EL0, for return to EL0,
> the eret is in the trampoline:
> 
>         .macro tramp_exit, regsize = 64
>         adr     x30, tramp_vectors
>         msr     vbar_el1, x30
>         tramp_unmap_kernel      x30
>         .if     \regsize == 64
>         mrs     x30, far_el1
>         .endif
>         eret
>         .endm
> 
> ENTRY(tramp_exit_native)
>         tramp_exit
> END(tramp_exit_native)
> 
> ENTRY(tramp_exit_compat)
>         tramp_exit      32
> END(tramp_exit_compat)
> 
> 
> One approach I would consider for this is to duplicate this
> comment and add it just above the "eret" instruction within the
> macro:
> 
> 	/*
> 	 * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
> 	 * when returning from IPI handler, and when returning to user-space.
> 	 */
> 
> Or perhaps Will has something else in mind ?

To be honest with you, I'd just drop the comment entirely. entry.S is
terrifying these days and nobody should have to go in there to understand
why we select ARCH_HAS_MEMBARRIER_SYNC_CORE. If you really feel a justification
is needed, I'd be happy with a line in the Kconfig file.

Will

Re: linux-next: manual merge of the tip tree with Linus' tree

[Mathieu Desnoyers]

----- On Feb 5, 2018, at 7:40 PM, Stephen Rothwell sfr@canb.auug.org.au wrote:

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

The change introduced by 4bf3286d29 "arm64: entry: Hook up entry trampoline
to exception vectors" adds a trampoline as mechanism for return:

-       eret                                    // return to kernel
+
+#ifndef CONFIG_UNMAP_KERNEL_AT_EL0
+       eret
+#else
+       .if     \el == 0
+       bne     4f
+       msr     far_el1, x30
+       tramp_alias     x30, tramp_exit_native
+       br      x30
+4:
+       tramp_alias     x30, tramp_exit_compat
+       br      x30
+       .else
+       eret
+       .endif
+#endif

Which means that with CONFIG_UNMAP_KERNEL_AT_EL0, for return to EL0,
the eret is in the trampoline:

        .macro tramp_exit, regsize = 64
        adr     x30, tramp_vectors
        msr     vbar_el1, x30
        tramp_unmap_kernel      x30
        .if     \regsize == 64
        mrs     x30, far_el1
        .endif
        eret
        .endm

ENTRY(tramp_exit_native)
        tramp_exit
END(tramp_exit_native)

ENTRY(tramp_exit_compat)
        tramp_exit      32
END(tramp_exit_compat)


One approach I would consider for this is to duplicate this
comment and add it just above the "eret" instruction within the
macro:

	/*
	 * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
	 * when returning from IPI handler, and when returning to user-space.
	 */

Or perhaps Will has something else in mind ?

Thanks,

Mathieu

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

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: linux-next: manual merge of the tip tree with Linus' tree

[Peter Zijlstra]

On Tue, Feb 06, 2018 at 11:54:38AM +1100, Stephen Rothwell wrote:
> 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")

FWIW, akpm has a patch that re-inlines mmdrop().

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

Re: linux-next: manual merge of the tip tree with Linus' tree

[Mark Rutland]

Hi Stephen,

On Tue, May 23, 2017 at 07:44:56AM +1000, Stephen Rothwell wrote:
> On Mon, 22 May 2017 09:32:15 +0100 Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > Just to check, is your copy of tip up-to-date?
> 
> Yes, it was fetched just before being merged.  I use the auto-latest
> branch of the tip tree which may not be as up to date as the master
> branch.

Thanks for the pointer; there was a stale copy there, which has now been
zapped.

Hopefully we're conflict-free for next-20170524.

Thanks for the heads-up!

Mark.

Re: linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

Hi Mark,

On Mon, 22 May 2017 09:32:15 +0100 Mark Rutland <mark.rutland@arm.com> wrote:
>
> Just to check, is your copy of tip up-to-date?

Yes, it was fetched just before being merged.  I use the auto-latest
branch of the tip tree which may not be as up to date as the master
branch.

> That latter commit was in the tip smp/hotplug branch, but that branch
> was reset to v4.12-rc1 a few days ago (before the first commit was sent
> to Linus), specifically to avoid this conflict.
> 
> ... did we miss another branch that was merged into, perhaps?

Presumably, but that's ok - I assume it will come good eventually.

> The good news is that the commit in Linus' tree is the correct fix. :)

Well, except that I only fixed up that one spot, the rest of the commit
from the tip tree was still there.

> The other commit was a slightly broken prior attempt, and shouldn't be
> in the tip tree any more.

OK.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the tip tree with Linus' tree

[Mark Rutland]

On Mon, May 22, 2017 at 01:27:11PM +1000, Stephen Rothwell wrote:
> Hi all,

Hi,

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

Just to check, is your copy of tip up-to-date?

That latter commit was in the tip smp/hotplug branch, but that branch
was reset to v4.12-rc1 a few days ago (before the first commit was sent
to Linus), specifically to avoid this conflict.

... did we miss another branch that was merged into, perhaps?

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

The good news is that the commit in Linus' tree is the correct fix. :)

The other commit was a slightly broken prior attempt, and shouldn't be
in the tip tree any more.

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

We tried, but evidently something went wrong. :/

Thanks,
Mark.

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

Re: linux-next: manual merge of the tip tree with Linus' tree

[Toshi Kani]

On Wed, 2016-02-03 at 11:09 +1100, Stephen Rothwell wrote:
> 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).

Looks good.  Thanks for the marge.
-Toshi

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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;

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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,

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

Re: linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

Hi Paolo,

On Mon, 6 Jul 2015 09:49:09 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 06/07/2015 02:08, Stephen Rothwell wrote:
> > 
> > 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).
> 
> The commit from the tip tree is obsolete.

And has now been removed from the tip tree, so we won't see that
conflict today.

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

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

Re: linux-next: manual merge of the tip tree with Linus' tree

[Paolo Bonzini]

On 06/07/2015 02:08, Stephen Rothwell wrote:
> 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).

The commit from the tip tree is obsolete.

Paolo

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* Ingo Molnar <mingo@kernel.org> wrote:

> 
> * H. Peter Anvin <hpa@zytor.com> wrote:
> 
> > On 05/20/2014 09:12 PM, Stephen Rothwell wrote:
> > > 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).
> > > 
> > 
> > This (and the previous one) is not the correct fix, although it will
> > work.  The correct fix is instead to completely revert fa81511bb0bb
> > before merging in tip:x86/espfix.
> > 
> > Sorry for the inconvenience.  Linus generally doesn't like it when we
> > fix up merges for him, or I'd set up a "clean" tip:x86/espfix branch.
> 
> Please merge x86/urgent into x86/vdso while memories are still fresh 
> - fixing up conflicts between our own branches is entirely fine (I'm 
> doing it all the time to help the development flow) and it will make 
> life easier.
> 
> What Linus dislikes most are merges between completely _unrelated_ 
> topic branches, especially if they cross maintenance domains.

Also, 'pre pull request' conflict resolution merges are frowned upon 
mostly, as they tend to be of lower quality, come with little testing, 
and they also hide the various conflict interactions, many of which 
are canaries of bad development flow.

Here the development flow is healthy: what conflicted was a quick and 
simple short term urgent fix for upstream which came through you, with 
the longer term fix coming in the next window, through you as well. 

Resolving those conflicts in the development branch, to make developer 
life easier, is pretty natural and I'd say is even considered good 
practice in a clean Git flow.

Thanks,

	Ingo

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> Ok.  Will do.

Thanks!

	Ingo

Re: linux-next: manual merge of the tip tree with Linus' tree

[H. Peter Anvin]

Ok.  Will do.

On May 20, 2014 11:01:00 PM PDT, Ingo Molnar <mingo@kernel.org> wrote:
>
>* H. Peter Anvin <hpa@zytor.com> wrote:
>
>> On 05/20/2014 09:12 PM, Stephen Rothwell wrote:
>> > 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).
>> > 
>> 
>> This (and the previous one) is not the correct fix, although it will
>> work.  The correct fix is instead to completely revert fa81511bb0bb
>> before merging in tip:x86/espfix.
>> 
>> Sorry for the inconvenience.  Linus generally doesn't like it when we
>> fix up merges for him, or I'd set up a "clean" tip:x86/espfix branch.
>
>Please merge x86/urgent into x86/vdso while memories are still fresh - 
>fixing up conflicts between our own branches is entirely fine (I'm 
>doing it all the time to help the development flow) and it will make 
>life easier.
>
>What Linus dislikes most are merges between completely _unrelated_ 
>topic branches, especially if they cross maintenance domains.
>
>Thanks,
>
>	Ingo

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> On 05/20/2014 09:12 PM, Stephen Rothwell wrote:
> > 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).
> > 
> 
> This (and the previous one) is not the correct fix, although it will
> work.  The correct fix is instead to completely revert fa81511bb0bb
> before merging in tip:x86/espfix.
> 
> Sorry for the inconvenience.  Linus generally doesn't like it when we
> fix up merges for him, or I'd set up a "clean" tip:x86/espfix branch.

Please merge x86/urgent into x86/vdso while memories are still fresh - 
fixing up conflicts between our own branches is entirely fine (I'm 
doing it all the time to help the development flow) and it will make 
life easier.

What Linus dislikes most are merges between completely _unrelated_ 
topic branches, especially if they cross maintenance domains.

Thanks,

	Ingo

Re: linux-next: manual merge of the tip tree with Linus' tree

[H. Peter Anvin]

On 05/20/2014 09:12 PM, Stephen Rothwell wrote:
> 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).
> 

This (and the previous one) is not the correct fix, although it will
work.  The correct fix is instead to completely revert fa81511bb0bb
before merging in tip:x86/espfix.

Sorry for the inconvenience.  Linus generally doesn't like it when we
fix up merges for him, or I'd set up a "clean" tip:x86/espfix branch.

	-hpa

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Srivatsa S. Bhat]

On 03/21/2014 09:53 AM, Stephen Rothwell wrote:
> 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).
> 

The fix looks good to me. Thank you!

Regards,
Srivatsa S. Bhat

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Chen Gang]

On 02/18/2014 04:06 PM, Hans-Christian Egtvedt wrote:
> Around Tue 18 Feb 2014 14:09:20 +1100 or thereabout, Stephen Rothwell wrote:
> 
> Hello Stephen,
> 
>> 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).
> 
> Thank you for handling the merge.
> 
> PS! I typically don't use my Cisco address for avr32 related kernel patches,
> but it seems to be my own fault, my global gitconfig contained my @cisco.com
> address. Fixed now.
> 

Thank all of your work (also include another 2 patches).

And I guess, in the next month, I shall/can have more free time for
upstream open source, so I will/should finish avr32 allmodconfig within
next month (2014-03-31).


Thanks.
-- 
Chen Gang

Open, share and attitude like air, water and life which God blessed

Re: linux-next: manual merge of the tip tree with Linus' tree

[Hans-Christian Egtvedt]

Around Tue 18 Feb 2014 14:09:20 +1100 or thereabout, Stephen Rothwell wrote:

Hello Stephen,

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

Thank you for handling the merge.

PS! I typically don't use my Cisco address for avr32 related kernel patches,
but it seems to be my own fault, my global gitconfig contained my @cisco.com
address. Fixed now.

-- 
Best regards,
Hans-Christian Egtvedt

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Andi Kleen]

On Thu, Jan 30, 2014 at 12:58:35PM +1100, Stephen Rothwell wrote:
> Hi Andi,
> 
> On Wed, 29 Jan 2014 17:49:14 -0800 Andi Kleen <ak@linux.intel.com> wrote:
> >
> > > I fixed it up (see below) and can carry the fix as necessary (no action
> > > is required).
> > 
> > I don't think the fix is correct, both sysctls need to be kept. They
> > do different things.
> 
> The tip tree commit 52bf84aa206c ("sched/numa,mm: Remove
> p->numa_migrate_deferred") explicitly removed the
> numa_balancing_migrate_deferred sysctl.

Okay, sorry for the noise then.

-Andi

Re: linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

Hi Andi,

On Wed, 29 Jan 2014 17:49:14 -0800 Andi Kleen <ak@linux.intel.com> wrote:
>
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
> 
> I don't think the fix is correct, both sysctls need to be kept. They
> do different things.

The tip tree commit 52bf84aa206c ("sched/numa,mm: Remove
p->numa_migrate_deferred") explicitly removed the
numa_balancing_migrate_deferred sysctl.

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

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

Re: linux-next: manual merge of the tip tree with Linus' tree

[Andi Kleen]

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

I don't think the fix is correct, both sysctls need to be kept. They
do different things.

-Andi

> 
> -- 
> 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 */
>   	{



-- 
ak@linux.intel.com -- Speaking for myself only

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Sören Brinkmann]

Hi Stephen,

On Fri, Jan 17, 2014 at 02:30:35PM +1100, Stephen Rothwell wrote:
> 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).

The fix is correct.

	Thanks,
	Sören

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

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

Ok, this conflict should go away the next time you integrate 
linux-next.

Thanks,

	Ingo

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

Hi Ingo,

On Tue, 3 Jan 2012 09:06:18 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> No, Linus's version is the correct resolution - i've resolved 
> this in tip:auto-latest.

Thanks for that.

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

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

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

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

No, Linus's version is the correct resolution - i've resolved 
this in tip:auto-latest.

Thanks,

	Ingo

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, 2011-04-14 at 13:14 +1000, Stephen Rothwell wrote:
> > 
> > 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. 
> 
> It looks like Ingo accidentially published an older version of these patches 
> because I also got a UP build error from Tony yesterday.

It was intentionally published.

> A new series was merged this morning which should hopefully address both 
> problems.

Yes.

Thanks,

	Ingo

Re: linux-next: manual merge of the tip tree with Linus' tree

[Peter Zijlstra]

On Thu, 2011-04-14 at 13:14 +1000, Stephen Rothwell wrote:
> 
> 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. 

It looks like Ingo accidentially published an older version of these
patches because I also got a UP build error from Tony yesterday.

A new series was merged this morning which should hopefully address both
problems.

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

Hi Sebastian,

On Wed, 16 Mar 2011 09:50:06 +0100 Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>
> I just looked and Linus already pulled and fixed it up by himself. Thanks
> for letting me know.

And he fixed it much better than I did :-)

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

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

Re: linux-next: manual merge of the tip tree with Linus' tree

[Sebastian Andrzej Siewior]

Stephen Rothwell wrote:
> Hi all,
Hi Stephen,

> 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 just looked and Linus already pulled and fixed it up by himself. Thanks
for letting me know.

Sebastian

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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)

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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)

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

Hi Ingo,

On Mon, 18 Jan 2010 08:50:25 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> FYI, i resolved the conflict already in tip:master yesterday, a bit 
> differently.

Excellent, thanks.

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

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

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

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

FYI, i resolved the conflict already in tip:master yesterday, a bit 
differently.

Thanks,

	Ingo

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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';
  }
  
  #

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

Hi Ingo,

On Thu, 24 Sep 2009 10:33:09 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> Thanks - that's how i fixed it up yesterday, and it tested fine. Have 
> just pushed out this resolution, so the conflict should disappear from 
> linux-next tomorrow.

OK, thanks.

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

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

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

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

Thanks - that's how i fixed it up yesterday, and it tested fine. Have 
just pushed out this resolution, so the conflict should disappear from 
linux-next tomorrow.

Thanks,

	Ingo

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

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

Re: linux-next: manual merge of the tip tree with Linus' tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

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

Yeah - that's the right resolution - thanks Stephen.

	Ingo

linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

[-- 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 --]