linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the akpm-current tree with the arm tree
@ 2015-07-16  4:50 Stephen Rothwell
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen Rothwell @ 2015-07-16  4:50 UTC (permalink / raw)
  To: Andrew Morton, Russell King
  Cc: linux-next, linux-kernel, Will Deacon, Laurent Dufour

Hi Andrew,

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

  arch/arm/include/asm/Kbuild

between commit:

  57853e8906a0 ("ARM: 8403/1: kbuild: don't use generic mcs_spinlock.h header")

from the arm tree and commit:

  74cf1a5a0c64 ("mm: clean up per architecture MM hook header files")

from the akpm-current 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/arm/include/asm/Kbuild
index 517ef6dd22b9,30b3bc1666d2..000000000000
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@@ -12,6 -12,8 +12,7 @@@ generic-y += irq_regs.
  generic-y += kdebug.h
  generic-y += local.h
  generic-y += local64.h
 -generic-y += mcs_spinlock.h
+ generic-y += mm-arch-hooks.h
  generic-y += msgbuf.h
  generic-y += param.h
  generic-y += parport.h

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

* Re: linux-next: manual merge of the akpm-current tree with the arm tree
  2021-08-24  9:10 Stephen Rothwell
@ 2021-09-06  4:46 ` Stephen Rothwell
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen Rothwell @ 2021-09-06  4:46 UTC (permalink / raw)
  To: Russell King
  Cc: Andrew Morton, Arnd Bergmann, Linux Kernel Mailing List,
	Linux Next Mailing List, Russell King (Oracle),
	Vasily Averin

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

Hi all,

On Tue, 24 Aug 2021 19:10:39 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   ipc/sem.c
> 
> between commit:
> 
>   bdec0145286f ("ARM: 9114/1: oabi-compat: rework sys_semtimedop emulation")
> 
> from the arm tree and commit:
> 
>   7a4207f02a96 ("memcg: enable accounting of ipc resources")
> 
> from the akpm-current 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.
> 
> diff --cc ipc/sem.c
> index ae8d9104b0a0,1a8b9f0ac047..000000000000
> --- a/ipc/sem.c
> +++ b/ipc/sem.c
> @@@ -2216,40 -2229,9 +2216,40 @@@ long __do_semtimedop(int semid, struct 
>   
>   	unlink_queue(sma, &queue);
>   
>  -out_unlock_free:
>  +out_unlock:
>   	sem_unlock(sma, locknum);
>   	rcu_read_unlock();
>  +out:
>  +	return error;
>  +}
>  +
>  +static long do_semtimedop(int semid, struct sembuf __user *tsops,
>  +		unsigned nsops, const struct timespec64 *timeout)
>  +{
>  +	struct sembuf fast_sops[SEMOPM_FAST];
>  +	struct sembuf *sops = fast_sops;
>  +	struct ipc_namespace *ns;
>  +	int ret;
>  +
>  +	ns = current->nsproxy->ipc_ns;
>  +	if (nsops > ns->sc_semopm)
>  +		return -E2BIG;
>  +	if (nsops < 1)
>  +		return -EINVAL;
>  +
>  +	if (nsops > SEMOPM_FAST) {
> - 		sops = kvmalloc_array(nsops, sizeof(*sops), GFP_KERNEL);
> ++		sops = kvmalloc_array(nsops, sizeof(*sops), GFP_KERNEL_ACCOUNT);
>  +		if (sops == NULL)
>  +			return -ENOMEM;
>  +	}
>  +
>  +	if (copy_from_user(sops, tsops, nsops * sizeof(*tsops))) {
>  +		ret =  -EFAULT;
>  +		goto out_free;
>  +	}
>  +
>  +	ret = __do_semtimedop(semid, sops, nsops, timeout, ns);
>  +
>   out_free:
>   	if (sops != fast_sops)
>   		kvfree(sops);

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

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: manual merge of the akpm-current tree with the arm tree
@ 2021-08-24  9:10 Stephen Rothwell
  2021-09-06  4:46 ` Stephen Rothwell
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Rothwell @ 2021-08-24  9:10 UTC (permalink / raw)
  To: Andrew Morton, Russell King
  Cc: Arnd Bergmann, Linux Kernel Mailing List,
	Linux Next Mailing List, Russell King (Oracle),
	Vasily Averin

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

Hi all,

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

  ipc/sem.c

between commit:

  bdec0145286f ("ARM: 9114/1: oabi-compat: rework sys_semtimedop emulation")

from the arm tree and commit:

  7a4207f02a96 ("memcg: enable accounting of ipc resources")

from the akpm-current 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 ipc/sem.c
index ae8d9104b0a0,1a8b9f0ac047..000000000000
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@@ -2216,40 -2229,9 +2216,40 @@@ long __do_semtimedop(int semid, struct 
  
  	unlink_queue(sma, &queue);
  
 -out_unlock_free:
 +out_unlock:
  	sem_unlock(sma, locknum);
  	rcu_read_unlock();
 +out:
 +	return error;
 +}
 +
 +static long do_semtimedop(int semid, struct sembuf __user *tsops,
 +		unsigned nsops, const struct timespec64 *timeout)
 +{
 +	struct sembuf fast_sops[SEMOPM_FAST];
 +	struct sembuf *sops = fast_sops;
 +	struct ipc_namespace *ns;
 +	int ret;
 +
 +	ns = current->nsproxy->ipc_ns;
 +	if (nsops > ns->sc_semopm)
 +		return -E2BIG;
 +	if (nsops < 1)
 +		return -EINVAL;
 +
 +	if (nsops > SEMOPM_FAST) {
- 		sops = kvmalloc_array(nsops, sizeof(*sops), GFP_KERNEL);
++		sops = kvmalloc_array(nsops, sizeof(*sops), GFP_KERNEL_ACCOUNT);
 +		if (sops == NULL)
 +			return -ENOMEM;
 +	}
 +
 +	if (copy_from_user(sops, tsops, nsops * sizeof(*tsops))) {
 +		ret =  -EFAULT;
 +		goto out_free;
 +	}
 +
 +	ret = __do_semtimedop(semid, sops, nsops, timeout, ns);
 +
  out_free:
  	if (sops != fast_sops)
  		kvfree(sops);

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

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

* linux-next: manual merge of the akpm-current tree with the arm tree
@ 2016-07-15  8:38 Stephen Rothwell
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen Rothwell @ 2016-07-15  8:38 UTC (permalink / raw)
  To: Andrew Morton, Russell King
  Cc: linux-next, linux-kernel, Krzysztof Kozlowski, Gregory CLEMENT

Hi Andrew,

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

  arch/arm/mm/dma-mapping.c

between commit:

  f12708965069 ("ARM: 8561/3: dma-mapping: Don't use outer_flush_range when the L2C is coherent")

from the arm tree and patch:

   "dma-mapping: remove dma_get_attr"

from the akpm-current 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/arm/mm/dma-mapping.c
index 40d3a9be7832,43e03b5293d0..000000000000
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@@ -763,8 -744,7 +763,8 @@@ static void *__dma_alloc(struct device 
  		.gfp = gfp,
  		.prot = prot,
  		.caller = caller,
- 		.want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs),
+ 		.want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0),
 +		.coherent_flag = is_coherent ? COHERENT : NORMAL,
  	};
  
  #ifdef CONFIG_DMA_API_DEBUG

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

* linux-next: manual merge of the akpm-current tree with the arm tree
@ 2015-12-07  8:00 Stephen Rothwell
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen Rothwell @ 2015-12-07  8:00 UTC (permalink / raw)
  To: Andrew Morton, Russell King
  Cc: linux-next, linux-kernel, Arnd Bergmann, Daniel Cashman

Hi Andrew,

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

  arch/arm/Kconfig

between commit:

  437682eeab45 ("ARM: 8456/1: code patching only works on MMU")

from the arm tree and commits:

  47fb802e4fcd ("arm: mm: support ARCH_MMAP_RND_BITS")
  8100fa068b27 ("ARM: avoid ARCH_MMAP_RND_BITS for NOMMU")

from the akpm-current 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/arm/Kconfig
index 752775aab3ae,536a8e477a96..000000000000
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -33,8 -33,9 +33,9 @@@ config AR
  	select HARDIRQS_SW_RESEND
  	select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
  	select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
 -	select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32
 -	select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32
 +	select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
 +	select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
+ 	select HAVE_ARCH_MMAP_RND_BITS if MMU
  	select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT)
  	select HAVE_ARCH_TRACEHOOK
  	select HAVE_BPF_JIT

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

* linux-next: manual merge of the akpm-current tree with the arm tree
@ 2014-06-02  8:42 Stephen Rothwell
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen Rothwell @ 2014-06-02  8:42 UTC (permalink / raw)
  To: Andrew Morton, Russell King
  Cc: linux-next, linux-kernel, Will Deacon, Laura Abbott

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
arch/arm/include/asm/Kbuild between commit 8a87411b649c ("ARM: 8047/1:
rwsem: use asm-generic rwsem implementation") from the arm tree and
commit bca74b3faf68 ("lib/scatterlist: make ARCH_HAS_SG_CHAIN an actual
Kconfig") from the akpm-current 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/arm/include/asm/Kbuild
index f5a357601983,2d95820276fd..000000000000
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@@ -21,7 -21,7 +21,8 @@@ generic-y += parport.
  generic-y += poll.h
  generic-y += preempt.h
  generic-y += resource.h
 +generic-y += rwsem.h
+ generic-y += scatterlist.h
  generic-y += sections.h
  generic-y += segment.h
  generic-y += sembuf.h

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

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

* Re: linux-next: manual merge of the akpm-current tree with the arm tree
  2014-04-24  5:25 Stephen Rothwell
@ 2014-04-24 14:27 ` Mark Salter
  0 siblings, 0 replies; 8+ messages in thread
From: Mark Salter @ 2014-04-24 14:27 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Russell King, linux-next, linux-kernel, Liu Hua

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

On Thu, 2014-04-24 at 15:25 +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in
> arch/arm/include/asm/fixmap.h between commits 4221e2e6b316 ("ARM: 8031/1:
> fixmap: remove FIX_KMAP_BEGIN and FIX_KMAP_END") and a05e54c103b0 ("ARM:
> 8031/2: change fixmap mapping region to support 32 CPUs") from the arm
> tree and commit a665f864487d ("arm: use generic fixmap.h") from the
> akpm-current tree.
> 
> I fixed it up (I have just dropped the akpm-current tree patch for now)
> and can carry the fix as necessary (no action is required).

I'm okay with just dropping it from Andrew's tree. We never got an ack
for it. Now that the generic fixmap and early_ioremap patches are in
Linus' tree, it would probably be best to fold the arm fixmap change
into a new patch set adding early_ioremap to arm.

--Mark


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: manual merge of the akpm-current tree with the arm tree
@ 2014-04-24  5:25 Stephen Rothwell
  2014-04-24 14:27 ` Mark Salter
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Rothwell @ 2014-04-24  5:25 UTC (permalink / raw)
  To: Andrew Morton, Russell King
  Cc: linux-next, linux-kernel, Mark Salter, Liu Hua

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
arch/arm/include/asm/fixmap.h between commits 4221e2e6b316 ("ARM: 8031/1:
fixmap: remove FIX_KMAP_BEGIN and FIX_KMAP_END") and a05e54c103b0 ("ARM:
8031/2: change fixmap mapping region to support 32 CPUs") from the arm
tree and commit a665f864487d ("arm: use generic fixmap.h") from the
akpm-current tree.

I fixed it up (I have just dropped the akpm-current tree patch for now)
and can carry the fix as necessary (no action is required).

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

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

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

end of thread, other threads:[~2021-09-06  4:46 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-16  4:50 linux-next: manual merge of the akpm-current tree with the arm tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2021-08-24  9:10 Stephen Rothwell
2021-09-06  4:46 ` Stephen Rothwell
2016-07-15  8:38 Stephen Rothwell
2015-12-07  8:00 Stephen Rothwell
2014-06-02  8:42 Stephen Rothwell
2014-04-24  5:25 Stephen Rothwell
2014-04-24 14:27 ` Mark Salter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).