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 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 EAC74C2B9F4 for ; Thu, 17 Jun 2021 07:04:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 92698611CE for ; Thu, 17 Jun 2021 07:04:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 92698611CE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 249816B0070; Thu, 17 Jun 2021 03:04:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FA066B0071; Thu, 17 Jun 2021 03:04:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0743F6B0072; Thu, 17 Jun 2021 03:04:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0089.hostedemail.com [216.40.44.89]) by kanga.kvack.org (Postfix) with ESMTP id C5F9C6B0070 for ; Thu, 17 Jun 2021 03:04:34 -0400 (EDT) Received: from smtpin37.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 60AD9824C445 for ; Thu, 17 Jun 2021 07:04:34 +0000 (UTC) X-FDA: 78262327668.37.C0CC4D7 Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by imf19.hostedemail.com (Postfix) with ESMTP id 53664900073F for ; Thu, 17 Jun 2021 07:04:19 +0000 (UTC) Received: by mail-pg1-f175.google.com with SMTP id q15so4151904pgg.12 for ; Thu, 17 Jun 2021 00:04:25 -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:content-transfer-encoding; bh=LDO+ysM0sZT13J4jvjx62XJsQjzELPOWU0d8eft8zqE=; b=MSYHsRMV+YBgrqCmtspIiBHsjVSnp8q2rrU7xIz1exEHNDD8d7ZXVFDAiYBGzUTszU oxWDRoOSLJRRil8r0ifAAGjL5CWEnd/9F61h67dMi34JsBfVO0VLMQtf5+pezRqLC5go PZTK6NzMCmnsv6Qee5K86hnFigHdQ1dgeZcQIuVrdFW0XhnCWNCv6gPMF5NyGFHxeSL2 dMEKiaeQr/vUpglRZ2etWHZYLgOnrHHZEM97IasJ8/tLkV4naYw1TegZMq93k1Ibrwf3 nx7W6YkErqI+becB9QtyiVW1SHmC8nzieD38fWwyhux5OnGh/tqoZ0JbbhUCgYq1ZMiH JyTg== 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:content-transfer-encoding; bh=LDO+ysM0sZT13J4jvjx62XJsQjzELPOWU0d8eft8zqE=; b=rRTR3zywMXRW/+5QUudwUwGXNaXIIAVNUlgnAJlddKz5F4ZzfTaik5sH9/o1ZEM+Ah LFpJb9gkjdJE2djvoZXUsPutVgwZ43bnfNak75AyBzjO673cCQgJHxxTXfH/2CmqWtVt 04QlTbkl5Rh75gTD0Kc9Ktv9W0c1Vn4xrFOW1jrRYN1UYegwr/+C9YQHGPt6b6BsBdie P79gytGDL1MrJCHNwis+IyV2sfTqLlfNb8wpiP/9nLsh/JjNX8Ot2J8UJaiHAWmH1QGj o0mfyLdZe+A3FdKFWzKKdwL2qhquM4mC4oStw2oHzVwPs+dS2y02xwc840qwEMuB5lGL iMuQ== X-Gm-Message-State: AOAM530pRZdrtCVwLa6zo7NMp4hVTIb0zzv0YfnmR96QJEsKNckLuxYy Ss1UMB+eGLk/EUFE9XQhcqhUoNnRELOWAt47o3MgxF1gLNgjmQ== X-Google-Smtp-Source: ABdhPJytJXCfpu88GCMpLd2JmLVLvndI0iUm974A4Uf+gWPRlWE3qUqN/z2XXe284KMMKTo0F5nBS9HRMjP/H8ccbSA= X-Received: by 2002:a62:768c:0:b029:2ff:2002:d3d0 with SMTP id r134-20020a62768c0000b02902ff2002d3d0mr324838pfc.70.1623913464979; Thu, 17 Jun 2021 00:04:24 -0700 (PDT) MIME-Version: 1.0 References: <20210604011844.1756145-1-ruansy.fnst@fujitsu.com> <20210604011844.1756145-4-ruansy.fnst@fujitsu.com> In-Reply-To: From: Dan Williams Date: Thu, 17 Jun 2021 00:04:14 -0700 Message-ID: Subject: Re: [PATCH v4 03/10] fs: Introduce ->corrupted_range() for superblock To: "ruansy.fnst@fujitsu.com" Cc: Linux Kernel Mailing List , linux-xfs , Linux MM , linux-fsdevel , device-mapper development , "Darrick J. Wong" , david , Christoph Hellwig , Alasdair Kergon , Mike Snitzer , Goldwyn Rodrigues , Linux NVDIMM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=intel-com.20150623.gappssmtp.com header.s=20150623 header.b=MSYHsRMV; spf=none (imf19.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.215.175) 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: jga6mmbp8obwab9tq4uexrjgb64sshz1 X-Rspamd-Queue-Id: 53664900073F X-Rspamd-Server: rspam06 X-HE-Tag: 1623913459-30789 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 Wed, Jun 16, 2021 at 11:51 PM ruansy.fnst@fujitsu.com wrote: > > > -----Original Message----- > > From: Dan Williams > > Subject: Re: [PATCH v4 03/10] fs: Introduce ->corrupted_range() for sup= erblock > > > > [ drop old linux-nvdimm@lists.01.org, add nvdimm@lists.linux.dev ] > > > > On Thu, Jun 3, 2021 at 6:19 PM Shiyang Ruan w= rote: > > > > > > Memory failure occurs in fsdax mode will finally be handled in > > > filesystem. We introduce this interface to find out files or metadat= a > > > affected by the corrupted range, and try to recover the corrupted dat= a > > > if possiable. > > > > > > Signed-off-by: Shiyang Ruan > > > --- > > > include/linux/fs.h | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/include/linux/fs.h b/include/linux/fs.h index > > > c3c88fdb9b2a..92af36c4225f 100644 > > > --- a/include/linux/fs.h > > > +++ b/include/linux/fs.h > > > @@ -2176,6 +2176,8 @@ struct super_operations { > > > struct shrink_control *); > > > long (*free_cached_objects)(struct super_block *, > > > struct shrink_control *); > > > + int (*corrupted_range)(struct super_block *sb, struct block_d= evice > > *bdev, > > > + loff_t offset, size_t len, void *data)= ; > > > > Why does the superblock need a new operation? Wouldn't whatever functio= n is > > specified here just be specified to the dax_dev as the > > ->notify_failure() holder callback? > > Because we need to find out which file is effected by the given poison pa= ge so that memory-failure code can do collect_procs() and kill_procs() jobs= . And it needs filesystem to use its rmap feature to search the file from = a given offset. So, we need this implemented by the specified filesystem a= nd called by dax_device's holder. > > This is the call trace I described in cover letter: > memory_failure() > * fsdax case > pgmap->ops->memory_failure() =3D> pmem_pgmap_memory_failure() > dax_device->holder_ops->corrupted_range() =3D> > - fs_dax_corrupted_range() > - md_dax_corrupted_range() > sb->s_ops->currupted_range() =3D> xfs_fs_corrupted_range() <=3D=3D= **HERE** > xfs_rmap_query_range() > xfs_currupt_helper() > * corrupted on metadata > try to recover data, call xfs_force_shutdown() > * corrupted on file data > try to recover data, call mf_dax_kill_procs() > * normal case > mf_generic_kill_procs() > > As you can see, this new added operation is an important for the whole pr= ogress. I don't think you need either fs_dax_corrupted_range() nor sb->s_ops->corrupted_range(). In fact that fs_dax_corrupted_range() looks broken because the filesystem may not even be mounted on the device associated with the error. The holder_data and holder_op should be sufficient from communicating the stack of notifications: pgmap->notify_memory_failure() =3D> pmem_pgmap_notify_failure() pmem_dax_dev->holder_ops->notify_failure(pmem_dax_dev) =3D> md_dax_notify_failure() md_dax_dev->holder_ops->notify_failure() =3D> xfs_notify_failure() I.e. the entire chain just walks dax_dev holder ops.