linux-mm.kvack.org archive mirror
 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: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox