linux-kernel - [PATCH v2 06/10] blk-debugfs: upgrade warns to BUG

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]

Date:   Sun, 19 Apr 2020 19:45:25 +0000
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     axboe@...nel.dk, viro@...iv.linux.org.uk, bvanassche@....org,
        gregkh@...uxfoundation.org, rostedt@...dmis.org, mingo@...hat.com,
        jack@...e.cz, ming.lei@...hat.com, nstange@...e.de,
        akpm@...ux-foundation.org
Cc:     mhocko@...e.com, yukuai3@...wei.com, linux-block@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Luis Chamberlain <mcgrof@...nel.org>
Subject: [PATCH v2 06/10] blk-debugfs: upgrade warns to BUG_ON() if directory is already found

Now that we have moved release_queue from being asynchronous to
synchronous, and fixed how we use the debugfs directory with blktrace
we should no longer have expected races with device removal/addition
and other operations with the debugfs directory.

If races do happen however, we want to be informed of *how* this races
happens rather than dealing with a debugfs splat, so upgrading this to a
BUG_ON() should capture better information about how this can happen
in the future.

This is specially true these days with funky reproducers in userspace
for which we have no access to, but only a bug splat.

Note that on addition the gendisk kobject is used as the parent for the
request_queue kobject, and upon removal, now that request_queue removal
is synchronous, blk_unregister_queue() is called prior to the gendisk
device_del(). This means we expect to see a sysfs clash first now prior
to running into a race with the debugfs dentry; so this bug would be
considered highly unlikely.

Signed-off-by: Luis Chamberlain <mcgrof@...nel.org>
---
 block/blk-debugfs.c | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/block/blk-debugfs.c b/block/blk-debugfs.c
index d84038bce0a5..761318dcbf40 100644
--- a/block/blk-debugfs.c
+++ b/block/blk-debugfs.c
@@ -19,16 +19,8 @@ void blk_debugfs_register(void)

 int __must_check blk_queue_debugfs_register(struct request_queue *q)
 {
-	struct dentry *dir = NULL;
-
 	/* This can happen if we have a bug in the lower layers */
-	dir = debugfs_lookup(kobject_name(q->kobj.parent), blk_debugfs_root);
-	if (dir) {
-		pr_warn("%s: registering request_queue debugfs directory twice is not allowed\n",
-			kobject_name(q->kobj.parent));
-		dput(dir);
-		return -EALREADY;
-	}
+	BUG_ON(debugfs_lookup(kobject_name(q->kobj.parent), blk_debugfs_root));

 	q->debugfs_dir = debugfs_create_dir(kobject_name(q->kobj.parent),
 					    blk_debugfs_root);
-- 
2.25.1