Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp180505pxb; Fri, 8 Jan 2021 01:57:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJw0a9t0wiYzoYxsKsGnF0E4ZApyrbeOsEQh1ZTwoLu1VRgJVVpfhKRxQUuVtbr8w7+FUCdW X-Received: by 2002:a17:906:a2d0:: with SMTP id by16mr2053897ejb.207.1610099879495; Fri, 08 Jan 2021 01:57:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610099879; cv=none; d=google.com; s=arc-20160816; b=sFTmwiI6kW6vXo3E7F6JkZcQYDwcCVvXl6BEgSPjKQbyZ4snkYeV4KPUARd1UgOKp+ 68VogeYIeMxkdW3dbjFUuyHkNEtvpRNbfRdlhb/UENK+dbLx/X1BnV7w6yfhYlhM2Z9U CdQrUd49PEZWFWbnG5ed/6BhdmXe2v4gIjKe1syP92OitqIewlFWxhnBdN6krJwqnFyN doK9v8W/xkG9XSbNShfdjT89WDCEjicWCTk91cSJXb3+vXmjnpJhPX4XU4tQ7gRfkv2Z 7l5wty8Cv2MReYrupMGh6kxTXo/jFKsjDc6mPxvnVM3UCRpANANjDlehQ4yj/6dPBpoK MlCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=0kzRyCMSDSyQTv/4YMjyBMnVPHjBgM/CJmhcTiA/5Z4=; b=LEhgP/CDDkh6Ri2iONQ0whld5Ixj0gLsX0rqhW4zhj0Gcknct0Xvh7r3j7xalsDYAT 9TNGOqIwmjU2vDmb9AQ7rYcgp8Ie9jHdL5z+58Fs60s2g1xWsP9ErsJiJTwSTjb4GGmN C9aiyjCbIkLThPAKdxHo/2N6DqJ+Dp6HG1gt3o+dzIT+vhn9578UOpAcKENgz7amdNHS AnIhrwYfIaRpB4A2cvQxb/zJO2AIw5sV9moaiimw1rtR6miFi4+P6zSRSzWlODKqyD4t OunvuSVXIHIsTGCCaLFNdtjvQWyasLxb+BfJjM85JjZWRS1bqREQlHDWRHJWFpJ8HNAu ls+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a15si3366794eda.177.2021.01.08.01.57.36; Fri, 08 Jan 2021 01:57:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728164AbhAHJ46 (ORCPT + 99 others); Fri, 8 Jan 2021 04:56:58 -0500 Received: from verein.lst.de ([213.95.11.211]:43323 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727795AbhAHJ45 (ORCPT ); Fri, 8 Jan 2021 04:56:57 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id 0C03967373; Fri, 8 Jan 2021 10:56:15 +0100 (CET) Date: Fri, 8 Jan 2021 10:56:14 +0100 From: Christoph Hellwig To: Shiyang Ruan Cc: linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-nvdimm@lists.01.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-raid@vger.kernel.org, darrick.wong@oracle.com, dan.j.williams@intel.com, david@fromorbit.com, hch@lst.de, song@kernel.org, rgoldwyn@suse.de, qi.fuli@fujitsu.com, y-goto@fujitsu.com Subject: Re: [PATCH 03/10] fs: Introduce ->corrupted_range() for superblock Message-ID: <20210108095614.GB5647@lst.de> References: <20201230165601.845024-1-ruansy.fnst@cn.fujitsu.com> <20201230165601.845024-4-ruansy.fnst@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201230165601.845024-4-ruansy.fnst@cn.fujitsu.com> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 31, 2020 at 12:55:54AM +0800, Shiyang Ruan wrote: > Memory failure occurs in fsdax mode will finally be handled in > filesystem. We introduce this interface to find out files or metadata > affected by the corrupted range, and try to recover the corrupted data > 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 8667d0cdc71e..282e2139b23e 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -1965,6 +1965,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_device *bdev, This adds an overly long line. But more importantly it must work on the dax device and not the block device. I'd also structure the callback so that it is called on the dax device only, with the file system storing the super block in a private data member.