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, 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 80A88C4361B for ; Wed, 16 Dec 2020 21:26:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ECFDC233F6 for ; Wed, 16 Dec 2020 21:26:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ECFDC233F6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fromorbit.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DB94A6B0036; Wed, 16 Dec 2020 16:26:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D90F16B005C; Wed, 16 Dec 2020 16:26:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CCE3B6B005D; Wed, 16 Dec 2020 16:26:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0029.hostedemail.com [216.40.44.29]) by kanga.kvack.org (Postfix) with ESMTP id B77066B0036 for ; Wed, 16 Dec 2020 16:26:54 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 79D72824999B for ; Wed, 16 Dec 2020 21:26:54 +0000 (UTC) X-FDA: 77600430348.05.suit98_55144182742f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 61E2418028ED5 for ; Wed, 16 Dec 2020 21:26:54 +0000 (UTC) X-HE-Tag: suit98_55144182742f X-Filterd-Recvd-Size: 3604 Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Wed, 16 Dec 2020 21:26:53 +0000 (UTC) Received: from dread.disaster.area (pa49-179-6-140.pa.nsw.optusnet.com.au [49.179.6.140]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 66BF9D7FD6B; Thu, 17 Dec 2020 08:26:49 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1kpeJs-004h5o-Hy; Thu, 17 Dec 2020 08:26:48 +1100 Date: Thu, 17 Dec 2020 08:26:48 +1100 From: Dave Chinner 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, hch@lst.de, song@kernel.org, rgoldwyn@suse.de, qi.fuli@fujitsu.com, y-goto@fujitsu.com Subject: Re: [RFC PATCH v3 4/9] mm, fsdax: Refactor memory-failure handler for dax mapping Message-ID: <20201216212648.GN632069@dread.disaster.area> References: <20201215121414.253660-1-ruansy.fnst@cn.fujitsu.com> <20201215121414.253660-5-ruansy.fnst@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201215121414.253660-5-ruansy.fnst@cn.fujitsu.com> X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=Ubgvt5aN c=1 sm=1 tr=0 cx=a_idp_d a=uDU3YIYVKEaHT0eX+MXYOQ==:117 a=uDU3YIYVKEaHT0eX+MXYOQ==:17 a=kj9zAlcOel0A:10 a=zTNgK-yGK50A:10 a=omOdbC7AAAAA:8 a=7-415B0cAAAA:8 a=eyTjK9YyoW615e0u8fsA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 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, Dec 15, 2020 at 08:14:09PM +0800, Shiyang Ruan wrote: > The current memory_failure_dev_pagemap() can only handle single-mapped > dax page for fsdax mode. The dax page could be mapped by multiple files > and offsets if we let reflink feature & fsdax mode work together. So, > we refactor current implementation to support handle memory failure on > each file and offset. > > Signed-off-by: Shiyang Ruan > --- ..... > static const char *action_name[] = { > @@ -1147,6 +1148,60 @@ static int try_to_split_thp_page(struct page *page, const char *msg) > return 0; > } > > +int mf_dax_mapping_kill_procs(struct address_space *mapping, pgoff_t index, int flags) > +{ > + const bool unmap_success = true; > + unsigned long pfn, size = 0; > + struct to_kill *tk; > + LIST_HEAD(to_kill); > + int rc = -EBUSY; > + loff_t start; > + dax_entry_t cookie; > + > + /* > + * Prevent the inode from being freed while we are interrogating > + * the address_space, typically this would be handled by > + * lock_page(), but dax pages do not use the page lock. This > + * also prevents changes to the mapping of this pfn until > + * poison signaling is complete. > + */ > + cookie = dax_lock(mapping, index, &pfn); > + if (!cookie) > + goto unlock; Why do we need to prevent the inode from going away here? This function gets called by XFS after doing an xfs_iget() call to grab the inode that owns the block. Hence the the inode (and the mapping) are guaranteed to be referenced and can't go away. Hence for the filesystem based callers, this whole "dax_lock()" thing can go away. So, AFAICT, the dax_lock() stuff is only necessary when the filesystem can't be used to resolve the owner of physical page that went bad.... Cheers, Dave. -- Dave Chinner david@fromorbit.com