All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: oe-kbuild-all@lists.linux.dev
Subject: Re: [PATCH bpf-next v9 2/6] mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation
Date: Sun, 23 Feb 2025 10:17:27 +0800	[thread overview]
Message-ID: <202502230935.fqsCRt0F-lkp@intel.com> (raw)
In-Reply-To: <20250222024427.30294-3-alexei.starovoitov@gmail.com>

Hi Alexei,

kernel test robot noticed the following build warnings:

[auto build test WARNING on bpf-next/master]

url:    https://github.com/intel-lab-lkp/linux/commits/Alexei-Starovoitov/locking-local_lock-Introduce-localtry_lock_t/20250222-104619
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
patch link:    https://lore.kernel.org/r/20250222024427.30294-3-alexei.starovoitov%40gmail.com
patch subject: [PATCH bpf-next v9 2/6] mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation
config: x86_64-buildonly-randconfig-003-20250223 (https://download.01.org/0day-ci/archive/20250223/202502230935.fqsCRt0F-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250223/202502230935.fqsCRt0F-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/202502230935.fqsCRt0F-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> mm/page_alloc.c:7103: warning: Function parameter or struct member 'nid' not described in 'try_alloc_pages'
>> mm/page_alloc.c:7103: warning: Function parameter or struct member 'order' not described in 'try_alloc_pages'


vim +7103 mm/page_alloc.c

  7087	
  7088	/**
  7089	 * try_alloc_pages - opportunistic reentrant allocation from any context
  7090	 * @nid - node to allocate from
  7091	 * @order - allocation order size
  7092	 *
  7093	 * Allocates pages of a given order from the given node. This is safe to
  7094	 * call from any context (from atomic, NMI, and also reentrant
  7095	 * allocator -> tracepoint -> try_alloc_pages_noprof).
  7096	 * Allocation is best effort and to be expected to fail easily so nobody should
  7097	 * rely on the success. Failures are not reported via warn_alloc().
  7098	 * See always fail conditions below.
  7099	 *
  7100	 * Return: allocated page or NULL on failure.
  7101	 */
  7102	struct page *try_alloc_pages_noprof(int nid, unsigned int order)
> 7103	{
  7104		/*
  7105		 * Do not specify __GFP_DIRECT_RECLAIM, since direct claim is not allowed.
  7106		 * Do not specify __GFP_KSWAPD_RECLAIM either, since wake up of kswapd
  7107		 * is not safe in arbitrary context.
  7108		 *
  7109		 * These two are the conditions for gfpflags_allow_spinning() being true.
  7110		 *
  7111		 * Specify __GFP_NOWARN since failing try_alloc_pages() is not a reason
  7112		 * to warn. Also warn would trigger printk() which is unsafe from
  7113		 * various contexts. We cannot use printk_deferred_enter() to mitigate,
  7114		 * since the running context is unknown.
  7115		 *
  7116		 * Specify __GFP_ZERO to make sure that call to kmsan_alloc_page() below
  7117		 * is safe in any context. Also zeroing the page is mandatory for
  7118		 * BPF use cases.
  7119		 *
  7120		 * Though __GFP_NOMEMALLOC is not checked in the code path below,
  7121		 * specify it here to highlight that try_alloc_pages()
  7122		 * doesn't want to deplete reserves.
  7123		 */
  7124		gfp_t alloc_gfp = __GFP_NOWARN | __GFP_ZERO | __GFP_NOMEMALLOC;
  7125		unsigned int alloc_flags = ALLOC_TRYLOCK;
  7126		struct alloc_context ac = { };
  7127		struct page *page;
  7128	
  7129		/*
  7130		 * In PREEMPT_RT spin_trylock() will call raw_spin_lock() which is
  7131		 * unsafe in NMI. If spin_trylock() is called from hard IRQ the current
  7132		 * task may be waiting for one rt_spin_lock, but rt_spin_trylock() will
  7133		 * mark the task as the owner of another rt_spin_lock which will
  7134		 * confuse PI logic, so return immediately if called form hard IRQ or
  7135		 * NMI.
  7136		 *
  7137		 * Note, irqs_disabled() case is ok. This function can be called
  7138		 * from raw_spin_lock_irqsave region.
  7139		 */
  7140		if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq()))
  7141			return NULL;
  7142		if (!pcp_allowed_order(order))
  7143			return NULL;
  7144	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

  reply	other threads:[~2025-02-23  2:18 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-22  2:44 [PATCH bpf-next v9 0/6] bpf, mm: Introduce try_alloc_pages() Alexei Starovoitov
2025-02-22  2:44 ` [PATCH bpf-next v9 1/6] locking/local_lock: Introduce localtry_lock_t Alexei Starovoitov
2025-03-11 15:44   ` Mateusz Guzik
2025-03-11 16:20     ` Sebastian Andrzej Siewior
2025-03-11 16:31       ` Mateusz Guzik
2025-03-11 20:21         ` Vlastimil Babka
2025-03-11 22:24           ` Alexei Starovoitov
2025-03-12  8:29             ` Vlastimil Babka
2025-03-14 21:05               ` Alexei Starovoitov
2025-03-14 21:08                 ` Vlastimil Babka
2025-03-14 21:18                   ` Alexei Starovoitov
2025-02-22  2:44 ` [PATCH bpf-next v9 2/6] mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation Alexei Starovoitov
2025-02-23  2:17   ` kernel test robot [this message]
2025-03-11  2:04   ` Andrew Morton
2025-03-11 13:32     ` Alexei Starovoitov
2025-03-11 18:04       ` Mateusz Guzik
2025-03-12  9:45         ` Steven Rostedt
2025-03-15  0:34         ` Alexei Starovoitov
2025-03-12 10:00       ` Vlastimil Babka
2025-03-12 19:06         ` Shakeel Butt
2025-03-13  8:44           ` Michal Hocko
2025-03-13 14:21             ` Vlastimil Babka
2025-03-13 16:02               ` Shakeel Butt
2025-03-14 10:16               ` Michal Hocko
2025-03-15  0:51         ` Alexei Starovoitov
2025-02-22  2:44 ` [PATCH bpf-next v9 3/6] mm, bpf: Introduce free_pages_nolock() Alexei Starovoitov
2025-02-23  3:00   ` kernel test robot
2025-02-22  2:44 ` [PATCH bpf-next v9 4/6] memcg: Use trylock to access memcg stock_lock Alexei Starovoitov
2025-02-23  3:53   ` kernel test robot
2025-02-22  2:44 ` [PATCH bpf-next v9 5/6] mm, bpf: Use memcg in try_alloc_pages() Alexei Starovoitov
2025-02-22  2:44 ` [PATCH bpf-next v9 6/6] bpf: Use try_alloc_pages() to allocate pages for bpf needs Alexei Starovoitov
2025-02-26  3:19 ` [PATCH bpf-next v9 0/6] bpf, mm: Introduce try_alloc_pages() Alexei Starovoitov
2025-02-27 17:50 ` patchwork-bot+netdevbpf

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=202502230935.fqsCRt0F-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=alexei.starovoitov@gmail.com \
    --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.