All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander A Sverdlin <alexander.sverdlin@nokia.com>
To: linux-i2c@vger.kernel.org
Cc: Alexander Sverdlin <alexander.sverdlin@nokia.com>,
	Wolfram Sang <wsa@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: [PATCH] i2c: core: Workaround false-positive LOCKDEP in delete_device
Date: Tue, 17 May 2022 09:55:18 +0200	[thread overview]
Message-ID: <20220517075518.43613-1-alexander.sverdlin@nokia.com> (raw)

From: Alexander Sverdlin <alexander.sverdlin@nokia.com>

Drop the mutex earlier in the loop so that LOCKDEP is not being provoked:

WARNING: possible circular locking dependency detected
.../9201 is trying to acquire lock:
ffffff85656d4e78 (kn->count#159){++++}, at: kernfs_remove_by_name_ns+0x5c/0xac

but task is already holding lock:
ffffff857b329e80 (&adap->userspace_clients_lock){+.+.}, at: i2c_sysfs_delete_device+0x8c/0x1f0

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&adap->userspace_clients_lock){+.+.}:
       __mutex_lock+0xa4/0x924
       mutex_lock_nested+0x48/0x5c
       i2c_sysfs_new_device+0x108/0x220
       dev_attr_store+0x48/0x60
       sysfs_kf_write+0x54/0x80
       kernfs_fop_write+0x120/0x240
       __vfs_write+0x4c/0x90
       vfs_write+0xe8/0x1d0
       ksys_write+0x7c/0x104
       __arm64_sys_write+0x28/0x3c
       el0_svc_handler+0x90/0x200
       el0_svc+0x8/0x16c

-> #0 (kn->count#159){++++}:
       __lock_acquire+0xe8c/0x1a90
       lock_acquire+0xd8/0x270
       __kernfs_remove+0x2fc/0x360
       kernfs_remove_by_name_ns+0x5c/0xac
       remove_files+0x48/0x90
       sysfs_remove_group+0x50/0xa0
       sysfs_remove_groups+0x44/0x60
       device_remove_attrs+0x60/0x80
       device_del+0x134/0x360
       device_unregister+0x28/0x80
       i2c_del_adapter+0x210/0x2a4
       i2c_mux_del_adapters+0xa4/0xfc
       pca9641_remove+0x24/0x34 [i2c_mux_pca9641]
       i2c_device_remove+0x60/0xd4
       __device_release_driver+0x164/0x1f4
       device_release_driver+0x38/0x4c
       bus_remove_device+0xe0/0x15c
       device_del+0x13c/0x360
       device_unregister+0x28/0x80
       i2c_unregister_device+0x5c/0x70
       i2c_sysfs_delete_device+0x1b8/0x1f0
       dev_attr_store+0x48/0x60
       sysfs_kf_write+0x54/0x80
       kernfs_fop_write+0x120/0x240
       __vfs_write+0x4c/0x90
       vfs_write+0xe8/0x1d0
       ksys_write+0x7c/0x104
       __arm64_sys_write+0x28/0x3c
       el0_svc_handler+0x90/0x200
       el0_svc+0x8/0x16c

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&adap->userspace_clients_lock);
                               lock(kn->count#159);
                               lock(&adap->userspace_clients_lock);
  lock(kn->count#159);

 *** DEADLOCK ***

5 locks held by .../9201:
 #0: ffffff83f29c3ce0 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x74/0xe0
 #1: ffffff857a2f0410 (sb_writers#4){.+.+}, at: vfs_write+0x174/0x1d0
 #2: ffffff856bbbe680 (&of->mutex){+.+.}, at: kernfs_fop_write+0xf0/0x240
 #3: ffffff857b329e80 (&adap->userspace_clients_lock){+.+.}, at: i2c_sysfs_delete_device+0x8c/0x1f0
 #4: ffffff83f134ad80 (&dev->mutex){....}, at: device_release_driver+0x2c/0x4c

stack backtrace:
Call trace:
 dump_backtrace+0x0/0x180
 show_stack+0x28/0x3c
 dump_stack+0xf4/0x150
 print_circular_bug+0x21c/0x22c
 check_noncircular+0x15c/0x1e0
 __lock_acquire+0xe8c/0x1a90
 lock_acquire+0xd8/0x270
 __kernfs_remove+0x2fc/0x360
 kernfs_remove_by_name_ns+0x5c/0xac
 remove_files+0x48/0x90
 sysfs_remove_group+0x50/0xa0
 sysfs_remove_groups+0x44/0x60
 device_remove_attrs+0x60/0x80
 device_del+0x134/0x360
 device_unregister+0x28/0x80
 i2c_del_adapter+0x210/0x2a4
 i2c_mux_del_adapters+0xa4/0xfc
 pca9641_remove+0x24/0x34 [i2c_mux_pca9641]
 i2c_device_remove+0x60/0xd4
 __device_release_driver+0x164/0x1f4
 device_release_driver+0x38/0x4c
 bus_remove_device+0xe0/0x15c
 device_del+0x13c/0x360
 device_unregister+0x28/0x80
 i2c_unregister_device+0x5c/0x70
 i2c_sysfs_delete_device+0x1b8/0x1f0
 dev_attr_store+0x48/0x60
 sysfs_kf_write+0x54/0x80
 kernfs_fop_write+0x120/0x240
 __vfs_write+0x4c/0x90
 vfs_write+0xe8/0x1d0
 ksys_write+0x7c/0x104
 __arm64_sys_write+0x28/0x3c
 el0_svc_handler+0x90/0x200
 el0_svc+0x8/0x16c

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
---
 drivers/i2c/i2c-core-base.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index d43db2c..bd2e3e4 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1272,9 +1272,14 @@ delete_device_store(struct device *dev, struct device_attribute *attr,
 				 "delete_device", client->name, client->addr);
 
 			list_del(&client->detected);
+			/*
+			 * We drop the mutex here, because device unregister
+			 * will take sysfs lock (kn->count) which, as LOCKDEP
+			 * would think, depends on this mutex
+			 */
+			mutex_unlock(&adap->userspace_clients_lock);
 			i2c_unregister_device(client);
-			res = count;
-			break;
+			return count;
 		}
 	}
 	mutex_unlock(&adap->userspace_clients_lock);
-- 
2.10.2


             reply	other threads:[~2022-05-17  7:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-17  7:55 Alexander A Sverdlin [this message]
2022-05-21  9:50 ` [PATCH] i2c: core: Workaround false-positive LOCKDEP in delete_device Wolfram Sang
2022-05-23  7:15   ` Alexander Sverdlin

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=20220517075518.43613-1-alexander.sverdlin@nokia.com \
    --to=alexander.sverdlin@nokia.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wsa@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.