linux-next: manual merge of the pidfd tree with the powerpc-fixes tree

4 messages, 3 authors, 2020-06-23 · open the first message on its own page

linux-next: manual merge of the pidfd tree with the powerpc-fixes tree

From: Stephen Rothwell <hidden>
Date: 2020-06-18 02:11:41

Hi all,

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

  arch/powerpc/kernel/syscalls/syscall.tbl

between commit:

  35e32a6cb5f6 ("powerpc/syscalls: Split SPU-ness out of ABI")

from the powerpc-fixes tree and commit:

  9b4feb630e8e ("arch: wire-up close_range()")

from the pidfd 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/powerpc/kernel/syscalls/syscall.tbl
index c0cdaacd770e,dd87a782d80e..000000000000
--- a/arch/powerpc/kernel/syscalls/syscall.tbl
+++ b/arch/powerpc/kernel/syscalls/syscall.tbl
@@@ -480,6 -524,8 +480,7 @@@
  434	common	pidfd_open			sys_pidfd_open
  435	32	clone3				ppc_clone3			sys_clone3
  435	64	clone3				sys_clone3
 -435	spu	clone3				sys_ni_syscall
+ 436	common	close_range			sys_close_range
  437	common	openat2				sys_openat2
  438	common	pidfd_getfd			sys_pidfd_getfd
  439	common	faccessat2			sys_faccessat2

Re: linux-next: manual merge of the pidfd tree with the powerpc-fixes tree

From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2020-06-19 11:17:06

Stephen Rothwell [off-list ref] writes:
Hi all,

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

  arch/powerpc/kernel/syscalls/syscall.tbl

between commit:

  35e32a6cb5f6 ("powerpc/syscalls: Split SPU-ness out of ABI")

from the powerpc-fixes tree and commit:

  9b4feb630e8e ("arch: wire-up close_range()")

from the pidfd 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.

I thought the week between rc1 and rc2 would be a safe time to do that
conversion of the syscall table, but I guess I was wrong :)

I'm planning to send those changes to Linus for rc2, so the conflict
will then be vs mainline. But I guess it's pretty trivial so it doesn't
really matter.

cheers
quoted hunk
diff --cc arch/powerpc/kernel/syscalls/syscall.tbl
index c0cdaacd770e,dd87a782d80e..000000000000
--- a/arch/powerpc/kernel/syscalls/syscall.tbl
+++ b/arch/powerpc/kernel/syscalls/syscall.tbl
@@@ -480,6 -524,8 +480,7 @@@
  434	common	pidfd_open			sys_pidfd_open
  435	32	clone3				ppc_clone3			sys_clone3
  435	64	clone3				sys_clone3
 -435	spu	clone3				sys_ni_syscall
+ 436	common	close_range			sys_close_range
  437	common	openat2				sys_openat2
  438	common	pidfd_getfd			sys_pidfd_getfd
  439	common	faccessat2			sys_faccessat2

Re: linux-next: manual merge of the pidfd tree with the powerpc-fixes tree

From: Christian Brauner <hidden>
Date: 2020-06-19 14:02:36

On Fri, Jun 19, 2020 at 09:17:30PM +1000, Michael Ellerman wrote:
Stephen Rothwell [off-list ref] writes:
quoted
Hi all,

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

  arch/powerpc/kernel/syscalls/syscall.tbl

between commit:

  35e32a6cb5f6 ("powerpc/syscalls: Split SPU-ness out of ABI")

from the powerpc-fixes tree and commit:

  9b4feb630e8e ("arch: wire-up close_range()")

from the pidfd 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.

I thought the week between rc1 and rc2 would be a safe time to do that
conversion of the syscall table, but I guess I was wrong :)
:)
I'm planning to send those changes to Linus for rc2, so the conflict
will then be vs mainline. But I guess it's pretty trivial so it doesn't
really matter.
close_range() is targeted for the v5.9 merge window. I always do
test-merges with mainline at the time I'm creating a pr and I'll just
mention to Linus that there's conflict with ppc. :)

Thanks!
Christian

Re: linux-next: manual merge of the pidfd tree with the powerpc-fixes tree

From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2020-06-23 11:42:22

Christian Brauner [off-list ref] writes:
On Fri, Jun 19, 2020 at 09:17:30PM +1000, Michael Ellerman wrote:
quoted
Stephen Rothwell [off-list ref] writes:
quoted
Hi all,

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

  arch/powerpc/kernel/syscalls/syscall.tbl

between commit:

  35e32a6cb5f6 ("powerpc/syscalls: Split SPU-ness out of ABI")

from the powerpc-fixes tree and commit:

  9b4feb630e8e ("arch: wire-up close_range()")

from the pidfd 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.
...
quoted
I'm planning to send those changes to Linus for rc2, so the conflict
will then be vs mainline. But I guess it's pretty trivial so it doesn't
really matter.
close_range() is targeted for the v5.9 merge window. I always do
test-merges with mainline at the time I'm creating a pr and I'll just
mention to Linus that there's conflict with ppc. :)
I ended up dropping the patch, so there shouldn't be a conflict anymore.

cheers
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help