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 DE9B2C433FE for ; Tue, 4 Jan 2022 22:56:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25AA66B0071; Tue, 4 Jan 2022 17:56:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E3566B0072; Tue, 4 Jan 2022 17:56:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 084806B0073; Tue, 4 Jan 2022 17:56:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0045.hostedemail.com [216.40.44.45]) by kanga.kvack.org (Postfix) with ESMTP id ED1876B0071 for ; Tue, 4 Jan 2022 17:56:06 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B56A08249980 for ; Tue, 4 Jan 2022 22:56:06 +0000 (UTC) X-FDA: 78994114332.09.C5EBE38 Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) by imf24.hostedemail.com (Postfix) with ESMTP id E4BEB180006 for ; Tue, 4 Jan 2022 22:55:57 +0000 (UTC) Received: by mail-pg1-f169.google.com with SMTP id g22so33922500pgn.1 for ; Tue, 04 Jan 2022 14:56:05 -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=QDrla7Rgv/PbJy5q1B/gTLicO7LUJ4Uh87OcS/ewnKE=; b=UnQWpQr21b08H9CCzMDJ58NV59i32gSxpHT+QzAwkrO4OAmJ//j0XPMmeqp9ezNcVD wc+LG30An/agayNvl+NJHt6YBjXm6O408MGhsYl9h7mvor6IRClKKERwR+G7NA4rrrxD YEhHssP/S9/5wHZr2A6Ly4Y41OVCTab/vh3T/47v9/0Zl1rBfzSzhFxVXZwEhpw+OAlb lHdxMEYtx8koB4EsWoqsmItGdKo9eHAhy8j0Jf078FeDyQ6lYITt2LM67Tetu3wYlKWG m/cVqQ6dQgccJh3/k7W1YuPpUIzvCRVDDwWPDHRnOkQXBz8LQPfn4BPfDg0xP1ivy5we 53Dw== 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=QDrla7Rgv/PbJy5q1B/gTLicO7LUJ4Uh87OcS/ewnKE=; b=JvYEo7vjh73L+zEVDl3CKBKkIk68QaQxAQaIoKqFlAoi0WucN8IVPNFfHobJVQ9sLT UqRRxg/NKGVr2GolD30rA33SgRT3rB/4/sXSjlP0wEoVlCMligfFbLL6EgZULIfGoSH2 e4q4g4/4t31WTaiKYCPN5hRF6Vr6zgq6prDmjZaJhbwMUDYnpAEW49kF5VuY9p8EkUUj XmmQwhRllv09jAJ7zs2idJnBX+jhdLzmeo4RVzu4owXHIEtn/kLhX+u31zt2eS1Y57qo k8v+f48nYm/p3bnpUZ+jepXd2hubqYoSLXrKilaGgKcIZMNmbPkJq92XNWxBK75jZ+q9 mbYw== X-Gm-Message-State: AOAM531VLSERVSdmtBkNerZl12y1FvWrpGqFBVTvLl6ru8UZGLl2NTdu Ja4zRAYu0gN19gYHaH2vVpaU5ZwAAn9090N9xpgUq38cpic= X-Google-Smtp-Source: ABdhPJw+Vos8Ml12UKdWDConJMoM6GI2KsSQYifbyzS1cJDllpf9uH/RB9uuvuXF/vjErHmErkc/FI0EcnSktAhTHJQ= X-Received: by 2002:a63:79c2:: with SMTP id u185mr904600pgc.74.1641336965053; Tue, 04 Jan 2022 14:56:05 -0800 (PST) MIME-Version: 1.0 References: <20211226143439.3985960-1-ruansy.fnst@fujitsu.com> <20211226143439.3985960-7-ruansy.fnst@fujitsu.com> In-Reply-To: <20211226143439.3985960-7-ruansy.fnst@fujitsu.com> From: Dan Williams Date: Tue, 4 Jan 2022 14:55:54 -0800 Message-ID: Subject: Re: [PATCH v9 06/10] fsdax: Introduce dax_lock_mapping_entry() To: Shiyang Ruan Cc: Linux Kernel Mailing List , linux-xfs , Linux NVDIMM , Linux MM , linux-fsdevel , "Darrick J. Wong" , david , Christoph Hellwig , Jane Chu , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: E4BEB180006 X-Stat-Signature: uf73cx8u7c7tpjnre8p3ytgmy75yixt6 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b=UnQWpQr2; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none); spf=none (imf24.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.215.169) smtp.mailfrom=dan.j.williams@intel.com X-Rspamd-Server: rspam11 X-HE-Tag: 1641336957-825837 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: > > The current dax_lock_page() locks dax entry by obtaining mapping and > index in page. To support 1-to-N RMAP in NVDIMM, we need a new function > to lock a specific dax entry corresponding to this file's mapping,index. > And output the page corresponding to the specific dax entry for caller > use. Is this necessary? The point of dax_lock_page() is to ensure that the fs does not destroy the address_space, or remap the pfn while memory_failure() is operating on the pfn. In the notify_failure case control is handed to the fs so I expect it can make those guarantees itself, no?