Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp562597pxb; Thu, 14 Jan 2021 12:40:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJyf0SJeN0bU7VeTUNZKHA2AoDbR5Yun7QZQ/TOxGbkNVOLEvvNpwqC38E7/9ULe+YxAbcuf X-Received: by 2002:a17:906:adce:: with SMTP id lb14mr6460528ejb.502.1610656824333; Thu, 14 Jan 2021 12:40:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610656824; cv=none; d=google.com; s=arc-20160816; b=GD63W6v7AxbMl7pM3PnZqbGIJze3uyxfQYX3gace0XhnFHEqCaTvTykwOHZT2IYYX6 0GNCtT2lc4NH71p8SOHRlkrc4IsywZDl+wnEftliReLMr1aWwwgEWtJC5UjG1+P7e8Cv 6Ota9UZ/sZVo1ZD38/Peyi8Ag36AM8Ol5ghLkIgT7WXUUFUJth1v7tl1P/kmvDvmv+ch 2u6WUO03NnaTPt9AH+GrTx9TjlzubwpHO99QVtyYkV1r+Bjcr4HJ2WjY6XlvNPU0Iho5 OKvRy17T0i3wJ31mxusiA5mYU/4A2r2YjZ3rynXc8e3Rzhu2+EW0hNWUW4PlgTklkAy+ Au5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=HW2Gy+bmbScdrUiihPvmqmOfoBoJ371Y9lVdMFUmq+Y=; b=KoXQqyT85B3RYAuQ25zvjWt+wpv46dQC5okR/vimievgT5be9WrGqczukxY6auuCdL nWRBm/wkdkaRr1laVrfCfdz1HovR0ztV6ZgFxtYUIKA3wriSOdrvcgBKEXf+f8NxzvCp A52vgKkzxjeddHPCt6fvPHrQdjlaDaM1JXg3PZoQp14XOc94csWoHTkmXTh6FFHQTQkp 3YVQGA4VvRd5dmFD6lzHviGKMVpuki/XLvbxBxWdsljZqoRuFBmGKjTHjenAjgR4IEG9 rnOeei5Yogd6jxQ758FdXwyVeID5IzPSFqqqvNkrLjKDuxJ1ROwSOuMkoHBEp/hdH6S1 MWmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=yGOdyQNI; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id zk17si2873609ejb.268.2021.01.14.12.40.00; Thu, 14 Jan 2021 12:40:24 -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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=yGOdyQNI; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728120AbhANUjX (ORCPT + 99 others); Thu, 14 Jan 2021 15:39:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726573AbhANUjX (ORCPT ); Thu, 14 Jan 2021 15:39:23 -0500 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2ABCC061575 for ; Thu, 14 Jan 2021 12:38:42 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id c7so7178500edv.6 for ; Thu, 14 Jan 2021 12:38:42 -0800 (PST) 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=HW2Gy+bmbScdrUiihPvmqmOfoBoJ371Y9lVdMFUmq+Y=; b=yGOdyQNILINypQm/2jqXO6AfJMafn21XGw8EuGb3Op3CFg1tTZMSAR0rEasGJ1fNOS yLllo/9Y8iS/xZYU6AxccWxMPTpSMM8D6QvzzM4jMSGwEs9hnHIlBnLno7KTxzdYF3Kp KwtNyxup1uOWxXyQrcBBAo2o9U51ITkYAiriKkt2QNr2JX6HrELaFQgxFhhCA8zYidBs k7aOmIV3u5QzjG0umzVAbcSHGi2o9GzSnc7gS6T59a8K4b8xbNr8QhTa7Jy5EYUITqET o40thjAjGnsgi1R5vPAh+U9Vvz+toY/DwyAl8fonbO5ueCyy/1GYAeVF73/Ndh+roNVD 9VQg== 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=HW2Gy+bmbScdrUiihPvmqmOfoBoJ371Y9lVdMFUmq+Y=; b=pK0Lzsj1pqryo18T5sRoaueEvXguL0iOZnyp1Oy5WHZrq0ac5zZ53KXJUxBnNWWiPG 8IlhI7LeQ4Dv9yFa/CeJOaEijzNluxC/sLu1nylN1GOHlKfzNBQ7TH3zO7aHju7sAlDu 2ZaeLN0NA36Cw0KdVadnX0cvGnmSMqsT+FhknZ9XCCZRiVq9nO0QKex6ZTjA3m5huOBa q/p3WRaxbNueBbA2JF2dEppuTKqB/vQbDVEp2c7c924XgdoloUZd550cILixVYKXXht3 aCOTVssuvfkEWJfPcv1VM1MB8cH68moud18CR7SHMnx897U0AcSFw0PbTldq7zXMlCUn opQw== X-Gm-Message-State: AOAM532Fp8IlfWbUsxup0bjh2ycqQW/y7QC3+xLRx1BeKOtE9NrF9kdY J6MK4lEAkgTg+V3888J8iJGJk6ppnMrDbxtt6DVOMQ== X-Received: by 2002:a50:b282:: with SMTP id p2mr7358432edd.210.1610656721518; Thu, 14 Jan 2021 12:38:41 -0800 (PST) MIME-Version: 1.0 References: <20201230165601.845024-1-ruansy.fnst@cn.fujitsu.com> <20201230165601.845024-5-ruansy.fnst@cn.fujitsu.com> In-Reply-To: <20201230165601.845024-5-ruansy.fnst@cn.fujitsu.com> From: Dan Williams Date: Thu, 14 Jan 2021 12:38:30 -0800 Message-ID: Subject: Re: [PATCH 04/10] mm, fsdax: Refactor memory-failure handler for dax mapping To: Shiyang Ruan Cc: Linux Kernel Mailing List , linux-xfs , linux-nvdimm , Linux MM , linux-fsdevel , linux-raid , "Darrick J. Wong" , david , Christoph Hellwig , song@kernel.org, Goldwyn Rodrigues , qi.fuli@fujitsu.com, y-goto@fujitsu.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 30, 2020 at 8:59 AM 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 > --- > fs/dax.c | 21 +++++++++++ > include/linux/dax.h | 1 + > include/linux/mm.h | 9 +++++ > mm/memory-failure.c | 91 ++++++++++++++++++++++++++++++++++----------- > 4 files changed, 100 insertions(+), 22 deletions(-) > > diff --git a/fs/dax.c b/fs/dax.c > index 5b47834f2e1b..799210cfa687 100644 > --- a/fs/dax.c > +++ b/fs/dax.c > @@ -378,6 +378,27 @@ static struct page *dax_busy_page(void *entry) > return NULL; > } > > +/* > + * dax_load_pfn - Load pfn of the DAX entry corresponding to a page > + * @mapping: The file whose entry we want to load > + * @index: The offset where the DAX entry located in > + * > + * Return: pfn of the DAX entry > + */ > +unsigned long dax_load_pfn(struct address_space *mapping, unsigned long index) > +{ > + XA_STATE(xas, &mapping->i_pages, index); > + void *entry; > + unsigned long pfn; > + > + xas_lock_irq(&xas); > + entry = xas_load(&xas); > + pfn = dax_to_pfn(entry); > + xas_unlock_irq(&xas); > + > + return pfn; > +} > + > /* > * dax_lock_mapping_entry - Lock the DAX entry corresponding to a page > * @page: The page whose entry we want to lock > diff --git a/include/linux/dax.h b/include/linux/dax.h > index b52f084aa643..89e56ceeffc7 100644 > --- a/include/linux/dax.h > +++ b/include/linux/dax.h > @@ -150,6 +150,7 @@ int dax_writeback_mapping_range(struct address_space *mapping, > > struct page *dax_layout_busy_page(struct address_space *mapping); > struct page *dax_layout_busy_page_range(struct address_space *mapping, loff_t start, loff_t end); > +unsigned long dax_load_pfn(struct address_space *mapping, unsigned long index); > dax_entry_t dax_lock_page(struct page *page); > void dax_unlock_page(struct page *page, dax_entry_t cookie); > #else > diff --git a/include/linux/mm.h b/include/linux/mm.h > index db6ae4d3fb4e..db3059a1853e 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -1141,6 +1141,14 @@ static inline bool is_device_private_page(const struct page *page) > page->pgmap->type == MEMORY_DEVICE_PRIVATE; > } > > +static inline bool is_device_fsdax_page(const struct page *page) > +{ > + return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) && > + IS_ENABLED(CONFIG_DEVICE_PRIVATE) && > + is_zone_device_page(page) && > + page->pgmap->type == MEMORY_DEVICE_FS_DAX; > +} > + Have a look at the recent fixes to pfn_to_online_page() vs DAX pages [1]. This above page type check is racy given that the pfn could stop being pfn_valid() while this check is running. I think hwpoison_filter() needs an explicit check for whether the page is already referenced or not. For example the current call to hwpoison_filter() from memory_failure_dev_pagemap() is safe because the page has already been validated as ZONE_DEVICE and is safe to de-reference page->pgmap. [1]: http://lore.kernel.org/r/161058499000.1840162.702316708443239771.stgit@dwillia2-desk3.amr.corp.intel.com