linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the mm tree with the bitmap tree
@ 2022-07-04  6:58 Stephen Rothwell
  2022-07-04  7:26 ` Stephen Rothwell
  0 siblings, 1 reply; 5+ messages in thread
From: Stephen Rothwell @ 2022-07-04  6:58 UTC (permalink / raw)
  To: Andrew Morton, Yury Norov
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Sander Vanheule

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

Hi all,

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

  include/linux/cpumask.h

between commits:

  50e413c31800 ("lib/cpumask: change return types to unsigned")
  e32bd0390739 ("lib/cpumask: move one-line wrappers around find_bit to the header")

from the bitmap tree and commits:

  2b0b9f2665b2 ("cpumask: Fix invalid uniprocessor mask assumption")
  284d22458843 ("cpumask: update cpumask_next_wrap() signature")

from the mm tree.

I fixed it up (I hope, 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 include/linux/cpumask.h
index 0738a6c9be40,523857884ae4..000000000000
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@@ -274,29 -179,31 +195,47 @@@ static inline unsigned int cpumask_next
  	return find_next_zero_bit(cpumask_bits(srcp), nr_cpumask_bits, n+1);
  }
  
 -int __pure cpumask_next_and(int n, const struct cpumask *, const struct cpumask *);
 -int __pure cpumask_any_but(const struct cpumask *mask, unsigned int cpu);
 +/**
 + * cpumask_next_and - get the next cpu in *src1p & *src2p
 + * @n: the cpu prior to the place to search (ie. return will be > @n)
 + * @src1p: the first cpumask pointer
 + * @src2p: the second cpumask pointer
 + *
 + * Returns >= nr_cpu_ids if no further cpus set in both.
 + */
 +static inline
 +unsigned int cpumask_next_and(int n, const struct cpumask *src1p,
 +		     const struct cpumask *src2p)
 +{
 +	/* -1 is a legal arg here. */
 +	if (n != -1)
 +		cpumask_check(n);
 +	return find_next_and_bit(cpumask_bits(src1p), cpumask_bits(src2p),
 +		nr_cpumask_bits, n + 1);
 +}
  
+ #if NR_CPUS == 1
+ /* Uniprocessor: there is only one valid CPU */
+ static inline unsigned int cpumask_local_spread(unsigned int i, int node)
+ {
+ 	return 0;
+ }
+ 
+ static inline int cpumask_any_and_distribute(const struct cpumask *src1p,
+ 					     const struct cpumask *src2p) {
+ 	return cpumask_first_and(src1p, src2p);
+ }
+ 
+ static inline int cpumask_any_distribute(const struct cpumask *srcp)
+ {
+ 	return cpumask_first(srcp);
+ }
+ #else
  unsigned int cpumask_local_spread(unsigned int i, int node);
 -int cpumask_any_and_distribute(const struct cpumask *src1p,
 +unsigned int cpumask_any_and_distribute(const struct cpumask *src1p,
  			       const struct cpumask *src2p);
 -int cpumask_any_distribute(const struct cpumask *srcp);
 +unsigned int cpumask_any_distribute(const struct cpumask *srcp);
+ #endif /* NR_CPUS */
  
  /**
   * for_each_cpu - iterate over every cpu in a mask
@@@ -322,7 -229,7 +261,7 @@@
  		(cpu) = cpumask_next_zero((cpu), (mask)),	\
  		(cpu) < nr_cpu_ids;)
  
- unsigned int cpumask_next_wrap(int n, const struct cpumask *mask, int start, bool wrap);
 -int __pure cpumask_next_wrap(int n, const struct cpumask *mask, int start, bool wrap);
++unsigned int __pure cpumask_next_wrap(int n, const struct cpumask *mask, int start, bool wrap);
  
  /**
   * for_each_cpu_wrap - iterate over every cpu in a mask, starting at a specified location

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

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

* Re: linux-next: manual merge of the mm tree with the bitmap tree
  2022-07-04  6:58 linux-next: manual merge of the mm tree with the bitmap tree Stephen Rothwell
@ 2022-07-04  7:26 ` Stephen Rothwell
  2022-07-10  7:07   ` Sander Vanheule
  0 siblings, 1 reply; 5+ messages in thread
From: Stephen Rothwell @ 2022-07-04  7:26 UTC (permalink / raw)
  To: Andrew Morton, Yury Norov
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Sander Vanheule

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

Hi all,

On Mon, 4 Jul 2022 16:58:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the mm tree got a conflict in:
> 
>   include/linux/cpumask.h
> 
> between commits:
> 
>   50e413c31800 ("lib/cpumask: change return types to unsigned")
>   e32bd0390739 ("lib/cpumask: move one-line wrappers around find_bit to the header")
> 
> from the bitmap tree and commits:
> 
>   2b0b9f2665b2 ("cpumask: Fix invalid uniprocessor mask assumption")
>   284d22458843 ("cpumask: update cpumask_next_wrap() signature")
> 
> from the mm tree.
> 
> I fixed it up (I hope, 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

It actually needed to be:

785d45d2ce79973aa13920e855aff8a67c61b1c8
diff --cc include/linux/cpumask.h
index 0738a6c9be40,523857884ae4..6a8f75cc9985
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@@ -274,29 -179,31 +195,47 @@@ static inline unsigned int cpumask_next
  	return find_next_zero_bit(cpumask_bits(srcp), nr_cpumask_bits, n+1);
  }
  
 -int __pure cpumask_next_and(int n, const struct cpumask *, const struct cpumask *);
 -int __pure cpumask_any_but(const struct cpumask *mask, unsigned int cpu);
 +/**
 + * cpumask_next_and - get the next cpu in *src1p & *src2p
 + * @n: the cpu prior to the place to search (ie. return will be > @n)
 + * @src1p: the first cpumask pointer
 + * @src2p: the second cpumask pointer
 + *
 + * Returns >= nr_cpu_ids if no further cpus set in both.
 + */
 +static inline
 +unsigned int cpumask_next_and(int n, const struct cpumask *src1p,
 +		     const struct cpumask *src2p)
 +{
 +	/* -1 is a legal arg here. */
 +	if (n != -1)
 +		cpumask_check(n);
 +	return find_next_and_bit(cpumask_bits(src1p), cpumask_bits(src2p),
 +		nr_cpumask_bits, n + 1);
 +}
  
+ #if NR_CPUS == 1
+ /* Uniprocessor: there is only one valid CPU */
+ static inline unsigned int cpumask_local_spread(unsigned int i, int node)
+ {
+ 	return 0;
+ }
+ 
+ static inline int cpumask_any_and_distribute(const struct cpumask *src1p,
+ 					     const struct cpumask *src2p) {
+ 	return cpumask_first_and(src1p, src2p);
+ }
+ 
+ static inline int cpumask_any_distribute(const struct cpumask *srcp)
+ {
+ 	return cpumask_first(srcp);
+ }
+ #else
  unsigned int cpumask_local_spread(unsigned int i, int node);
 -int cpumask_any_and_distribute(const struct cpumask *src1p,
 +unsigned int cpumask_any_and_distribute(const struct cpumask *src1p,
  			       const struct cpumask *src2p);
 -int cpumask_any_distribute(const struct cpumask *srcp);
 +unsigned int cpumask_any_distribute(const struct cpumask *srcp);
+ #endif /* NR_CPUS */
  
  /**
   * for_each_cpu - iterate over every cpu in a mask
@@@ -322,7 -229,7 +261,7 @@@
  		(cpu) = cpumask_next_zero((cpu), (mask)),	\
  		(cpu) < nr_cpu_ids;)
  
- unsigned int cpumask_next_wrap(int n, const struct cpumask *mask, int start, bool wrap);
 -int __pure cpumask_next_wrap(int n, const struct cpumask *mask, int start, bool wrap);
++unsigned int __pure cpumask_next_wrap(int n, const struct cpumask *mask, int start, bool wrap);
  
  /**
   * for_each_cpu_wrap - iterate over every cpu in a mask, starting at a specified location
@@@ -358,27 -265,6 +297,26 @@@
  		(cpu) = cpumask_next_and((cpu), (mask1), (mask2)),	\
  		(cpu) < nr_cpu_ids;)
  
 +/**
 + * cpumask_any_but - return a "random" in a cpumask, but not this one.
 + * @mask: the cpumask to search
 + * @cpu: the cpu to ignore.
 + *
 + * Often used to find any cpu but smp_processor_id() in a mask.
 + * Returns >= nr_cpu_ids if no cpus set.
 + */
 +static inline
 +unsigned int cpumask_any_but(const struct cpumask *mask, unsigned int cpu)
 +{
 +	unsigned int i;
 +
 +	cpumask_check(cpu);
 +	for_each_cpu(i, mask)
 +		if (i != cpu)
 +			break;
 +	return i;
 +}
- #endif /* SMP */
 +
  #define CPU_BITS_NONE						\
  {								\
  	[0 ... BITS_TO_LONGS(NR_CPUS)-1] = 0UL			\

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

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

* Re: linux-next: manual merge of the mm tree with the bitmap tree
  2022-07-04  7:26 ` Stephen Rothwell
@ 2022-07-10  7:07   ` Sander Vanheule
  0 siblings, 0 replies; 5+ messages in thread
From: Sander Vanheule @ 2022-07-10  7:07 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton, Yury Norov
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

Hi Stephen,

On Mon, 2022-07-04 at 17:26 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 4 Jul 2022 16:58:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au>
> wrote:
> > 
> > Today's linux-next merge of the mm tree got a conflict in:
> > 
> >   include/linux/cpumask.h
> > 
> > between commits:
> > 
> >   50e413c31800 ("lib/cpumask: change return types to unsigned")
> >   e32bd0390739 ("lib/cpumask: move one-line wrappers around find_bit to the
> > header")
> > 
> > from the bitmap tree and commits:
> > 
> >   2b0b9f2665b2 ("cpumask: Fix invalid uniprocessor mask assumption")
> >   284d22458843 ("cpumask: update cpumask_next_wrap() signature")
> > 
> > from the mm tree.
> > 
> > I fixed it up (I hope, 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 for solving the conflicts, looks fine to me. I've asked Andrew to reorder
my patches. The end result for the series should be the same though, and I don't
think my patches should require too many changes anymore.

If further merge conflicts arise with Yury's cpumask patches, I'm also fine with
them being run as one series if that would make things easier.

Best,
Sander

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

* linux-next: manual merge of the mm tree with the bitmap tree
@ 2022-07-15 11:14 Stephen Rothwell
  0 siblings, 0 replies; 5+ messages in thread
From: Stephen Rothwell @ 2022-07-15 11:14 UTC (permalink / raw)
  To: Andrew Morton, Yury Norov
  Cc: Ingo Molnar, Linux Kernel Mailing List, Linux Next Mailing List,
	NeilBrown

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

Hi all,

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

  include/linux/gfp.h

between commit:

  34973181c728 ("headers/deps: mm: Split <linux/gfp_types.h> out of <linux/gfp.h>")

from the bitmap tree and commit:

  c2cda11cec4f ("mm: discard __GFP_ATOMIC")

from the mm tree.

I fixed it up (I used the former version of this file and then
applied the following merge resolution 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 40347cfa3f5fe59fbf04be561c669f0dda06ea35 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 15 Jul 2022 21:09:09 +1000
Subject: [PATCH] fix up for "headers/deps: mm: Split <linux/gfp_types.h> out
 of <linux/gfp.h>"

interacting with "mm: discard __GFP_ATOMIC"

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

diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
index d88c46ca82e1..5088637fe5c2 100644
--- a/include/linux/gfp_types.h
+++ b/include/linux/gfp_types.h
@@ -31,7 +31,7 @@ typedef unsigned int __bitwise gfp_t;
 #define ___GFP_IO		0x40u
 #define ___GFP_FS		0x80u
 #define ___GFP_ZERO		0x100u
-#define ___GFP_ATOMIC		0x200u
+/* 0x200u unused */
 #define ___GFP_DIRECT_RECLAIM	0x400u
 #define ___GFP_KSWAPD_RECLAIM	0x800u
 #define ___GFP_WRITE		0x1000u
@@ -116,11 +116,8 @@ typedef unsigned int __bitwise gfp_t;
  *
  * %__GFP_HIGH indicates that the caller is high-priority and that granting
  * the request is necessary before the system can make forward progress.
- * For example, creating an IO context to clean pages.
- *
- * %__GFP_ATOMIC indicates that the caller cannot reclaim or sleep and is
- * high priority. Users are typically interrupt handlers. This may be
- * used in conjunction with %__GFP_HIGH
+ * For example creating an IO context to clean pages and requests
+ * from atomic context.
  *
  * %__GFP_MEMALLOC allows access to all memory. This should only be used when
  * the caller guarantees the allocation will allow more memory to be freed
@@ -135,7 +132,6 @@ typedef unsigned int __bitwise gfp_t;
  * %__GFP_NOMEMALLOC is used to explicitly forbid access to emergency reserves.
  * This takes precedence over the %__GFP_MEMALLOC flag if both are set.
  */
-#define __GFP_ATOMIC	((__force gfp_t)___GFP_ATOMIC)
 #define __GFP_HIGH	((__force gfp_t)___GFP_HIGH)
 #define __GFP_MEMALLOC	((__force gfp_t)___GFP_MEMALLOC)
 #define __GFP_NOMEMALLOC ((__force gfp_t)___GFP_NOMEMALLOC)
@@ -329,7 +325,7 @@ typedef unsigned int __bitwise gfp_t;
  * version does not attempt reclaim/compaction at all and is by default used
  * in page fault path, while the non-light is used by khugepaged.
  */
-#define GFP_ATOMIC	(__GFP_HIGH|__GFP_ATOMIC|__GFP_KSWAPD_RECLAIM)
+#define GFP_ATOMIC	(__GFP_HIGH|__GFP_KSWAPD_RECLAIM)
 #define GFP_KERNEL	(__GFP_RECLAIM | __GFP_IO | __GFP_FS)
 #define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT)
 #define GFP_NOWAIT	(__GFP_KSWAPD_RECLAIM)
-- 
2.35.1



-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: manual merge of the mm tree with the bitmap tree
@ 2022-07-04  7:13 Stephen Rothwell
  0 siblings, 0 replies; 5+ messages in thread
From: Stephen Rothwell @ 2022-07-04  7:13 UTC (permalink / raw)
  To: Andrew Morton, Yury Norov
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, NeilBrown

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

Hi all,

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

  include/linux/gfp.h

between commit:

  db0e627fee42 ("mm: split include/linux/gfp.h")

from the bitmap tree and commit:

  199520d04b35 ("mm: discard __GFP_ATOMIC")

from the mm tree.

I fixed it up (I used the former version of this files and applied 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: Mon, 4 Jul 2022 17:09:47 +1000
Subject: [PATCH] fix up for "mm: split include/linux/gfp.h"

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

diff --git a/include/linux/gfp_flags.h b/include/linux/gfp_flags.h
index 846cc8151340..6338c093cc38 100644
--- a/include/linux/gfp_flags.h
+++ b/include/linux/gfp_flags.h
@@ -17,7 +17,7 @@
 #define ___GFP_IO		0x40u
 #define ___GFP_FS		0x80u
 #define ___GFP_ZERO		0x100u
-#define ___GFP_ATOMIC		0x200u
+/* 0x200u unused */
 #define ___GFP_DIRECT_RECLAIM	0x400u
 #define ___GFP_KSWAPD_RECLAIM	0x800u
 #define ___GFP_WRITE		0x1000u
@@ -102,11 +102,8 @@
  *
  * %__GFP_HIGH indicates that the caller is high-priority and that granting
  * the request is necessary before the system can make forward progress.
- * For example, creating an IO context to clean pages.
- *
- * %__GFP_ATOMIC indicates that the caller cannot reclaim or sleep and is
- * high priority. Users are typically interrupt handlers. This may be
- * used in conjunction with %__GFP_HIGH
+ * For example creating an IO context to clean pages and requests
+ * from atomic context.
  *
  * %__GFP_MEMALLOC allows access to all memory. This should only be used when
  * the caller guarantees the allocation will allow more memory to be freed
@@ -121,7 +118,6 @@
  * %__GFP_NOMEMALLOC is used to explicitly forbid access to emergency reserves.
  * This takes precedence over the %__GFP_MEMALLOC flag if both are set.
  */
-#define __GFP_ATOMIC	((__force gfp_t)___GFP_ATOMIC)
 #define __GFP_HIGH	((__force gfp_t)___GFP_HIGH)
 #define __GFP_MEMALLOC	((__force gfp_t)___GFP_MEMALLOC)
 #define __GFP_NOMEMALLOC ((__force gfp_t)___GFP_NOMEMALLOC)
@@ -315,7 +311,7 @@
  * version does not attempt reclaim/compaction at all and is by default used
  * in page fault path, while the non-light is used by khugepaged.
  */
-#define GFP_ATOMIC	(__GFP_HIGH|__GFP_ATOMIC|__GFP_KSWAPD_RECLAIM)
+#define GFP_ATOMIC	(__GFP_HIGH|__GFP_KSWAPD_RECLAIM)
 #define GFP_KERNEL	(__GFP_RECLAIM | __GFP_IO | __GFP_FS)
 #define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT)
 #define GFP_NOWAIT	(__GFP_KSWAPD_RECLAIM)
-- 
2.35.1

-- 
Cheers,
Stephen Rothwell

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

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

end of thread, other threads:[~2022-07-15 11:14 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-04  6:58 linux-next: manual merge of the mm tree with the bitmap tree Stephen Rothwell
2022-07-04  7:26 ` Stephen Rothwell
2022-07-10  7:07   ` Sander Vanheule
2022-07-04  7:13 Stephen Rothwell
2022-07-15 11:14 Stephen Rothwell

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