From patchwork Sun Apr 19 19:45:20 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11497891 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0BDE414DD for ; Sun, 19 Apr 2020 19:46:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E7E9A2145D for ; Sun, 19 Apr 2020 19:46:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587325589; bh=q4DCyWT4AgzypP+nfMyDtHXJy722L6tiNHo+S8Zk/SE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=dYQ4gU7UwpA7W8cHxVTvWD9n3QNdEVuqkMIVf9cJRkB1Vx+nrpR+ELqthQOfo2vzZ vEz3EFiTInXQUx/q7CKbRDc2ruwAGs0fY4zodoZ6FnVpNrjBkLLgLsUuuGWq3KP2io fRvyLEY+ARW0SNTqm4lo2CE6I+yO8O1fykffXTqA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726881AbgDSTq0 (ORCPT ); Sun, 19 Apr 2020 15:46:26 -0400 Received: from mail-pj1-f67.google.com ([209.85.216.67]:40274 "EHLO mail-pj1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726563AbgDSTpn (ORCPT ); Sun, 19 Apr 2020 15:45:43 -0400 Received: by mail-pj1-f67.google.com with SMTP id a22so3475529pjk.5; Sun, 19 Apr 2020 12:45:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=r6zFNIw10vgpvTX2Zn0RR00QHrc+pqJgnMvwYTYZ65c=; b=gcFAIB6IpOolxYN7xaroQI0p1Bj0Q616EeI6dpoWhOdJnLYvzW4TCt5zqHVszqboPb nRciDBwQr6iIP0AZqZuSoHm+wslvjneMo1RDmYvGQTKrefP6pv+ohBizw86vxHT5/oyb c3uYhfsx81pFfSWczKZ4NTRGbbUC/TpR8JJMWgmFRd9zr36JXM2cOn48zBZ1DBrjjuVa 49Eq43yb8NjiC/2u1B9yuKK3uiS6rS/gPlr+wVXkbQBKTYJbQNteOKgy68+jQ+1eWXgz nIgwAcWKMGADGJ4LmVUGDAUMDrXp76GWpk2BQBpBI3uv6hCEspTCpfMaTd6ZaJ1Hn3hr s32Q== X-Gm-Message-State: AGi0PublMAwLieWZgSTb4+re5HziQdFDYF7i+qS0Gex7xP5pClq1bjRO FyOjDdyc/rWpxHxL1m16ank= X-Google-Smtp-Source: APiQypIlsNOV5Ts+IvXr65G+RjFeJz8dWYTQcX7sXrFlOO+fyRvy9LWo2BPInwdwLagGF64+QL93qg== X-Received: by 2002:a17:902:44d:: with SMTP id 71mr14197849ple.123.1587325541529; Sun, 19 Apr 2020 12:45:41 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id r26sm20777722pfq.75.2020.04.19.12.45.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2020 12:45:39 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 898B9404EF; Sun, 19 Apr 2020 19:45:38 +0000 (UTC) From: Luis Chamberlain To: axboe@kernel.dk, viro@zeniv.linux.org.uk, bvanassche@acm.org, gregkh@linuxfoundation.org, rostedt@goodmis.org, mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com, nstange@suse.de, akpm@linux-foundation.org Cc: mhocko@suse.com, yukuai3@huawei.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Luis Chamberlain , Omar Sandoval , Hannes Reinecke , Michal Hocko Subject: [PATCH v2 01/10] block: move main block debugfs initialization to its own file Date: Sun, 19 Apr 2020 19:45:20 +0000 Message-Id: <20200419194529.4872-2-mcgrof@kernel.org> X-Mailer: git-send-email 2.23.0.rc1 In-Reply-To: <20200419194529.4872-1-mcgrof@kernel.org> References: <20200419194529.4872-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org make_request-based drivers and and request-based drivers share some some debugfs code. By moving this into its own file it makes it easier to expand and audit this shared code. This patch contains no functional changes. Cc: Bart Van Assche Cc: Omar Sandoval Cc: Hannes Reinecke Cc: Nicolai Stange Cc: Greg Kroah-Hartman Cc: Michal Hocko Cc: yu kuai Reviewed-by: Greg Kroah-Hartman Reviewed-by: Bart Van Assche Signed-off-by: Luis Chamberlain --- block/Makefile | 1 + block/blk-core.c | 9 +-------- block/blk-debugfs.c | 15 +++++++++++++++ block/blk.h | 7 +++++++ 4 files changed, 24 insertions(+), 8 deletions(-) create mode 100644 block/blk-debugfs.c diff --git a/block/Makefile b/block/Makefile index 206b96e9387f..1d3ab20505d8 100644 --- a/block/Makefile +++ b/block/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_BLOCK) := bio.o elevator.o blk-core.o blk-sysfs.o \ blk-mq-sysfs.o blk-mq-cpumap.o blk-mq-sched.o ioctl.o \ genhd.o ioprio.o badblocks.o partitions/ blk-rq-qos.o +obj-$(CONFIG_DEBUG_FS) += blk-debugfs.o obj-$(CONFIG_BOUNCE) += bounce.o obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_ioctl.o obj-$(CONFIG_BLK_DEV_BSG) += bsg.o diff --git a/block/blk-core.c b/block/blk-core.c index 7e4a1da0715e..5aaae7a1b338 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -48,10 +48,6 @@ #include "blk-pm.h" #include "blk-rq-qos.h" -#ifdef CONFIG_DEBUG_FS -struct dentry *blk_debugfs_root; -#endif - EXPORT_TRACEPOINT_SYMBOL_GPL(block_bio_remap); EXPORT_TRACEPOINT_SYMBOL_GPL(block_rq_remap); EXPORT_TRACEPOINT_SYMBOL_GPL(block_bio_complete); @@ -1796,10 +1792,7 @@ int __init blk_dev_init(void) blk_requestq_cachep = kmem_cache_create("request_queue", sizeof(struct request_queue), 0, SLAB_PANIC, NULL); - -#ifdef CONFIG_DEBUG_FS - blk_debugfs_root = debugfs_create_dir("block", NULL); -#endif + blk_debugfs_register(); return 0; } diff --git a/block/blk-debugfs.c b/block/blk-debugfs.c new file mode 100644 index 000000000000..19091e1effc0 --- /dev/null +++ b/block/blk-debugfs.c @@ -0,0 +1,15 @@ +// SPDX-License-Identifier: GPL-2.0 + +/* + * Shared request-based / make_request-based functionality + */ +#include +#include +#include + +struct dentry *blk_debugfs_root; + +void blk_debugfs_register(void) +{ + blk_debugfs_root = debugfs_create_dir("block", NULL); +} diff --git a/block/blk.h b/block/blk.h index 0a94ec68af32..86a66b614f08 100644 --- a/block/blk.h +++ b/block/blk.h @@ -487,5 +487,12 @@ struct request_queue *__blk_alloc_queue(int node_id); int __bio_add_pc_page(struct request_queue *q, struct bio *bio, struct page *page, unsigned int len, unsigned int offset, bool *same_page); +#ifdef CONFIG_DEBUG_FS +void blk_debugfs_register(void); +#else +static inline void blk_debugfs_register(void) +{ +} +#endif /* CONFIG_DEBUG_FS */ #endif /* BLK_INTERNAL_H */ From patchwork Sun Apr 19 19:45:21 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11497899 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id B20C61667 for ; Sun, 19 Apr 2020 19:46:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9A9D021927 for ; Sun, 19 Apr 2020 19:46:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587325594; bh=mEncwTlPQ/QwNpZrdXPAXFRaRHDlumsKGBnaQpNcAaM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=ro5Wyyr6MgfY+2HQf7+mIvHZ1cY65+FA+0Rmi0a2ja6n+iGk0V2vTu5qMVatzxXD6 CNB25XJDcHyjNkr0wIilnO/sc7XIaPCV2OYJD1U1GOfgmKEeAsg7zY0KeEtm6soGiA g8ilu5y3b0cCUGPW+abMmFISXnHEGvVaNuy51rpI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726601AbgDSTpn (ORCPT ); Sun, 19 Apr 2020 15:45:43 -0400 Received: from mail-pj1-f67.google.com ([209.85.216.67]:33992 "EHLO mail-pj1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726557AbgDSTpn (ORCPT ); Sun, 19 Apr 2020 15:45:43 -0400 Received: by mail-pj1-f67.google.com with SMTP id q16so3964021pje.1; Sun, 19 Apr 2020 12:45:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=M3p9eZkDL4rEHA+mf+DziMPxePr/ZoUmDl5szec5+p8=; b=kR7P3BpAumPQtEMpAMmv0uihs24LdWxJtNtJ2omS7Ox0qs9r5J2qp9RrtvD88kWJY1 ij8zHez55DsUUyQZWftPGU1YUdc8en78zP8XOvjclDo1rvYNdRXFKnc3RyI71JVcWsiJ bCieHoiHNVERbif90e3YALOBbdp+lt2cRnllLMiELsK2jfJEQk+2+WFWS5FIGgad9vN7 Yq3Yj5/Cz80aSvUyHNUvKv8styN7QUgVcUuRotby0/HidFwnpisc8UtwedwlcYPJPr9d aUp3+zepgDIPzVZ+iHZRafmCRC+9gDXhAWr1fuwzWFR+EtKXxZeSmzAOHOa2IfggiSI+ Ir3A== X-Gm-Message-State: AGi0PuaJXAlcfUFCX6nxyLaZHUjg6T9zn9mmnYE2mo9fNogCLeaokZ1Y EVtbjyw4CmdDM1+UtiB5UDE= X-Google-Smtp-Source: APiQypKEQ+ZAqACW0RZLGTrbfImbk5QqwTv9Koug1Ir4h4Bs5C6QKAeh0qwqzCBFedbk3w1nTzpjvQ== X-Received: by 2002:a17:90a:5b:: with SMTP id 27mr16351976pjb.190.1587325542367; Sun, 19 Apr 2020 12:45:42 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id v4sm25201600pfb.31.2020.04.19.12.45.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2020 12:45:39 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 99AAB40E7B; Sun, 19 Apr 2020 19:45:38 +0000 (UTC) From: Luis Chamberlain To: axboe@kernel.dk, viro@zeniv.linux.org.uk, bvanassche@acm.org, gregkh@linuxfoundation.org, rostedt@goodmis.org, mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com, nstange@suse.de, akpm@linux-foundation.org Cc: mhocko@suse.com, yukuai3@huawei.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Luis Chamberlain Subject: [PATCH v2 02/10] blktrace: move blktrace debugfs creation to helper function Date: Sun, 19 Apr 2020 19:45:21 +0000 Message-Id: <20200419194529.4872-3-mcgrof@kernel.org> X-Mailer: git-send-email 2.23.0.rc1 In-Reply-To: <20200419194529.4872-1-mcgrof@kernel.org> References: <20200419194529.4872-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Move the work to create the debugfs directory used into a helper. It will make further checks easier to read. This commit introduces no functional changes. Signed-off-by: Luis Chamberlain Reviewed-by: Bart Van Assche --- kernel/trace/blktrace.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c index ca39dc3230cb..2c6e6c386ace 100644 --- a/kernel/trace/blktrace.c +++ b/kernel/trace/blktrace.c @@ -468,6 +468,18 @@ static void blk_trace_setup_lba(struct blk_trace *bt, } } +static struct dentry *blk_trace_debugfs_dir(struct blk_user_trace_setup *buts, + struct blk_trace *bt) +{ + struct dentry *dir = NULL; + + dir = debugfs_lookup(buts->name, blk_debugfs_root); + if (!dir) + bt->dir = dir = debugfs_create_dir(buts->name, blk_debugfs_root); + + return dir; +} + /* * Setup everything required to start tracing */ @@ -509,9 +521,7 @@ static int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev, ret = -ENOENT; - dir = debugfs_lookup(buts->name, blk_debugfs_root); - if (!dir) - bt->dir = dir = debugfs_create_dir(buts->name, blk_debugfs_root); + dir = blk_trace_debugfs_dir(buts, bt); bt->dev = dev; atomic_set(&bt->dropped, 0); From patchwork Sun Apr 19 19:45:22 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11497851 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 5CE9D1667 for ; Sun, 19 Apr 2020 19:45:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 24EA321D79 for ; Sun, 19 Apr 2020 19:45:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587325553; bh=Vr8cySaXHFKyUwhUDcTGmTrnhaXKZVab78M4h15jOnA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=hWO6MkctYa62+zCot/vLXM2cEXIrLjjmwiE1Dhbtw6+1DIE4grqpYdCnrCYiTA/c0 S/uiCAAdm2oMeuHWIvAKy5Xz1IjO5cGGiPQ17HYodZUgLDGV5XmHLp9Uiiweu66bS6 tZaSmWC6UG5+Yn3qksGzk40HPyuWQYp8dRv9wzYs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726809AbgDSTpv (ORCPT ); Sun, 19 Apr 2020 15:45:51 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:41478 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726760AbgDSTpt (ORCPT ); Sun, 19 Apr 2020 15:45:49 -0400 Received: by mail-pg1-f193.google.com with SMTP id h69so3961444pgc.8; Sun, 19 Apr 2020 12:45:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=NfZ0CGpXM408BLI+JTnLaP9+hTWHS+ak5H64DsHwe+U=; b=HXEbvziQVPWsqvdqi9Z5q4opX7eVzv+UiSo2gIPKdj2N27qQA1epZxa/pES2sQ38Kf 3qFakPojpxGJgsIz9p2koUMYlRq85vtsENdxSnXhIVQphKf/uzOwxuECrlwo2UxKPgUK 7n9AmFjwI2c6LkciTyWXYpMtVOVgVpSAGK5sZRVGke1Jm+0yy48eWbiHexfuU4UDXXEo k/pHBmG3aHRSkoN2ySV7PRptiw7i0SESYqXjMFNeJKJWLyAynFpg/8sb6d/fk9DxsBPe mlMSeNX1Fy5Yy8GKkUAIR6TcEbjZaODxKY7ht0nYQrntoId4XiCyW/j1sw0vSELrdRDu 7I1w== X-Gm-Message-State: AGi0PuYEZvt9YnX+DsVkhk69UdLpEu3GcbsrhbbLEtI5ddL5vuZLxiPB YrMzgK/LXtg/ayKk51roldk= X-Google-Smtp-Source: APiQypJ6bnJ0rlwGymcyw63MUruuzFDFbkQ4D0UHyI3+4jLivHWMyxrjz3q+GZQtHyRNB34mhpOi4Q== X-Received: by 2002:a63:de41:: with SMTP id y1mr12910054pgi.176.1587325547486; Sun, 19 Apr 2020 12:45:47 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id t23sm11668393pjq.27.2020.04.19.12.45.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2020 12:45:43 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id AEEA741D12; Sun, 19 Apr 2020 19:45:38 +0000 (UTC) From: Luis Chamberlain To: axboe@kernel.dk, viro@zeniv.linux.org.uk, bvanassche@acm.org, gregkh@linuxfoundation.org, rostedt@goodmis.org, mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com, nstange@suse.de, akpm@linux-foundation.org Cc: mhocko@suse.com, yukuai3@huawei.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Luis Chamberlain , Omar Sandoval , Hannes Reinecke , Michal Hocko , syzbot+603294af2d01acfdd6da@syzkaller.appspotmail.com Subject: [PATCH v2 03/10] blktrace: fix debugfs use after free Date: Sun, 19 Apr 2020 19:45:22 +0000 Message-Id: <20200419194529.4872-4-mcgrof@kernel.org> X-Mailer: git-send-email 2.23.0.rc1 In-Reply-To: <20200419194529.4872-1-mcgrof@kernel.org> References: <20200419194529.4872-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On commit 6ac93117ab00 ("blktrace: use existing disk debugfs directory") merged on v4.12 Omar fixed the original blktrace code for request-based drivers (multiqueue). This however left in place a possible crash, if you happen to abuse blktrace in a way it was not intended, and even more so with our current asynchronous request_queue removal. Namely, if you loop adding a device, setup the blktrace with BLKTRACESETUP, forget to BLKTRACETEARDOWN, and then just remove the device you end up with a panic: [ 107.193134] debugfs: Directory 'loop0' with parent 'block' already present! [ 107.254615] BUG: kernel NULL pointer dereference, address: 00000000000000a0 [ 107.258785] #PF: supervisor write access in kernel mode [ 107.262035] #PF: error_code(0x0002) - not-present page [ 107.264106] PGD 0 P4D 0 [ 107.264404] Oops: 0002 [#1] SMP NOPTI [ 107.264803] CPU: 8 PID: 674 Comm: kworker/8:2 Tainted: G E 5.6.0-rc7-next-20200327 #1 [ 107.265712] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014 [ 107.266553] Workqueue: events __blk_release_queue [ 107.267051] RIP: 0010:down_write+0x15/0x40 [ 107.267488] Code: eb ca e8 ee a5 8d ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 55 48 89 fd e8 52 db ff ff 31 c0 ba 01 00 00 00 48 0f b1 55 00 75 0f 65 48 8b 04 25 c0 8b 01 00 48 89 45 08 5d [ 107.269300] RSP: 0018:ffff9927c06efda8 EFLAGS: 00010246 [ 107.269841] RAX: 0000000000000000 RBX: ffff8be7e73b0600 RCX: ffffff8100000000 [ 107.270559] RDX: 0000000000000001 RSI: ffffff8100000000 RDI: 00000000000000a0 [ 107.271281] RBP: 00000000000000a0 R08: ffff8be7ebc80fa8 R09: ffff8be7ebc80fa8 [ 107.272001] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 107.272722] R13: ffff8be7efc30400 R14: ffff8be7e0571200 R15: 00000000000000a0 [ 107.273475] FS: 0000000000000000(0000) GS:ffff8be7efc00000(0000) knlGS:0000000000000000 [ 107.274346] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 107.274968] CR2: 00000000000000a0 CR3: 000000042abee003 CR4: 0000000000360ee0 [ 107.275710] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 107.276465] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 107.277214] Call Trace: [ 107.277532] simple_recursive_removal+0x4e/0x2e0 [ 107.278049] ? debugfs_remove+0x60/0x60 [ 107.278493] debugfs_remove+0x40/0x60 [ 107.278922] blk_trace_free+0xd/0x50 [ 107.279339] __blk_trace_remove+0x27/0x40 [ 107.279797] blk_trace_shutdown+0x30/0x40 [ 107.280256] __blk_release_queue+0xab/0x110 [ 107.280734] process_one_work+0x1b4/0x380 [ 107.281194] worker_thread+0x50/0x3c0 [ 107.281622] kthread+0xf9/0x130 [ 107.281994] ? process_one_work+0x380/0x380 [ 107.282467] ? kthread_park+0x90/0x90 [ 107.282895] ret_from_fork+0x1f/0x40 [ 107.283316] Modules linked in: loop(E) [ 107.288562] CR2: 00000000000000a0 [ 107.288957] ---[ end trace b885d243d441bbce ]--- This splat happens to be very similar to the one reported via kernel.org korg#205713, only that korg#205713 was for v4.19.83 and the above now includes the simple_recursive_removal() introduced via commit a3d1e7eb5abe ("simple_recursive_removal(): kernel-side rm -rf for ramfs-style filesystems") merged on v5.6. korg#205713 then was used to create CVE-2019-19770 and claims that the bug is in a use-after-free in the debugfs core code. The implications of this being a generic UAF on debugfs would be much more severe, as it would imply parent dentries can sometimes not be positive, which we hold by design is just not possible. Below is the splat explained with a bit more details, explaining what is happening in userspace, kernel, and a print of the CPU on, which the code runs on: load loopback module [ 13.603371] == blk_mq_debugfs_register(12) start [ 13.604040] == blk_mq_debugfs_register(12) q->debugfs_dir created [ 13.604934] == blk_mq_debugfs_register(12) end [ 13.627382] == blk_mq_debugfs_register(12) start [ 13.628041] == blk_mq_debugfs_register(12) q->debugfs_dir created [ 13.629240] == blk_mq_debugfs_register(12) end [ 13.651667] == blk_mq_debugfs_register(12) start [ 13.652836] == blk_mq_debugfs_register(12) q->debugfs_dir created [ 13.655107] == blk_mq_debugfs_register(12) end [ 13.684917] == blk_mq_debugfs_register(12) start [ 13.687876] == blk_mq_debugfs_register(12) q->debugfs_dir created [ 13.691588] == blk_mq_debugfs_register(13) end [ 13.707320] == blk_mq_debugfs_register(13) start [ 13.707863] == blk_mq_debugfs_register(13) q->debugfs_dir created [ 13.708856] == blk_mq_debugfs_register(13) end [ 13.735623] == blk_mq_debugfs_register(13) start [ 13.736656] == blk_mq_debugfs_register(13) q->debugfs_dir created [ 13.738411] == blk_mq_debugfs_register(13) end [ 13.763326] == blk_mq_debugfs_register(13) start [ 13.763972] == blk_mq_debugfs_register(13) q->debugfs_dir created [ 13.765167] == blk_mq_debugfs_register(13) end [ 13.779510] == blk_mq_debugfs_register(13) start [ 13.780522] == blk_mq_debugfs_register(13) q->debugfs_dir created [ 13.782338] == blk_mq_debugfs_register(13) end [ 13.783521] loop: module loaded LOOP_CTL_DEL(loop0) #1 [ 13.803550] = __blk_release_queue(4) start [ 13.807772] == blk_trace_shutdown(4) start [ 13.810749] == blk_trace_shutdown(4) end [ 13.813437] = __blk_release_queue(4) calling blk_mq_debugfs_unregister() [ 13.817593] ==== blk_mq_debugfs_unregister(4) begin [ 13.817621] ==== blk_mq_debugfs_unregister(4) debugfs_remove_recursive(q->debugfs_dir) [ 13.821203] ==== blk_mq_debugfs_unregister(4) end q->debugfs_dir is NULL [ 13.826166] = __blk_release_queue(4) blk_mq_debugfs_unregister() end [ 13.832992] = __blk_release_queue(4) end LOOP_CTL_ADD(loop0) #1 [ 13.843742] == blk_mq_debugfs_register(7) start [ 13.845569] == blk_mq_debugfs_register(7) q->debugfs_dir created [ 13.848628] == blk_mq_debugfs_register(7) end BLKTRACE_SETUP(loop0) #1 [ 13.850924] == blk_trace_ioctl(7, BLKTRACESETUP) start [ 13.852852] === do_blk_trace_setup(7) start [ 13.854580] === do_blk_trace_setup(7) creating directory [ 13.856620] === do_blk_trace_setup(7) using what debugfs_lookup() gave [ 13.860635] === do_blk_trace_setup(7) end with ret: 0 [ 13.862615] == blk_trace_ioctl(7, BLKTRACESETUP) end LOOP_CTL_DEL(loop0) #2 [ 13.883304] = __blk_release_queue(7) start [ 13.885324] == blk_trace_shutdown(7) start [ 13.887197] == blk_trace_shutdown(7) calling __blk_trace_remove() [ 13.889807] == __blk_trace_remove(7) start [ 13.891669] === blk_trace_cleanup(7) start [ 13.911656] ====== blk_trace_free(7) start This is a scheduled __blk_release_queue(). Note that at this point we know that the old device is gone as the gendisk removal is synchronous. LOOP_CTL_ADD(loop0) #2 [ 13.912709] == blk_mq_debugfs_register(2) start This is a *new* device, as we know the last one was removed synchronously. ---> From LOOP_CTL_DEL(loop0) #2 [ 13.915887] ====== blk_trace_free(7) end ---> From LOOP_CTL_ADD(loop0) #2 [ 13.918359] debugfs: Directory 'loop0' with parent 'block' already present! Above we have a case where the upon LOOP_CTL_ADD(loop) #2 the debugfs_create_dir() start_creating() call will have found an existing dentry, and return ERR_PTR(-EEXIST), and so the q->debugfs_dir will be initialized to NULL. This clash happens because an asynchronous __blk_release_queue() has been scheduled from the above LOOP_CTL_DEL(loop0) #2 call, and it has not yet removed the old loop0 debugfs directory. [ 13.926433] == blk_mq_debugfs_register(2) q->debugfs_dir created This is a huge assumption, since we never check for errors on blk_mq_debugfs_register(), and so the child files we need to create *can* simply be created using NULL as as the parent, in which case debugfs would use debugfs_mount->mnt_root as the parent. [ 13.930373] == blk_mq_debugfs_register(2) end BLKTRACE_SETUP(loop0) #2 [ 13.933961] == blk_trace_ioctl(2, BLKTRACESETUP) start [ 13.936758] === do_blk_trace_setup(2) start [ 13.938944] === do_blk_trace_setup(2) creating directory [ 13.941029] === do_blk_trace_setup(2) using what debugfs_lookup() gave Here debugfs_lookup() will have found the old debugfs directory, even though q->debugfs_dir was empty when initializing this device. So the files created can actually be created where they should have. ---> From LOOP_CTL_DEL(loop0) #2 [ 13.971046] === blk_trace_cleanup(7) end [ 13.973175] == __blk_trace_remove(7) end [ 13.975352] == blk_trace_shutdown(7) end [ 13.977415] = __blk_release_queue(7) calling blk_mq_debugfs_unregister() [ 13.980645] ==== blk_mq_debugfs_unregister(7) begin [ 13.980696] ==== blk_mq_debugfs_unregister(7) debugfs_remove_recursive(q->debugfs_dir) This is a continuation from the old scheduled __blk_release_queue(). It is using another request_queue structure than what the currently activated blktrace setup is using. Here now the dentry where the blktrace setup files were created on top of is gone. In fact, since debugfs_remove_recursive() is used, *all* of those blktrace debugfs files should have been removed as well, including the relay. This is despite the fact that the removal and blktrace setup are working on two different request_queue structures. [ 13.983118] ==== blk_mq_debugfs_unregister(7) end q->debugfs_dir is NULL [ 13.986945] = __blk_release_queue(7) blk_mq_debugfs_unregister() end [ 13.993155] = __blk_release_queue(7) end The scheduled __blk_release_queue completes finally. ---> From BLKTRACE_SETUP(loop0) #2 [ 13.995928] === do_blk_trace_setup(2) end with ret: 0 [ 13.997623] == blk_trace_ioctl(2, BLKTRACESETUP) end At this point the old blktrace *setup* is complete though, and let us recall that the old dentry is still used. But recall that we just had our old device removed, and since debugfs_remove_recursive() was used, so are all of its files. This request_queue however is still active. LOOP_CTL_DEL(loop0) #3 [ 14.035119] = __blk_release_queue(2) start [ 14.036925] == blk_trace_shutdown(2) start [ 14.038518] == blk_trace_shutdown(2) calling __blk_trace_remove() [ 14.040829] == __blk_trace_remove(2) start [ 14.042413] === blk_trace_cleanup(2) start This removal will cleanup the blktrace setup. Note the trap though, the blktrace setup will already have been cleaned up since the scheduled removal from instance #2 removed the files on the same debugfs path. The __blk_release_queue() is scheduled and is asynchronous so can continue later, and that is where the crash happens, on CPU 2. LOOP_CTL_ADD(loop0) #3 [ 14.072522] == blk_mq_debugfs_register(6) start ---> From LOOP_CTL_DEL(loop0) #3 [ 14.075151] ====== blk_trace_free(2) start ---> From LOOP_CTL_ADD(loop0) #3 [ 14.075882] == blk_mq_debugfs_register(6) q->debugfs_dir created ---> From LOOP_CTL_DEL(loop0) #3 The panic happens on CPU 2 when we continue with the old scheduled removal of the request_queue, which will run into a blktrace setup with NULL pointers. [ 14.078624] BUG: kernel NULL pointer dereference, address: 00000000000000a0 [ 14.084332] == blk_mq_debugfs_register(6) end [ 14.086971] #PF: supervisor write access in kernel mode [ 14.086974] #PF: error_code(0x0002) - not-present page [ 14.086977] PGD 0 P4D 0 [ 14.086984] Oops: 0002 [#1] SMP NOPTI [ 14.086990] CPU: 2 PID: 287 Comm: kworker/2:2 Tainted: G E 5.6.0-next-20200403+ #54 [ 14.086991] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014 [ 14.087002] Workqueue: events __blk_release_queue [ 14.087011] RIP: 0010:down_write+0x15/0x40 [ 14.090300] == blk_trace_ioctl(6, BLKTRACESETUP) start [ 14.093277] Code: eb ca e8 3e 34 8d ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 55 48 89 fd e8 52 db ff ff 31 c0 ba 01 00 00 00 48 0f b1 55 00 75 0f 65 48 8b 04 25 c0 8b 01 00 48 89 45 08 5d [ 14.093280] RSP: 0018:ffffc28a00533da8 EFLAGS: 00010246 [ 14.093284] RAX: 0000000000000000 RBX: ffff9f7a24d07980 RCX: ffffff8100000000 [ 14.093286] RDX: 0000000000000001 RSI: ffffff8100000000 RDI: 00000000000000a0 [ 14.093287] RBP: 00000000000000a0 R08: 0000000000000000 R09: 0000000000000019 [ 14.093289] R10: 0000000000000774 R11: 0000000000000000 R12: 0000000000000000 [ 14.093291] R13: ffff9f7a2fab0400 R14: ffff9f7a21dd1140 R15: 00000000000000a0 [ 14.093294] FS: 0000000000000000(0000) GS:ffff9f7a2fa80000(0000) knlGS:0000000000000000 [ 14.093296] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 14.093298] CR2: 00000000000000a0 CR3: 00000004293d2003 CR4: 0000000000360ee0 [ 14.093307] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 14.093308] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 14.093310] Call Trace: [ 14.093324] simple_recursive_removal+0x4e/0x2e0 [ 14.093330] ? debugfs_remove+0x60/0x60 [ 14.093334] debugfs_remove+0x40/0x60 [ 14.093339] blk_trace_free+0x20/0x70 [ 14.093346] __blk_trace_remove+0x54/0x90 [ 14.096704] === do_blk_trace_setup(6) start [ 14.098534] blk_trace_shutdown+0x74/0x80 [ 14.100958] === do_blk_trace_setup(6) creating directory [ 14.104575] __blk_release_queue+0xbe/0x160 [ 14.104580] process_one_work+0x1b4/0x380 [ 14.104585] worker_thread+0x50/0x3c0 [ 14.104589] kthread+0xf9/0x130 [ 14.104593] ? process_one_work+0x380/0x380 [ 14.104596] ? kthread_park+0x90/0x90 [ 14.104599] ret_from_fork+0x1f/0x40 [ 14.104603] Modules linked in: loop(E) xfs(E) libcrc32c(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) joydev(E) serio_raw(E) aesni_intel(E) glue_helper(E) virtio_balloon(E) evdev(E) crypto_simd(E) pcspkr(E) cryptd(E) i6300esb(E) button(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) virtio_net(E) net_failover(E) failover(E) virtio_blk(E) ata_generic(E) uhci_hcd(E) ata_piix(E) ehci_hcd(E) nvme(E) libata(E) crc32c_intel(E) usbcore(E) psmouse(E) nvme_core(E) virtio_pci(E) scsi_mod(E) virtio_ring(E) t10_pi(E) virtio(E) i2c_piix4(E) floppy(E) [ 14.107400] === do_blk_trace_setup(6) using what debugfs_lookup() gave [ 14.108939] CR2: 00000000000000a0 [ 14.110589] === do_blk_trace_setup(6) end with ret: 0 [ 14.111592] ---[ end trace 7a783b33b9614db9 ]--- The root cause to this issue is that debugfs_lookup() can find a previous incarnation's dir of the same name which is about to get removed from a not yet schedule work. When that happens, the the files are taken underneath the nose of the blktrace, and when it comes time to cleanup, these dentries are long gone because of a scheduled removal. This issue is happening because of two reasons: 1) The request_queue is currently removed asynchronously as of commit dc9edc44de6c ("block: Fix a blk_exit_rl() regression") merged on v4.12, this allows races with userspace which were not possible before unless as removal of a block device used to happen synchronously with its request_queue. One could however still parallelize blksetup calls while one loops on device addition and removal. 2) There are no errors checks when we create the debugfs directory, be it on init or for blktrace. The concept of when the directory *should* really exist is further complicated by the fact that we have asynchronous request_queue removal. And, we have no real sanity checks to ensure we don't re-create the queue debugfs directory. We can fix the UAF by using a debugfs directory which moving forward will always be accessible if debugfs is enabled, this way, its allocated and avaialble always for both request-based block drivers or make_request drivers (multiqueue) block drivers. We also put sanity checks in place to ensure that if the directory is found with debugfs_lookup() it is the dentry we expect. When doing a blktrace against a parition, we will always be creating a temporary debugfs directory, so ensure that only exists once as well to avoid issues against concurrent blktrace runs. Lastly, since we are now always creating the needed request_queue debugfs directory upon init, we can also take the initiative to proactively check against errors. We currently do not check for errors on add_disk() and friends, but we shouldn't make the issue any worse. This also simplifies the code considerably, with the only penalty now being that we're always creating the request queue debugfs directory for the request-based block device drivers. The UAF then is not a core debugfs issue, but instead a complex misuse of debugfs, and this issue can only be triggered if you are root. This issue can be reproduced with break-blktrace [2] using: break-blktrace -c 10 -d -s This patch fixes this issue. Note that there is also another respective UAF but from the ioctl path [3], this should also fix that issue. This patch then also disputes the severity of CVE-2019-19770 as this issue is only possible by being root and using blktrace. It is not a core debugfs issue. [0] https://bugzilla.kernel.org/show_bug.cgi?id=205713 [1] https://nvd.nist.gov/vuln/detail/CVE-2019-19770 [2] https://github.com/mcgrof/break-blktrace [3] https://lore.kernel.org/lkml/000000000000ec635b059f752700@google.com/ Cc: Bart Van Assche Cc: Omar Sandoval Cc: Hannes Reinecke Cc: Nicolai Stange Cc: Greg Kroah-Hartman Cc: Michal Hocko Cc: yu kuai Reported-by: syzbot+603294af2d01acfdd6da@syzkaller.appspotmail.com Fixes: 6ac93117ab00 ("blktrace: use existing disk debugfs directory") Signed-off-by: Luis Chamberlain --- block/blk-debugfs.c | 30 +++++++++++ block/blk-mq-debugfs.c | 5 -- block/blk-sysfs.c | 9 ++++ block/blk.h | 11 ++++ include/linux/blkdev.h | 5 +- include/linux/blktrace_api.h | 1 + kernel/trace/blktrace.c | 98 +++++++++++++++++++++++++++++++++--- 7 files changed, 146 insertions(+), 13 deletions(-) diff --git a/block/blk-debugfs.c b/block/blk-debugfs.c index 19091e1effc0..d84038bce0a5 100644 --- a/block/blk-debugfs.c +++ b/block/blk-debugfs.c @@ -3,6 +3,9 @@ /* * Shared request-based / make_request-based functionality */ + +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include #include #include @@ -13,3 +16,30 @@ void blk_debugfs_register(void) { blk_debugfs_root = debugfs_create_dir("block", NULL); } + +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; + } + + q->debugfs_dir = debugfs_create_dir(kobject_name(q->kobj.parent), + blk_debugfs_root); + if (!q->debugfs_dir) + return -ENOMEM; + + return 0; +} + +void blk_queue_debugfs_unregister(struct request_queue *q) +{ + debugfs_remove_recursive(q->debugfs_dir); + q->debugfs_dir = NULL; +} diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c index b3f2ba483992..bda9378eab90 100644 --- a/block/blk-mq-debugfs.c +++ b/block/blk-mq-debugfs.c @@ -823,9 +823,6 @@ void blk_mq_debugfs_register(struct request_queue *q) struct blk_mq_hw_ctx *hctx; int i; - q->debugfs_dir = debugfs_create_dir(kobject_name(q->kobj.parent), - blk_debugfs_root); - debugfs_create_files(q->debugfs_dir, q, blk_mq_debugfs_queue_attrs); /* @@ -856,9 +853,7 @@ void blk_mq_debugfs_register(struct request_queue *q) void blk_mq_debugfs_unregister(struct request_queue *q) { - debugfs_remove_recursive(q->debugfs_dir); q->sched_debugfs_dir = NULL; - q->debugfs_dir = NULL; } static void blk_mq_debugfs_register_ctx(struct blk_mq_hw_ctx *hctx, diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c index fca9b158f4a0..7072f408e69a 100644 --- a/block/blk-sysfs.c +++ b/block/blk-sysfs.c @@ -895,6 +895,7 @@ static void __blk_release_queue(struct work_struct *work) blk_trace_shutdown(q); + blk_queue_debugfs_unregister(q); if (queue_is_mq(q)) blk_mq_debugfs_unregister(q); @@ -975,6 +976,14 @@ int blk_register_queue(struct gendisk *disk) goto unlock; } + ret = blk_queue_debugfs_register(q); + if (ret) { + blk_trace_remove_sysfs(dev); + kobject_del(&q->kobj); + kobject_put(&dev->kobj); + goto unlock; + } + if (queue_is_mq(q)) { __blk_mq_register_dev(dev, q); blk_mq_debugfs_register(q); diff --git a/block/blk.h b/block/blk.h index 86a66b614f08..0cae5a92fe0b 100644 --- a/block/blk.h +++ b/block/blk.h @@ -489,10 +489,21 @@ int __bio_add_pc_page(struct request_queue *q, struct bio *bio, bool *same_page); #ifdef CONFIG_DEBUG_FS void blk_debugfs_register(void); +int __must_check blk_queue_debugfs_register(struct request_queue *q); +void blk_queue_debugfs_unregister(struct request_queue *q); #else static inline void blk_debugfs_register(void) { } + +static inline int __must_check blk_queue_debugfs_register(struct request_queue *q) +{ + return 0; +} + +static inline void blk_queue_debugfs_unregister(struct request_queue *q) +{ +} #endif /* CONFIG_DEBUG_FS */ #endif /* BLK_INTERNAL_H */ diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index 32868fbedc9e..cc43c8e6516c 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -569,8 +569,11 @@ struct request_queue { struct list_head tag_set_list; struct bio_set bio_split; -#ifdef CONFIG_BLK_DEBUG_FS +#ifdef CONFIG_DEBUG_FS + /* Used by block/blk-*debugfs.c and kernel/trace/blktrace.c */ struct dentry *debugfs_dir; +#endif +#ifdef CONFIG_BLK_DEBUG_FS struct dentry *sched_debugfs_dir; struct dentry *rqos_debugfs_dir; #endif diff --git a/include/linux/blktrace_api.h b/include/linux/blktrace_api.h index 3b6ff5902edc..43a6f98840dc 100644 --- a/include/linux/blktrace_api.h +++ b/include/linux/blktrace_api.h @@ -23,6 +23,7 @@ struct blk_trace { u32 pid; u32 dev; struct dentry *dir; + struct dentry *backing_dir; struct dentry *dropped_file; struct dentry *msg_file; struct list_head running_list; diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c index 2c6e6c386ace..8f87979d0971 100644 --- a/kernel/trace/blktrace.c +++ b/kernel/trace/blktrace.c @@ -3,6 +3,9 @@ * Copyright (C) 2006 Jens Axboe * */ + +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include #include #include @@ -311,7 +314,15 @@ static void blk_trace_free(struct blk_trace *bt) debugfs_remove(bt->msg_file); debugfs_remove(bt->dropped_file); relay_close(bt->rchan); - debugfs_remove(bt->dir); + /* + * backing_dir is set when we use the request_queue debugfs directory. + * Otherwise we are using a temporary directory created only for the + * purpose of blktrace. + */ + if (bt->backing_dir) + dput(bt->backing_dir); + else + debugfs_remove(bt->dir); free_percpu(bt->sequence); free_percpu(bt->msg_data); kfree(bt); @@ -468,16 +479,89 @@ static void blk_trace_setup_lba(struct blk_trace *bt, } } +static bool blk_trace_target_disk(const char *target, const char *diskname) +{ + if (strlen(target) != strlen(diskname)) + return false; + + if (!strncmp(target, diskname, + min_t(size_t, strlen(target), strlen(diskname)))) + return true; + + return false; +} + static struct dentry *blk_trace_debugfs_dir(struct blk_user_trace_setup *buts, + struct request_queue *q, struct blk_trace *bt) { struct dentry *dir = NULL; + /* This can only happen if we have a bug on our lower layers */ + if (!q->kobj.parent) { + pr_warn("%s: request_queue parent is gone\n", buts->name); + return NULL; + } + + /* + * From a sysfs kobject perspective, the request_queue sits on top of + * the gendisk, which has the name of the disk. We always create a + * debugfs directory upon init for this gendisk kobject, so we re-use + * that if blktrace is going to be done for it. + */ + if (blk_trace_target_disk(buts->name, kobject_name(q->kobj.parent))) { + if (!q->debugfs_dir) { + pr_warn("%s: expected request_queue debugfs_dir is not set\n", + buts->name); + return NULL; + } + /* + * debugfs_lookup() is used to ensure the directory is not + * taken from underneath us. We must dput() it later once + * done with it within blktrace. + */ + dir = debugfs_lookup(buts->name, blk_debugfs_root); + if (!dir) { + pr_warn("%s: expected request_queue debugfs_dir dentry is gone\n", + buts->name); + return NULL; + } + /* + * This is a reaffirmation that debugfs_lookup() shall always + * return the same dentry if it was already set. + */ + if (dir != q->debugfs_dir) { + dput(dir); + pr_warn("%s: expected dentry dir != q->debugfs_dir\n", + buts->name); + return NULL; + } + bt->backing_dir = q->debugfs_dir; + return bt->backing_dir; + } + + /* + * If not using blktrace on the gendisk, we are going to create a + * temporary debugfs directory for it, however this cannot be shared + * between two concurrent blktraces since the path is not unique, so + * ensure this is only done once. + */ dir = debugfs_lookup(buts->name, blk_debugfs_root); - if (!dir) - bt->dir = dir = debugfs_create_dir(buts->name, blk_debugfs_root); + if (dir) { + pr_warn("%s: temporary blktrace debugfs directory already present\n", + buts->name); + dput(dir); + return NULL; + } + + bt->dir = debugfs_create_dir(buts->name, blk_debugfs_root); + if (!bt->dir) { + pr_warn("%s: temporary blktrace debugfs directory could not be created\n", + buts->name); + return NULL; + } - return dir; + return bt->dir; } /* @@ -521,7 +605,9 @@ static int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev, ret = -ENOENT; - dir = blk_trace_debugfs_dir(buts, bt); + dir = blk_trace_debugfs_dir(buts, q, bt); + if (!dir) + goto err; bt->dev = dev; atomic_set(&bt->dropped, 0); @@ -561,8 +647,6 @@ static int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev, ret = 0; err: - if (dir && !bt->dir) - dput(dir); if (ret) blk_trace_free(bt); return ret; From patchwork Sun Apr 19 19:45:23 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11497887 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 8BD251667 for ; Sun, 19 Apr 2020 19:46:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 745FE22240 for ; Sun, 19 Apr 2020 19:46:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587325583; bh=xfrXAq2AJb+uDbbkWa8wqpwPlI7WKNYNY791aSwBb60=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=DgsazXrxObMczvEhHEX1J8BP22GHkeyJs5ITpRrlqPgR/7DY6ir0KDo878HJys/RX 03GVmHWTP+dzfMdJ6a8FIRHuYsUH79exOj9STn+U4sw6phnjEbLQwwD9ZF3A4c7vpR T/9qxzt8BNz8ryigYuAkgStgxSRQDOigCYXc0zDs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726703AbgDSTpp (ORCPT ); Sun, 19 Apr 2020 15:45:45 -0400 Received: from mail-pl1-f196.google.com ([209.85.214.196]:46946 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726557AbgDSTpo (ORCPT ); Sun, 19 Apr 2020 15:45:44 -0400 Received: by mail-pl1-f196.google.com with SMTP id n24so3113937plp.13; Sun, 19 Apr 2020 12:45:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=9g7E9FOCqFkTw5Ciwl4oviIYEaolA3qTKeuqYi+WFWY=; b=hquz/j2f5TEoms4TreW89NKm8PbaTwnlOLMSPKY7BaWhg1gcR9TYDtS8Q3Thma+FwF 8EyQ0vO9LGZMx9De2cLz4Fk91ijHuvjaIN/pXyjGwPTG8MBpQb81kuul3C2LlBntEjA9 fs5V7eudap99TtDhrTC1G5EL16oqEUvb5r+ksyr5VVUKuG7j+ICw1onNtFp8m5YunRxO lvMP2JOqzsCsf17lonSOGAWd3COCTzmUwSqAqUy+jlvHd42wRAIarN74sZ98LnRZB34T yDKQJjLDxEaD6kYNiVnNM+frluhHG3B+OLdxnU6NFXuVt3LRkp8OJ8w5zJzIkJMaro1Q D6BQ== X-Gm-Message-State: AGi0Puavai9+pVYnpKsuc8/+Ty5EtmivizXlDCLOwWiQ9HGH82wMJUSp GumJzstPgB4i/t8mhZtZwdM= X-Google-Smtp-Source: APiQypJoxji8jVoivsCdX8CVxNobx49lsjqDOTkkp7XYl1tqlZIyIvY4JGew9LHMikJ4JXQa3pufBA== X-Received: by 2002:a17:90a:26a2:: with SMTP id m31mr17228757pje.128.1587325543437; Sun, 19 Apr 2020 12:45:43 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id x13sm2715567pfq.154.2020.04.19.12.45.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2020 12:45:39 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id C119041D25; Sun, 19 Apr 2020 19:45:38 +0000 (UTC) From: Luis Chamberlain To: axboe@kernel.dk, viro@zeniv.linux.org.uk, bvanassche@acm.org, gregkh@linuxfoundation.org, rostedt@goodmis.org, mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com, nstange@suse.de, akpm@linux-foundation.org Cc: mhocko@suse.com, yukuai3@huawei.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Luis Chamberlain , Omar Sandoval , Hannes Reinecke , Michal Hocko Subject: [PATCH v2 04/10] block: revert back to synchronous request_queue removal Date: Sun, 19 Apr 2020 19:45:23 +0000 Message-Id: <20200419194529.4872-5-mcgrof@kernel.org> X-Mailer: git-send-email 2.23.0.rc1 In-Reply-To: <20200419194529.4872-1-mcgrof@kernel.org> References: <20200419194529.4872-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Commit dc9edc44de6c ("block: Fix a blk_exit_rl() regression") merged on v4.12 moved the work behind blk_release_queue() into a workqueue after a splat floated around which indicated some work on blk_release_queue() could sleep in blk_exit_rl(). This splat would be possible when a driver called blk_put_queue() or blk_cleanup_queue() (which calls blk_put_queue() as its final call) from an atomic context. blk_put_queue() decrements the refcount for the request_queue kobject, and upon reaching 0 blk_release_queue() is called. Although blk_exit_rl() is now removed through commit db6d9952356 ("block: remove request_list code"), we reserve the right to be able to sleep within blk_release_queue() context. If you see no other way and *have* be in atomic context when you driver calls the last blk_put_queue() you can always just increase your block device's reference count with bdgrab() as this can be done in atomic context and the request_queue removal would be left to upper layers later. We document this bit of tribal knowledge as well now, and adjust kdoc format a bit. We revert back to synchronous request_queue removal because asynchronous removal creates a regression with expected userspace interaction with several drivers. An example is when removing the loopback driver and issues ioctl from userspace to do so, upon return and if successful one expects the device to be removed. Moving to asynchronous request_queue removal could have broken many scripts which relied on the removal to have been completed if there was no error. Using asynchronous request_queue removal however has helped us find other bugs, in the future we can test what could break with this arrangement by enabling CONFIG_DEBUG_KOBJECT_RELEASE. Cc: Bart Van Assche Cc: Omar Sandoval Cc: Hannes Reinecke Cc: Nicolai Stange Cc: Greg Kroah-Hartman Cc: Michal Hocko Cc: yu kuai Reviewed-by: Ming Lei Suggested-by: Nicolai Stange Fixes: dc9edc44de6c ("block: Fix a blk_exit_rl() regression") Signed-off-by: Luis Chamberlain --- block/blk-core.c | 19 +++++++++++++++++++ block/blk-sysfs.c | 38 +++++++++++++++++--------------------- include/linux/blkdev.h | 2 -- 3 files changed, 36 insertions(+), 23 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index 5aaae7a1b338..19e24d7f40ef 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -301,6 +301,17 @@ void blk_clear_pm_only(struct request_queue *q) } EXPORT_SYMBOL_GPL(blk_clear_pm_only); +/** + * blk_put_queue - decrement the request_queue refcount + * + * @q: the request_queue structure to decrement the refcount for + * + * Decrements the refcount to the request_queue kobject, when this reaches + * 0 we'll have blk_release_queue() called. You should avoid calling + * this function in atomic context but if you really have to ensure you + * first refcount the block device with bdgrab() / bdput() so that the + * last decrement happens in blk_cleanup_queue(). + */ void blk_put_queue(struct request_queue *q) { kobject_put(&q->kobj); @@ -328,13 +339,21 @@ EXPORT_SYMBOL_GPL(blk_set_queue_dying); /** * blk_cleanup_queue - shutdown a request queue + * * @q: request queue to shutdown * * Mark @q DYING, drain all pending requests, mark @q DEAD, destroy and * put it. All future requests will be failed immediately with -ENODEV. + * + * You should not call this function in atomic context. If you need to + * refcount a request_queue in atomic context, instead refcount the + * block device with bdgrab() / bdput(). */ void blk_cleanup_queue(struct request_queue *q) { + /* cannot be called from atomic context */ + might_sleep(); + WARN_ON_ONCE(blk_queue_registered(q)); /* mark @q DYING, no new request or merges will be allowed afterwards */ diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c index 7072f408e69a..dc7985b7e4c5 100644 --- a/block/blk-sysfs.c +++ b/block/blk-sysfs.c @@ -860,22 +860,27 @@ static void blk_exit_queue(struct request_queue *q) bdi_put(q->backing_dev_info); } - /** - * __blk_release_queue - release a request queue - * @work: pointer to the release_work member of the request queue to be released + * blk_release_queue - release a request queue + * + * This function is called as part of the process when a block device is being + * unregistered. Releasing a request queue starts with blk_cleanup_queue(), + * which set the appropriate flags and then calls blk_put_queue() as the last + * step. blk_put_queue() decrements the reference counter of the request queue + * and once the reference counter reaches zero, this function is called to + * release all allocated resources of the request queue. * - * Description: - * This function is called when a block device is being unregistered. The - * process of releasing a request queue starts with blk_cleanup_queue, which - * set the appropriate flags and then calls blk_put_queue, that decrements - * the reference counter of the request queue. Once the reference counter - * of the request queue reaches zero, blk_release_queue is called to release - * all allocated resources of the request queue. + * This function can sleep, and so we must ensure that the very last + * blk_put_queue() is never called from atomic context. + * + * @kobj: pointer to a kobject, who's container is a request_queue */ -static void __blk_release_queue(struct work_struct *work) +static void blk_release_queue(struct kobject *kobj) { - struct request_queue *q = container_of(work, typeof(*q), release_work); + struct request_queue *q = + container_of(kobj, struct request_queue, kobj); + + might_sleep(); if (test_bit(QUEUE_FLAG_POLL_STATS, &q->queue_flags)) blk_stat_remove_callback(q, q->poll_cb); @@ -905,15 +910,6 @@ static void __blk_release_queue(struct work_struct *work) call_rcu(&q->rcu_head, blk_free_queue_rcu); } -static void blk_release_queue(struct kobject *kobj) -{ - struct request_queue *q = - container_of(kobj, struct request_queue, kobj); - - INIT_WORK(&q->release_work, __blk_release_queue); - schedule_work(&q->release_work); -} - static const struct sysfs_ops queue_sysfs_ops = { .show = queue_attr_show, .store = queue_attr_store, diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index cc43c8e6516c..81f7ddb1587e 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -582,8 +582,6 @@ struct request_queue { size_t cmd_size; - struct work_struct release_work; - #define BLK_MAX_WRITE_HINTS 5 u64 write_hints[BLK_MAX_WRITE_HINTS]; }; From patchwork Sun Apr 19 19:45:24 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11497881 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id BCD04174A for ; Sun, 19 Apr 2020 19:46:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A525821973 for ; Sun, 19 Apr 2020 19:46:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587325577; bh=T0GBP5za7TNf86ChX/6yYRpbASDDEiyRtBa4SItL2YQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=VUEuPnAii87uWFAqrCldes3jiNhMuvC9ST/5z6yOUIUsXWhrO11M7WZuQFfp0hJ1j QQ0WC6WXUkGmv1DkbUMyyYpcDH89V38BH+NabjziviEPb0AyDwv3FIHzvPHPTbSMk1 8AY5/hpw1tAb0+fhYfqp7yY2MabgzPUU+maewzLk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726738AbgDSTpr (ORCPT ); Sun, 19 Apr 2020 15:45:47 -0400 Received: from mail-pj1-f67.google.com ([209.85.216.67]:38204 "EHLO mail-pj1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726472AbgDSTpp (ORCPT ); Sun, 19 Apr 2020 15:45:45 -0400 Received: by mail-pj1-f67.google.com with SMTP id t40so3482889pjb.3; Sun, 19 Apr 2020 12:45:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=lw6CMKkQMFMHq+JcbcXT4Wlc0L0GLPdzzdwm/oxZzJU=; b=UINH5tFzNaYbytIVwIEd7daO7qPinwxDMDt4fbmxezvJjg/fxHHnDuUDhEnir2hNAz +sLT47iycwrBacAeyug2YjsYM1foG1peLFxeBhLZsYRim+WwMslw+QnFJJRtwKW1XbrW TnIJ/ZRvTN9ZXwZuCQozyiPUSgdWYhO9SkH5dM0/HOrWQht7IQxd9vk/q6oZJLAh7OD3 WCYxrsQZZ5/s+prZ4nntTEJPhreHd46i6EGaEKHhCvr1u+gUR9rN7LiaY27aSHEXbG1i jRTFxqDwXPMxU1xsBdK2ZM0DMnBFX1dwzLJ79DyEn14gC4eRmUD+UrRfPi4/NlpvLLaY 0iaQ== X-Gm-Message-State: AGi0PubVu5/nIMRrsfPgt72eLVabXsICncb4SKFSbYN3KCL/g4jXUGvf AfbHYn+1UWlOOSOVLObagcg= X-Google-Smtp-Source: APiQypJN2vwqTccXzDsvJU7EvUNJe2PNem8YoTGnDKMmXr8pElEwHxwiT3otlRDKvstViTgiEvw3Lw== X-Received: by 2002:a17:90a:d3ce:: with SMTP id d14mr2807740pjw.46.1587325544475; Sun, 19 Apr 2020 12:45:44 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id s63sm11869114pfb.44.2020.04.19.12.45.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2020 12:45:43 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id D737641EDA; Sun, 19 Apr 2020 19:45:38 +0000 (UTC) From: Luis Chamberlain To: axboe@kernel.dk, viro@zeniv.linux.org.uk, bvanassche@acm.org, gregkh@linuxfoundation.org, rostedt@goodmis.org, mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com, nstange@suse.de, akpm@linux-foundation.org Cc: mhocko@suse.com, yukuai3@huawei.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Luis Chamberlain Subject: [PATCH v2 05/10] blktrace: upgrade warns to BUG_ON() on unexpected circmunstances Date: Sun, 19 Apr 2020 19:45:24 +0000 Message-Id: <20200419194529.4872-6-mcgrof@kernel.org> X-Mailer: git-send-email 2.23.0.rc1 In-Reply-To: <20200419194529.4872-1-mcgrof@kernel.org> References: <20200419194529.4872-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Now that the request_queue removal is scheduled synchronously again, we have certain expectations on when debugfs directories used for blktrace are used. Any violation of these expecations should reflect core bugs we want to hear about. Signed-off-by: Luis Chamberlain --- kernel/trace/blktrace.c | 32 ++++++++------------------------ 1 file changed, 8 insertions(+), 24 deletions(-) diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c index 8f87979d0971..909db597b551 100644 --- a/kernel/trace/blktrace.c +++ b/kernel/trace/blktrace.c @@ -498,10 +498,7 @@ static struct dentry *blk_trace_debugfs_dir(struct blk_user_trace_setup *buts, struct dentry *dir = NULL; /* This can only happen if we have a bug on our lower layers */ - if (!q->kobj.parent) { - pr_warn("%s: request_queue parent is gone\n", buts->name); - return NULL; - } + BUG_ON(!q->kobj.parent); /* * From a sysfs kobject perspective, the request_queue sits on top of @@ -510,32 +507,19 @@ static struct dentry *blk_trace_debugfs_dir(struct blk_user_trace_setup *buts, * that if blktrace is going to be done for it. */ if (blk_trace_target_disk(buts->name, kobject_name(q->kobj.parent))) { - if (!q->debugfs_dir) { - pr_warn("%s: expected request_queue debugfs_dir is not set\n", - buts->name); - return NULL; - } + BUG_ON(!q->debugfs_dir); + /* * debugfs_lookup() is used to ensure the directory is not * taken from underneath us. We must dput() it later once * done with it within blktrace. + * + * This is also a reaffirmation that debugfs_lookup() shall + * always return the same dentry if it was already set. */ dir = debugfs_lookup(buts->name, blk_debugfs_root); - if (!dir) { - pr_warn("%s: expected request_queue debugfs_dir dentry is gone\n", - buts->name); - return NULL; - } - /* - * This is a reaffirmation that debugfs_lookup() shall always - * return the same dentry if it was already set. - */ - if (dir != q->debugfs_dir) { - dput(dir); - pr_warn("%s: expected dentry dir != q->debugfs_dir\n", - buts->name); - return NULL; - } + BUG_ON(!dir || dir != q->debugfs_dir); + bt->backing_dir = q->debugfs_dir; return bt->backing_dir; } From patchwork Sun Apr 19 19:45:25 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11497883 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0B16514DD for ; Sun, 19 Apr 2020 19:46:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E639B2145D for ; Sun, 19 Apr 2020 19:46:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587325582; bh=fQXCFGRgJbRf7moNvG4Dc1RHJ+2CVURXn5hwDnCxeLw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=HgT7LBK1DH1BQWWQEWRj96Oji14YNiuu+zi5uZ6Jh2LV2WpuFY68JxRlY7xqrU3nj eVTSyjd1vPORctqQ0tv2BEEn734VDbuoKxzfaWUvxeVheSUhgTnJAc0PLtKcH8KL7d XZdsAglCeh+5aSYKwyWHDmqOUd6HCax30tPRqKtg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726869AbgDSTqS (ORCPT ); Sun, 19 Apr 2020 15:46:18 -0400 Received: from mail-pg1-f196.google.com ([209.85.215.196]:43539 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726719AbgDSTpq (ORCPT ); Sun, 19 Apr 2020 15:45:46 -0400 Received: by mail-pg1-f196.google.com with SMTP id x26so3958754pgc.10; Sun, 19 Apr 2020 12:45:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=V2K7EZXYN6Xe1jPwFmqZWg/LsfDQ8FxEGzorYIUkLfM=; b=gZSXBx4e+IW+hhj5NGIM5wStvfIBMt58IrDpPpdDDO6ujIjmP5OlcSyiGA+RJvgAlR u4J3TAXJ49XmMpQHPBl/RHqLvoeymtWQ33ogEe0xJLe1ADQOmYV45Z4DepAamC/qPkdY nVlqSB27JHgnFMxA5pjxAf99ruzt8RPDW5oyJgd0kWtyJsBKJWB8OiiN+39Vza2TDEHK 7RW3vI0k2tSLINvNoe3fpi3jteT1qnjF4qWyu6DMWUAH0m+zqQjv+2zdSDnZVr01Ulvx +L5csmaYI6JY/KonTUpujfYmR8QJyPY/W1sC2bGksPD27MCi4Q/t2LXPXir8W6hFjfmr jEpg== X-Gm-Message-State: AGi0Pub7nChwkSk7y8heGnlCil78S9dy45MHhN5Caqp4/Ha2ArHZ+kwX DwebKWbOxVR92/dxm40DqpiejYqv0CQ= X-Google-Smtp-Source: APiQypIMWS/ShJP5LZ41kIXm9G1F2gs0Kheeswgp6JGQgly3HmDS9WmGOoUUTQl9T2/u5sowlGqZhg== X-Received: by 2002:a63:7c2:: with SMTP id 185mr2478993pgh.131.1587325545506; Sun, 19 Apr 2020 12:45:45 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id a23sm19365100pfo.145.2020.04.19.12.45.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2020 12:45:43 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id E685642000; Sun, 19 Apr 2020 19:45:38 +0000 (UTC) From: Luis Chamberlain To: axboe@kernel.dk, viro@zeniv.linux.org.uk, bvanassche@acm.org, gregkh@linuxfoundation.org, rostedt@goodmis.org, mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com, nstange@suse.de, akpm@linux-foundation.org Cc: mhocko@suse.com, yukuai3@huawei.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Luis Chamberlain Subject: [PATCH v2 06/10] blk-debugfs: upgrade warns to BUG_ON() if directory is already found Date: Sun, 19 Apr 2020 19:45:25 +0000 Message-Id: <20200419194529.4872-7-mcgrof@kernel.org> X-Mailer: git-send-email 2.23.0.rc1 In-Reply-To: <20200419194529.4872-1-mcgrof@kernel.org> References: <20200419194529.4872-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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 --- 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); From patchwork Sun Apr 19 19:45:26 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11497877 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D907514DD for ; Sun, 19 Apr 2020 19:46:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C09DC21973 for ; Sun, 19 Apr 2020 19:46:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587325573; bh=Kjz2UV2IjrUUvcAO3SW0csvuEdtPQY4bw4xowWf485E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=XtEZIRSl+10myp0ZagsCtPoj8lL1QfmOKVqm8bsWpvZqn9cbzjot2517/wUz+D0Kj zaLj2GbiTbuBYJJzpjYDXR86yMutYYx3eeOOAsdXQeB3taH/xi6VVBtpMDva+kNUNR PvOm2Qo93ZiYCwvrBKVe/gMkrBqFVNRss/UcI3IU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726764AbgDSTps (ORCPT ); Sun, 19 Apr 2020 15:45:48 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:43538 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726727AbgDSTpr (ORCPT ); Sun, 19 Apr 2020 15:45:47 -0400 Received: by mail-pg1-f193.google.com with SMTP id x26so3958764pgc.10; Sun, 19 Apr 2020 12:45:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=LBqvAh1pYV5Fu2bzEcPAYJWpFa0bYvX8DrHKThwj4sE=; b=L7YGnf7XJr4I4x9i5OWrNeKaKaVwY38xtKh43Z3hKIipeKiqVXlm+bQZbjU0fBMRzy hQs4ucIU0rpYuWin6MxeAl8esKbZCfO7xtVSalmJwlbqiVhK6uK5/8w3BgV5Ob8ndmV9 paiksCUM/RAXGw0Q0Dnp0+9gvzrIYbqB3XzFYZyKR5EZ6vCxKgyGUCBDQH1/T+72VOVp N3UPlEeJ1JIcyisbfVqnfEspAjN8QJiuyrdJbvIXgL9t4rBAlE51hdtg4wPtKZ+O56iJ nSQx9yBpYGNOriGVQe0hg9Sjj/WQ80OGFw4FoOHggTMIX2HlgXkFVW8i5W2gKJAeZQFs ANZw== X-Gm-Message-State: AGi0PuYOUg8ZId54A0xrkj9Xg6XB3SQ9YOzS5Cv3wLdvNbXwIR+AWOgK sGn3LthxhqoJ8RapYIXNS2w= X-Google-Smtp-Source: APiQypJR1GexWXMsOuzmodtJsMQOkpRREQvUx/laufKXdAZAUebNf6h/SmgSJQg0ohk2VxpwhRFMdg== X-Received: by 2002:aa7:96cf:: with SMTP id h15mr9042692pfq.319.1587325546455; Sun, 19 Apr 2020 12:45:46 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id 13sm10159972pfv.95.2020.04.19.12.45.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2020 12:45:43 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id F313A42079; Sun, 19 Apr 2020 19:45:38 +0000 (UTC) From: Luis Chamberlain To: axboe@kernel.dk, viro@zeniv.linux.org.uk, bvanassche@acm.org, gregkh@linuxfoundation.org, rostedt@goodmis.org, mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com, nstange@suse.de, akpm@linux-foundation.org Cc: mhocko@suse.com, yukuai3@huawei.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Luis Chamberlain Subject: [PATCH v2 07/10] blktrace: move debugfs file creation to its own function Date: Sun, 19 Apr 2020 19:45:26 +0000 Message-Id: <20200419194529.4872-8-mcgrof@kernel.org> X-Mailer: git-send-email 2.23.0.rc1 In-Reply-To: <20200419194529.4872-1-mcgrof@kernel.org> References: <20200419194529.4872-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Move creating the blktrace debugfs files into its own function. We'll expand on this later. Signed-off-by: Luis Chamberlain --- kernel/trace/blktrace.c | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c index 909db597b551..9cc0153849c3 100644 --- a/kernel/trace/blktrace.c +++ b/kernel/trace/blktrace.c @@ -548,6 +548,25 @@ static struct dentry *blk_trace_debugfs_dir(struct blk_user_trace_setup *buts, return bt->dir; } +static int blk_trace_create_debugfs_files(struct blk_user_trace_setup *buts, + struct dentry *dir, + struct blk_trace *bt) +{ + int ret = -EIO; + + bt->dropped_file = debugfs_create_file("dropped", 0444, dir, bt, + &blk_dropped_fops); + + bt->msg_file = debugfs_create_file("msg", 0222, dir, bt, &blk_msg_fops); + + bt->rchan = relay_open("trace", dir, buts->buf_size, + buts->buf_nr, &blk_relay_callbacks, bt); + if (!bt->rchan) + return ret; + + return 0; +} + /* * Setup everything required to start tracing */ @@ -597,15 +616,8 @@ static int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev, atomic_set(&bt->dropped, 0); INIT_LIST_HEAD(&bt->running_list); - ret = -EIO; - bt->dropped_file = debugfs_create_file("dropped", 0444, dir, bt, - &blk_dropped_fops); - - bt->msg_file = debugfs_create_file("msg", 0222, dir, bt, &blk_msg_fops); - - bt->rchan = relay_open("trace", dir, buts->buf_size, - buts->buf_nr, &blk_relay_callbacks, bt); - if (!bt->rchan) + ret = blk_trace_create_debugfs_files(buts, dir, bt); + if (ret) goto err; bt->act_mask = buts->act_mask; From patchwork Sun Apr 19 19:45:27 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11497873 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 012B614DD for ; Sun, 19 Apr 2020 19:46:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D921221973 for ; Sun, 19 Apr 2020 19:46:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587325568; bh=4OhlOdyFnJ2tiRBSqEwNm/uy5s4uSzRF5PzKx9/Np+k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=skwjKSWANUUU5kQ0l+78oCyw3Bh69jYiwmDPHz4qDAUx+MENQqaVqyhNnArLFVp3V +Vgnngw8zS7/sNOpEu9A+pq+2kB1dEh6cEO5LVHtGfvxTJkm58pMByDi3vQGKKliib OFZLD2FZQmwtw8HVAHfHkoL058ltq5kaF3GTx7SU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726855AbgDSTqI (ORCPT ); Sun, 19 Apr 2020 15:46:08 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:39336 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726790AbgDSTpt (ORCPT ); Sun, 19 Apr 2020 15:45:49 -0400 Received: by mail-pl1-f195.google.com with SMTP id k18so3128489pll.6; Sun, 19 Apr 2020 12:45:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ocPGiMVOY8YbX62vNwIAKusoCpTyvn+IDMEr8V2SPWM=; b=TZUwPDrv4qc/Gi+28U/DbZt6Xq/21p9IQxW8UZRcvMH0ePAhpn/BI7PMGA0jJ5eYt5 LdnHDq+GbuhDSdFCqAZ30501Qjxxwf9aZlsoU+4HX6aqzioC73s/8gU2JKH2rTzr06iM sNFhGRjVa/K/owaUqxogmu2FsTkeSH+4ZHeAQtMKKQBv3mkkRfckMLAHoOcymH207tiW yVAQ1v7GSNnmKcFUKGbUUiD6wwDbsuYXW6yYX51w/RLI3Hywivdo2JP7n9XO1Mu9IoRt JIr1lsZK/GgEAY7xBapx+9TXP5HBCRfX48zc4iwSk2LnUm98acgTqXzV0zUpfwn8Qcf0 RNBg== X-Gm-Message-State: AGi0PuYomujpgMnSwfVstXuBfYVSsIzidsfktMEEjW/smTIYxLxp7ueg M/pThJVKTacQp6dZNq3pTJ4= X-Google-Smtp-Source: APiQypKviuIIU6uo7RWeYDR6Y1M/9tlUiCmGKN/t71TBIfd8bt+jjyzreCRxLywsikXiZrAm1y65nA== X-Received: by 2002:a17:90a:f98b:: with SMTP id cq11mr757945pjb.193.1587325548759; Sun, 19 Apr 2020 12:45:48 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id u8sm11614115pjy.16.2020.04.19.12.45.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2020 12:45:43 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 082A04223D; Sun, 19 Apr 2020 19:45:39 +0000 (UTC) From: Luis Chamberlain To: axboe@kernel.dk, viro@zeniv.linux.org.uk, bvanassche@acm.org, gregkh@linuxfoundation.org, rostedt@goodmis.org, mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com, nstange@suse.de, akpm@linux-foundation.org Cc: mhocko@suse.com, yukuai3@huawei.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Luis Chamberlain Subject: [PATCH v2 08/10] blktrace: add checks for created debugfs files on setup Date: Sun, 19 Apr 2020 19:45:27 +0000 Message-Id: <20200419194529.4872-9-mcgrof@kernel.org> X-Mailer: git-send-email 2.23.0.rc1 In-Reply-To: <20200419194529.4872-1-mcgrof@kernel.org> References: <20200419194529.4872-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Even though debugfs can be disabled, enabling BLK_DEV_IO_TRACE will select DEBUG_FS, and blktrace exposes an API which userspace uses relying on certain files created in debugfs. If files are not created blktrace will not work correctly, so we do want to ensure that a blktrace setup creates these files properly, and otherwise inform userspace. Signed-off-by: Luis Chamberlain --- kernel/trace/blktrace.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c index 9cc0153849c3..fc32a8665ce8 100644 --- a/kernel/trace/blktrace.c +++ b/kernel/trace/blktrace.c @@ -552,17 +552,19 @@ static int blk_trace_create_debugfs_files(struct blk_user_trace_setup *buts, struct dentry *dir, struct blk_trace *bt) { - int ret = -EIO; - bt->dropped_file = debugfs_create_file("dropped", 0444, dir, bt, &blk_dropped_fops); + if (!bt->dropped_file) + return -ENOMEM; bt->msg_file = debugfs_create_file("msg", 0222, dir, bt, &blk_msg_fops); + if (!bt->msg_file) + return -ENOMEM; bt->rchan = relay_open("trace", dir, buts->buf_size, buts->buf_nr, &blk_relay_callbacks, bt); if (!bt->rchan) - return ret; + return -EIO; return 0; } From patchwork Sun Apr 19 19:45:28 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11497853 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id CF1DB14DD for ; Sun, 19 Apr 2020 19:45:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AC5B021973 for ; Sun, 19 Apr 2020 19:45:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587325554; bh=3ermhqtRTukrfIyxromhdTXML7WENrc2Gg+w0I86O8A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=gkOh4hI4vN2/Wx9OBduZggJsS5QBMQaGD9W3DenPLOEbiLhEK3Ij1WuM5MdDD/FIE LQMgsh0ba29b/BYfq4JmhddHrJj9cCidzfXP0BA0h2pojiBfOBfsegTfAp2nlf9Luu VReu9a25GV6XuqN+wryjvqLct+JHi19Ufgfxs/l4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726820AbgDSTpx (ORCPT ); Sun, 19 Apr 2020 15:45:53 -0400 Received: from mail-pf1-f195.google.com ([209.85.210.195]:45240 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726805AbgDSTpv (ORCPT ); Sun, 19 Apr 2020 15:45:51 -0400 Received: by mail-pf1-f195.google.com with SMTP id w65so3871804pfc.12; Sun, 19 Apr 2020 12:45:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=8eAcVIKDv5Pxv4vhGmI5RPGxd5/34ByDOVy4yEbxjOw=; b=RI7Tb7ixJCt7mw/hARKoiiuSv/PYwKGbDB0yUl4YY04/uKh4eVKP8I5syQ+xeI9Pjg iPQA8Q+ASOqzkEMHzMznAh4kaQR9/JN66r6tXUK0XdROzHecPRBUcWq4HShlkeZ9CPTb kjmBTD4VA0bBGBFQpIiY2ge0HA4azg4CQCeJ8oZLdGe8l8d4RJIQFqrKXbXXOshUKN5L vc+qltOeB7Sn/1YXyNPHtTuv0wYmxDJzJnnYR+Yar70eqICcLRO21+oL7VDnOj3N7jY4 Ix7vwhCQ/eaqE1u3+PVRLmk9aPw3wbAxzfC439nDa+Rf8FbRdXZgbU8CUkUNdS52IjUp onoQ== X-Gm-Message-State: AGi0PubRsfaehcCTpI/oyeEd5qyhjEy3Cu8XQfg++g9NF2nSfN5UmEjU /xAR30Y7wgF4PY5k0TLtn6Y= X-Google-Smtp-Source: APiQypJKWR3D9PTkDLW015p+SOWl71AOzd1pfWUaHiOwDS7oh/tvTofjj4cC8q+yS3mo4hA7hYStiQ== X-Received: by 2002:a63:3814:: with SMTP id f20mr4061780pga.283.1587325550777; Sun, 19 Apr 2020 12:45:50 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id v94sm12047750pjb.39.2020.04.19.12.45.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2020 12:45:43 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 10FCD422E5; Sun, 19 Apr 2020 19:45:39 +0000 (UTC) From: Luis Chamberlain To: axboe@kernel.dk, viro@zeniv.linux.org.uk, bvanassche@acm.org, gregkh@linuxfoundation.org, rostedt@goodmis.org, mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com, nstange@suse.de, akpm@linux-foundation.org Cc: mhocko@suse.com, yukuai3@huawei.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Luis Chamberlain Subject: [PATCH v2 09/10] block: panic if block debugfs dir is not created Date: Sun, 19 Apr 2020 19:45:28 +0000 Message-Id: <20200419194529.4872-10-mcgrof@kernel.org> X-Mailer: git-send-email 2.23.0.rc1 In-Reply-To: <20200419194529.4872-1-mcgrof@kernel.org> References: <20200419194529.4872-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org If DEBUG_FS is disabled we have another inline blk_debugfs_register() which just returns 0. If BLK_DEV_IO_TRACE is enabled we rely on the block debugfs directory to have been created. If BLK_DEV_IO_TRACE is not enabled though, but if debugfs is still enabled we will always create a debugfs directory for a request_queue. Instead of special-casing this just for BLK_DEV_IO_TRACE, ensure this block debugfs dir is always created at boot if we have enabled debugfs. Signed-off-by: Luis Chamberlain --- block/blk-debugfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/block/blk-debugfs.c b/block/blk-debugfs.c index 761318dcbf40..d6ec980e7531 100644 --- a/block/blk-debugfs.c +++ b/block/blk-debugfs.c @@ -15,6 +15,8 @@ struct dentry *blk_debugfs_root; void blk_debugfs_register(void) { blk_debugfs_root = debugfs_create_dir("block", NULL); + if (!blk_debugfs_root) + panic("Failed to create block debugfs directory\n"); } int __must_check blk_queue_debugfs_register(struct request_queue *q) From patchwork Sun Apr 19 19:45:29 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11497859 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E4F611667 for ; Sun, 19 Apr 2020 19:45:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C284F2224F for ; Sun, 19 Apr 2020 19:45:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587325556; bh=0fEKditsiCBeZebRHug5c4iFSYsesSSDjhjURwpdjT0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=MOf+7Se0+aoV5Z7PtQUMUhY2wca7H0utlf3l8o2ZtAaKOOfLt0kRv/bqmDlyDPleS 9FTSP5qIxHu8icZ00TS8KU13pucdGQjq1Y6sYzhgyf4erIhecOHOr0xeGjinvfw5Zj h0FIKnDUJLGYywnaYsHOpMnngsY9saf/3Qxxf2x8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726826AbgDSTpy (ORCPT ); Sun, 19 Apr 2020 15:45:54 -0400 Received: from mail-pj1-f68.google.com ([209.85.216.68]:50993 "EHLO mail-pj1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726813AbgDSTpw (ORCPT ); Sun, 19 Apr 2020 15:45:52 -0400 Received: by mail-pj1-f68.google.com with SMTP id t9so1475946pjw.0; Sun, 19 Apr 2020 12:45:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=JI0MWD+QJRNLm9H/ySGaj7rD32bWrmPpBuBR7vXM0po=; b=FSJ85UrLjGmYQeyidAk9RbNmDPLXhoqbhpyk9DXkl8GmFnUNmj6xK9avazoX7e+v2a yubrmnSJcrelYPc79zjTQnVncHM8t9RnTAcFcLnmBXNDTK5srsNIouENQhvr6qzX6DtS mrO+foTLSt0khki2wpQsT4J1B9cgafDpTodUZePybyYZHO3aHc1HbREzoXsYTXMN2/+U HNhM1sN7aDHazQ+GfLsFwVwzfC5g7Shj/cxZRnlgvJ8wAwgVYhSk8JDAske7GsuM3bgO i4rG34RlZKPB4djq8QpVVh35J9lOyRXh7B/EVLhXtOMlGeYICVE6kr+9ZeGwpq9QaAgb hgLA== X-Gm-Message-State: AGi0PubTppbpnuwqowBk7Hh7pCAZaZyBJg8BE0ax5eG9NyRi4WMjBBUA J7FpEAurtWDS8qSWwoXhS6A= X-Google-Smtp-Source: APiQypI5CAO7B1a2nLDOtdLnxkI6y2BKcHcPj3NYYswPtP9sWC/TtH2DZACqpYblnpzrNGt00D3cQA== X-Received: by 2002:a17:90a:b10f:: with SMTP id z15mr15705940pjq.188.1587325551767; Sun, 19 Apr 2020 12:45:51 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id 1sm4588pff.151.2020.04.19.12.45.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2020 12:45:43 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 1D0CD42309; Sun, 19 Apr 2020 19:45:39 +0000 (UTC) From: Luis Chamberlain To: axboe@kernel.dk, viro@zeniv.linux.org.uk, bvanassche@acm.org, gregkh@linuxfoundation.org, rostedt@goodmis.org, mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com, nstange@suse.de, akpm@linux-foundation.org Cc: mhocko@suse.com, yukuai3@huawei.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Luis Chamberlain Subject: [PATCH v2 10/10] block: put_device() if device_add() fails Date: Sun, 19 Apr 2020 19:45:29 +0000 Message-Id: <20200419194529.4872-11-mcgrof@kernel.org> X-Mailer: git-send-email 2.23.0.rc1 In-Reply-To: <20200419194529.4872-1-mcgrof@kernel.org> References: <20200419194529.4872-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Through code inspection I've found that we don't put_device() if device_add() fails, and this must be done to decrement its refcount. Signed-off-by: Luis Chamberlain Reviewed-by: Bart Van Assche --- block/genhd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/block/genhd.c b/block/genhd.c index 06b642b23a07..c52095a74792 100644 --- a/block/genhd.c +++ b/block/genhd.c @@ -721,8 +721,10 @@ static void register_disk(struct device *parent, struct gendisk *disk, WARN_ON(ddev->groups); ddev->groups = groups; } - if (device_add(ddev)) + if (device_add(ddev)) { + put_device(ddev); return; + } if (!sysfs_deprecated) { err = sysfs_create_link(block_depr, &ddev->kobj, kobject_name(&ddev->kobj));