From: Dan Carpenter <error27@gmail.com>
To: oe-kbuild@lists.linux.dev, "Kiryl Shutsemau (Meta)" <kas@kernel.org>
Cc: lkp@intel.com, oe-kbuild-all@lists.linux.dev
Subject: [kas:collapse/rfc-wip 41/84] mm/swap_state.c:481 __swap_cache_alloc() warn: use 'gfp' here instead of GFP_KERNEL?
Date: Mon, 14 Sep 2026 11:46:56 +0300 [thread overview]
Message-ID: <aqe0gMZsQSnofm3f@stanley.mountain> (raw)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git collapse/rfc-wip
head: 36226b1e4970c52a3c0d491dcf17800eb800958a
commit: 1e7fc9164723073d7b48f251446ae662becf45e2 [41/84] mm/huge_memory: let the caller pick the gfp for the deferred-split heads
config: mips-randconfig-r072-20260913 (https://download.01.org/0day-ci/archive/20260914/202609140034.5e6tLkPc-lkp@intel.com/config)
compiler: mips64-linux-gcc (GCC) 16.1.0
smatch: v0.5.0-9187-g5189e3fb
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>
| Reported-by: Dan Carpenter <error27@gmail.com>
| Closes: https://lore.kernel.org/r/202609140034.5e6tLkPc-lkp@intel.com/
smatch warnings:
mm/swap_state.c:481 __swap_cache_alloc() warn: use 'gfp' here instead of GFP_KERNEL?
vim +/gfp +481 mm/swap_state.c
e1e6750df3b473 Kairui Song 2026-05-17 416 static struct folio *__swap_cache_alloc(struct swap_cluster_info *ci,
e1e6750df3b473 Kairui Song 2026-05-17 417 swp_entry_t targ_entry, gfp_t gfp,
e1e6750df3b473 Kairui Song 2026-05-17 418 unsigned int order, struct vm_fault *vmf,
e1e6750df3b473 Kairui Song 2026-05-17 419 struct mempolicy *mpol, pgoff_t ilx)
e1e6750df3b473 Kairui Song 2026-05-17 420 {
e1e6750df3b473 Kairui Song 2026-05-17 421 int err;
e1e6750df3b473 Kairui Song 2026-05-17 422 swp_entry_t entry;
e1e6750df3b473 Kairui Song 2026-05-17 423 struct folio *folio;
e1e6750df3b473 Kairui Song 2026-05-17 424 void *shadow = NULL;
bc34e87a51d9e5 Kairui Song 2026-05-17 425 unsigned short memcg_id;
e1e6750df3b473 Kairui Song 2026-05-17 426 unsigned long address, nr_pages = 1UL << order;
e1e6750df3b473 Kairui Song 2026-05-17 427 struct vm_area_struct *vma = vmf ? vmf->vma : NULL;
e1e6750df3b473 Kairui Song 2026-05-17 428
e1e6750df3b473 Kairui Song 2026-05-17 429 VM_WARN_ON_ONCE(nr_pages > SWAPFILE_CLUSTER);
e1e6750df3b473 Kairui Song 2026-05-17 430 entry.val = round_down(targ_entry.val, nr_pages);
e1e6750df3b473 Kairui Song 2026-05-17 431
e1e6750df3b473 Kairui Song 2026-05-17 432 /* Check if the slot and range are available, skip allocation if not */
e1e6750df3b473 Kairui Song 2026-05-17 433 spin_lock(&ci->lock);
bc34e87a51d9e5 Kairui Song 2026-05-17 434 err = __swap_cache_add_check(ci, targ_entry, nr_pages, NULL, NULL);
e1e6750df3b473 Kairui Song 2026-05-17 435 spin_unlock(&ci->lock);
e1e6750df3b473 Kairui Song 2026-05-17 436 if (unlikely(err))
e1e6750df3b473 Kairui Song 2026-05-17 437 return ERR_PTR(err);
e1e6750df3b473 Kairui Song 2026-05-17 438
e1e6750df3b473 Kairui Song 2026-05-17 439 /*
e1e6750df3b473 Kairui Song 2026-05-17 440 * Limit THP gfp. The limitation is a no-op for typical
e1e6750df3b473 Kairui Song 2026-05-17 441 * GFP_HIGHUSER_MOVABLE but matters for shmem.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Comment here which mentions gfp but is too advanced for my small
brain.
e1e6750df3b473 Kairui Song 2026-05-17 442 */
e1e6750df3b473 Kairui Song 2026-05-17 443 if (order)
e1e6750df3b473 Kairui Song 2026-05-17 444 gfp = thp_shmem_limit_gfp_mask(vma_thp_gfp_mask(vma), gfp);
e1e6750df3b473 Kairui Song 2026-05-17 445
e1e6750df3b473 Kairui Song 2026-05-17 446 if (mpol || !vmf) {
e1e6750df3b473 Kairui Song 2026-05-17 447 folio = folio_alloc_mpol(gfp, order, mpol, ilx, numa_node_id());
e1e6750df3b473 Kairui Song 2026-05-17 448 } else {
e1e6750df3b473 Kairui Song 2026-05-17 449 address = round_down(vmf->address, PAGE_SIZE << order);
e1e6750df3b473 Kairui Song 2026-05-17 450 folio = vma_alloc_folio(gfp, order, vmf->vma, address);
e1e6750df3b473 Kairui Song 2026-05-17 451 }
e1e6750df3b473 Kairui Song 2026-05-17 452 if (unlikely(!folio))
e1e6750df3b473 Kairui Song 2026-05-17 453 return ERR_PTR(-ENOMEM);
e1e6750df3b473 Kairui Song 2026-05-17 454
e1e6750df3b473 Kairui Song 2026-05-17 455 /* Double check the range is still not in conflict */
e1e6750df3b473 Kairui Song 2026-05-17 456 spin_lock(&ci->lock);
bc34e87a51d9e5 Kairui Song 2026-05-17 457 err = __swap_cache_add_check(ci, targ_entry, nr_pages, &shadow, &memcg_id);
e1e6750df3b473 Kairui Song 2026-05-17 458 if (unlikely(err)) {
e1e6750df3b473 Kairui Song 2026-05-17 459 spin_unlock(&ci->lock);
e1e6750df3b473 Kairui Song 2026-05-17 460 folio_put(folio);
e1e6750df3b473 Kairui Song 2026-05-17 461 return ERR_PTR(err);
e1e6750df3b473 Kairui Song 2026-05-17 462 }
e1e6750df3b473 Kairui Song 2026-05-17 463
e1e6750df3b473 Kairui Song 2026-05-17 464 __folio_set_locked(folio);
e1e6750df3b473 Kairui Song 2026-05-17 465 __folio_set_swapbacked(folio);
e1e6750df3b473 Kairui Song 2026-05-17 466 __swap_cache_do_add_folio(ci, folio, entry);
e1e6750df3b473 Kairui Song 2026-05-17 467 spin_unlock(&ci->lock);
e1e6750df3b473 Kairui Song 2026-05-17 468
bc34e87a51d9e5 Kairui Song 2026-05-17 469 if (mem_cgroup_swapin_charge_folio(folio, memcg_id,
bc34e87a51d9e5 Kairui Song 2026-05-17 470 vmf ? vmf->vma->vm_mm : NULL, gfp)) {
e1e6750df3b473 Kairui Song 2026-05-17 471 spin_lock(&ci->lock);
e1e6750df3b473 Kairui Song 2026-05-17 472 __swap_cache_do_del_folio(ci, folio, entry, shadow);
e1e6750df3b473 Kairui Song 2026-05-17 473 spin_unlock(&ci->lock);
e1e6750df3b473 Kairui Song 2026-05-17 474 folio_unlock(folio);
e1e6750df3b473 Kairui Song 2026-05-17 475 /* nr_pages refs from swap cache, 1 from allocation */
e1e6750df3b473 Kairui Song 2026-05-17 476 folio_put_refs(folio, nr_pages + 1);
e1e6750df3b473 Kairui Song 2026-05-17 477 count_mthp_stat(order, MTHP_STAT_SWPIN_FALLBACK_CHARGE);
e1e6750df3b473 Kairui Song 2026-05-17 478 return ERR_PTR(-ENOMEM);
e1e6750df3b473 Kairui Song 2026-05-17 479 }
e1e6750df3b473 Kairui Song 2026-05-17 480
1e7fc916472307 Kiryl Shutsemau (Meta 2026-08-24 @481) if (order > 1 && folio_memcg_alloc_deferred(folio, GFP_KERNEL)) {
Should this be gfp instead of GFP_KERNEL?
fafaeceb89a5e2 Johannes Weiner 2026-05-27 482 spin_lock(&ci->lock);
fafaeceb89a5e2 Johannes Weiner 2026-05-27 483 __swap_cache_do_del_folio(ci, folio, entry, shadow);
fafaeceb89a5e2 Johannes Weiner 2026-05-27 484 spin_unlock(&ci->lock);
fafaeceb89a5e2 Johannes Weiner 2026-05-27 485 folio_unlock(folio);
fafaeceb89a5e2 Johannes Weiner 2026-05-27 486 /* nr_pages refs from swap cache, 1 from allocation */
fafaeceb89a5e2 Johannes Weiner 2026-05-27 487 folio_put_refs(folio, nr_pages + 1);
fafaeceb89a5e2 Johannes Weiner 2026-05-27 488 return ERR_PTR(-ENOMEM);
fafaeceb89a5e2 Johannes Weiner 2026-05-27 489 }
fafaeceb89a5e2 Johannes Weiner 2026-05-27 490
945578fee2ec17 Kairui Song 2026-05-17 491 /* memsw uncharges swap when folio is added to swap cache */
945578fee2ec17 Kairui Song 2026-05-17 492 memcg1_swapin(folio);
e1e6750df3b473 Kairui Song 2026-05-17 493 if (shadow)
e1e6750df3b473 Kairui Song 2026-05-17 494 workingset_refault(folio, shadow);
e1e6750df3b473 Kairui Song 2026-05-17 495
e1e6750df3b473 Kairui Song 2026-05-17 496 node_stat_mod_folio(folio, NR_FILE_PAGES, nr_pages);
e1e6750df3b473 Kairui Song 2026-05-17 497 lruvec_stat_mod_folio(folio, NR_SWAPCACHE, nr_pages);
e1e6750df3b473 Kairui Song 2026-05-17 498
e1e6750df3b473 Kairui Song 2026-05-17 499 /* Caller will initiate read into locked new_folio */
e1e6750df3b473 Kairui Song 2026-05-17 500 folio_add_lru(folio);
e1e6750df3b473 Kairui Song 2026-05-17 501 return folio;
e1e6750df3b473 Kairui Song 2026-05-17 502 }
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next reply other threads:[~2026-09-14 8:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 8:46 Dan Carpenter [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-09-13 22:32 [kas:collapse/rfc-wip 41/84] mm/swap_state.c:481 __swap_cache_alloc() warn: use 'gfp' here instead of GFP_KERNEL? kernel test robot
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=aqe0gMZsQSnofm3f@stanley.mountain \
--to=error27@gmail.com \
--cc=kas@kernel.org \
--cc=lkp@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=oe-kbuild@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox