Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp510614ybz; Wed, 29 Apr 2020 04:29:12 -0700 (PDT) X-Google-Smtp-Source: APiQypLY+NGF+KbOHOGXTj+t1rsUQUs8rB2Ica+HDEgvZFEY1MhjKAzHUCTq04aTz88pi/qJFpWQ X-Received: by 2002:a17:906:4907:: with SMTP id b7mr1998902ejq.279.1588159752395; Wed, 29 Apr 2020 04:29:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588159752; cv=none; d=google.com; s=arc-20160816; b=dSlUddZnB28nDuy+dvpnvXtEVtDJlAWXc62/jundfX+w08bXFPwlmO35JRcjYK0de6 CoPDLyjW0FG/Bj1jSdSoQ50TI+8Y7Ir4fV3gDElrX792hHJ4jfVTYzQSBmnylBwd/1Mo hEIw1TUI2jHgu0BCfB8zslA5j/DaGQZyRSvlzEVqGkUhCQQFck6BqAcXhVM3Yr4NSnjo ME5h2eiYik+frgQGi1Z6E3v0r6bUOpQ7WSMF+9GnRNLmhyapGzi0XgsqVTpI6TeRFAKs R9b/X5u69RhVoqGzvK0Ed16q6gCewf9tQv2AvSjtp1unE21tivWzLIX9PiVLhsCnI8JZ RMfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=oMyZzcwYB9QX35xXWfMxn1LcoCBA2vSTd5XHHBAVDLs=; b=PPhUlI3NMBZkzfRRzL29zlXredpXmYUSN52M2TBW9aeb4ZbjoSwCuSUOlo/mbt2okh IcTNBqGLOIZIwuNxq1Fb6anFbSQYpmlhIClCiuEVdkI3Rmlgrhf5fABGjfEEm79fhT2A GuiXiFn+4ds93a8KSKB/OqDnIxoVV+TS4b04A1YF8X64m05ZaqNfkjVTxHcOHzQmtsGR HJeBoE3emSXEyTAZJjpdzDWIM0oUaO9xs5ho8PizkZ6PLM7SV0MSrlvcscBTwYZHyDYb 5ttig543lGTAx+Kp35d9kcyEXvONMcJV9OO5S5tLQbDIpM5DBI8y7kE3cgRg/CEnY0m0 FWDg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=kg+m6tJ4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v21si3221087edq.326.2020.04.29.04.28.49; Wed, 29 Apr 2020 04:29:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=kg+m6tJ4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726743AbgD2L1B (ORCPT + 99 others); Wed, 29 Apr 2020 07:27:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60860 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726345AbgD2L1A (ORCPT ); Wed, 29 Apr 2020 07:27:00 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C82D8C03C1AD; Wed, 29 Apr 2020 04:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=oMyZzcwYB9QX35xXWfMxn1LcoCBA2vSTd5XHHBAVDLs=; b=kg+m6tJ4HaLGqGi7L7gstSvKMs YDgkaZ/cGPu6ODEqaVw232Je5GEWjRRYEjHK9uOFWaUO4atRWg2BXWiI1LPIHTLBDFplziRU5H4ox iqBXcF7fqWs/xGGbdZMrsFfQNXONb0PeNewAdFs8D8C7gGh8Qd93dcCHhCOj9xSG9KhFSX9vBGFd7 2E0DlHpiVavu8Rp/hnJ+XjDqt7X64gadEpHZlb6llzDdzmw+boxgIp0pztPc8PbaNz1L9uC+SFjin DBqBBaU1br6h3UiT90ARqme+gdqd+rGPrBLkH0pIRMpRSLouPI9xpjg+OoOopTse/EsY+/3NFwI+E Mi8PEgcw==; Received: from hch by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jTkrN-0008GQ-VZ; Wed, 29 Apr 2020 11:26:37 +0000 Date: Wed, 29 Apr 2020 04:26:37 -0700 From: Christoph Hellwig To: Luis Chamberlain Cc: 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, 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, Omar Sandoval , Hannes Reinecke , Michal Hocko , syzbot+603294af2d01acfdd6da@syzkaller.appspotmail.com Subject: Re: [PATCH v3 4/6] blktrace: fix debugfs use after free Message-ID: <20200429112637.GD21892@infradead.org> References: <20200429074627.5955-1-mcgrof@kernel.org> <20200429074627.5955-5-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200429074627.5955-5-mcgrof@kernel.org> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I can't say I'm a fan of all these long backtraces in commit logs.. > +static struct dentry *blk_debugfs_dir_register(const char *name) > +{ > + return debugfs_create_dir(name, blk_debugfs_root); > +} I don't think we really need this helper. > +void blk_part_debugfs_unregister(struct hd_struct *p) > +{ > + debugfs_remove_recursive(p->debugfs_dir); > + p->debugfs_dir = NULL; > +} Why do we need to clear the pointer here? > +#ifdef CONFIG_DEBUG_FS > + /* Currently only used by kernel/trace/blktrace.c */ > + struct dentry *debugfs_dir; > +#endif Does that comment really add value? > +static struct dentry *blk_trace_debugfs_dir(struct block_device *bdev, > + struct request_queue *q) > { > + struct hd_struct *p = NULL; > > + * Some drivers like scsi-generic use a NULL block device. For > + * other drivers when bdev != bdev->bd_contain we are doing a blktrace > + * on a parition, otherwise we know we are working on the whole > + * disk, and for that the request_queue already has its own debugfs_dir. > + * which we have been using for other things other than blktrace. > + */ > + if (bdev && bdev != bdev->bd_contains) > + p = bdev->bd_part; > > + if (p) > + return p->debugfs_dir; > + > + return q->debugfs_dir; This could be simplified down to: if (bdev && bdev != bdev->bd_contains) return bdev->bd_part->debugfs_dir; return q->debugfs_dir; Given that bd_part is in __blkdev_get very near bd_contains. Also given that this patch completely rewrites blk_trace_debugfs_dir is there any point in the previous patch? > @@ -491,6 +500,7 @@ static int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev, > struct dentry *dir = NULL; > int ret; > > + > if (!buts->buf_size || !buts->buf_nr) > return -EINVAL; > Spurious whitespace change.