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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DEE20C433EF for ; Wed, 16 Feb 2022 01:47:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5E6466B0078; Tue, 15 Feb 2022 20:47:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5957F6B007B; Tue, 15 Feb 2022 20:47:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 435526B007D; Tue, 15 Feb 2022 20:47:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0072.hostedemail.com [216.40.44.72]) by kanga.kvack.org (Postfix) with ESMTP id 34F946B0078 for ; Tue, 15 Feb 2022 20:47:28 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E8ECA901B7 for ; Wed, 16 Feb 2022 01:47:27 +0000 (UTC) X-FDA: 79146955734.24.1C44333 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf21.hostedemail.com (Postfix) with ESMTP id BF04B1C0002 for ; Wed, 16 Feb 2022 01:47:26 +0000 (UTC) Received: by mail-pl1-f180.google.com with SMTP id l8so813200pls.7 for ; Tue, 15 Feb 2022 17:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nlq8z2arOhNkxaYYwLaD3RpZ3GoR+UWwTLLnfnZTXnY=; b=DMFJ896b0Vz97kUGCM8E2K0r8djjVIJRIYsuIAYOAkaBkfNx2QQREloFJCf8CCj90h nKbD8u01PBQSSUY4vqTZ47YDWw/7PCDnAZR43J2UUhOWiepjRATef/AE87HO4hR7J2nz GU11Ftko5mrJ93140D/KkqH3K/LZp7UXoU/O7KYuYnti1rfi+dGGasqbL8Ese5rf7bo9 0zlx0b2y45jW/cov0X+AFCz60VpwmqGu+eu6OeJ6DLRZRoZejU+362F7o9KjYYX+BWaK Z6uEVIvEuOOUm7Sj5OgLhqGQtk5FGMlS5mNoa//ff5PaLIM4owD5EtniIIHFb0scDZ9e EWmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nlq8z2arOhNkxaYYwLaD3RpZ3GoR+UWwTLLnfnZTXnY=; b=CTg4cSaSVlMewHZrWWLb2RyfoSXcxtzKmUBNv8CgrK2HiLwj6q+mZu4I3IM1Ac1xHk qReR7vMuWw5T/1NhSvoDUrEglASJ1f3XWNW4R0r1aAUmIwtpFrHz67fU4yYfbMUcoOdm IX7goQjTJfMF7EUjvjmdPi0zxCv8yDUf9UKonKXiPKKxa1z+TSdNrwShqiqTtK6Ua1HB 0syf6n11Nb2QYFstQbgGhcuaa2a/YQnQ/ccSYoVl8a9XXznE41IdkJNM3mvKMwnca9Lk vs5gav1wWCxrnCTtgFd/EMuBA7wOQ7CqS6XlFPqN/yaKJkb4LYtTAkINf9gvL1+5/Rk7 Vijg== X-Gm-Message-State: AOAM5316SMqXeFkPpNCl5bMxsdbBGKZsqVr5avKVyTqzR3IrkUodwray JKs3T/El021w3HIVzTwc/hfNnnuSRs4taLJJ0o144A== X-Google-Smtp-Source: ABdhPJwT3hvSagc3TEPzllcZbvtit0z9Qok37GmkfTUSfHMWGioDKT1cQ4/685zOQu/6xCOe6mcuODN03F7rGWAFZWg= X-Received: by 2002:a17:902:7296:b0:14b:4bc6:e81 with SMTP id d22-20020a170902729600b0014b4bc60e81mr636363pll.132.1644976045685; Tue, 15 Feb 2022 17:47:25 -0800 (PST) MIME-Version: 1.0 References: <20220127124058.1172422-1-ruansy.fnst@fujitsu.com> <20220127124058.1172422-8-ruansy.fnst@fujitsu.com> In-Reply-To: <20220127124058.1172422-8-ruansy.fnst@fujitsu.com> From: Dan Williams Date: Tue, 15 Feb 2022 17:47:19 -0800 Message-ID: Subject: Re: [PATCH v10 7/9] mm: Introduce mf_dax_kill_procs() for fsdax case To: Shiyang Ruan Cc: Linux Kernel Mailing List , linux-xfs , Linux NVDIMM , Linux MM , linux-fsdevel , "Darrick J. Wong" , david , Christoph Hellwig , Jane Chu Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: BF04B1C0002 X-Stat-Signature: 6zjnqjmujaaw9mqexjkknuuif81meygf X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b=DMFJ896b; spf=none (imf21.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.214.180) smtp.mailfrom=dan.j.williams@intel.com; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none) X-HE-Tag: 1644976046-820738 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 Thu, Jan 27, 2022 at 4:41 AM Shiyang Ruan wrote: > > This function is called at the end of RMAP routine, i.e. filesystem > recovery function, to collect and kill processes using a shared page of > DAX file. The difference with mf_generic_kill_procs() is, it accepts > file's (mapping,offset) instead of struct page because different files' > mappings and offsets may share the same page in fsdax mode. > It will be called when filesystem's RMAP results are found. > > Signed-off-by: Shiyang Ruan > --- > include/linux/mm.h | 4 ++ > mm/memory-failure.c | 91 +++++++++++++++++++++++++++++++++++++++------ > 2 files changed, 84 insertions(+), 11 deletions(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 9b1d56c5c224..0420189e4788 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -3195,6 +3195,10 @@ enum mf_flags { > MF_SOFT_OFFLINE = 1 << 3, > MF_UNPOISON = 1 << 4, > }; > +#if IS_ENABLED(CONFIG_FS_DAX) > +int mf_dax_kill_procs(struct address_space *mapping, pgoff_t index, > + unsigned long count, int mf_flags); > +#endif /* CONFIG_FS_DAX */ > extern int memory_failure(unsigned long pfn, int flags); > extern void memory_failure_queue(unsigned long pfn, int flags); > extern void memory_failure_queue_kick(int cpu); > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > index b2d13eba1071..8d123cc4102e 100644 > --- a/mm/memory-failure.c > +++ b/mm/memory-failure.c > @@ -304,10 +304,9 @@ void shake_page(struct page *p) > } > EXPORT_SYMBOL_GPL(shake_page); > > -static unsigned long dev_pagemap_mapping_shift(struct page *page, > - struct vm_area_struct *vma) > +static unsigned long dev_pagemap_mapping_shift(struct vm_area_struct *vma, > + unsigned long address) > { > - unsigned long address = vma_address(page, vma); > unsigned long ret = 0; > pgd_t *pgd; > p4d_t *p4d; > @@ -347,9 +346,8 @@ static unsigned long dev_pagemap_mapping_shift(struct page *page, > * Schedule a process for later kill. > * Uses GFP_ATOMIC allocations to avoid potential recursions in the VM. > */ > -static void add_to_kill(struct task_struct *tsk, struct page *p, > - struct vm_area_struct *vma, > - struct list_head *to_kill) > +static void add_to_kill(struct task_struct *tsk, struct page *p, pgoff_t pgoff, > + struct vm_area_struct *vma, struct list_head *to_kill) > { > struct to_kill *tk; > > @@ -360,9 +358,15 @@ static void add_to_kill(struct task_struct *tsk, struct page *p, > } > > tk->addr = page_address_in_vma(p, vma); > - if (is_zone_device_page(p)) > - tk->size_shift = dev_pagemap_mapping_shift(p, vma); > - else > + if (is_zone_device_page(p)) { > + /* > + * Since page->mapping is not used for fsdax, we need > + * calculate the address based on the vma. > + */ > + if (p->pgmap->type == MEMORY_DEVICE_FS_DAX) > + tk->addr = vma_pgoff_address(vma, pgoff); > + tk->size_shift = dev_pagemap_mapping_shift(vma, tk->addr); > + } else > tk->size_shift = page_shift(compound_head(p)); > > /* > @@ -510,7 +514,7 @@ static void collect_procs_anon(struct page *page, struct list_head *to_kill, > if (!page_mapped_in_vma(page, vma)) > continue; > if (vma->vm_mm == t->mm) > - add_to_kill(t, page, vma, to_kill); > + add_to_kill(t, page, 0, vma, to_kill); Why is the @pgoff argument 0? @pgoff is available. Not that I expect dax pages will ever be anonymous, might as well not leave that land mine for future refactoring. Other than that you can add: Reviewed-by: Dan Williams