All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vishal Moola (Oracle)" <vishal.moola@gmail.com>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: oe-kbuild@lists.linux.dev, lkp@intel.com,
	oe-kbuild-all@lists.linux.dev,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [linux-next:master 4756/5283] kernel/fork.c:457 account_kernel_stack() warn: we never enter this loop
Date: Tue, 2 Sep 2025 10:01:39 -0700	[thread overview]
Message-ID: <aLci857GmuP2tMV9@fedora> (raw)
In-Reply-To: <202508300929.TrRovUMu-lkp@intel.com>

On Mon, Sep 01, 2025 at 01:56:05PM +0300, Dan Carpenter wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head:   3cace99d63192a7250461b058279a42d91075d0c
> commit: e0aa7237ef4323a66ed06953225d9b07cf039530 [4756/5283] mm: tag kernel stack pages
> config: hexagon-randconfig-r072-20250829 (https://download.01.org/0day-ci/archive/20250830/202508300929.TrRovUMu-lkp@intel.com/config)
> compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
> 
> 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 <dan.carpenter@linaro.org>
> | Closes: https://lore.kernel.org/r/202508300929.TrRovUMu-lkp@intel.com/
> 
> smatch warnings:
> kernel/fork.c:457 account_kernel_stack() warn: we never enter this loop
> kernel/fork.c:457 account_kernel_stack() warn: unsigned 'i' is never less than zero.
> kernel/fork.c:479 exit_task_stack_account() warn: we never enter this loop
> kernel/fork.c:479 exit_task_stack_account() warn: unsigned 'i' is never less than zero.

Thanks for catching this!

> vim +457 kernel/fork.c
> 
> ba14a194a434cc Andy Lutomirski           2016-08-11  437  static void account_kernel_stack(struct task_struct *tsk, int account)
> c6a7f5728a1db4 KOSAKI Motohiro           2009-09-21  438  {
> 0ce055f85335e4 Sebastian Andrzej Siewior 2022-02-17  439  	if (IS_ENABLED(CONFIG_VMAP_STACK)) {
> 449e0b4ed5a16c Pasha Tatashin            2025-05-09  440  		struct vm_struct *vm_area = task_stack_vm_area(tsk);
> 27faca83a7e955 Muchun Song               2021-04-29  441  		int i;
> efdc94907977d2 Andy Lutomirski           2016-07-28  442  
> e0aa7237ef4323 Vishal Moola (Oracle      2025-08-20  443) 		for (i = 0; i < THREAD_SIZE / PAGE_SIZE; i++) {
> 449e0b4ed5a16c Pasha Tatashin            2025-05-09  444  			mod_lruvec_page_state(vm_area->pages[i], NR_KERNEL_STACK_KB,
> 27faca83a7e955 Muchun Song               2021-04-29  445  					      account * (PAGE_SIZE / 1024));
> e0aa7237ef4323 Vishal Moola (Oracle      2025-08-20  446) 			__SetPageStack(vm_area->pages[i]);
> e0aa7237ef4323 Vishal Moola (Oracle      2025-08-20  447) 		}
> 27faca83a7e955 Muchun Song               2021-04-29  448  	} else {
> 0ce055f85335e4 Sebastian Andrzej Siewior 2022-02-17  449  		void *stack = task_stack_page(tsk);
> e0aa7237ef4323 Vishal Moola (Oracle      2025-08-20  450) 		struct page *page = virt_to_head_page(stack);
> e0aa7237ef4323 Vishal Moola (Oracle      2025-08-20  451) 		int i;
> 0ce055f85335e4 Sebastian Andrzej Siewior 2022-02-17  452  
> 991e7673859ed4 Shakeel Butt              2020-08-06  453  		/* All stack pages are in the same node. */
> da3ceeff923e3b Muchun Song               2020-12-14  454  		mod_lruvec_kmem_state(stack, NR_KERNEL_STACK_KB,
> efdc94907977d2 Andy Lutomirski           2016-07-28  455  				      account * (THREAD_SIZE / 1024));
> e0aa7237ef4323 Vishal Moola (Oracle      2025-08-20  456) 
> e0aa7237ef4323 Vishal Moola (Oracle      2025-08-20 @457) 		for (i = 0; i < THREAD_SIZE / PAGE_SIZE; i++, page++)
> e0aa7237ef4323 Vishal Moola (Oracle      2025-08-20  458) 			__SetPageStack(page);
> 
> Apparently in the linked config the THREAD_SIZE / PAGE_SIZE is zero.
> Is this the expected behavior?  I don't know mm enough to say the
> answer...

THREAD_SIZE and PAGE_SIZE are very architecture dependent. This behavior
is expected in some configs. This can't happen in the VMAP_STACK case,
only !VMAP_STACK, so looks like my patch is wrong in handling that case.
I'll send a fix shortly.


      reply	other threads:[~2025-09-02 17:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-30  1:15 [linux-next:master 4756/5283] kernel/fork.c:457 account_kernel_stack() warn: we never enter this loop kernel test robot
2025-09-01 10:56 ` Dan Carpenter
2025-09-02 17:01 ` Vishal Moola (Oracle) [this message]

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=aLci857GmuP2tMV9@fedora \
    --to=vishal.moola@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.carpenter@linaro.org \
    --cc=linux-mm@kvack.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 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.