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=ham 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 59F70C4338F for ; Fri, 20 Aug 2021 22:59:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D744E60C41 for ; Fri, 20 Aug 2021 22:59:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D744E60C41 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 667CD6B0071; Fri, 20 Aug 2021 18:59:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 617156B0072; Fri, 20 Aug 2021 18:59:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52D258D0001; Fri, 20 Aug 2021 18:59:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0105.hostedemail.com [216.40.44.105]) by kanga.kvack.org (Postfix) with ESMTP id 36EA06B0071 for ; Fri, 20 Aug 2021 18:59:15 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B98422CFFD for ; Fri, 20 Aug 2021 22:59:14 +0000 (UTC) X-FDA: 78496976628.33.14A9B8E Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf23.hostedemail.com (Postfix) with ESMTP id 759909000093 for ; Fri, 20 Aug 2021 22:59:14 +0000 (UTC) Received: by mail-pl1-f174.google.com with SMTP id b9so2418349plx.2 for ; Fri, 20 Aug 2021 15:59:14 -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=4J9u3EAGcrYRrFr9a28F3qghmkpi2i6oIZ8UbGMRg5Q=; b=anEFs1UiP9dfKz4P/uHPE9kEqv7MkVMmOpvTAzqV08rYDche7b0ksSUnfNPfaCpgzP e9o7hblx+hLz5Nl60I6+hAR3wChILzkxma984XnglnGUVjrxySBf9RHwcnCyvmHR0E3D /PO4zKOIZ00vbiCJCST1mcmqExfELWV35I4c28sImt4NeEjmuyoqAo4veMcamynIXSly N374deXmUfZlN3MdOJk8WH+CtiC6uTHGByFsY0+nzx9U5qO6R2wXluoewcgzM1QD9Uqk vDn3TqmthLxUy2TNMDmX+v1WaZ3As1fJ46enIH2XqW2Cm8fX2W+a1rUf0UBQqimRAjvl /C9g== 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=4J9u3EAGcrYRrFr9a28F3qghmkpi2i6oIZ8UbGMRg5Q=; b=ppKmUEwgEhML4bpLhDNuTUeCs/SIlEGHULV7iwU/At2eTClxPUk+GyU8+v+IB0+8si 3Oyp/5igUGsLvAtaDFuC7ZlEEl1L286toSdMPQ4Z/d/uXa0G8PlIxeyz0Lay2tXZvi1N 5vuhrJnv7Xr0GiFn7nV2G0WwrooSaJD0BBQr1vOx10vlO3T+T6bFayYYjxOvTBmxgGrg B8ZRmb2yOyPAIAkmYRLarsM6Knvtgj+IYQj514Oq0/3SqPhJXi5cfrZNHwVFjl1RoL5+ HLxED0OGppGbXNIwOJTl6nHtXyXzowJ8MwrozUOzsxKGKCAeqNkou33BIoxXS+ISMJrk 7LmA== X-Gm-Message-State: AOAM532QtCMNJIDS09L1KThKrDDF5CdN2UGA7zfsZV1vnjTWLW9CyxP3 4oWmwXZiIWi7tST6v61iUcgHmAztTJYL5G2AM+7olg== X-Google-Smtp-Source: ABdhPJzmm+ahkZHadNRsrgbZ7uYrM7d7oiVybo+IGZSGhl9C+B3H/3syn4zyd/DiLhslnXQ3Gq0ivqGhKs2WDDhbCAQ= X-Received: by 2002:a17:90a:708c:: with SMTP id g12mr7031600pjk.13.1629500353664; Fri, 20 Aug 2021 15:59:13 -0700 (PDT) MIME-Version: 1.0 References: <20210730100158.3117319-1-ruansy.fnst@fujitsu.com> <20210730100158.3117319-7-ruansy.fnst@fujitsu.com> In-Reply-To: <20210730100158.3117319-7-ruansy.fnst@fujitsu.com> From: Dan Williams Date: Fri, 20 Aug 2021 15:59:02 -0700 Message-ID: Subject: Re: [PATCH RESEND v6 6/9] xfs: Implement ->notify_failure() for XFS 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: 759909000093 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=intel-com.20150623.gappssmtp.com header.s=20150623 header.b=anEFs1Ui; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none); spf=none (imf23.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.214.174) smtp.mailfrom=dan.j.williams@intel.com X-Rspamd-Server: rspam01 X-Stat-Signature: uomifomiomiw849edx9jc7boq8ft7uae X-HE-Tag: 1629500354-915143 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: > > This function is used to handle errors which may cause data lost in > filesystem. Such as memory failure in fsdax mode. > > If the rmap feature of XFS enabled, we can query it to find files and > metadata which are associated with the corrupt data. For now all we do > is kill processes with that file mapped into their address spaces, but > future patches could actually do something about corrupt metadata. > > After that, the memory failure needs to notify the processes who are > using those files. > > Signed-off-by: Shiyang Ruan > --- > drivers/dax/super.c | 12 ++++ > fs/xfs/xfs_fsops.c | 5 ++ > fs/xfs/xfs_mount.h | 1 + > fs/xfs/xfs_super.c | 135 ++++++++++++++++++++++++++++++++++++++++++++ > include/linux/dax.h | 13 +++++ > 5 files changed, 166 insertions(+) > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c > index 00c32dfa5665..63f7b63d078d 100644 > --- a/drivers/dax/super.c > +++ b/drivers/dax/super.c > @@ -65,6 +65,18 @@ struct dax_device *fs_dax_get_by_bdev(struct block_device *bdev) > return dax_get_by_host(bdev->bd_disk->disk_name); > } > EXPORT_SYMBOL_GPL(fs_dax_get_by_bdev); > + > +void fs_dax_set_holder(struct dax_device *dax_dev, void *holder, > + const struct dax_holder_operations *ops) > +{ > + dax_set_holder(dax_dev, holder, ops); > +} > +EXPORT_SYMBOL_GPL(fs_dax_set_holder); Small style issue, I'd prefer a pair of functions: fs_dax_register_holder(struct dax_device *dax_dev, void *holder, const struct dax_holder_operations *ops) fs_dax_unregister_holder(struct dax_device *dax_dev) ...rather than open coding unregister as a special set that passes NULL arguments. > +void *fs_dax_get_holder(struct dax_device *dax_dev) > +{ > + return dax_get_holder(dax_dev); Does dax_get_holder() have a lockdep_assert to check that the caller has at least a read_lock? Please add kernel-doc for this api to indicate the locking context expectations. The rest of this looks plausibly ok to me, but it would be up to xfs folks to comment on the details. I'm not entirely comfortable with these handlers assuming DAX, i.e. they should also one day be useful for page cache memory failure notifications, but that support can come later.