From: kernel test robot <lkp@intel.com>
To: Yunsheng Lin <yunshenglin0825@gmail.com>
Cc: oe-kbuild-all@lists.linux.dev
Subject: [linyunsheng:pcp_prototype_241117 1/1] mm/memory-failure.c:181:17: error: implicit declaration of function 'drain_all_pages'; did you mean 'drain_local_pages'?
Date: Mon, 2 Dec 2024 05:25:45 +0800 [thread overview]
Message-ID: <202412020516.HKyPiDrZ-lkp@intel.com> (raw)
tree: https://github.com/gestionlin/linux.git pcp_prototype_241117
head: 0bd7954c9b0be944e9c39400721255546f1624d8
commit: 0bd7954c9b0be944e9c39400721255546f1624d8 [1/1] mm: split out per cpu page
config: parisc-allyesconfig (https://download.01.org/0day-ci/archive/20241202/202412020516.HKyPiDrZ-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241202/202412020516.HKyPiDrZ-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/202412020516.HKyPiDrZ-lkp@intel.com/
All errors (new ones prefixed by >>):
mm/memory-failure.c: In function '__page_handle_poison':
>> mm/memory-failure.c:181:17: error: implicit declaration of function 'drain_all_pages'; did you mean 'drain_local_pages'? [-Wimplicit-function-declaration]
181 | drain_all_pages(page_zone(page));
| ^~~~~~~~~~~~~~~
| drain_local_pages
vim +181 mm/memory-failure.c
8cbc82f3ec0d58 Kefeng Wang 2023-03-20 156
7453bf621cfaf0 Naoya Horiguchi 2022-07-14 157 /*
7453bf621cfaf0 Naoya Horiguchi 2022-07-14 158 * Return values:
7453bf621cfaf0 Naoya Horiguchi 2022-07-14 159 * 1: the page is dissolved (if needed) and taken off from buddy,
7453bf621cfaf0 Naoya Horiguchi 2022-07-14 160 * 0: the page is dissolved (if needed) and not taken off from buddy,
7453bf621cfaf0 Naoya Horiguchi 2022-07-14 161 * < 0: failed to dissolve.
7453bf621cfaf0 Naoya Horiguchi 2022-07-14 162 */
7453bf621cfaf0 Naoya Horiguchi 2022-07-14 163 static int __page_handle_poison(struct page *page)
510d25c92ec4ac Naoya Horiguchi 2021-06-30 164 {
f87060d345232c Michael Wang 2021-09-02 165 int ret;
510d25c92ec4ac Naoya Horiguchi 2021-06-30 166
1983184c22dd84 Miaohe Lin 2024-04-07 167 /*
1983184c22dd84 Miaohe Lin 2024-04-07 168 * zone_pcp_disable() can't be used here. It will
54fa49b2e0ef3a Sidhartha Kumar 2024-04-11 169 * hold pcp_batch_high_lock and dissolve_free_hugetlb_folio() might hold
1983184c22dd84 Miaohe Lin 2024-04-07 170 * cpu_hotplug_lock via static_key_slow_dec() when hugetlb vmemmap
1983184c22dd84 Miaohe Lin 2024-04-07 171 * optimization is enabled. This will break current lock dependency
1983184c22dd84 Miaohe Lin 2024-04-07 172 * chain and leads to deadlock.
1983184c22dd84 Miaohe Lin 2024-04-07 173 * Disabling pcp before dissolving the page was a deterministic
1983184c22dd84 Miaohe Lin 2024-04-07 174 * approach because we made sure that those pages cannot end up in any
1983184c22dd84 Miaohe Lin 2024-04-07 175 * PCP list. Draining PCP lists expels those pages to the buddy system,
1983184c22dd84 Miaohe Lin 2024-04-07 176 * but nothing guarantees that those pages do not get back to a PCP
1983184c22dd84 Miaohe Lin 2024-04-07 177 * queue if we need to refill those.
1983184c22dd84 Miaohe Lin 2024-04-07 178 */
54fa49b2e0ef3a Sidhartha Kumar 2024-04-11 179 ret = dissolve_free_hugetlb_folio(page_folio(page));
1983184c22dd84 Miaohe Lin 2024-04-07 180 if (!ret) {
1983184c22dd84 Miaohe Lin 2024-04-07 @181 drain_all_pages(page_zone(page));
510d25c92ec4ac Naoya Horiguchi 2021-06-30 182 ret = take_page_off_buddy(page);
1983184c22dd84 Miaohe Lin 2024-04-07 183 }
510d25c92ec4ac Naoya Horiguchi 2021-06-30 184
7453bf621cfaf0 Naoya Horiguchi 2022-07-14 185 return ret;
510d25c92ec4ac Naoya Horiguchi 2021-06-30 186 }
510d25c92ec4ac Naoya Horiguchi 2021-06-30 187
:::::: The code at line 181 was first introduced by commit
:::::: 1983184c22dd84a4d95a71e5c6775c2638557dc7 mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled
:::::: TO: Miaohe Lin <linmiaohe@huawei.com>
:::::: CC: Andrew Morton <akpm@linux-foundation.org>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
reply other threads:[~2024-12-01 21:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=202412020516.HKyPiDrZ-lkp@intel.com \
--to=lkp@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=yunshenglin0825@gmail.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.