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=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 C019BC433E6 for ; Thu, 14 Jan 2021 20:44:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 64223221FD for ; Thu, 14 Jan 2021 20:44:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 64223221FD 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 97B598D0125; Thu, 14 Jan 2021 15:44:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 92BBF8D00F0; Thu, 14 Jan 2021 15:44:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8413F8D0125; Thu, 14 Jan 2021 15:44:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0214.hostedemail.com [216.40.44.214]) by kanga.kvack.org (Postfix) with ESMTP id 6EBE58D00F0 for ; Thu, 14 Jan 2021 15:44:30 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 2D7F0181AEF3E for ; Thu, 14 Jan 2021 20:44:30 +0000 (UTC) X-FDA: 77705558700.29.jar75_31165a827529 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 10EAE180868EC for ; Thu, 14 Jan 2021 20:38:44 +0000 (UTC) X-HE-Tag: jar75_31165a827529 X-Filterd-Recvd-Size: 6636 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Thu, 14 Jan 2021 20:38:42 +0000 (UTC) Received: by mail-ed1-f43.google.com with SMTP id by27so7154641edb.10 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=W4RX6rlCzEhnvk8fTua042rNkJUJYZ7+ju/JdUk9r7gLIttqN6mlwewdOC2kpj2vzb s68DLwZwMKjhQuLw0QbC5AlGeQ0Y5f8FZo/50wxHGAKMjVtdTHMJazqFWW5kmtMjpCZV vpXDKtS1sag4Tie6+4On5jKAxP6A2OlaRt4b1Ll6ZNbHWwC4squ6gUoftSPlMMdxAweq RHR6RcD6uK/i9Th5vPqR8TCzA+xrFjkqY+1ag6VQQB8KXdXjohTZQujm2svHxS2Q1J4p 6n1w0nnMQNn4KEdXr+wKfxzsl9rBjlE3L5Grs+3btBM3opnHSkLKHlCRTZ37cT7eB4a0 lruQ== X-Gm-Message-State: AOAM530NaorjuUEEhgaQv/W8HStnU4ciiiq/hhRuRLqTwx5hqTKY+ifR KBIjp55DHDS5Y6G/VTmJmdOUPqz/AcLW65dVWG9P6A== X-Google-Smtp-Source: ABdhPJw/UE18mcptuTTaq48ZA3l/slnXhk/5uHJysnrWQLOxkXl0WkGF7VK5q6iTBMceXPuJ8xY9V/7LnANIuvkLoIM= 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" 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, 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