All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kefeng Wang <wangkefeng.wang@huawei.com>
To: kernel test robot <lkp@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: <oe-kbuild-all@lists.linux.dev>,
	Linux Memory Management List <linux-mm@kvack.org>,
	<willy@infradead.org>, David Hildenbrand <david@redhat.com>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Naoya Horiguchi <nao.horiguchi@gmail.com>,
	Oscar Salvador <osalvador@suse.de>, Zi Yan <ziy@nvidia.com>,
	Hugh Dickins <hughd@google.com>, Jonathan Corbet <corbet@lwn.net>,
	Vishal Moola <vishal.moola@gmail.com>
Subject: Re: [PATCH v2 01/10] mm: memory_hotplug: check hwpoisoned page firstly in do_migrate_range()
Date: Sun, 28 Apr 2024 08:49:55 +0800	[thread overview]
Message-ID: <90144595-48d9-48e0-bfbb-e45f1d220a6a@huawei.com> (raw)
In-Reply-To: <202404271110.2fxPtHNB-lkp@intel.com>



On 2024/4/27 11:57, kernel test robot wrote:
> Hi Kefeng,
> 
> kernel test robot noticed the following build warnings:
> 
> [auto build test WARNING on akpm-mm/mm-everything]
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Kefeng-Wang/mm-memory_hotplug-check-hwpoisoned-page-firstly-in-do_migrate_range/20240425-164317
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
> patch link:    https://lore.kernel.org/r/20240425084028.3888403-2-wangkefeng.wang%40huawei.com
> patch subject: [PATCH v2 01/10] mm: memory_hotplug: check hwpoisoned page firstly in do_migrate_range()
> config: arm64-defconfig (https://download.01.org/0day-ci/archive/20240427/202404271110.2fxPtHNB-lkp@intel.com/config)
> compiler: aarch64-linux-gcc (GCC) 13.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240427/202404271110.2fxPtHNB-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202404271110.2fxPtHNB-lkp@intel.com/
> 
> All warnings (new ones prefixed by >>):
> 
>     mm/memory_hotplug.c: In function 'isolate_and_unmap_hwposion_folio':
>     mm/memory_hotplug.c:1786:27: error: implicit declaration of function 'hugetlb_page_mapping_lock_write'; did you mean 'hugetlb_folio_mapping_lock_write'? [-Werror=implicit-function-declaration]
>      1786 |                 mapping = hugetlb_page_mapping_lock_write(&folio->page);
>           |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>           |                           hugetlb_folio_mapping_lock_write
>>> mm/memory_hotplug.c:1786:25: warning: assignment to 'struct address_space *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
>      1786 |                 mapping = hugetlb_page_mapping_lock_write(&folio->page);
>           |                         ^
>     cc1: some warnings being treated as errors


The patch based on next-20240425, but from next-20240426 with
"mm: convert hugetlb_page_mapping_lock_write to folio", so it is easy to
fix by converting to hugetlb_folio_mapping_lock_write() api, but keep it
for a while, see if there are any new comments about this patchset.


Thanks.

> 
> 
> vim +1786 mm/memory_hotplug.c
> 
>    1774	
>    1775	static bool isolate_and_unmap_hwposion_folio(struct folio *folio)
>    1776	{
>    1777		if (WARN_ON(folio_test_lru(folio)))
>    1778			folio_isolate_lru(folio);
>    1779	
>    1780		if (!folio_mapped(folio))
>    1781			return true;
>    1782	
>    1783		if (folio_test_hugetlb(folio) && !folio_test_anon(folio)) {
>    1784			struct address_space *mapping;
>    1785	
>> 1786			mapping = hugetlb_page_mapping_lock_write(&folio->page);
>    1787			if (mapping) {
>    1788				/*
>    1789				 * In shared mappings, try_to_unmap could potentially
>    1790				 * call huge_pmd_unshare.  Because of this, take
>    1791				 * semaphore in write mode here and set TTU_RMAP_LOCKED
>    1792				 * to let lower levels know we have taken the lock.
>    1793				 */
>    1794				try_to_unmap(folio, TTU_IGNORE_MLOCK | TTU_RMAP_LOCKED);
>    1795				i_mmap_unlock_write(mapping);
>    1796			}
>    1797		} else {
>    1798			try_to_unmap(folio, TTU_IGNORE_MLOCK);
>    1799		}
>    1800	
>    1801		return folio_mapped(folio);
>    1802	}
>    1803	
> 

  reply	other threads:[~2024-04-28  0:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-25  8:40 [PATCH v2 00/10] mm: remove isolate_lru_page() and isolate_movable_page() Kefeng Wang
2024-04-25  8:40 ` [PATCH v2 01/10] mm: memory_hotplug: check hwpoisoned page firstly in do_migrate_range() Kefeng Wang
2024-04-27  3:57   ` kernel test robot
2024-04-28  0:49     ` Kefeng Wang [this message]
2024-04-27  5:40   ` kernel test robot
2024-04-27  7:23   ` kernel test robot
2024-04-25  8:40 ` [PATCH v2 02/10] mm: add isolate_folio_to_list() Kefeng Wang
2024-04-25  8:40 ` [PATCH v2 03/10] mm: memory_hotplug: unify Huge/LRU/non-LRU folio isolation Kefeng Wang
2024-04-25  8:40 ` [PATCH v2 04/10] mm: compaction: try get reference before non-lru movable folio migration Kefeng Wang
2024-04-25  8:40 ` [PATCH v2 05/10] mm: migrate: add folio_isolate_movable() Kefeng Wang
2024-04-25  8:40 ` [PATCH v2 06/10] mm: compaction: use folio_isolate_movable() Kefeng Wang
2024-04-25  8:40 ` [PATCH v2 07/10] mm: migrate: " Kefeng Wang
2024-04-25  8:40 ` [PATCH v2 08/10] mm: migrate: remove isolate_movable_page() Kefeng Wang
2024-04-25  8:40 ` [PATCH v2 09/10] mm: migrate_device: use more folio in migrate_device_unmap() Kefeng Wang
2024-04-25  9:31   ` David Hildenbrand
2024-04-25 11:05     ` Kefeng Wang
2024-04-25  8:40 ` [PATCH v2 10/10] mm: remove isolate_lru_page() Kefeng Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=90144595-48d9-48e0-bfbb-e45f1d220a6a@huawei.com \
    --to=wangkefeng.wang@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=nao.horiguchi@gmail.com \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=osalvador@suse.de \
    --cc=vishal.moola@gmail.com \
    --cc=willy@infradead.org \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.