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 C3ABBC001B0 for ; Fri, 14 Jul 2023 03:05:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 554E1900009; Thu, 13 Jul 2023 23:05:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 50329900002; Thu, 13 Jul 2023 23:05:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CB08900009; Thu, 13 Jul 2023 23:05:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2C945900002 for ; Thu, 13 Jul 2023 23:05:58 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id DC4AD140480 for ; Fri, 14 Jul 2023 03:05:57 +0000 (UTC) X-FDA: 81008727954.30.E2493F4 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf29.hostedemail.com (Postfix) with ESMTP id 6A56712000C for ; Fri, 14 Jul 2023 03:05:55 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689303956; a=rsa-sha256; cv=none; b=0eF74CFAAxw8w4XqU/lqlBl3uurH4oBz/DABvtZwMJAa6yMkVT72wqHsBm07MSfm0KKdXY BOseMxAFV/MLEbGT/hQC5mH5AywPl+R8pcZaMbOtjzfbKu+dJTcOh2DxZTvkgW7S0smEu6 bscM3dDjiui+zoBMmOIqEx/qBtRZTsQ= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689303956; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3b61XOxPsUhNJ3dENz9mGa9e/+P4EbzJTyMQvbLMIHY=; b=VRq5C8LAWwY4qozG/KsdKtmDEAiuruRhjr/8cs/KGM9aWQ9PO9CAShoh3Y0Y8P/cFFDEvl t5fK66quSrsr2byTE46SSU6HbBwQsVZfT6haBu26N3LSt6bZnpU1Ye68g7VH2UEB2K8rbp LQMkx/lAVsG4US2OKzES/SjGB5TK9Go= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 694F11570; Thu, 13 Jul 2023 20:06:36 -0700 (PDT) Received: from [10.163.47.78] (unknown [10.163.47.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D95D23F67D; Thu, 13 Jul 2023 20:05:51 -0700 (PDT) Message-ID: <7c05a142-09a4-cfc1-b6ef-db89abcffd35@arm.com> Date: Fri, 14 Jul 2023 08:35:50 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v1] mm/hwpoison: rename hwp_walk* to hwpoison_walk* Content-Language: en-US To: Jiaqi Yan , naoya.horiguchi@nec.com Cc: linmiaohe@huawei.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, willy@infradead.org References: <20230713235553.4121855-1-jiaqiyan@google.com> From: Anshuman Khandual In-Reply-To: <20230713235553.4121855-1-jiaqiyan@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6A56712000C X-Stat-Signature: 68rieptqpubbcjwhj9r7z3o5ip9bhm9c X-HE-Tag: 1689303955-843493 X-HE-Meta: U2FsdGVkX1+bae5XjwBdaqJM1XgJkITt2/j3rAOY7nEbP8Hl/PSGKLQUTl9KZF7HmudQAKhqWm8+m7BFiQqp/rvXkoOGCy+C22cjRXEpOw19v3hLzke0XSYKpc8jA5iM7YV6I90F7phiVP67lrdZ0yHH9NIv91VONgLoSDOwWRyk6iQ8JYsTL6rrbb1Tir5YduCp8wBwV1SzFqNQ8jyEcNwPHtCThtB8Ll+He0eJgujA3bTF5pukhvvydJbm+eMSTBstIMZIB2tNGvCbh4Vm/veWild11eXVuk8gdsUXRTIV1hsJFs/BDP9gKzrfitbsceLe61Jxn5d0prJvWBh0hMSh9elnhzA5KHe3XJhU7Jhm8eqiasohoZrsCwBQfdq+itCJzM8DEgDcpfnBhGnoEeCrusds/rB5a8VMveu6vY1Myf8qp5gpu8KPYWC4YaqXBft2Dhf8ArRUxNB4o1xZf5lVqJVeb2Qh9mhP/wjlH7cYZ5DbIywY9+96fNSXRE2Mv4HKKE8AWl/5qJJ7q0A7bq+kbhjl5dnJxtZiHr9F8jhNBvF0EdrIXbUa7YUJfEbIiTPeioqk5QKrqGn9ETLVTKGeE2UQB1RCEkBPSbfEFbHZEqmnotRCQ4bRbx2NPCR9boq4zGB/7MFSC/rFvFGYGwpq94ELFE+fG694ns3+V6DKsNmDcRpRMzrG+oJpDPH+V2zD8q/CjImBoZ0cEA9mocde7L+sBvYubZm96mYKwBwq+3VsHYMywEb9Ldi/TUQE+AcDzGsuJHOh5kS5/YqxGLK0nNltSWFuBEBoHBQGKdnhaYuJ3tRTpW3bq2RpSk4sq+89Wnjzi3rZ5J6qS2zFYyND4WcUMg8BXgCOSs6++QKujnwuTdslRgXz3XpD5/rtxvPV8NS3XL1iPu7MYjfWfBj2DaP8pptGKvV+t1zOCZtCNEb5VzdgnZQB4bq6tzBVslAe1PiHPNbCB4JHWmh JQsGCAN6 cG+QmbkrLuGx+MHqeuyL/LTFnwWvWOFWvq3wQaNuSPBInMb77hGdRsIRpDomv43xoYrNau/svU/LrdCxnd3A6LtrgdSBDtSOPCmG7rhn7MeG3374APpfbmnFZPTO02O69vUkCcucpwoc3qo5qMsqZKkm7OpiStqoPs/RuxUjD7cpAL8s3U8nOI+skO8XeuYkPPBTg4tYY5CmRIVu/RlXjgwt9xRdgLbPZi/Arhzz+wzK27rL42FhMkF9ntAKEMlKWBADqlVRJ79SYi1WEFoMebVhbk2tYfcOuRd+CAEyV6pyIqdM6kfMu4staT+jnsY6FONMXY0vk9Y7/5n7NDX4jrtzhUOHtMn9qznR1 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 7/14/23 05:25, Jiaqi Yan wrote: > In the discussion of "Improve hugetlbfs read on HWPOISON hugepages", A very small nit, [1] should appear here instead ^^^^ > Matthew Wilcox suggests hwp is a bad abbreviation of hwpoison, as hwp > is already used as "an acronym by acpi, intel_pstate, some clock > drivers, an ethernet driver, and a scsi driver"[1]. Some examples here might have been useful, but never mind. > > So rename hwp_walk and hwp_walk_ops to hwpoison_walk and > hwpoison_walk_ops respectively. > > raw_hwp_(page|list), *_raw_hwp, and raw_hwp_unreliable flag are other > major appearances of "hwp". However, given the "raw" hint in the name, > it is easy to differentiate them from other "hwp" acronyms. Since > renaming them is not as straightforward as renaming hwp_walk*, they > are not covered by this commit. Makes sense. > > [1] https://lore.kernel.org/lkml/20230707201904.953262-5-jiaqiyan@google.com/T/#me6fecb8ce1ad4d5769199c9e162a44bc88f7bdec > > Signed-off-by: Jiaqi Yan > --- > mm/memory-failure.c | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > index e245191e6b04..cb232e41f6c0 100644 > --- a/mm/memory-failure.c > +++ b/mm/memory-failure.c > @@ -721,7 +721,7 @@ static void collect_procs(struct page *page, struct list_head *tokill, > collect_procs_file(page, tokill, force_early); > } > > -struct hwp_walk { > +struct hwpoison_walk { > struct to_kill tk; > unsigned long pfn; > int flags; > @@ -756,7 +756,7 @@ static int check_hwpoisoned_entry(pte_t pte, unsigned long addr, short shift, > > #ifdef CONFIG_TRANSPARENT_HUGEPAGE > static int check_hwpoisoned_pmd_entry(pmd_t *pmdp, unsigned long addr, > - struct hwp_walk *hwp) > + struct hwpoison_walk *hwp) > { > pmd_t pmd = *pmdp; > unsigned long pfn; > @@ -774,7 +774,7 @@ static int check_hwpoisoned_pmd_entry(pmd_t *pmdp, unsigned long addr, > } > #else > static int check_hwpoisoned_pmd_entry(pmd_t *pmdp, unsigned long addr, > - struct hwp_walk *hwp) > + struct hwpoison_walk *hwp) > { > return 0; > } > @@ -783,7 +783,7 @@ static int check_hwpoisoned_pmd_entry(pmd_t *pmdp, unsigned long addr, > static int hwpoison_pte_range(pmd_t *pmdp, unsigned long addr, > unsigned long end, struct mm_walk *walk) > { > - struct hwp_walk *hwp = walk->private; > + struct hwpoison_walk *hwp = walk->private; > int ret = 0; > pte_t *ptep, *mapped_pte; > spinlock_t *ptl; > @@ -817,7 +817,7 @@ static int hwpoison_hugetlb_range(pte_t *ptep, unsigned long hmask, > unsigned long addr, unsigned long end, > struct mm_walk *walk) > { > - struct hwp_walk *hwp = walk->private; > + struct hwpoison_walk *hwp = walk->private; > pte_t pte = huge_ptep_get(ptep); > struct hstate *h = hstate_vma(walk->vma); > > @@ -828,7 +828,7 @@ static int hwpoison_hugetlb_range(pte_t *ptep, unsigned long hmask, > #define hwpoison_hugetlb_range NULL > #endif > > -static const struct mm_walk_ops hwp_walk_ops = { > +static const struct mm_walk_ops hwpoison_walk_ops = { > .pmd_entry = hwpoison_pte_range, > .hugetlb_entry = hwpoison_hugetlb_range, > }; > @@ -850,7 +850,7 @@ static int kill_accessing_process(struct task_struct *p, unsigned long pfn, > int flags) > { > int ret; > - struct hwp_walk priv = { > + struct hwpoison_walk priv = { > .pfn = pfn, > }; > priv.tk.tsk = p; > @@ -859,7 +859,7 @@ static int kill_accessing_process(struct task_struct *p, unsigned long pfn, > return -EFAULT; > > mmap_read_lock(p->mm); > - ret = walk_page_range(p->mm, 0, TASK_SIZE, &hwp_walk_ops, > + ret = walk_page_range(p->mm, 0, TASK_SIZE, &hwpoison_walk_ops, > (void *)&priv); > if (ret == 1 && priv.tk.addr) > kill_proc(&priv.tk, pfn, flags); This makes better sense, and the patch LGTM in itself. There are no residues for "hwp_walk_ops" and "hwp_walk" symbols in the tree afterwards. Reviewed-by: Anshuman Khandual