linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the asm-generic tree with Linus' tree
@ 2018-04-02 23:22 Stephen Rothwell
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen Rothwell @ 2018-04-02 23:22 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Waiman Long,
	Ingo Molnar

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

Hi Arnd,

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

  lib/Kconfig.debug

between commits:

  f07cbebb6daf ("locking/Kconfig: Add LOCK_DEBUGGING_SUPPORT to make it more readable")
  19193bcad8dc ("locking/Kconfig: Restructure the lock debugging menu")

from Linus' tree and commit:

  a687a5337063 ("treewide: simplify Kconfig dependencies for removed archs")

from the asm-generic 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 lib/Kconfig.debug
index 40f45144320a,6927c6d8d185..000000000000
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@@ -1107,80 -1164,6 +1104,80 @@@ config LOCK_STA
  	 CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
  	 (CONFIG_LOCKDEP defines "acquire" and "release" events.)
  
 +config DEBUG_RT_MUTEXES
 +	bool "RT Mutex debugging, deadlock detection"
 +	depends on DEBUG_KERNEL && RT_MUTEXES
 +	help
 +	 This allows rt mutex semantics violations and rt mutex related
 +	 deadlocks (lockups) to be detected and reported automatically.
 +
 +config DEBUG_SPINLOCK
 +	bool "Spinlock and rw-lock debugging: basic checks"
 +	depends on DEBUG_KERNEL
 +	select UNINLINE_SPIN_UNLOCK
 +	help
 +	  Say Y here and build SMP to catch missing spinlock initialization
 +	  and certain other kinds of spinlock errors commonly made.  This is
 +	  best used in conjunction with the NMI watchdog so that spinlock
 +	  deadlocks are also debuggable.
 +
 +config DEBUG_MUTEXES
 +	bool "Mutex debugging: basic checks"
 +	depends on DEBUG_KERNEL
 +	help
 +	 This feature allows mutex semantics violations to be detected and
 +	 reported.
 +
 +config DEBUG_WW_MUTEX_SLOWPATH
 +	bool "Wait/wound mutex debugging: Slowpath testing"
 +	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
 +	select DEBUG_LOCK_ALLOC
 +	select DEBUG_SPINLOCK
 +	select DEBUG_MUTEXES
 +	help
 +	 This feature enables slowpath testing for w/w mutex users by
 +	 injecting additional -EDEADLK wound/backoff cases. Together with
 +	 the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this
 +	 will test all possible w/w mutex interface abuse with the
 +	 exception of simply not acquiring all the required locks.
 +	 Note that this feature can introduce significant overhead, so
 +	 it really should not be enabled in a production or distro kernel,
 +	 even a debug kernel.  If you are a driver writer, enable it.  If
 +	 you are a distro, do not.
 +
 +config DEBUG_RWSEMS
 +	bool "RW Semaphore debugging: basic checks"
 +	depends on DEBUG_KERNEL && RWSEM_SPIN_ON_OWNER
 +	help
 +	  This debugging feature allows mismatched rw semaphore locks and unlocks
 +	  to be detected and reported.
 +
 +config DEBUG_LOCK_ALLOC
 +	bool "Lock debugging: detect incorrect freeing of live locks"
 +	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
 +	select DEBUG_SPINLOCK
 +	select DEBUG_MUTEXES
 +	select DEBUG_RT_MUTEXES if RT_MUTEXES
 +	select LOCKDEP
 +	help
 +	 This feature will check whether any held lock (spinlock, rwlock,
 +	 mutex or rwsem) is incorrectly freed by the kernel, via any of the
 +	 memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
 +	 vfree(), etc.), whether a live lock is incorrectly reinitialized via
 +	 spin_lock_init()/mutex_init()/etc., or whether there is any lock
 +	 held during task exit.
 +
 +config LOCKDEP
 +	bool
 +	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
 +	select STACKTRACE
- 	select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND && !S390 && !MICROBLAZE && !ARC && !SCORE && !X86
++	select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND && !S390 && !MICROBLAZE && !ARC && !X86
 +	select KALLSYMS
 +	select KALLSYMS_ALL
 +
 +config LOCKDEP_SMALL
 +	bool
 +
  config DEBUG_LOCKDEP
  	bool "Lock dependency engine debugging"
  	depends on DEBUG_KERNEL && LOCKDEP

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

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

* Re: linux-next: manual merge of the asm-generic tree with Linus' tree
  2021-10-07 22:38 Stephen Rothwell
@ 2021-10-08  8:29 ` Arnd Bergmann
  0 siblings, 0 replies; 8+ messages in thread
From: Arnd Bergmann @ 2021-10-08  8:29 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Arnd Bergmann, Bjorn Andersson, Geert Uytterhoeven,
	Linux Kernel Mailing List, Linux Next Mailing List

On Fri, Oct 8, 2021 at 12:38 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the asm-generic tree got a conflict in:
>
>   drivers/firmware/Kconfig
>
> between commit:
>
>   4382c73a12b4 ("firmware: qcom_scm: QCOM_SCM should depend on ARCH_QCOM")
>
> from Linus' tree and commit:
>
>   7efbbe6e1414 ("qcom_scm: hide Kconfig symbol")
>
> from the asm-generic tree.
>
> I fixed it up (I just used the latter) 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 the report. Both of them came through my trees, so maybe
I should have added them into the same fixes branch after all...

     Arnd

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

* linux-next: manual merge of the asm-generic tree with Linus' tree
@ 2021-10-07 22:38 Stephen Rothwell
  2021-10-08  8:29 ` Arnd Bergmann
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Rothwell @ 2021-10-07 22:38 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Andersson, Geert Uytterhoeven, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

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

  drivers/firmware/Kconfig

between commit:

  4382c73a12b4 ("firmware: qcom_scm: QCOM_SCM should depend on ARCH_QCOM")

from Linus' tree and commit:

  7efbbe6e1414 ("qcom_scm: hide Kconfig symbol")

from the asm-generic tree.

I fixed it up (I just used the latter) 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

[-- 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 asm-generic tree with Linus' tree
@ 2016-11-09 22:38 Stephen Rothwell
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen Rothwell @ 2016-11-09 22:38 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-next, linux-kernel, Heiko Carstens, Martin Schwidefsky,
	Chunyan Zhang

Hi Arnd,

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

  include/asm-generic/percpu.h

between commit:

  7f8d61f00522 ("percpu: use notrace variant of preempt_disable/preempt_enable")

from Linus' tree and commit:

  acbdf0e98066 ("percpu: make this_cpu_generic_read notrace")

from the asm-generic tree.

I fixed it up (these commits do exactly the same thing ... so I just
used the version from Linus' tree (since there is another patch there
that affects this part of the code)) 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

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

* Re: linux-next: manual merge of the asm-generic tree with Linus' tree
  2009-06-12  8:05 ` Arnd Bergmann
@ 2009-06-12  8:18   ` Stephen Rothwell
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen Rothwell @ 2009-06-12  8:18 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linux-next, linux-kernel, Peter Zijlstra, Ingo Molnar

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

Hi Arnd,

On Fri, 12 Jun 2009 10:05:32 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Friday 12 June 2009, Stephen Rothwell wrote:
> > Today's linux-next merge of the asm-generic tree got a conflict in
> > include/asm-generic/atomic.h between commit
> > 53e111a730ea8b002d57dd226098c12789993329 ("x86: Fix atomic_long_xchg() on
> > 64bit") from Linus' tree and commit
> > 72099ed2719fc5829bd79c6ca9d1783ed026eb37 ("asm-generic: rename atomic.h
> > to atomic-long.h") from the asm-generic tree.
> > 
> > I applied the fix from the former patch to atomic-long.h
> 
> I pulled Linus' tree into the asm-generic tree now and fixed the two conflicts
> in the same way you did. I thought about doing a rebase on his tree instead,
> but wasn't sure what works better.

I think what works better is what you are most comfortable with.  Your
way works fine for me.  Thanks.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

* Re: linux-next: manual merge of the asm-generic tree with Linus' tree
  2009-06-12  6:49 Stephen Rothwell
@ 2009-06-12  8:05 ` Arnd Bergmann
  2009-06-12  8:18   ` Stephen Rothwell
  0 siblings, 1 reply; 8+ messages in thread
From: Arnd Bergmann @ 2009-06-12  8:05 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Peter Zijlstra, Ingo Molnar

On Friday 12 June 2009, Stephen Rothwell wrote:
> Today's linux-next merge of the asm-generic tree got a conflict in
> include/asm-generic/atomic.h between commit
> 53e111a730ea8b002d57dd226098c12789993329 ("x86: Fix atomic_long_xchg() on
> 64bit") from Linus' tree and commit
> 72099ed2719fc5829bd79c6ca9d1783ed026eb37 ("asm-generic: rename atomic.h
> to atomic-long.h") from the asm-generic tree.
> 
> I applied the fix from the former patch to atomic-long.h

Hi Stephen,

I pulled Linus' tree into the asm-generic tree now and fixed the two conflicts
in the same way you did. I thought about doing a rebase on his tree instead,
but wasn't sure what works better.

	Arnd <><

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

* linux-next: manual merge of the asm-generic tree with Linus' tree
@ 2009-06-12  6:49 Stephen Rothwell
  2009-06-12  8:05 ` Arnd Bergmann
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Rothwell @ 2009-06-12  6:49 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linux-next, linux-kernel, Peter Zijlstra, Ingo Molnar

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

Hi Arnd,

Today's linux-next merge of the asm-generic tree got a conflict in
include/asm-generic/atomic.h between commit
53e111a730ea8b002d57dd226098c12789993329 ("x86: Fix atomic_long_xchg() on
64bit") from Linus' tree and commit
72099ed2719fc5829bd79c6ca9d1783ed026eb37 ("asm-generic: rename atomic.h
to atomic-long.h") from the asm-generic tree.

I applied the fix from the former patch to atomic-long.h
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

* linux-next: manual merge of the asm-generic tree with Linus' tree
@ 2009-06-12  6:43 Stephen Rothwell
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen Rothwell @ 2009-06-12  6:43 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linux-next, linux-kernel, Ingo Molnar

Hi Arnd,

Today's linux-next merge of the asm-generic tree got a conflict in
arch/x86/include/asm/atomic_32.h between commit
9b194e831fb2c322ed81a373e49620f34edc2778 ("x86: implement atomic64_t on
32-bit") from Linus' tree and commit
72099ed2719fc5829bd79c6ca9d1783ed026eb37 ("asm-generic: rename atomic.h
to atomic-long.h") from the asm-generic tree.

Just context changes (I think). I have fixed it up (see below).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/include/asm/atomic_32.h
index aff9f1f,c83d314..0000000
--- a/arch/x86/include/asm/atomic_32.h
+++ b/arch/x86/include/asm/atomic_32.h
@@@ -247,241 -247,5 +247,241 @@@ static inline int atomic_add_unless(ato
  #define smp_mb__before_atomic_inc()	barrier()
  #define smp_mb__after_atomic_inc()	barrier()
  
 +/* An 64bit atomic type */
 +
 +typedef struct {
 +	unsigned long long counter;
 +} atomic64_t;
 +
 +#define ATOMIC64_INIT(val)	{ (val) }
 +
 +/**
 + * atomic64_read - read atomic64 variable
 + * @v: pointer of type atomic64_t
 + *
 + * Atomically reads the value of @v.
 + * Doesn't imply a read memory barrier.
 + */
 +#define __atomic64_read(ptr)		((ptr)->counter)
 +
 +static inline unsigned long long
 +cmpxchg8b(unsigned long long *ptr, unsigned long long old, unsigned long long new)
 +{
 +	asm volatile(
 +
 +		LOCK_PREFIX "cmpxchg8b (%[ptr])\n"
 +
 +		     :		"=A" (old)
 +
 +		     : [ptr]	"D" (ptr),
 +				"A" (old),
 +				"b" (ll_low(new)),
 +				"c" (ll_high(new))
 +
 +		     : "memory");
 +
 +	return old;
 +}
 +
 +static inline unsigned long long
 +atomic64_cmpxchg(atomic64_t *ptr, unsigned long long old_val,
 +		 unsigned long long new_val)
 +{
 +	return cmpxchg8b(&ptr->counter, old_val, new_val);
 +}
 +
 +/**
 + * atomic64_xchg - xchg atomic64 variable
 + * @ptr:      pointer to type atomic64_t
 + * @new_val:  value to assign
 + * @old_val:  old value that was there
 + *
 + * Atomically xchgs the value of @ptr to @new_val and returns
 + * the old value.
 + */
 +
 +static inline unsigned long long
 +atomic64_xchg(atomic64_t *ptr, unsigned long long new_val)
 +{
 +	unsigned long long old_val;
 +
 +	do {
 +		old_val = atomic_read(ptr);
 +	} while (atomic64_cmpxchg(ptr, old_val, new_val) != old_val);
 +
 +	return old_val;
 +}
 +
 +/**
 + * atomic64_set - set atomic64 variable
 + * @ptr:      pointer to type atomic64_t
 + * @new_val:  value to assign
 + *
 + * Atomically sets the value of @ptr to @new_val.
 + */
 +static inline void atomic64_set(atomic64_t *ptr, unsigned long long new_val)
 +{
 +	atomic64_xchg(ptr, new_val);
 +}
 +
 +/**
 + * atomic64_read - read atomic64 variable
 + * @ptr:      pointer to type atomic64_t
 + *
 + * Atomically reads the value of @ptr and returns it.
 + */
 +static inline unsigned long long atomic64_read(atomic64_t *ptr)
 +{
 +	unsigned long long curr_val;
 +
 +	do {
 +		curr_val = __atomic64_read(ptr);
 +	} while (atomic64_cmpxchg(ptr, curr_val, curr_val) != curr_val);
 +
 +	return curr_val;
 +}
 +
 +/**
 + * atomic64_add_return - add and return
 + * @delta: integer value to add
 + * @ptr:   pointer to type atomic64_t
 + *
 + * Atomically adds @delta to @ptr and returns @delta + *@ptr
 + */
 +static inline unsigned long long
 +atomic64_add_return(unsigned long long delta, atomic64_t *ptr)
 +{
 +	unsigned long long old_val, new_val;
 +
 +	do {
 +		old_val = atomic_read(ptr);
 +		new_val = old_val + delta;
 +
 +	} while (atomic64_cmpxchg(ptr, old_val, new_val) != old_val);
 +
 +	return new_val;
 +}
 +
 +static inline long atomic64_sub_return(unsigned long long delta, atomic64_t *ptr)
 +{
 +	return atomic64_add_return(-delta, ptr);
 +}
 +
 +static inline long atomic64_inc_return(atomic64_t *ptr)
 +{
 +	return atomic64_add_return(1, ptr);
 +}
 +
 +static inline long atomic64_dec_return(atomic64_t *ptr)
 +{
 +	return atomic64_sub_return(1, ptr);
 +}
 +
 +/**
 + * atomic64_add - add integer to atomic64 variable
 + * @delta: integer value to add
 + * @ptr:   pointer to type atomic64_t
 + *
 + * Atomically adds @delta to @ptr.
 + */
 +static inline void atomic64_add(unsigned long long delta, atomic64_t *ptr)
 +{
 +	atomic64_add_return(delta, ptr);
 +}
 +
 +/**
 + * atomic64_sub - subtract the atomic64 variable
 + * @delta: integer value to subtract
 + * @ptr:   pointer to type atomic64_t
 + *
 + * Atomically subtracts @delta from @ptr.
 + */
 +static inline void atomic64_sub(unsigned long long delta, atomic64_t *ptr)
 +{
 +	atomic64_add(-delta, ptr);
 +}
 +
 +/**
 + * atomic64_sub_and_test - subtract value from variable and test result
 + * @delta: integer value to subtract
 + * @ptr:   pointer to type atomic64_t
 + *
 + * Atomically subtracts @delta from @ptr and returns
 + * true if the result is zero, or false for all
 + * other cases.
 + */
 +static inline int
 +atomic64_sub_and_test(unsigned long long delta, atomic64_t *ptr)
 +{
 +	unsigned long long old_val = atomic64_sub_return(delta, ptr);
 +
 +	return old_val == 0;
 +}
 +
 +/**
 + * atomic64_inc - increment atomic64 variable
 + * @ptr: pointer to type atomic64_t
 + *
 + * Atomically increments @ptr by 1.
 + */
 +static inline void atomic64_inc(atomic64_t *ptr)
 +{
 +	atomic64_add(1, ptr);
 +}
 +
 +/**
 + * atomic64_dec - decrement atomic64 variable
 + * @ptr: pointer to type atomic64_t
 + *
 + * Atomically decrements @ptr by 1.
 + */
 +static inline void atomic64_dec(atomic64_t *ptr)
 +{
 +	atomic64_sub(1, ptr);
 +}
 +
 +/**
 + * atomic64_dec_and_test - decrement and test
 + * @ptr: pointer to type atomic64_t
 + *
 + * Atomically decrements @ptr by 1 and
 + * returns true if the result is 0, or false for all other
 + * cases.
 + */
 +static inline int atomic64_dec_and_test(atomic64_t *ptr)
 +{
 +	return atomic64_sub_and_test(1, ptr);
 +}
 +
 +/**
 + * atomic64_inc_and_test - increment and test
 + * @ptr: pointer to type atomic64_t
 + *
 + * Atomically increments @ptr by 1
 + * and returns true if the result is zero, or false for all
 + * other cases.
 + */
 +static inline int atomic64_inc_and_test(atomic64_t *ptr)
 +{
 +	return atomic64_sub_and_test(-1, ptr);
 +}
 +
 +/**
 + * atomic64_add_negative - add and test if negative
 + * @delta: integer value to add
 + * @ptr:   pointer to type atomic64_t
 + *
 + * Atomically adds @delta to @ptr and returns true
 + * if the result is negative, or false when
 + * result is greater than or equal to zero.
 + */
 +static inline int
 +atomic64_add_negative(unsigned long long delta, atomic64_t *ptr)
 +{
 +	long long old_val = atomic64_add_return(delta, ptr);
 +
 +	return old_val < 0;
 +}
 +
- #include <asm-generic/atomic.h>
+ #include <asm-generic/atomic-long.h>
  #endif /* _ASM_X86_ATOMIC_32_H */

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

end of thread, other threads:[~2021-10-08  8:30 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-02 23:22 linux-next: manual merge of the asm-generic tree with Linus' tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2021-10-07 22:38 Stephen Rothwell
2021-10-08  8:29 ` Arnd Bergmann
2016-11-09 22:38 Stephen Rothwell
2009-06-12  6:49 Stephen Rothwell
2009-06-12  8:05 ` Arnd Bergmann
2009-06-12  8:18   ` Stephen Rothwell
2009-06-12  6:43 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).