linux-next: manual merge of the tip tree with the vfs tree

linux-next: manual merge of the tip tree with the vfs tree

[Stephen Rothwell]

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

Hi all,

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

  arch/x86/kernel/cpu/intel_rdt_rdtgroup.c

between commit:

  58e4e43911f8 ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")

from the vfs tree and commit:

  a3dbd01e6c9d ("x86/intel_rdt: Create character device exposing pseudo-locked region")

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/kernel/cpu/intel_rdt_rdtgroup.c
index 38a54f56ff40,7b4a09d81a30..000000000000
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@@ -1270,9 -1861,16 +1842,15 @@@ static int rdt_get_tree(struct fs_conte
  		rdtgroup_default.mon.mon_data_kn = kn_mondata;
  	}
  
+ 	ret = rdt_pseudo_lock_init();
+ 	if (ret) {
+ 		dentry = ERR_PTR(ret);
+ 		goto out_mondata;
+ 	}
+ 
 -	dentry = kernfs_mount(fs_type, flags, rdt_root,
 -			      RDTGROUP_SUPER_MAGIC, NULL);
 -	if (IS_ERR(dentry))
 +	ret = kernfs_get_tree(fc);
 +	if (ret < 0)
- 		goto out_mondata;
+ 		goto out_psl;
  
  	if (rdt_alloc_capable)
  		static_branch_enable_cpuslocked(&rdt_alloc_enable_key);

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

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

[Stephen Rothwell]

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

Hi all,

On Fri, 22 Jun 2018 11:53:46 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> diff --cc arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> index 38a54f56ff40,7b4a09d81a30..000000000000
> --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> @@@ -1270,9 -1861,16 +1842,15 @@@ static int rdt_get_tree(struct fs_conte
>   		rdtgroup_default.mon.mon_data_kn = kn_mondata;
>   	}
>   
> + 	ret = rdt_pseudo_lock_init();
> + 	if (ret) {
> + 		dentry = ERR_PTR(ret);

Actually I have removed the above line as well.

-- 
Cheers,
Stephen Rothwell

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

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

[Reinette Chatre]

All,

On 6/21/2018 6:53 PM, Stephen Rothwell wrote:
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> 
> between commit:
> 
>   58e4e43911f8 ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")
> 
> from the vfs tree and commit:
> 
>   a3dbd01e6c9d ("x86/intel_rdt: Create character device exposing pseudo-loc=
> ked region")
> 
> 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/kernel/cpu/intel_rdt_rdtgroup.c
> index 38a54f56ff40,7b4a09d81a30..000000000000
> --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> @@@ -1270,9 -1861,16 +1842,15 @@@ static int rdt_get_tree(struct fs_conte
>   		rdtgroup_default.mon.mon_data_kn = kn_mondata;
>   	}
>  
> + 	ret = rdt_pseudo_lock_init();
> + 	if (ret) {
> + 		dentry = ERR_PTR(ret);
> + 		goto out_mondata;
> + 	}
> +
>  -	dentry = kernfs_mount(fs_type, flags, rdt_root,
>  -			      RDTGROUP_SUPER_MAGIC, NULL);
>  -	if (IS_ERR(dentry))
>  +	ret = kernfs_get_tree(fc);
>  +	if (ret < 0)
> - 		goto out_mondata;
> + 		goto out_psl;
>  
>   	if (rdt_alloc_capable)
>   		static_branch_enable_cpuslocked(&rdt_alloc_enable_key);


>> + 	ret = rdt_pseudo_lock_init();
>> + 	if (ret) {
>> + 		dentry = ERR_PTR(ret);
>
> Actually I have removed the above line as well.

I am the contributor of the pseudo-locking related code that caused the
conflict.

Stephen, thank you very much for proceeding with the merge and fixing it
up. I copied your later fix addition to this email and combined they
look good. I did some basic smoke testing of the merged code and it works.

Thomas and David, please let me know what I can do from my side to help
with this.

As summary, with the above changes combined the merge can be done using:

->8-
diff --cc arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index 7b4a09d81a30,38a54f56ff40..caa2754f8948
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@@ -1861,16 -1270,9 +1842,13 @@@ static int rdt_get_tree(struct fs_conte
  		rdtgroup_default.mon.mon_data_kn = kn_mondata;
  	}

 +	ret = rdt_pseudo_lock_init();
- 	if (ret) {
- 		dentry = ERR_PTR(ret);
++	if (ret)
 +		goto out_mondata;
- 	}
 +
- 	dentry = kernfs_mount(fs_type, flags, rdt_root,
- 			      RDTGROUP_SUPER_MAGIC, NULL);
- 	if (IS_ERR(dentry))
+ 	ret = kernfs_get_tree(fc);
+ 	if (ret < 0)
 -		goto out_mondata;
 +		goto out_psl;

  	if (rdt_alloc_capable)
  		static_branch_enable_cpuslocked(&rdt_alloc_enable_key);

Reinette

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

[Thomas Gleixner]

On Thu, 21 Jun 2018, Reinette Chatre wrote:
> I am the contributor of the pseudo-locking related code that caused the
> conflict.
> 
> Stephen, thank you very much for proceeding with the merge and fixing it
> up. I copied your later fix addition to this email and combined they
> look good. I did some basic smoke testing of the merged code and it works.
> 
> Thomas and David, please let me know what I can do from my side to help
> with this.

I'll have a look later today.

> 
> As summary, with the above changes combined the merge can be done using:
> 
> ->8-
> diff --cc arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> index 7b4a09d81a30,38a54f56ff40..caa2754f8948
> --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> @@@ -1861,16 -1270,9 +1842,13 @@@ static int rdt_get_tree(struct fs_conte
>   		rdtgroup_default.mon.mon_data_kn = kn_mondata;
>   	}
> 
>  +	ret = rdt_pseudo_lock_init();
> - 	if (ret) {
> - 		dentry = ERR_PTR(ret);
> ++	if (ret)
>  +		goto out_mondata;
> - 	}
>  +
> - 	dentry = kernfs_mount(fs_type, flags, rdt_root,
> - 			      RDTGROUP_SUPER_MAGIC, NULL);
> - 	if (IS_ERR(dentry))
> + 	ret = kernfs_get_tree(fc);
> + 	if (ret < 0)
>  -		goto out_mondata;
>  +		goto out_psl;
> 
>   	if (rdt_alloc_capable)
>   		static_branch_enable_cpuslocked(&rdt_alloc_enable_key);
> 
> Reinette
> 
> 

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

[David Howells]

Reinette Chatre <reinette.chatre@intel.com> wrote:

> Thomas and David, please let me know what I can do from my side to help
> with this.

You could try basing on Al Viro's for-next tree which has the mount API
changes in it.  Sorry, I was hoping that this would go in the last merge
window, but I don't think Al has sufficient bandwidth available.

Note that it's likely to get rebased shortly as I have some patches to apply,
which given we're not at -rc2 yet, I'd like to roll into the original patches
to for bisectability reasons.

Also, Eric has some user_ns fixes that conflict with my procfs changes that he
wants to get upstream, though Linus said no - so I'm not sure what's going to
happen there.

David

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

[Al Viro]

On Fri, Jun 22, 2018 at 01:45:23PM +0100, David Howells wrote:
> Reinette Chatre <reinette.chatre@intel.com> wrote:
> 
> > Thomas and David, please let me know what I can do from my side to help
> > with this.
> 
> You could try basing on Al Viro's for-next tree which has the mount API
> changes in it.

Umm...  That would be a massive headache for everyone involved; the changes
in there have very little in common with what you are doing in rdt_mount(),
so it might make sense to start with a minimal never-rebased branch that
would
	* define rdt_pseudo_lock_init as 0
	* define rdt_pseudo_lock_release as empty
	* do the rdt_mount() part of a3dbd01e6c9d
	* have commit message along the lines of
"hooks in rdt_mount() for rdt_pseudo_lock to use

Functionally a no-op right now; the only reason for having that
as a never-rebased branch to get rdt_pseudo_lock and mount series
out of each other's hair"

Base that on -rc1, then pull it into your rdt branch and David could pull the
same into his.

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

[Thomas Gleixner]

On Fri, 22 Jun 2018, Al Viro wrote:
> On Fri, Jun 22, 2018 at 01:45:23PM +0100, David Howells wrote:
> > Reinette Chatre <reinette.chatre@intel.com> wrote:
> > 
> > > Thomas and David, please let me know what I can do from my side to help
> > > with this.
> > 
> > You could try basing on Al Viro's for-next tree which has the mount API
> > changes in it.
> 
> Umm...  That would be a massive headache for everyone involved; the changes
> in there have very little in common with what you are doing in rdt_mount(),
> so it might make sense to start with a minimal never-rebased branch that
> would
> 	* define rdt_pseudo_lock_init as 0
> 	* define rdt_pseudo_lock_release as empty
> 	* do the rdt_mount() part of a3dbd01e6c9d
> 	* have commit message along the lines of
> "hooks in rdt_mount() for rdt_pseudo_lock to use
> 
> Functionally a no-op right now; the only reason for having that
> as a never-rebased branch to get rdt_pseudo_lock and mount series
> out of each other's hair"
> 
> Base that on -rc1, then pull it into your rdt branch and David could pull the
> same into his.

Yes, that works.

Reinette, can you please look into creating that ordering. Then we just zap
the existing branch and redo it with this scheme.

Thanks,

	tglx

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

[Reinette Chatre]

Hi Thomas,

On 6/22/2018 6:39 AM, Thomas Gleixner wrote:
> On Fri, 22 Jun 2018, Al Viro wrote:
>> On Fri, Jun 22, 2018 at 01:45:23PM +0100, David Howells wrote:
>>> Reinette Chatre <reinette.chatre@intel.com> wrote:
>>>
>>>> Thomas and David, please let me know what I can do from my side to help
>>>> with this.
>>>
>>> You could try basing on Al Viro's for-next tree which has the mount API
>>> changes in it.
>>
>> Umm...  That would be a massive headache for everyone involved; the changes
>> in there have very little in common with what you are doing in rdt_mount(),
>> so it might make sense to start with a minimal never-rebased branch that
>> would
>> 	* define rdt_pseudo_lock_init as 0
>> 	* define rdt_pseudo_lock_release as empty
>> 	* do the rdt_mount() part of a3dbd01e6c9d
>> 	* have commit message along the lines of
>> "hooks in rdt_mount() for rdt_pseudo_lock to use
>>
>> Functionally a no-op right now; the only reason for having that
>> as a never-rebased branch to get rdt_pseudo_lock and mount series
>> out of each other's hair"
>>
>> Base that on -rc1, then pull it into your rdt branch and David could pull the
>> same into his.
> 
> Yes, that works.
> 
> Reinette, can you please look into creating that ordering. Then we just zap
> the existing branch and redo it with this scheme.

Will do. How would you prefer to consume this to make the branches
simple to create? Is it ok if I create a new patch series with Al's
suggestion above as the first commit?

The original pseudo-locking patch series consisted out of two sections
with the pseudo-locking specific parts starting in the middle. If I
create a new series with the above change then it will not be cleanly
separate anymore. Is that ok?

Reinette

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

[Thomas Gleixner]

On Fri, 22 Jun 2018, Reinette Chatre wrote:
> On 6/22/2018 6:39 AM, Thomas Gleixner wrote:
> > On Fri, 22 Jun 2018, Al Viro wrote:
> >> On Fri, Jun 22, 2018 at 01:45:23PM +0100, David Howells wrote:
> >>> Reinette Chatre <reinette.chatre@intel.com> wrote:
> >>>
> >>>> Thomas and David, please let me know what I can do from my side to help
> >>>> with this.
> >>>
> >>> You could try basing on Al Viro's for-next tree which has the mount API
> >>> changes in it.
> >>
> >> Umm...  That would be a massive headache for everyone involved; the changes
> >> in there have very little in common with what you are doing in rdt_mount(),
> >> so it might make sense to start with a minimal never-rebased branch that
> >> would
> >> 	* define rdt_pseudo_lock_init as 0
> >> 	* define rdt_pseudo_lock_release as empty
> >> 	* do the rdt_mount() part of a3dbd01e6c9d
> >> 	* have commit message along the lines of
> >> "hooks in rdt_mount() for rdt_pseudo_lock to use
> >>
> >> Functionally a no-op right now; the only reason for having that
> >> as a never-rebased branch to get rdt_pseudo_lock and mount series
> >> out of each other's hair"
> >>
> >> Base that on -rc1, then pull it into your rdt branch and David could pull the
> >> same into his.
> > 
> > Yes, that works.
> > 
> > Reinette, can you please look into creating that ordering. Then we just zap
> > the existing branch and redo it with this scheme.
> 
> Will do. How would you prefer to consume this to make the branches
> simple to create? Is it ok if I create a new patch series with Al's
> suggestion above as the first commit?
> 
> The original pseudo-locking patch series consisted out of two sections
> with the pseudo-locking specific parts starting in the middle. If I
> create a new series with the above change then it will not be cleanly
> separate anymore. Is that ok?

That's fine. Just mention it clearly in the changelog of that first one or
two patches you need for that.

Thanks,

	tglx

linux-next: manual merge of the tip tree with the vfs tree

[Stephen Rothwell]

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

Hi all,

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

  arch/Kconfig

between commit:

  139d7deeea00 ("[elfcore-compat][amd64] clean PRSTATUS_SIZE/SET_PR_FPVALID up properly")

from the vfs tree and commit:

  2ca408d9c749 ("fanotify: Fix sys_fanotify_mark() on native x86-32")

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/Kconfig
index a17ced73b23c,24862d15f3a3..000000000000
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@@ -1105,9 -1105,12 +1105,15 @@@ config HAVE_ARCH_PFN_VALI
  config ARCH_SUPPORTS_DEBUG_PAGEALLOC
  	bool
  
 +config ARCH_HAS_ELFCORE_COMPAT
 +	bool
 +
+ config ARCH_SPLIT_ARG64
+ 	bool
+ 	help
+ 	   If a 32-bit architecture requires 64-bit arguments to be split into
+ 	   pairs of 32-bit arguments, select this option.
+ 
  source "kernel/gcov/Kconfig"
  
  source "scripts/gcc-plugins/Kconfig"

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

linux-next: manual merge of the tip tree with the vfs tree

[Stephen Rothwell]

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

Hi all,

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

  arch/ia64/Kconfig
  arch/s390/Kconfig

between commit:

  5e6e9852d6f7 ("uaccess: add infrastructure for kernel builds with set_fs()")

from the vfs tree and commit:

  077ee78e3928 ("PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable")
  981aa1d366bf ("PCI: MSI: Fix Kconfig dependencies for PCI_MSI_ARCH_FALLBACKS")

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/ia64/Kconfig
index 3414e67229b3,9d0f1e13c918..000000000000
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@@ -55,7 -56,7 +55,8 @@@ config IA6
  	select NEED_DMA_MAP_STATE
  	select NEED_SG_DMA_LENGTH
  	select NUMA if !FLATMEM
+ 	select PCI_MSI_ARCH_FALLBACKS if PCI_MSI
 +	select SET_FS
  	default y
  	help
  	  The Itanium Processor Family is Intel's 64-bit successor to
diff --cc arch/s390/Kconfig
index dde501bc6304,0a3899386a51..000000000000
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@@ -190,7 -185,7 +190,8 @@@ config S39
  	select OLD_SIGSUSPEND3
  	select PCI_DOMAINS		if PCI
  	select PCI_MSI			if PCI
+ 	select PCI_MSI_ARCH_FALLBACKS	if PCI_MSI
 +	select SET_FS
  	select SPARSE_IRQ
  	select SYSCTL_EXCEPTION_TRACE
  	select THREAD_INFO_IN_TASK

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

linux-next: manual merge of the tip tree with the vfs tree

[Stephen Rothwell]

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

Hi all,

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

  arch/ia64/Kconfig
  arch/s390/Kconfig

between commit:

  5e6e9852d6f7 ("uaccess: add infrastructure for kernel builds with set_fs()")

from the vfs tree and commit:

  077ee78e3928 ("PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable")

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/ia64/Kconfig
index 3414e67229b3,7ff5b3bbf160..000000000000
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@@ -55,7 -56,7 +55,8 @@@ config IA6
  	select NEED_DMA_MAP_STATE
  	select NEED_SG_DMA_LENGTH
  	select NUMA if !FLATMEM
+ 	select PCI_MSI_ARCH_FALLBACKS
 +	select SET_FS
  	default y
  	help
  	  The Itanium Processor Family is Intel's 64-bit successor to
diff --cc arch/s390/Kconfig
index dde501bc6304,63dd5a0aa252..000000000000
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@@ -190,7 -185,7 +190,8 @@@ config S39
  	select OLD_SIGSUSPEND3
  	select PCI_DOMAINS		if PCI
  	select PCI_MSI			if PCI
+ 	select PCI_MSI_ARCH_FALLBACKS
 +	select SET_FS
  	select SPARSE_IRQ
  	select SYSCTL_EXCEPTION_TRACE
  	select THREAD_INFO_IN_TASK

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

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

[Stephen Rothwell]

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

Hi all,

On Mon, 27 Jul 2020 15:35:10 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/x86/include/asm/fpu/xstate.h
> 
> between commit:
> 
>   c196049cc732 ("x86: switch to ->regset_get()")
> 
> from the vfs tree and commit:
> 
>   ce711ea3cab9 ("perf/x86/intel/lbr: Support XSAVES/XRSTORS for LBR context switch")
> 
> 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.
> 
> diff --cc arch/x86/include/asm/fpu/xstate.h
> index f691ea1bc086,1559554af931..000000000000
> --- a/arch/x86/include/asm/fpu/xstate.h
> +++ b/arch/x86/include/asm/fpu/xstate.h
> @@@ -71,8 -103,9 +103,9 @@@ extern void __init update_regset_xstate
>   void *get_xsave_addr(struct xregs_state *xsave, int xfeature_nr);
>   const void *get_xsave_field_ptr(int xfeature_nr);
>   int using_compacted_format(void);
> + int xfeature_size(int xfeature_nr);
>  -int copy_xstate_to_kernel(void *kbuf, struct xregs_state *xsave, unsigned int offset, unsigned int size);
>  -int copy_xstate_to_user(void __user *ubuf, struct xregs_state *xsave, unsigned int offset, unsigned int size);
>  +struct membuf;
>  +void copy_xstate_to_kernel(struct membuf to, struct xregs_state *xsave);
>   int copy_kernel_to_xstate(struct xregs_state *xsave, const void *kbuf);
>   int copy_user_to_xstate(struct xregs_state *xsave, const void __user *ubuf);
>   void copy_supervisor_to_kernel(struct xregs_state *xsave);

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

-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the tip tree with the vfs tree

[Stephen Rothwell]

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

Hi all,

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

  arch/x86/include/asm/fpu/xstate.h

between commit:

  c196049cc732 ("x86: switch to ->regset_get()")

from the vfs tree and commit:

  ce711ea3cab9 ("perf/x86/intel/lbr: Support XSAVES/XRSTORS for LBR context switch")

from the tip tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/fpu/xstate.h
index f691ea1bc086,1559554af931..000000000000
--- a/arch/x86/include/asm/fpu/xstate.h
+++ b/arch/x86/include/asm/fpu/xstate.h
@@@ -71,8 -103,9 +103,9 @@@ extern void __init update_regset_xstate
  void *get_xsave_addr(struct xregs_state *xsave, int xfeature_nr);
  const void *get_xsave_field_ptr(int xfeature_nr);
  int using_compacted_format(void);
+ int xfeature_size(int xfeature_nr);
 -int copy_xstate_to_kernel(void *kbuf, struct xregs_state *xsave, unsigned int offset, unsigned int size);
 -int copy_xstate_to_user(void __user *ubuf, struct xregs_state *xsave, unsigned int offset, unsigned int size);
 +struct membuf;
 +void copy_xstate_to_kernel(struct membuf to, struct xregs_state *xsave);
  int copy_kernel_to_xstate(struct xregs_state *xsave, const void *kbuf);
  int copy_user_to_xstate(struct xregs_state *xsave, const void __user *ubuf);
  void copy_supervisor_to_kernel(struct xregs_state *xsave);

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

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

[Stephen Rothwell]

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

Hi all,

On Mon, 26 Nov 2018 15:39:25 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/x86/kernel/cpu/resctrl/rdtgroup.c
> 
> between commit:
> 
>   16ec1a5d58ea ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")
> (where the file is arch/x86/kernel/cpu/intel_rdt_rdtgroup.c)
> 
> from the vfs tree and commit:
> 
>   580ebb66cbb3 ("x86/resctrl: Add vendor check for the MBA software controller")
> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 37c0ccb50823,61b102dd51a5..000000000000
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@@ -2032,88 -2065,8 +2032,91 @@@ out
>   	rdt_last_cmd_clear();
>   	mutex_unlock(&rdtgroup_mutex);
>   	cpus_read_unlock();
>  +	return ret;
>  +}
>  +
>  +enum rdt_param {
>  +	Opt_cdp,
>  +	Opt_cdpl2,
>  +	Opt_mba_mpbs,
>  +	nr__rdt_params
>  +};
>   
>  -	return dentry;
>  +static const struct fs_parameter_spec rdt_param_specs[nr__rdt_params] = {
>  +	[Opt_cdp]	= { fs_param_is_flag },
>  +	[Opt_cdpl2]	= { fs_param_is_flag },
>  +	[Opt_mba_mpbs]	= { fs_param_is_flag },
>  +};
>  +
>  +static const char *const rdt_param_keys[nr__rdt_params] = {
>  +	[Opt_cdp]	= "cdp",
>  +	[Opt_cdpl2]	= "cdpl2",
>  +	[Opt_mba_mpbs]	= "mba_mbps",
>  +};
>  +
>  +static const struct fs_parameter_description rdt_fs_parameters = {
>  +	.name		= "rdt",
>  +	.nr_params	= nr__rdt_params,
>  +	.keys		= rdt_param_keys,
>  +	.specs		= rdt_param_specs,
>  +	.no_source	= true,
>  +};
>  +
>  +static int rdt_parse_param(struct fs_context *fc, struct fs_parameter *param)
>  +{
>  +	struct rdt_fs_context *ctx = rdt_fc2context(fc);
>  +	struct fs_parse_result result;
>  +	int opt;
>  +
>  +	opt = fs_parse(fc, &rdt_fs_parameters, param, &result);
>  +	if (opt < 0)
>  +		return opt;
>  +
>  +	switch (opt) {
>  +	case Opt_cdp:
>  +		ctx->enable_cdpl3 = true;
>  +		return 0;
>  +	case Opt_cdpl2:
>  +		ctx->enable_cdpl2 = true;
>  +		return 0;
>  +	case Opt_mba_mpbs:
> - 		ctx->enable_mba_mbps = true;
> - 		return 0;
> ++		if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
> ++			ctx->enable_mba_mbps = true;
> ++			return 0;
> ++		}
> ++		break;
>  +	}
>  +
>  +	return -EINVAL;
>  +}
>  +
>  +static void rdt_fs_context_free(struct fs_context *fc)
>  +{
>  +	struct rdt_fs_context *ctx = rdt_fc2context(fc);
>  +
>  +	kernfs_free_fs_context(fc);
>  +	kfree(ctx);
>  +}
>  +
>  +static const struct fs_context_operations rdt_fs_context_ops = {
>  +	.free		= rdt_fs_context_free,
>  +	.parse_param	= rdt_parse_param,
>  +	.get_tree	= rdt_get_tree,
>  +};
>  +
>  +static int rdt_init_fs_context(struct fs_context *fc, struct dentry *reference)
>  +{
>  +	struct rdt_fs_context *ctx;
>  +
>  +	ctx = kzalloc(sizeof(struct rdt_fs_context), GFP_KERNEL);
>  +	if (!ctx)
>  +		return -ENOMEM;
>  +
>  +	ctx->kfc.root = rdt_root;
>  +	ctx->kfc.magic = RDTGROUP_SUPER_MAGIC;
>  +	fc->fs_private = &ctx->kfc;
>  +	fc->ops = &rdt_fs_context_ops;
>  +	return 0;
>   }
>   
>   static int reset_all_ctrls(struct rdt_resource *r)

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

-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the tip tree with the vfs tree

[Stephen Rothwell]

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

Hi all,

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

  arch/x86/kernel/cpu/resctrl/rdtgroup.c

between commit:

  16ec1a5d58ea ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")
(where the file is arch/x86/kernel/cpu/intel_rdt_rdtgroup.c)

from the vfs tree and commit:

  580ebb66cbb3 ("x86/resctrl: Add vendor check for the MBA software controller")

from the tip tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kernel/cpu/resctrl/rdtgroup.c
index 37c0ccb50823,61b102dd51a5..000000000000
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@@ -2032,88 -2065,8 +2032,91 @@@ out
  	rdt_last_cmd_clear();
  	mutex_unlock(&rdtgroup_mutex);
  	cpus_read_unlock();
 +	return ret;
 +}
 +
 +enum rdt_param {
 +	Opt_cdp,
 +	Opt_cdpl2,
 +	Opt_mba_mpbs,
 +	nr__rdt_params
 +};
  
 -	return dentry;
 +static const struct fs_parameter_spec rdt_param_specs[nr__rdt_params] = {
 +	[Opt_cdp]	= { fs_param_is_flag },
 +	[Opt_cdpl2]	= { fs_param_is_flag },
 +	[Opt_mba_mpbs]	= { fs_param_is_flag },
 +};
 +
 +static const char *const rdt_param_keys[nr__rdt_params] = {
 +	[Opt_cdp]	= "cdp",
 +	[Opt_cdpl2]	= "cdpl2",
 +	[Opt_mba_mpbs]	= "mba_mbps",
 +};
 +
 +static const struct fs_parameter_description rdt_fs_parameters = {
 +	.name		= "rdt",
 +	.nr_params	= nr__rdt_params,
 +	.keys		= rdt_param_keys,
 +	.specs		= rdt_param_specs,
 +	.no_source	= true,
 +};
 +
 +static int rdt_parse_param(struct fs_context *fc, struct fs_parameter *param)
 +{
 +	struct rdt_fs_context *ctx = rdt_fc2context(fc);
 +	struct fs_parse_result result;
 +	int opt;
 +
 +	opt = fs_parse(fc, &rdt_fs_parameters, param, &result);
 +	if (opt < 0)
 +		return opt;
 +
 +	switch (opt) {
 +	case Opt_cdp:
 +		ctx->enable_cdpl3 = true;
 +		return 0;
 +	case Opt_cdpl2:
 +		ctx->enable_cdpl2 = true;
 +		return 0;
 +	case Opt_mba_mpbs:
- 		ctx->enable_mba_mbps = true;
- 		return 0;
++		if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
++			ctx->enable_mba_mbps = true;
++			return 0;
++		}
++		break;
 +	}
 +
 +	return -EINVAL;
 +}
 +
 +static void rdt_fs_context_free(struct fs_context *fc)
 +{
 +	struct rdt_fs_context *ctx = rdt_fc2context(fc);
 +
 +	kernfs_free_fs_context(fc);
 +	kfree(ctx);
 +}
 +
 +static const struct fs_context_operations rdt_fs_context_ops = {
 +	.free		= rdt_fs_context_free,
 +	.parse_param	= rdt_parse_param,
 +	.get_tree	= rdt_get_tree,
 +};
 +
 +static int rdt_init_fs_context(struct fs_context *fc, struct dentry *reference)
 +{
 +	struct rdt_fs_context *ctx;
 +
 +	ctx = kzalloc(sizeof(struct rdt_fs_context), GFP_KERNEL);
 +	if (!ctx)
 +		return -ENOMEM;
 +
 +	ctx->kfc.root = rdt_root;
 +	ctx->kfc.magic = RDTGROUP_SUPER_MAGIC;
 +	fc->fs_private = &ctx->kfc;
 +	fc->ops = &rdt_fs_context_ops;
 +	return 0;
  }
  
  static int reset_all_ctrls(struct rdt_resource *r)

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

linux-next: manual merge of the tip tree with the vfs tree

[Stephen Rothwell]

Hi all,

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

  arch/x86/mm/fault.c

between commit:

  df720ac12fc7 ("exceptions: detritus removal")

from the vfs tree and commit:

  744c193eb9a2 ("x86: Migrate exception table users off module.h and onto extable.h")

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/fault.c
index c0413d5541af,4dc13340653e..000000000000
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@@ -5,7 -5,7 +5,7 @@@
   */
  #include <linux/sched.h>		/* test_thread_flag(), ...	*/
  #include <linux/kdebug.h>		/* oops_begin/end, ...		*/
- #include <linux/module.h>		/* search_exception_tables	*/
 -#include <linux/extable.h>		/* search_exception_table	*/
++#include <linux/extable.h>		/* search_exception_tables	*/
  #include <linux/bootmem.h>		/* max_low_pfn			*/
  #include <linux/kprobes.h>		/* NOKPROBE_SYMBOL, ...		*/
  #include <linux/mmiotrace.h>		/* kmmio_handler, ...		*/

linux-next: manual merge of the tip tree with the vfs tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in kernel/fork.c
between commit 7ab538da1f8a ("trim task_work: get rid of hlist") from the
vfs tree and commit 0ea86208345b ("sched, mm: Rework sched_{fork,exec}
node assignment") 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 kernel/fork.c
index bebabad,1a69745..0000000
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@@ -1414,8 -1415,7 +1415,7 @@@ static struct task_struct *copy_process
  	 * We dont wake it up yet.
  	 */
  	p->group_leader = p;
- 	INIT_LIST_HEAD(&p->thread_group);
 -	INIT_HLIST_HEAD(&p->task_works);
 +	p->task_works = NULL;
  
  	/* Now that the task is set up, run cgroup callbacks if
  	 * necessary. We need to run them before the task is visible

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

linux-next: manual merge of the tip tree with the vfs tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/ia32/ia32entry.S, arch/x86/include/asm/unistd_32.h,
arch/x86/include/asm/unistd_64.h and arch/x86/kernel/syscall_table_32.S
between commits 349f36689b3c ("x86: Add new syscalls for x86_32") and
204a06adf8cb ("x86: Add new syscalls for x86_64") from the vfs tree and
commit ce26efdefa5e ("x86: Add clock_adjtime for x86") from the tip tree.

Just overlapping additions of syscalls.  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/ia32/ia32entry.S
index 98d353e,9dc128f..0000000
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@@ -851,6 -844,5 +844,7 @@@ ia32_sys_call_table
  	.quad sys_fanotify_init
  	.quad sys32_fanotify_mark
  	.quad sys_prlimit64		/* 340 */
 +	.quad sys_name_to_handle_at
 +	.quad compat_sys_open_by_handle_at
+ 	.quad compat_sys_clock_adjtime
  ia32_syscall_end:
diff --cc arch/x86/include/asm/unistd_32.h
index f4c4973,b6f73f1..0000000
--- a/arch/x86/include/asm/unistd_32.h
+++ b/arch/x86/include/asm/unistd_32.h
@@@ -346,12 -346,11 +346,13 @@@
  #define __NR_fanotify_init	338
  #define __NR_fanotify_mark	339
  #define __NR_prlimit64		340
 -#define __NR_clock_adjtime	341
 +#define __NR_name_to_handle_at	341
 +#define __NR_open_by_handle_at  342
++#define __NR_clock_adjtime	343
  
  #ifdef __KERNEL__
  
- #define NR_syscalls 343
 -#define NR_syscalls 342
++#define NR_syscalls 344
  
  #define __ARCH_WANT_IPC_PARSE_VERSION
  #define __ARCH_WANT_OLD_READDIR
diff --cc arch/x86/include/asm/unistd_64.h
index 81a3d5b,5ee3085..0000000
--- a/arch/x86/include/asm/unistd_64.h
+++ b/arch/x86/include/asm/unistd_64.h
@@@ -669,10 -669,8 +669,12 @@@ __SYSCALL(__NR_fanotify_init, sys_fanot
  __SYSCALL(__NR_fanotify_mark, sys_fanotify_mark)
  #define __NR_prlimit64				302
  __SYSCALL(__NR_prlimit64, sys_prlimit64)
 -#define __NR_clock_adjtime			303
 +#define __NR_name_to_handle_at			303
 +__SYSCALL(__NR_name_to_handle_at, sys_name_to_handle_at)
 +#define __NR_open_by_handle_at			304
 +__SYSCALL(__NR_open_by_handle_at, sys_open_by_handle_at)
++#define __NR_clock_adjtime			305
+ __SYSCALL(__NR_clock_adjtime, sys_clock_adjtime)
  
  #ifndef __NO_STUBS
  #define __ARCH_WANT_OLD_READDIR
diff --cc arch/x86/kernel/syscall_table_32.S
index c314b21,68c7b9a..0000000
--- a/arch/x86/kernel/syscall_table_32.S
+++ b/arch/x86/kernel/syscall_table_32.S
@@@ -340,5 -340,4 +340,6 @@@ ENTRY(sys_call_table
  	.long sys_fanotify_init
  	.long sys_fanotify_mark
  	.long sys_prlimit64		/* 340 */
 +	.long sys_name_to_handle_at
 +	.long sys_open_by_handle_at
+ 	.long sys_clock_adjtime