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

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

[Mark Brown]

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

Hi all,

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

  arch/s390/include/asm/spinlock.h

between a series of commits adding wait queuing to s390 spinlocks
from the s390 tree:

eb3b7b848fb3dd00f7a57d633 s390/rwlock: introduce rwlock wait queueing
b96f7d881ad94203e997cd2aa s390/spinlock: introduce spinlock wait queueing
8153380379ecc8381f6d55f64 s390/spinlock: use the cpu number +1 as spinlock value

and Will's series of commits removing dummy implementations of spinlock
related things from the tip tree:

a4c1887d4c1462b0ec5a8989f locking/arch: Remove dummy arch_{read,spin,write}_lock_flags() implementations
0160fb177d484367e041ac251 locking/arch: Remove dummy arch_{read,spin,write}_relax() implementations
a8a217c22116eff6c120d753c locking/core: Remove {read,spin,write}_can_lock()

I'm don't feel confident I can resolve this conflict sensibly without
taking too long so I've used the tip tree from yesterday.

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

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

[Will Deacon]

Hi Mark,

On Wed, Oct 11, 2017 at 05:10:35PM +0100, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/s390/include/asm/spinlock.h
> 
> between a series of commits adding wait queuing to s390 spinlocks
> from the s390 tree:
> 
> eb3b7b848fb3dd00f7a57d633 s390/rwlock: introduce rwlock wait queueing
> b96f7d881ad94203e997cd2aa s390/spinlock: introduce spinlock wait queueing
> 8153380379ecc8381f6d55f64 s390/spinlock: use the cpu number +1 as spinlock value
> 
> and Will's series of commits removing dummy implementations of spinlock
> related things from the tip tree:
> 
> a4c1887d4c1462b0ec5a8989f locking/arch: Remove dummy arch_{read,spin,write}_lock_flags() implementations
> 0160fb177d484367e041ac251 locking/arch: Remove dummy arch_{read,spin,write}_relax() implementations
> a8a217c22116eff6c120d753c locking/core: Remove {read,spin,write}_can_lock()
> 
> I'm don't feel confident I can resolve this conflict sensibly without
> taking too long so I've used the tip tree from yesterday.

It's a shame that the conflict is so messy -- most of it is just context
because that file has changed a lot in the s390 tree so the cleanup doesn't
apply. I resolved it below.

On the plus side, it's one less implementation of arch_{read,write}_relax!

Will

--->8

diff --cc arch/s390/include/asm/spinlock.h
index 09e783d83d5d,9fa855f91e55..e31f554a3aa8
--- a/arch/s390/include/asm/spinlock.h
+++ b/arch/s390/include/asm/spinlock.h
@@@ -35,7 -35,7 +35,8 @@@ bool arch_vcpu_is_preempted(int cpu)
   * (the type definitions are in asm/spinlock_types.h)
   */
  
 -void arch_lock_relax(int cpu);
 +void arch_spin_relax(arch_spinlock_t *lock);
++#define arch_spin_relax		arch_spin_relax
  
  void arch_spin_lock_wait(arch_spinlock_t *);
  int arch_spin_trylock_retry(arch_spinlock_t *);
@@@ -72,8 -79,9 +73,9 @@@ static inline void arch_spin_lock_flags
  					unsigned long flags)
  {
  	if (!arch_spin_trylock_once(lp))
 -		arch_spin_lock_wait_flags(lp, flags);
 +		arch_spin_lock_wait(lp);
  }
+ #define arch_spin_lock_flags	arch_spin_lock_flags
  
  static inline int arch_spin_trylock(arch_spinlock_t *lp)
  {
@@@ -105,25 -112,58 +107,8 @@@ static inline void arch_spin_unlock(arc
   * read-locks.
   */
  
- /**
-  * read_can_lock - would read_trylock() succeed?
-  * @lock: the rwlock in question.
-  */
- #define arch_read_can_lock(x) (((x)->cnts & 0xffff0000) == 0)
 -extern int _raw_read_trylock_retry(arch_rwlock_t *lp);
 -extern int _raw_write_trylock_retry(arch_rwlock_t *lp);
--
- /**
-  * write_can_lock - would write_trylock() succeed?
-  * @lock: the rwlock in question.
-  */
- #define arch_write_can_lock(x) ((x)->cnts == 0)
 -static inline int arch_read_trylock_once(arch_rwlock_t *rw)
 -{
 -	int old = ACCESS_ONCE(rw->lock);
 -	return likely(old >= 0 &&
 -		      __atomic_cmpxchg_bool(&rw->lock, old, old + 1));
 -}
--
- #define arch_read_lock_flags(lock, flags) arch_read_lock(lock)
- #define arch_write_lock_flags(lock, flags) arch_write_lock(lock)
- #define arch_read_relax(rw) barrier()
- #define arch_write_relax(rw) barrier()
 -static inline int arch_write_trylock_once(arch_rwlock_t *rw)
 -{
 -	int old = ACCESS_ONCE(rw->lock);
 -	return likely(old == 0 &&
 -		      __atomic_cmpxchg_bool(&rw->lock, 0, 0x80000000));
 -}
 -
 -#ifdef CONFIG_HAVE_MARCH_Z196_FEATURES
 -
 -#define __RAW_OP_OR	"lao"
 -#define __RAW_OP_AND	"lan"
 -#define __RAW_OP_ADD	"laa"
 -
 -#define __RAW_LOCK(ptr, op_val, op_string)		\
 -({							\
 -	int old_val;					\
 -							\
 -	typecheck(int *, ptr);				\
 -	asm volatile(					\
 -		op_string "	%0,%2,%1\n"		\
 -		"bcr	14,0\n"				\
 -		: "=d" (old_val), "+Q" (*ptr)		\
 -		: "d" (op_val)				\
 -		: "cc", "memory");			\
 -	old_val;					\
 -})
 -
 -#define __RAW_UNLOCK(ptr, op_val, op_string)		\
 -({							\
 -	int old_val;					\
 -							\
 -	typecheck(int *, ptr);				\
 -	asm volatile(					\
 -		op_string "	%0,%2,%1\n"		\
 -		: "=d" (old_val), "+Q" (*ptr)		\
 -		: "d" (op_val)				\
 -		: "cc", "memory");			\
 -	old_val;					\
 -})
--
 -extern void _raw_read_lock_wait(arch_rwlock_t *lp);
 -extern void _raw_write_lock_wait(arch_rwlock_t *lp, int prev);
 +void arch_read_lock_wait(arch_rwlock_t *lp);
 +void arch_write_lock_wait(arch_rwlock_t *lp);
  
  static inline void arch_read_lock(arch_rwlock_t *rw)
  {

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

[Mark Brown]

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

On Wed, Oct 11, 2017 at 06:23:29PM +0100, Will Deacon wrote:
> On Wed, Oct 11, 2017 at 05:10:35PM +0100, Mark Brown wrote:

> > I'm don't feel confident I can resolve this conflict sensibly without
> > taking too long so I've used the tip tree from yesterday.

> It's a shame that the conflict is so messy -- most of it is just context
> because that file has changed a lot in the s390 tree so the cleanup doesn't
> apply. I resolved it below.

Thanks, I'll give that a spin today.  It did look like it should be fine
but it was such a mess I didn't want to try to resolve by hand.

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

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

[Stephen Rothwell]

Hi Mark,

On Wed, 11 Oct 2017 17:10:35 +0100 Mark Brown <broonie@kernel.org> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/s390/include/asm/spinlock.h
> 
> between a series of commits adding wait queuing to s390 spinlocks
> from the s390 tree:
> 
> eb3b7b848fb3dd00f7a57d633 s390/rwlock: introduce rwlock wait queueing
> b96f7d881ad94203e997cd2aa s390/spinlock: introduce spinlock wait queueing
> 8153380379ecc8381f6d55f64 s390/spinlock: use the cpu number +1 as spinlock value
> 
> and Will's series of commits removing dummy implementations of spinlock
> related things from the tip tree:
> 
> a4c1887d4c1462b0ec5a8989f locking/arch: Remove dummy arch_{read,spin,write}_lock_flags() implementations
> 0160fb177d484367e041ac251 locking/arch: Remove dummy arch_{read,spin,write}_relax() implementations
> a8a217c22116eff6c120d753c locking/core: Remove {read,spin,write}_can_lock()
> 
> I'm don't feel confident I can resolve this conflict sensibly without
> taking too long so I've used the tip tree from yesterday.

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

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

[Mark Brown]

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

Hi all,

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

  arch/ia64/Kconfig

between commits:

  fc5bad03709f9 ("ia64: remove the hpsim platform")
  cf07cb1ff4ea0 ("ia64: remove support for the SGI SN2 platform")

from the ia64 tree and commit:

  a2cbfd46559e8 ("arch, ia64: Make NUMA select SMP")

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/ia64/Kconfig
index 5dbd7fd7578f4,997baba02b70e..0000000000000
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@@ -311,7 -386,10 +311,9 @@@ config ARCH_DISCONTIGMEM_DEFAUL
  
  config NUMA
  	bool "NUMA support"
 -	depends on !IA64_HP_SIM && !FLATMEM
 -	default y if IA64_SGI_SN2
 +	depends on !FLATMEM
+ 	select ACPI_NUMA if ACPI
+ 	select SMP
  	help
  	  Say Y to compile the kernel to support NUMA (Non-Uniform Memory
  	  Access).  This option is for configuring high-end multiprocessor

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