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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DBD2FC433FE for ; Tue, 18 Oct 2022 05:26:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 210C36B0072; Tue, 18 Oct 2022 01:26:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C0B56B0075; Tue, 18 Oct 2022 01:26:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 089106B007D; Tue, 18 Oct 2022 01:26:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E7A386B0075 for ; Tue, 18 Oct 2022 01:26:11 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B44CDA0E6E for ; Tue, 18 Oct 2022 05:26:11 +0000 (UTC) X-FDA: 80032934142.10.9EEAE01 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf15.hostedemail.com (Postfix) with ESMTP id 0A108A0033 for ; Tue, 18 Oct 2022 05:26:10 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id BEE2D68C4E; Tue, 18 Oct 2022 07:26:06 +0200 (CEST) Date: Tue, 18 Oct 2022 07:26:06 +0200 From: Christoph Hellwig To: Dan Williams Cc: Jason Gunthorpe , linux-mm@kvack.org, Matthew Wilcox , Jan Kara , "Darrick J. Wong" , Christoph Hellwig , John Hubbard , david@fromorbit.com, nvdimm@lists.linux.dev, akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v3 07/25] fsdax: Hold dax lock over mapping insertion Message-ID: <20221018052606.GA18887@lst.de> References: <166579181584.2236710.17813547487183983273.stgit@dwillia2-xfh.jf.intel.com> <166579185727.2236710.8711235794537270051.stgit@dwillia2-xfh.jf.intel.com> <634db85363e2c_4da329489@dwillia2-xfh.jf.intel.com.notmuch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634db85363e2c_4da329489@dwillia2-xfh.jf.intel.com.notmuch> User-Agent: Mutt/1.5.17 (2007-11-01) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666070771; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gI/NjDYb3wHDWgN+yFJHQcqLFIkA53JFBH6Aa0BqzTs=; b=o8THuRfhqBlmpA2E5HXcvPulqVww0yANjDa2cREr9d6vatGQag+BFPnfyMkMpe1X2/AC7I xcWmK/AbxJdKCi0jDi+qGtv0iBpMT7sNC3ysWhRC/aWWY9Wqt2UpeH4ByBAdcfmb8k6r0i RoWMpv2Hr1X1TqY+EMJrMMD9FbZSkvc= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; dmarc=none; spf=none (imf15.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666070771; a=rsa-sha256; cv=none; b=Pz9YIUT2l9XbWr2SRh1Iu6gp5XrWeRlL3TNXrtgQUecPCRcfMIpEUuna0rl0hGjwnsmBIH 4dnfCdULb6/8a1CQeVTqL4RALd3oKuGkrwWQMwxOmCN1kAQYC0MToEOqZ4FC6AjWfSeMO9 wO9cj6K1IbQkq9M7pbNXHw3u7/6ptXM= Authentication-Results: imf15.hostedemail.com; dkim=none; dmarc=none; spf=none (imf15.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0A108A0033 X-Stat-Signature: 4uhc8pcbakepqaioyegrc51cqwobwinb X-Rspam-User: X-HE-Tag: 1666070770-661137 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: On Mon, Oct 17, 2022 at 01:17:23PM -0700, Dan Williams wrote: > Historically, no. The block-device is allowed to disappear while inodes > are still live. Btw, while I agree with what you wrote below this sentence is at least a bit confusing. Struct block_device/gendisk/request_queue will always be valid as long as a file system is mounted and inodes are live due to refcounting. It's just as you correctly pointed out del_gendisk might have aready been called and they are dead.