linux-kernel - [tip:locking/urgent] i2c/mux, locking/core: Annotate the nested rt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <tip-7b94ea50514d1a0dc94f02723b603c27bc0ea597@git.kernel.org>
Date:   Wed, 25 Jul 2018 07:19:34 -0700
From:   tip-bot for Peter Rosin <tipbot@...or.com>
To:     linux-tip-commits@...r.kernel.org
Cc:     will.deacon@....com, torvalds@...ux-foundation.org, hpa@...or.com,
        tglx@...utronix.de, jsperbeck@...gle.com, wsa@...-dreams.de,
        linux-kernel@...r.kernel.org, mingo@...nel.org, dave@...olabs.net,
        dpf@...gle.com, pombredanne@...b.com, peda@...ntia.se,
        peterz@...radead.org, gregkh@...uxfoundation.org,
        deepadinamani@...gle.com
Subject: [tip:locking/urgent] i2c/mux, locking/core: Annotate the nested
 rt_mutex usage

Commit-ID:  7b94ea50514d1a0dc94f02723b603c27bc0ea597
Gitweb:     https://git.kernel.org/tip/7b94ea50514d1a0dc94f02723b603c27bc0ea597
Author:     Peter Rosin <peda@...ntia.se>
AuthorDate: Fri, 20 Jul 2018 10:39:14 +0200
Committer:  Ingo Molnar <mingo@...nel.org>
CommitDate: Wed, 25 Jul 2018 11:22:20 +0200

i2c/mux, locking/core: Annotate the nested rt_mutex usage

If an i2c topology has instances of nested muxes, then a lockdep splat
is produced when when i2c_parent_lock_bus() is called.  Here is an
example:

  ============================================
  WARNING: possible recursive locking detected
  --------------------------------------------
  insmod/68159 is trying to acquire lock:
    (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux]

  but task is already holding lock:
    (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux]

  other info that might help us debug this:
    Possible unsafe locking scenario:

          CPU0
          ----
     lock(i2c_register_adapter#2);
     lock(i2c_register_adapter#2);

    *** DEADLOCK ***

    May be due to missing lock nesting notation

  1 lock held by insmod/68159:
    #0:  (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux]

  stack backtrace:
  CPU: 13 PID: 68159 Comm: insmod Tainted: G           O
  Call Trace:
    dump_stack+0x67/0x98
    __lock_acquire+0x162e/0x1780
    lock_acquire+0xba/0x200
    rt_mutex_lock+0x44/0x60
    i2c_parent_lock_bus+0x32/0x50 [i2c_mux]
    i2c_parent_lock_bus+0x3e/0x50 [i2c_mux]
    i2c_smbus_xfer+0xf0/0x700
    i2c_smbus_read_byte+0x42/0x70
    my2c_init+0xa2/0x1000 [my2c]
    do_one_initcall+0x51/0x192
    do_init_module+0x62/0x216
    load_module+0x20f9/0x2b50
    SYSC_init_module+0x19a/0x1c0
    SyS_init_module+0xe/0x10
    do_syscall_64+0x6c/0x1a0
    entry_SYSCALL_64_after_hwframe+0x42/0xb7

Reported-by: John Sperbeck <jsperbeck@...gle.com>
Tested-by: John Sperbeck <jsperbeck@...gle.com>
Signed-off-by: Peter Rosin <peda@...ntia.se>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Cc: Davidlohr Bueso <dave@...olabs.net>
Cc: Deepa Dinamani <deepadinamani@...gle.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Chang <dpf@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Philippe Ombredanne <pombredanne@...b.com>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Will Deacon <will.deacon@....com>
Cc: Wolfram Sang <wsa@...-dreams.de>
Link: http://lkml.kernel.org/r/20180720083914.1950-3-peda@axentia.se
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
 drivers/i2c/i2c-core-base.c | 2 +-
 drivers/i2c/i2c-mux.c       | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 301285c54603..15c95aaa484c 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -624,7 +624,7 @@ static int i2c_check_addr_busy(struct i2c_adapter *adapter, int addr)
 static void i2c_adapter_lock_bus(struct i2c_adapter *adapter,
 				 unsigned int flags)
 {
-	rt_mutex_lock(&adapter->bus_lock);
+	rt_mutex_lock_nested(&adapter->bus_lock, i2c_adapter_depth(adapter));
 }
 
 /**
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 300ab4b672e4..29646aa6132e 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -144,7 +144,7 @@ static void i2c_mux_lock_bus(struct i2c_adapter *adapter, unsigned int flags)
 	struct i2c_mux_priv *priv = adapter->algo_data;
 	struct i2c_adapter *parent = priv->muxc->parent;
 
-	rt_mutex_lock(&parent->mux_lock);
+	rt_mutex_lock_nested(&parent->mux_lock, i2c_adapter_depth(adapter));
 	if (!(flags & I2C_LOCK_ROOT_ADAPTER))
 		return;
 	i2c_lock_bus(parent, flags);
@@ -181,7 +181,7 @@ static void i2c_parent_lock_bus(struct i2c_adapter *adapter,
 	struct i2c_mux_priv *priv = adapter->algo_data;
 	struct i2c_adapter *parent = priv->muxc->parent;
 
-	rt_mutex_lock(&parent->mux_lock);
+	rt_mutex_lock_nested(&parent->mux_lock, i2c_adapter_depth(adapter));
 	i2c_lock_bus(parent, flags);
 }