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 D7569C433EF for ; Wed, 16 Feb 2022 03:07:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51C606B0078; Tue, 15 Feb 2022 22:07:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CAE76B007B; Tue, 15 Feb 2022 22:07:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 392786B007D; Tue, 15 Feb 2022 22:07:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0243.hostedemail.com [216.40.44.243]) by kanga.kvack.org (Postfix) with ESMTP id 2A6A16B0078 for ; Tue, 15 Feb 2022 22:07:37 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D12C58249980 for ; Wed, 16 Feb 2022 03:07:36 +0000 (UTC) X-FDA: 79147157712.06.0E7CCA2 Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by imf16.hostedemail.com (Postfix) with ESMTP id E2DF4180003 for ; Wed, 16 Feb 2022 03:07:35 +0000 (UTC) Received: by mail-pf1-f173.google.com with SMTP id i21so969480pfd.13 for ; Tue, 15 Feb 2022 19:07:35 -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:content-transfer-encoding; bh=P9/Lk8R9pgWnqbRmfZpLv8rIV8QLRWoWxnW3fVXtRwE=; b=RjnWgBK3XxvHo1Ay307j23W4JXT8TQPb6hFj1WWQgILnQS7eNKyQJMgEQ6MLGRjAzj cpqvAdt+bRfmKxd2DMH2g0nEh4hNCtehFduXIxofrgjg6XoPyqie6JVJuGc1MwQ5FkKI vmmOSY3GV3EVOA3OvdM8QxeOACAgAA4LGqIKnt+1GSczjtHj0DbM4sVL5lw7x7wHBwqx aMLJxUTbyj4KVMLw1zlUpdMjfp7ja2OO7yQ/Jy282kLaAMeBRPnvRuX3YD8ossHmvqj6 LEo8NXJTAA3SH1oXxW8qlPplpv+ntEO9ZTnRtiKwaCep2YtJRw9ai5tMBqHpb+EaQDGy D3xA== 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:content-transfer-encoding; bh=P9/Lk8R9pgWnqbRmfZpLv8rIV8QLRWoWxnW3fVXtRwE=; b=MeROf++c7dRJ0xRdDWp3bGNAnFZTOQCo2EneIgLDZWoq5WmJ65qIMbra3d6sFzKVxV GsywKm8ejeM1fV/cM4povgC2edE58kR9qQdmXN+oeYUvjltAJqAg9FFqmT7xc2+Kaw0p gvSo+EWOn2cJ5Qv9jxWszobeXZYdkJLWWb7VNKUIBy8oZqcNtd4DybUztqnuSP0DezG0 7kTkK9UYV/a0tN42HKG1ZdreCqjloUSZyI5Ngh9BB3GAWqVki8hYtDB3HO5eunz9B3Y9 h9k+e/0ftdWzm91zUn6PaTPsAXySqx9GTAZ0bsM4Ac6Fa9oEhiR2YODs899we+SeDpXN ch1g== X-Gm-Message-State: AOAM530oW2ivYz0lGFurhkg6zxRW5DsKgix2iuJHdcIaBXEAfK8gRJxO JNXi8vu0jQTns6pP4HnhD5ZNjHD9wSwAaNrOjxsZ0A== X-Google-Smtp-Source: ABdhPJwioc71Su+pBYx92WbiFVK2Wl/VnCTsrwfw9Z4vHbt8YGMFcSnoFePXywDRU7BA1BW3xC9QPBtHePBtQF6vDk8= X-Received: by 2002:a05:6a00:b4e:b0:4e1:9986:a5b6 with SMTP id p14-20020a056a000b4e00b004e19986a5b6mr139822pfo.61.1644980854632; Tue, 15 Feb 2022 19:07:34 -0800 (PST) MIME-Version: 1.0 References: <20220127124058.1172422-1-ruansy.fnst@fujitsu.com> <20220127124058.1172422-6-ruansy.fnst@fujitsu.com> <905fd72a-d551-4623-f448-89010b752d0e@fujitsu.com> In-Reply-To: <905fd72a-d551-4623-f448-89010b752d0e@fujitsu.com> From: Dan Williams Date: Tue, 15 Feb 2022 19:07:23 -0800 Message-ID: Subject: Re: [PATCH v10 5/9] fsdax: Introduce dax_load_page() 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" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: E2DF4180003 X-Rspam-User: Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b=RjnWgBK3; spf=none (imf16.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.210.173) smtp.mailfrom=dan.j.williams@intel.com; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none) X-Stat-Signature: wkfcn7xyf8x3wxyi6ws1btgjj7637cpf X-HE-Tag: 1644980855-464368 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, Feb 15, 2022 at 7:02 PM Shiyang Ruan wrot= e: > > > > =E5=9C=A8 2022/2/16 9:34, Dan Williams =E5=86=99=E9=81=93: > > On Thu, Jan 27, 2022 at 4:41 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 functi= on > >> to lock a specific dax entry > > > > I do not see a call to dax_lock_entry() in this function, what keeps > > this lookup valid after xas_unlock_irq()? > > I am not sure if I understood your advice correctly: You said > dax_lock_entry() is not necessary in v9[1]. So, I deleted it. > > [1]: > https://lore.kernel.org/linux-xfs/CAPcyv4jVDfpHb1DCW+NLXH2YBgLghCVy8o6wrc= 02CXx4g-Bv7Q@mail.gmail.com/ I also said, "if the filesystem can make those guarantees" it was not clear whether this helper is being called back from an FS context that guarantees those associations or not. As far as I can see there is nothing that protects that association. Apologies for the confusion, I was misunderstanding where the protection was being enforced in this case.