From: kernel test robot <lkp@intel.com>
To: Alexei Starovoitov <ast@kernel.org>
Cc: oe-kbuild-all@lists.linux.dev
Subject: [ast-bpf:trylock 7/9] mm/page_alloc.c:7326: warning: Function parameter or struct member 'gfp_flags' not described in 'try_alloc_pages'
Date: Mon, 7 Apr 2025 16:58:06 +0800 [thread overview]
Message-ID: <202504071652.Vecx2fpu-lkp@intel.com> (raw)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git trylock
head: ece70dcfc0603028860bddbb76ba86dc26c26d25
commit: 62677fc403ce41a43345fbb6b646205c44a3e2ee [7/9] mm: Allow GFP_ACCOUNT and GFP_COMP to be used in try_alloc_pages().
config: arc-randconfig-002-20250407 (https://download.01.org/0day-ci/archive/20250407/202504071652.Vecx2fpu-lkp@intel.com/config)
compiler: arc-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250407/202504071652.Vecx2fpu-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/202504071652.Vecx2fpu-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> mm/page_alloc.c:7326: warning: Function parameter or struct member 'gfp_flags' not described in 'try_alloc_pages'
vim +7326 mm/page_alloc.c
97769a53f117e2 Alexei Starovoitov 2025-02-21 7310
97769a53f117e2 Alexei Starovoitov 2025-02-21 7311 /**
97769a53f117e2 Alexei Starovoitov 2025-02-21 7312 * try_alloc_pages - opportunistic reentrant allocation from any context
97769a53f117e2 Alexei Starovoitov 2025-02-21 7313 * @nid: node to allocate from
97769a53f117e2 Alexei Starovoitov 2025-02-21 7314 * @order: allocation order size
97769a53f117e2 Alexei Starovoitov 2025-02-21 7315 *
97769a53f117e2 Alexei Starovoitov 2025-02-21 7316 * Allocates pages of a given order from the given node. This is safe to
97769a53f117e2 Alexei Starovoitov 2025-02-21 7317 * call from any context (from atomic, NMI, and also reentrant
97769a53f117e2 Alexei Starovoitov 2025-02-21 7318 * allocator -> tracepoint -> try_alloc_pages_noprof).
97769a53f117e2 Alexei Starovoitov 2025-02-21 7319 * Allocation is best effort and to be expected to fail easily so nobody should
97769a53f117e2 Alexei Starovoitov 2025-02-21 7320 * rely on the success. Failures are not reported via warn_alloc().
97769a53f117e2 Alexei Starovoitov 2025-02-21 7321 * See always fail conditions below.
97769a53f117e2 Alexei Starovoitov 2025-02-21 7322 *
97769a53f117e2 Alexei Starovoitov 2025-02-21 7323 * Return: allocated page or NULL on failure.
97769a53f117e2 Alexei Starovoitov 2025-02-21 7324 */
62677fc403ce41 Alexei Starovoitov 2025-04-06 7325 struct page *try_alloc_pages_noprof(gfp_t gfp_flags, int nid, unsigned int order)
97769a53f117e2 Alexei Starovoitov 2025-02-21 @7326 {
97769a53f117e2 Alexei Starovoitov 2025-02-21 7327 /*
97769a53f117e2 Alexei Starovoitov 2025-02-21 7328 * Do not specify __GFP_DIRECT_RECLAIM, since direct claim is not allowed.
97769a53f117e2 Alexei Starovoitov 2025-02-21 7329 * Do not specify __GFP_KSWAPD_RECLAIM either, since wake up of kswapd
97769a53f117e2 Alexei Starovoitov 2025-02-21 7330 * is not safe in arbitrary context.
97769a53f117e2 Alexei Starovoitov 2025-02-21 7331 *
97769a53f117e2 Alexei Starovoitov 2025-02-21 7332 * These two are the conditions for gfpflags_allow_spinning() being true.
97769a53f117e2 Alexei Starovoitov 2025-02-21 7333 *
97769a53f117e2 Alexei Starovoitov 2025-02-21 7334 * Specify __GFP_NOWARN since failing try_alloc_pages() is not a reason
97769a53f117e2 Alexei Starovoitov 2025-02-21 7335 * to warn. Also warn would trigger printk() which is unsafe from
97769a53f117e2 Alexei Starovoitov 2025-02-21 7336 * various contexts. We cannot use printk_deferred_enter() to mitigate,
97769a53f117e2 Alexei Starovoitov 2025-02-21 7337 * since the running context is unknown.
97769a53f117e2 Alexei Starovoitov 2025-02-21 7338 *
97769a53f117e2 Alexei Starovoitov 2025-02-21 7339 * Specify __GFP_ZERO to make sure that call to kmsan_alloc_page() below
97769a53f117e2 Alexei Starovoitov 2025-02-21 7340 * is safe in any context. Also zeroing the page is mandatory for
97769a53f117e2 Alexei Starovoitov 2025-02-21 7341 * BPF use cases.
97769a53f117e2 Alexei Starovoitov 2025-02-21 7342 *
97769a53f117e2 Alexei Starovoitov 2025-02-21 7343 * Though __GFP_NOMEMALLOC is not checked in the code path below,
97769a53f117e2 Alexei Starovoitov 2025-02-21 7344 * specify it here to highlight that try_alloc_pages()
97769a53f117e2 Alexei Starovoitov 2025-02-21 7345 * doesn't want to deplete reserves.
97769a53f117e2 Alexei Starovoitov 2025-02-21 7346 */
e8d78dbd0199a4 Alexei Starovoitov 2025-02-21 7347 gfp_t alloc_gfp = __GFP_NOWARN | __GFP_ZERO | __GFP_NOMEMALLOC
62677fc403ce41 Alexei Starovoitov 2025-04-06 7348 | gfp_flags;
97769a53f117e2 Alexei Starovoitov 2025-02-21 7349 unsigned int alloc_flags = ALLOC_TRYLOCK;
97769a53f117e2 Alexei Starovoitov 2025-02-21 7350 struct alloc_context ac = { };
97769a53f117e2 Alexei Starovoitov 2025-02-21 7351 struct page *page;
97769a53f117e2 Alexei Starovoitov 2025-02-21 7352
62677fc403ce41 Alexei Starovoitov 2025-04-06 7353 VM_WARN_ON_ONCE(gfp_flags & ~(__GFP_ACCOUNT | __GFP_COMP));
97769a53f117e2 Alexei Starovoitov 2025-02-21 7354 /*
97769a53f117e2 Alexei Starovoitov 2025-02-21 7355 * In PREEMPT_RT spin_trylock() will call raw_spin_lock() which is
97769a53f117e2 Alexei Starovoitov 2025-02-21 7356 * unsafe in NMI. If spin_trylock() is called from hard IRQ the current
97769a53f117e2 Alexei Starovoitov 2025-02-21 7357 * task may be waiting for one rt_spin_lock, but rt_spin_trylock() will
97769a53f117e2 Alexei Starovoitov 2025-02-21 7358 * mark the task as the owner of another rt_spin_lock which will
97769a53f117e2 Alexei Starovoitov 2025-02-21 7359 * confuse PI logic, so return immediately if called form hard IRQ or
97769a53f117e2 Alexei Starovoitov 2025-02-21 7360 * NMI.
97769a53f117e2 Alexei Starovoitov 2025-02-21 7361 *
97769a53f117e2 Alexei Starovoitov 2025-02-21 7362 * Note, irqs_disabled() case is ok. This function can be called
97769a53f117e2 Alexei Starovoitov 2025-02-21 7363 * from raw_spin_lock_irqsave region.
97769a53f117e2 Alexei Starovoitov 2025-02-21 7364 */
97769a53f117e2 Alexei Starovoitov 2025-02-21 7365 if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq()))
97769a53f117e2 Alexei Starovoitov 2025-02-21 7366 return NULL;
97769a53f117e2 Alexei Starovoitov 2025-02-21 7367 if (!pcp_allowed_order(order))
97769a53f117e2 Alexei Starovoitov 2025-02-21 7368 return NULL;
97769a53f117e2 Alexei Starovoitov 2025-02-21 7369
:::::: The code at line 7326 was first introduced by commit
:::::: 97769a53f117e2f33864c587d85992ee35194ecf mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation
:::::: TO: Alexei Starovoitov <ast@kernel.org>
:::::: CC: Alexei Starovoitov <ast@kernel.org>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
reply other threads:[~2025-04-07 8:59 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=202504071652.Vecx2fpu-lkp@intel.com \
--to=lkp@intel.com \
--cc=ast@kernel.org \
--cc=oe-kbuild-all@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 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.