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 427F6C433F5 for ; Wed, 5 Jan 2022 17:45:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7306B6B0071; Wed, 5 Jan 2022 12:45:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E0066B0073; Wed, 5 Jan 2022 12:45:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 580686B0074; Wed, 5 Jan 2022 12:45:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 468566B0071 for ; Wed, 5 Jan 2022 12:45:24 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id ED00495B1D for ; Wed, 5 Jan 2022 17:45:23 +0000 (UTC) X-FDA: 78996960126.28.AB2EC57 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf22.hostedemail.com (Postfix) with ESMTP id 05E91C000E for ; Wed, 5 Jan 2022 17:45:21 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 1A418CE128F; Wed, 5 Jan 2022 17:45:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C534C36AE0; Wed, 5 Jan 2022 17:45:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641404717; bh=Q3V6GchDz78dmmg78l3g/qEnjx4BoPVZZK1V2rhQnWg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ofv2KE4rUB3IDE5zL0LXmcN71knBnGoHLvDV2Kto/Au/uS6xKi4fnQx0ec7kw172w BbDNFOrbPnuJOnu/tQCE3V9lQ2JSWQ1I1m7/yWycIU8F9uEsfOdXaldGfOgLh1Xgpb D3biVEQT9XNIZXsP9hMsWsnfhqjojMiwV0zHGZ1smVOUaE0AlOMQDfH+Vwpzjde+IZ 4EI8Mn5CNoE2cfdgQzkACRm6y5W/dHKF/2rQvfDraCSyxaoyV29AuGF8wzBFLrrjtU Mhcf9BXbMVP9aEwYgBR/xsrhHli0xmRbJ4N5MsmsisGMstkwuV+eqF9nmkciju8Qzq y0rPZl0QRkSeA== Date: Wed, 5 Jan 2022 09:45:17 -0800 From: "Darrick J. Wong" To: Dan Williams Cc: Shiyang Ruan , Linux Kernel Mailing List , linux-xfs , Linux NVDIMM , Linux MM , linux-fsdevel , david , Christoph Hellwig , Jane Chu Subject: Re: [PATCH v9 01/10] dax: Use percpu rwsem for dax_{read,write}_lock() Message-ID: <20220105174517.GI31606@magnolia> References: <20211226143439.3985960-1-ruansy.fnst@fujitsu.com> <20211226143439.3985960-2-ruansy.fnst@fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 05E91C000E X-Stat-Signature: 3qer5z8qfgqpaep8jk6kd1m5934aiqti Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Ofv2KE4r; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf22.hostedemail.com: domain of djwong@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=djwong@kernel.org X-HE-Tag: 1641404721-868885 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 Tue, Jan 04, 2022 at 02:44:08PM -0800, Dan Williams wrote: > On Sun, Dec 26, 2021 at 6:35 AM Shiyang Ruan wrote: > > > > In order to introduce dax holder registration, we need a write lock for > > dax. > > As far as I can see, no, a write lock is not needed while the holder > is being registered. > > The synchronization that is needed is to make sure that the device > stays live over the registration event, and that any in-flight holder > operations are flushed before the device transitions from live to > dead, and that in turn relates to the live state of the pgmap. > > The dax device cannot switch from live to dead without first flushing > all readers, so holding dax_read_lock() over the register holder event > should be sufficient. ...and perhaps add a comment describing that this is what the synchronization primitive is really protecting against? The first time I read through this patchset, I assumed the rwsem was protecting &dax_hosts and was confused when I saw the one use of dax_write_lock. --D > If you are worried about 2 or more potential > holders colliding at registration time, I would expect that's already > prevented by block device exclusive holder synchronization, but you > could also use cmpxchg and a single pointer to a 'struct dax_holder { > void *holder_data, struct dax_holder_operations *holder_ops }'. If you > are worried about memory_failure triggering while the filesystem is > shutting down it can do a synchronize_srcu(&dax_srcu) if it really > needs to ensure that the notify path is idle after removing the holder > registration. > > ...are there any cases remaining not covered by the above suggestions?