Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: manual merge of the tip tree with Linus' tree
@ 2019-09-02  7:31 Stephen Rothwell
  2019-09-02 18:07 ` Ingo Molnar
  0 siblings, 1 reply; 94+ messages in thread
From: Stephen Rothwell @ 2019-09-02  7:31 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Len Brown,
	Zhang Rui, Rajneesh Bhardwaj

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

Hi all,

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

  tools/power/x86/turbostat/turbostat.c

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

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

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

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

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


* 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

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

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

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

Hi all,

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

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

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

I fixed it up (I removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Hi all,

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

  arch/x86/um/Kconfig

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/um/Kconfig
index 494eeb51e4e1,ab14e6f73ca4..a9e80e44178c
--- a/arch/x86/um/Kconfig
+++ b/arch/x86/um/Kconfig
@@@ -16,6 -16,8 +16,7 @@@ config 64BI
  
  config X86_32
  	def_bool !64BIT
 -	select HAVE_AOUT
+ 	select ARCH_32BIT_OFF_T
  	select ARCH_WANT_IPC_PARSE_VERSION
  	select MODULES_USE_ELF_REL
  	select CLONE_BACKWARDS

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2018-10-12 10:47   ` Ingo Molnar
@ 2018-10-12 18:56     ` Kees Cook
  0 siblings, 0 replies; 94+ messages in thread
From: Kees Cook @ 2018-10-12 18:56 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Ingo Molnar, Stephen Rothwell, Thomas Gleixner, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List,
	Linux Kernel Mailing List, Arnd Bergmann

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

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

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


* 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

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

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

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

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

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

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

Hi all,

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

  arch/x86/mm/pgtable.c

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

I fixed it up (I used the version from Linus' tree) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

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

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

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

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

Hi all,

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

  tools/testing/selftests/Makefile

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/testing/selftests/Makefile
index 4cd339b5366a,593fb44c9cd4..000000000000
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@@ -29,7 -28,7 +29,8 @@@ TARGETS += powerp
  TARGETS += proc
  TARGETS += pstore
  TARGETS += ptrace
+ TARGETS += rseq
 +TARGETS += rtc
  TARGETS += seccomp
  TARGETS += sigaltstack
  TARGETS += size

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

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

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

* 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

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

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

Hi all,

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

  arch/x86/kvm/vmx.c

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

I fixed it up (I think - see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2018-02-09 18:25               ` Will Deacon
@ 2018-02-09 20:35                 ` Mathieu Desnoyers
  0 siblings, 0 replies; 94+ messages in thread
From: Mathieu Desnoyers @ 2018-02-09 20:35 UTC (permalink / raw)
  To: Will Deacon, Ingo Molnar
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List, linux-kernel

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2018-02-08 19:04             ` Mathieu Desnoyers
@ 2018-02-09 18:25               ` Will Deacon
  2018-02-09 20:35                 ` Mathieu Desnoyers
  0 siblings, 1 reply; 94+ messages in thread
From: Will Deacon @ 2018-02-09 18:25 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Ingo Molnar, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Linux-Next Mailing List,
	linux-kernel

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2018-02-08 18:56           ` Will Deacon
@ 2018-02-08 19:04             ` Mathieu Desnoyers
  2018-02-09 18:25               ` Will Deacon
  0 siblings, 1 reply; 94+ messages in thread
From: Mathieu Desnoyers @ 2018-02-08 19:04 UTC (permalink / raw)
  To: Will Deacon
  Cc: Ingo Molnar, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Linux-Next Mailing List,
	linux-kernel

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2018-02-08  7:03         ` Ingo Molnar
@ 2018-02-08 18:56           ` Will Deacon
  2018-02-08 19:04             ` Mathieu Desnoyers
  0 siblings, 1 reply; 94+ messages in thread
From: Will Deacon @ 2018-02-08 18:56 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Mathieu Desnoyers, Stephen Rothwell, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, linux-kernel

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2018-02-06 14:11       ` Will Deacon
  2018-02-06 17:05         ` Mathieu Desnoyers
@ 2018-02-08  7:03         ` Ingo Molnar
  2018-02-08 18:56           ` Will Deacon
  1 sibling, 1 reply; 94+ messages in thread
From: Ingo Molnar @ 2018-02-08  7:03 UTC (permalink / raw)
  To: Will Deacon
  Cc: Mathieu Desnoyers, Stephen Rothwell, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, linux-kernel


* 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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2018-02-06 17:05         ` Mathieu Desnoyers
@ 2018-02-06 17:21           ` Will Deacon
  0 siblings, 0 replies; 94+ messages in thread
From: Will Deacon @ 2018-02-06 17:21 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List, linux-kernel

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2018-02-06 14:11       ` Will Deacon
@ 2018-02-06 17:05         ` Mathieu Desnoyers
  2018-02-06 17:21           ` Will Deacon
  2018-02-08  7:03         ` Ingo Molnar
  1 sibling, 1 reply; 94+ messages in thread
From: Mathieu Desnoyers @ 2018-02-06 17:05 UTC (permalink / raw)
  To: Will Deacon
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List, linux-kernel

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2018-02-06 14:06     ` Mathieu Desnoyers
@ 2018-02-06 14:11       ` Will Deacon
  2018-02-06 17:05         ` Mathieu Desnoyers
  2018-02-08  7:03         ` Ingo Molnar
  0 siblings, 2 replies; 94+ messages in thread
From: Will Deacon @ 2018-02-06 14:11 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List, linux-kernel

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2018-02-06 13:55   ` Will Deacon
@ 2018-02-06 14:06     ` Mathieu Desnoyers
  2018-02-06 14:11       ` Will Deacon
  0 siblings, 1 reply; 94+ messages in thread
From: Mathieu Desnoyers @ 2018-02-06 14:06 UTC (permalink / raw)
  To: Will Deacon
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List, linux-kernel

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2018-02-06 12:52 ` Mathieu Desnoyers
@ 2018-02-06 13:55   ` Will Deacon
  2018-02-06 14:06     ` Mathieu Desnoyers
  0 siblings, 1 reply; 94+ messages in thread
From: Will Deacon @ 2018-02-06 13:55 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List, linux-kernel

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

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

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

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

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

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

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

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

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

Hi all,

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

  include/linux/sched/mm.h

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

I fixed it up (I used the former version ofinclude/linux/sched/mm.h
and adde the following merge fix patch) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

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

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

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

-- 
Cheers,
Stephen Rothwell

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

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

Hi all,

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

  arch/x86/Kconfig

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/Kconfig
index b0771ceabb4b,e095bdb9afdf..000000000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -54,7 -54,7 +54,8 @@@ config X8
  	select ARCH_HAS_FORTIFY_SOURCE
  	select ARCH_HAS_GCOV_PROFILE_ALL
  	select ARCH_HAS_KCOV			if X86_64
+ 	select ARCH_HAS_MEMBARRIER_SYNC_CORE
 +	select ARCH_HAS_PHYS_TO_DMA
  	select ARCH_HAS_PMEM_API		if X86_64
  	select ARCH_HAS_REFCOUNT
  	select ARCH_HAS_UACCESS_FLUSHCACHE	if X86_64

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

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

Hi all,

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

  arch/arm64/kernel/entry.S

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

I fixed it up (probably not completely - see below) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

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

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

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

Hi all,

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

  arch/x86/mm/mem_encrypt.c

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2017-05-22 21:44   ` Stephen Rothwell
@ 2017-05-23  8:37     ` Mark Rutland
  0 siblings, 0 replies; 94+ messages in thread
From: Mark Rutland @ 2017-05-23  8:37 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Catalin Marinas

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.

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

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

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

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

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

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.

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

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

Hi all,

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

  arch/arm64/include/asm/cpufeature.h

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

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

I fixed it up (see above) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

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

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

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

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

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

Hi all,

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

  kernel/memremap.c

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

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

Hi all,

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

  tools/perf/ui/browsers/hists.c

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

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

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

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

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

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

Hi all,

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

  arch/x86/entry/entry_64_compat.S

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

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

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

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2015-07-06  7:49 ` Paolo Bonzini
@ 2015-07-06 21:34   ` Stephen Rothwell
  0 siblings, 0 replies; 94+ messages in thread
From: Stephen Rothwell @ 2015-07-06 21:34 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

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

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

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



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

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

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

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

Hi all,

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

  kernel/sched/core.c

between commit:

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

from Linus' tree and commit:

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

from the tip tree.

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

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

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

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2014-05-21  6:01   ` Ingo Molnar
  2014-05-21  6:02     ` H. Peter Anvin
@ 2014-05-21  6:10     ` Ingo Molnar
  1 sibling, 0 replies; 94+ messages in thread
From: Ingo Molnar @ 2014-05-21  6:10 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
	linux-next, linux-kernel, Linus


* 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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2014-05-21  6:02     ` H. Peter Anvin
@ 2014-05-21  6:05       ` Ingo Molnar
  0 siblings, 0 replies; 94+ messages in thread
From: Ingo Molnar @ 2014-05-21  6:05 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
	linux-next, linux-kernel, Linus


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

> Ok.  Will do.

Thanks!

	Ingo

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2014-05-21  6:01   ` Ingo Molnar
@ 2014-05-21  6:02     ` H. Peter Anvin
  2014-05-21  6:05       ` Ingo Molnar
  2014-05-21  6:10     ` Ingo Molnar
  1 sibling, 1 reply; 94+ messages in thread
From: H. Peter Anvin @ 2014-05-21  6:02 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
	linux-next, linux-kernel, Linus

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.

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2014-05-21  4:24 ` H. Peter Anvin
@ 2014-05-21  6:01   ` Ingo Molnar
  2014-05-21  6:02     ` H. Peter Anvin
  2014-05-21  6:10     ` Ingo Molnar
  0 siblings, 2 replies; 94+ messages in thread
From: Ingo Molnar @ 2014-05-21  6:01 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
	linux-next, linux-kernel, Linus


* 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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2014-02-18  8:06 ` Hans-Christian Egtvedt
@ 2014-02-18 14:15   ` Chen Gang
  0 siblings, 0 replies; 94+ messages in thread
From: Chen Gang @ 2014-02-18 14:15 UTC (permalink / raw)
  To: Hans-Christian Egtvedt
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Hans-Christian Egtvedt,
	Tim Chen

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2014-01-30  1:58   ` Stephen Rothwell
@ 2014-01-30  2:05     ` Andi Kleen
  0 siblings, 0 replies; 94+ messages in thread
From: Andi Kleen @ 2014-01-30  2:05 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Andrew Morton, Rik van Riel

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

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

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

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

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

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

> 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

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

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

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

Hi all,

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

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


* 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

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

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

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

Hi all,

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

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

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

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

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

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

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

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

Hi all,

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

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

I also added this merge fix patch:

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

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2012-01-03  8:06 ` Ingo Molnar
@ 2012-01-03  8:36   ` Stephen Rothwell
  0 siblings, 0 replies; 94+ messages in thread
From: Stephen Rothwell @ 2012-01-03  8:36 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, H. Peter Anvin, Peter Zijlstra, linux-next,
	linux-kernel, Hugh Dickins

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

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

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


* 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

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

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

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

Hi all,

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2011-04-14  9:02 ` Peter Zijlstra
@ 2011-04-14  9:25   ` Ingo Molnar
  0 siblings, 0 replies; 94+ messages in thread
From: Ingo Molnar @ 2011-04-14  9:25 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, linux-next,
	linux-kernel


* 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

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

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

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.

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

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

Hi all,

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

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

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

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

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

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

Hi all,

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

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

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2011-03-16  8:50 ` Sebastian Andrzej Siewior
@ 2011-03-16 11:02   ` Stephen Rothwell
  0 siblings, 0 replies; 94+ messages in thread
From: Stephen Rothwell @ 2011-03-16 11:02 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

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

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

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

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

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

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

Hi all,

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

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

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

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

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

Hi all,

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

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

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

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

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

Hi all,

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

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

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

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

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

Hi all,

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

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

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

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

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

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

Hi all,

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

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

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2010-01-18  7:50 ` Ingo Molnar
@ 2010-01-18  8:59   ` Stephen Rothwell
  0 siblings, 0 replies; 94+ messages in thread
From: Stephen Rothwell @ 2010-01-18  8:59 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, H. Peter Anvin, Peter Zijlstra, linux-next,
	linux-kernel, Jan Kiszka, Steven Rostedt, Wolfram Sang

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

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

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


* 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

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

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

Hi all,

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

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

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

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

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

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

Hi all,

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

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

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

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

* Re: linux-next: manual merge of the tip tree with Linus' tree
  2009-09-24  8:33 ` Ingo Molnar
@ 2009-09-24  9:23   ` Stephen Rothwell
  0 siblings, 0 replies; 94+ messages in thread
From: Stephen Rothwell @ 2009-09-24  9:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, H. Peter Anvin, Peter Zijlstra, linux-next,
	linux-kernel, Heiko Carstens, Stefani Seibold

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

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

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


* 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

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

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

Hi all,

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

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

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

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

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


* 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

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

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

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

Hi all,

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

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

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

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

end of thread, back to index

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

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org linux-next@archiver.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/ public-inbox