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 X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F443C4338F for ; Fri, 20 Aug 2021 20:51:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7D12F6115B for ; Fri, 20 Aug 2021 20:51:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7D12F6115B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id F07FF6B0071; Fri, 20 Aug 2021 16:51:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB8836B0072; Fri, 20 Aug 2021 16:51:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA7168D0001; Fri, 20 Aug 2021 16:51:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0147.hostedemail.com [216.40.44.147]) by kanga.kvack.org (Postfix) with ESMTP id B9F176B0071 for ; Fri, 20 Aug 2021 16:51:35 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 60862184B3AA0 for ; Fri, 20 Aug 2021 20:51:35 +0000 (UTC) X-FDA: 78496654950.04.C6379A1 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by imf12.hostedemail.com (Postfix) with ESMTP id 9DA1A10000A9 for ; Fri, 20 Aug 2021 20:51:34 +0000 (UTC) Received: by mail-pj1-f41.google.com with SMTP id j10-20020a17090a94ca00b00181f17b7ef7so1843601pjw.2 for ; Fri, 20 Aug 2021 13:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ULkGRivL56ptdhLg0qblOi29E6UuI3GKppQ73W5RcQM=; b=wljVRLX4qPe+NrAUHjhvsefxSXN6ijVZv63Pk+E8YjbzTLnFXsawQ4zasGGHJ9DI/j LNnvEAJOChgaeq15qhAKQrNdM+zSHl83TKm21KHMzu/Kj34ogt2J8PlNoComIFiSxTux ZKAeASlP7cb89cYcVuiKawdWSszkqhTR6dDUO6JiMBsI2TJxtUKHqwu8/Mu+C8IAY6TH IBg2Cuwk7G5a8G6lOMJjraA6x87/5aIT/X9Nt616MtxhG+Oyu8CGTIEk74nvOt3pIg5R jyMa0gao/WvU4WUXcSgzEhn+z0TTdpm2b2ioKkK5gyn1+vGrSRBrUOY03LKG9SxDZltK zElQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ULkGRivL56ptdhLg0qblOi29E6UuI3GKppQ73W5RcQM=; b=T7s/v9pu0Ao7d1keRN44aiF9hYGa7jL4PLJsnJSUSCK9Jk925KyaE2pwDJ2c+iiSjw YingHg/mIDjcpRBXAUM6VwQwm6gYItqePrCppEZbi8L7+mzWiEHiIX1+63YUPTt/Xs4I C61T1G46qS0qWm+SitbwQKY/3wNJOr0oKR8EZX7CeTZnAjnpy5iHEz7Tj2sc93Zr3sxy XYaNrwg0Asys7j8kVVJlNsoaEKy/d6Hb86RanKZ831IobdTBQ2raps5937kuCMINPhVi JBcPUZ+5aJBMfDXtc2xmV9Oasqr0bVV09MR/VGpecI+O505QiKwMYHNE2hUkSwVGFs/y DCIg== X-Gm-Message-State: AOAM530iqod0r/2u53XL979T81aA628HtKfaDz8/ZDYdKNq4ZIiAD2yJ mS60j79qv8N0AsWHumElqEhgLS1sWvWhzrfptWhVPA== X-Google-Smtp-Source: ABdhPJzPJ2XQpEtJq+wbuCgzapFmXjO/y38fzH3RNB8Wj2SGZHiAnemQziTjbPerD3pCdyF6tyAETSGC8SlS9MQj/UI= X-Received: by 2002:a17:902:e54e:b0:12d:cca1:2c1f with SMTP id n14-20020a170902e54e00b0012dcca12c1fmr17574055plf.79.1629492693543; Fri, 20 Aug 2021 13:51:33 -0700 (PDT) MIME-Version: 1.0 References: <20210730100158.3117319-1-ruansy.fnst@fujitsu.com> <20210730100158.3117319-5-ruansy.fnst@fujitsu.com> In-Reply-To: <20210730100158.3117319-5-ruansy.fnst@fujitsu.com> From: Dan Williams Date: Fri, 20 Aug 2021 13:51:22 -0700 Message-ID: Subject: Re: [PATCH RESEND v6 4/9] pmem,mm: Implement ->memory_failure in pmem driver To: Shiyang Ruan Cc: Linux Kernel Mailing List , linux-xfs , Linux NVDIMM , Linux MM , linux-fsdevel , device-mapper development , "Darrick J. Wong" , david , Christoph Hellwig , Alasdair Kergon , Mike Snitzer Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 9DA1A10000A9 Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=intel-com.20150623.gappssmtp.com header.s=20150623 header.b=wljVRLX4; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none); spf=none (imf12.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.216.41) smtp.mailfrom=dan.j.williams@intel.com X-Rspamd-Server: rspam04 X-Stat-Signature: 4u6n7cyjpsrrq6uipuemn6xxt8e1rzh9 X-HE-Tag: 1629492694-271125 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 Fri, Jul 30, 2021 at 3:02 AM Shiyang Ruan wrote: > > With dax_holder notify support, we are able to notify the memory failure > from pmem driver to upper layers. If there is something not support in > the notify routine, memory_failure will fall back to the generic hanlder. How about: "Any layer can return -EOPNOTSUPP to force memory_failure() to fall back to its generic implementation." > > Signed-off-by: Shiyang Ruan > --- > drivers/nvdimm/pmem.c | 13 +++++++++++++ > mm/memory-failure.c | 14 ++++++++++++++ > 2 files changed, 27 insertions(+) > > diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c > index 1e0615b8565e..fea4ffc333b8 100644 > --- a/drivers/nvdimm/pmem.c > +++ b/drivers/nvdimm/pmem.c > @@ -362,9 +362,22 @@ static void pmem_release_disk(void *__pmem) > del_gendisk(pmem->disk); > } > > +static int pmem_pagemap_memory_failure(struct dev_pagemap *pgmap, > + unsigned long pfn, unsigned long nr_pfns, int flags) > +{ > + struct pmem_device *pmem = > + container_of(pgmap, struct pmem_device, pgmap); > + loff_t offset = PFN_PHYS(pfn) - pmem->phys_addr - pmem->data_offset; > + > + return dax_holder_notify_failure(pmem->dax_dev, offset, > + page_size(pfn_to_page(pfn)) * nr_pfns, I do not understand the usage of page_size() here? memory_failure() assumes PAGE_SIZE pages. DAX pages also do not populate the compound metadata yet, but even if they did I would expect memory_failure() to be responsible for doing something like: pgmap->ops->memory_failure(pgmap, pfn, size >> PAGE_SHIFT, flags); ...where @size is calculated from dev_pagemap_mapping_shift(). > + &flags); Why is the local flags variable passed by reference? At a minimum the memory_failure() flags should be translated to a new set dax-notify flags, because memory_failure() will not be the only user of this notification interface. See NVDIMM_REVALIDATE_POISON, and the discussion Dave and I had about using this notification to signal unsafe hot-removal of a memory device. > +} > + > static const struct dev_pagemap_ops fsdax_pagemap_ops = { > .kill = pmem_pagemap_kill, > .cleanup = pmem_pagemap_cleanup, > + .memory_failure = pmem_pagemap_memory_failure, > }; > > static int pmem_attach_disk(struct device *dev, > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > index 3bdfcb45f66e..ab3eda335acd 100644 > --- a/mm/memory-failure.c > +++ b/mm/memory-failure.c > @@ -1600,6 +1600,20 @@ static int memory_failure_dev_pagemap(unsigned long pfn, int flags, > */ > SetPageHWPoison(page); > > + /* > + * Call driver's implementation to handle the memory failure, otherwise > + * fall back to generic handler. > + */ > + if (pgmap->ops->memory_failure) { > + rc = pgmap->ops->memory_failure(pgmap, pfn, 1, flags); > + /* > + * Fall back to generic handler too if operation is not > + * supported inside the driver/device/filesystem. > + */ > + if (rc != EOPNOTSUPP) > + goto out; > + } > + > mf_generic_kill_procs(pfn, flags); > out: > /* drop pgmap ref acquired in caller */ > -- > 2.32.0 > > >