linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Waiman Long <longman@redhat.com>, Ingo Molnar <mingo@kernel.org>
Subject: linux-next: manual merge of the asm-generic tree with Linus' tree
Date: Tue, 3 Apr 2018 09:22:18 +1000	[thread overview]
Message-ID: <20180403092218.1de5bec1@canb.auug.org.au> (raw)

[-- 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 --]

             reply	other threads:[~2018-04-02 23:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-02 23:22 Stephen Rothwell [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-10-07 22:38 linux-next: manual merge of the asm-generic tree with Linus' tree 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180403092218.1de5bec1@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mingo@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).