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 6D05BC4332F for ; Tue, 4 Jan 2022 22:44:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EEBD06B0071; Tue, 4 Jan 2022 17:44:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E9AB16B0072; Tue, 4 Jan 2022 17:44:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D62D26B0073; Tue, 4 Jan 2022 17:44:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) by kanga.kvack.org (Postfix) with ESMTP id C99986B0071 for ; Tue, 4 Jan 2022 17:44:21 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 764608954E for ; Tue, 4 Jan 2022 22:44:21 +0000 (UTC) X-FDA: 78994084722.29.CF673AB Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by imf29.hostedemail.com (Postfix) with ESMTP id BC74D12000B for ; Tue, 4 Jan 2022 22:44:13 +0000 (UTC) Received: by mail-pf1-f179.google.com with SMTP id 8so33470728pfo.4 for ; Tue, 04 Jan 2022 14:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kNI0FNXnZ92A9rcSSuTMSZWtPK6rcwK+FpLRa43srmk=; b=fOsqdC5v/Ljnlv2FEIyia5PEUe1s+e+1DuDDfE7u5MaVA4dXKJQHiE1mRK5iYBVsUJ /oowxIHxSAdxALfYzQ8kGvygGPJuCKMOHtF6DiXbqMs/059LnQCgFzEDESiTPsFxFWNn 7Xesjj8J0CJQX2rv/u96W/GJ5UgdA6Vcv8mkPCkFc6h66hCg6QsUbB+sYNaSz3UzdXUB lpIWK+oGnTNcmd+TytJ0U91J0Sv00HD75sq8eRh6giDzO8BfqgCduSAOWJzJitKNXhRW Yz6dvrh+hntEc7AjvBGIeEmebsxBEkSVtpsKzv/uaTDYZj1X2da7fQ7LGbcS1ECRAlNl 1k1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kNI0FNXnZ92A9rcSSuTMSZWtPK6rcwK+FpLRa43srmk=; b=SkSOpYZQBpizjANAb6UERmhoPG7ivOKO3R1ky+9858XpCuQ7Xlxu8SRv1RzKD2Dfx2 0UfkRgRad6Xw2XjaakQRQKMVRj2Kt/U8GX0RXWeQhIBInfAuU5z9hH61VEsaWWN+8OHr 49xIrgBSjr8Da8qwDVrad6XZJpVaVV1ch+G122WcY/Vio2fNXqTgntERincN9cdwD8G8 y6UXcIJ8MrRo4Ss+d+0RvF7uzU4tywwv2RcSXg9s1/8BxAhrm7OnHhfaB8tmKyDqT5+0 BQHeJl5jHtHTllb1VFY52E73A0xd7AmrrRG82tQ/bS4uH22GYCP575UotKH3giWvMjmg +b9A== X-Gm-Message-State: AOAM533JKMmLBly/WQxqxr/E0rwuRTjHziird4Mco0uktcD83lwozDWO T7R4Y6wsbn6kroT9DrLF138Fu577QcBg7bo0pfOpIA== X-Google-Smtp-Source: ABdhPJyP9Z0MRBW2RS42p0axndXN+7aFakOWJ0+wGPrF9fRJBeJgr0Nw19jdOKV52TidJL0PgD7xQGTpsKPEnebLsUg= X-Received: by 2002:a63:79c2:: with SMTP id u185mr876468pgc.74.1641336259609; Tue, 04 Jan 2022 14:44:19 -0800 (PST) MIME-Version: 1.0 References: <20211226143439.3985960-1-ruansy.fnst@fujitsu.com> <20211226143439.3985960-2-ruansy.fnst@fujitsu.com> In-Reply-To: <20211226143439.3985960-2-ruansy.fnst@fujitsu.com> From: Dan Williams Date: Tue, 4 Jan 2022 14:44:08 -0800 Message-ID: Subject: Re: [PATCH v9 01/10] dax: Use percpu rwsem for dax_{read,write}_lock() To: Shiyang Ruan Cc: Linux Kernel Mailing List , linux-xfs , Linux NVDIMM , Linux MM , linux-fsdevel , "Darrick J. Wong" , david , Christoph Hellwig , Jane Chu Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: ngzmkdj6srjeb5pqkst48fseabt8uhpm X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: BC74D12000B Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b=fOsqdC5v; spf=none (imf29.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.210.179) smtp.mailfrom=dan.j.williams@intel.com; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none) X-HE-Tag: 1641336253-581522 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 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. 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?