From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA75AC5519F for ; Wed, 25 Nov 2020 11:40:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 577402076B for ; Wed, 25 Nov 2020 11:40:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 577402076B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C9B416B0078; Wed, 25 Nov 2020 06:40:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C4C916B007B; Wed, 25 Nov 2020 06:40:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B89696B007D; Wed, 25 Nov 2020 06:40:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id A1BC06B0078 for ; Wed, 25 Nov 2020 06:40:47 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6992E181AEF21 for ; Wed, 25 Nov 2020 11:40:47 +0000 (UTC) X-FDA: 77522748534.02.beast37_0c03d1f27376 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id 504A010097AA0 for ; Wed, 25 Nov 2020 11:40:47 +0000 (UTC) X-HE-Tag: beast37_0c03d1f27376 X-Filterd-Recvd-Size: 3485 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Wed, 25 Nov 2020 11:40:46 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 3F6BDAC41; Wed, 25 Nov 2020 11:40:45 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id D8B791E130F; Wed, 25 Nov 2020 12:40:44 +0100 (CET) Date: Wed, 25 Nov 2020 12:40:44 +0100 From: Jan Kara To: Tejun Heo Cc: Christoph Hellwig , Jens Axboe , Josef Bacik , Konrad Rzeszutek Wilk , Coly Li , Mike Snitzer , dm-devel@redhat.com, Richard Weinberger , Jan Kara , linux-block@vger.kernel.org, xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org, linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 11/20] block: reference struct block_device from struct hd_struct Message-ID: <20201125114044.GC16944@quack2.suse.cz> References: <20201118084800.2339180-1-hch@lst.de> <20201118084800.2339180-12-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello! On Tue 24-11-20 11:59:49, Tejun Heo wrote: > > diff --git a/block/partitions/core.c b/block/partitions/core.c > > index a02e224115943d..0ba0bf44b88af3 100644 > > --- a/block/partitions/core.c > > +++ b/block/partitions/core.c > > @@ -340,12 +340,11 @@ void delete_partition(struct hd_struct *part) > > device_del(part_to_dev(part)); > > > > /* > > - * Remove gendisk pointer from idr so that it cannot be looked up > > - * while RCU period before freeing gendisk is running to prevent > > - * use-after-free issues. Note that the device number stays > > - * "in-use" until we really free the gendisk. > > + * Remove the block device from the inode hash, so that it cannot be > > + * looked up while waiting for the RCU grace period. > > */ > > - blk_invalidate_devt(part_devt(part)); > > + remove_inode_hash(part->bdev->bd_inode); > > I don't think this is necessary now that the bdev and inode lifetimes are > one. Before, punching out the association early was necessary because we > could be in a situation where we can successfully look up a part from idr > and then try to pin the associated disk which may already be freed. With the > new code, the lookup is through the inode whose lifetime is one and the same > with gendisk, so use-after-free isn't possible and __blkdev_get() will > reliably reject such open attempts. I think the remove_inode_hash() call is actually still needed. Consider a situation when the disk is unplugged, gendisk gets destroyed, bdev still lives on (e.g. because it is still open). Device gets re-plugged, gendisk for the same device number gets created. But we really need new bdev for this because from higher level POV this is completely new device. And the old bdev needs to live on as long as it is open. So IMO we still need to just unhash the inode and leave it lingering in the background. Honza -- Jan Kara SUSE Labs, CR