Commit 4ef905bda61f ("mm: tag kernel stack pages") began marking pages
that were being used for the kernel stack.

There are 3 cases where kernel pages are allocated for kernel stacks:
CONFIG_VMAP_STACK, THREAD_SIZE >= PAGE_SIZE, THREAD_SIZE < PAGE_SIZE.
These cases use vmalloc(), alloc_pages() and kmem_cache_alloc()
respectively.

In the first 2 cases, THREAD_SIZE / PAGE_SIZE will always be greater
than 0, and pages are tagged as expected. In the third case,
THREAD_SIZE / PAGE_SIZE evaluates to 0 and doesn't tag any pages at all.
This meant that in those configs, the stack tagging was a no-op, and led
to smatch build warnings.

We definitely have at least 1 page we want tagged at this point, so fix
it by using a do {} while loop instead of a for loop.

Fixes: 4ef905bda61f ("mm: tag kernel stack pages")
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/
Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
---
 kernel/fork.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index 1b394426ab4a..9b13cb83e1c6 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -448,14 +448,15 @@ static void account_kernel_stack(struct task_struct *tsk, int account)
 	} else {
 		void *stack = task_stack_page(tsk);
 		struct page *page = virt_to_head_page(stack);
-		int i;
+		int i = 0;
 
 		/* All stack pages are in the same node. */
 		mod_lruvec_kmem_state(stack, NR_KERNEL_STACK_KB,
 				      account * (THREAD_SIZE / 1024));
 
-		for (i = 0; i < THREAD_SIZE / PAGE_SIZE; i++, page++)
-			__SetPageStack(page);
+		do {
+			__SetPageStack(page++);
+		} while (++i < THREAD_SIZE / PAGE_SIZE);
 	}
 }
 
@@ -474,10 +475,11 @@ void exit_task_stack_account(struct task_struct *tsk)
 		}
 	} else {
 		struct page *page = virt_to_head_page(task_stack_page(tsk));
-		int i;
+		int i = 0;
 
-		for (i = 0; i < THREAD_SIZE / PAGE_SIZE; i++, page++)
-			__ClearPageStack(page);
+		do {
+			__ClearPageStack(page++);
+		} while (++i < THREAD_SIZE / PAGE_SIZE);
 	}
 }
 
-- 
2.51.0

On Tue, Sep 02, 2025 at 10:59:03AM -0700, Vishal Moola (Oracle) wrote:
> There are 3 cases where kernel pages are allocated for kernel stacks:
> CONFIG_VMAP_STACK, THREAD_SIZE >= PAGE_SIZE, THREAD_SIZE < PAGE_SIZE.
> These cases use vmalloc(), alloc_pages() and kmem_cache_alloc()
> respectively.

I missed that the third case existed ...

> In the first 2 cases, THREAD_SIZE / PAGE_SIZE will always be greater
> than 0, and pages are tagged as expected. In the third case,
> THREAD_SIZE / PAGE_SIZE evaluates to 0 and doesn't tag any pages at all.
> This meant that in those configs, the stack tagging was a no-op, and led
> to smatch build warnings.

I didn't see those smatch warnings.  Were they cc'd to the mailing list?

> We definitely have at least 1 page we want tagged at this point, so fix
> it by using a do {} while loop instead of a for loop.

We can't do this.  Pages can only have one type at a time.  Since
they're allocated from slab, they have PGTY_slab.  This will lead to
a warning at runtime:

        VM_BUG_ON_PAGE(data_race(page->page_type) != UINT_MAX, page);   \

But for our purposes (trying to figure out how fragmented the vmap
stack is making the memmap), we don't need to do this accounting.
These pages are already being allocated from slab, and slab allocates
naturally aligned, so we can skip all of this for these configurations.

(now I'll go back and reply to David's mail from the 21st which I
missed)

On 02.09.25 21:30, Matthew Wilcox wrote:
> On Tue, Sep 02, 2025 at 10:59:03AM -0700, Vishal Moola (Oracle) wrote:
>> There are 3 cases where kernel pages are allocated for kernel stacks:
>> CONFIG_VMAP_STACK, THREAD_SIZE >= PAGE_SIZE, THREAD_SIZE < PAGE_SIZE.
>> These cases use vmalloc(), alloc_pages() and kmem_cache_alloc()
>> respectively.
> 
> I missed that the third case existed ...
> 
>> In the first 2 cases, THREAD_SIZE / PAGE_SIZE will always be greater
>> than 0, and pages are tagged as expected. In the third case,
>> THREAD_SIZE / PAGE_SIZE evaluates to 0 and doesn't tag any pages at all.
>> This meant that in those configs, the stack tagging was a no-op, and led
>> to smatch build warnings.
> 
> I didn't see those smatch warnings.  Were they cc'd to the mailing list?
> 
>> We definitely have at least 1 page we want tagged at this point, so fix
>> it by using a do {} while loop instead of a for loop.
> 
> We can't do this.  Pages can only have one type at a time.  Since
> they're allocated from slab, they have PGTY_slab.  This will lead to
> a warning at runtime:
> 
>          VM_BUG_ON_PAGE(data_race(page->page_type) != UINT_MAX, page);   \
> 
> But for our purposes (trying to figure out how fragmented the vmap
> stack is making the memmap), we don't need to do this accounting.
> These pages are already being allocated from slab, and slab allocates
> naturally aligned, so we can skip all of this for these configurations.

IIUC what you mean, I am not a fan of having PGTY_stack being properly 
set or not based on a kernel config.

I much rather prefer this being done cleanly for all cases, or not at 
all (OOT for research/debugging purposes).

-- 
Cheers

David / dhildenb

On Tue, Sep 02, 2025 at 08:30:14PM +0100, Matthew Wilcox wrote:
> On Tue, Sep 02, 2025 at 10:59:03AM -0700, Vishal Moola (Oracle) wrote:
> > There are 3 cases where kernel pages are allocated for kernel stacks:
> > CONFIG_VMAP_STACK, THREAD_SIZE >= PAGE_SIZE, THREAD_SIZE < PAGE_SIZE.
> > These cases use vmalloc(), alloc_pages() and kmem_cache_alloc()
> > respectively.
> 
> I missed that the third case existed ...
> 
> > In the first 2 cases, THREAD_SIZE / PAGE_SIZE will always be greater
> > than 0, and pages are tagged as expected. In the third case,
> > THREAD_SIZE / PAGE_SIZE evaluates to 0 and doesn't tag any pages at all.
> > This meant that in those configs, the stack tagging was a no-op, and led
> > to smatch build warnings.
> 
> I didn't see those smatch warnings.  Were they cc'd to the mailing list?
> 

I messed up and accidentally sent an email with two Message-ID headers
so maybe it got eaten by your spam filter?

https://lore.kernel.org/all/202508300929.TrRovUMu-lkp@intel.com/

regards,
dan carpenter

On 02.09.25 19:59, Vishal Moola (Oracle) wrote:
> Commit 4ef905bda61f ("mm: tag kernel stack pages") began marking pages
> that were being used for the kernel stack.
> 
> There are 3 cases where kernel pages are allocated for kernel stacks:
> CONFIG_VMAP_STACK, THREAD_SIZE >= PAGE_SIZE, THREAD_SIZE < PAGE_SIZE.
> These cases use vmalloc(), alloc_pages() and kmem_cache_alloc()
> respectively.
> 
> In the first 2 cases, THREAD_SIZE / PAGE_SIZE will always be greater
> than 0, and pages are tagged as expected. In the third case,
> THREAD_SIZE / PAGE_SIZE evaluates to 0 and doesn't tag any pages at all.
> This meant that in those configs, the stack tagging was a no-op, and led
> to smatch build warnings.
> 
> We definitely have at least 1 page we want tagged at this point, so fix
> it by using a do {} while loop instead of a for loop.
> 
> Fixes: 4ef905bda61f ("mm: tag kernel stack pages")
> 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/
> Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
> ---

You sent the patch on August 20 and I replied on August 21.

I did not receive any reply so far.

And now I realize that this patch is not upstream yet and the commit id 
not stable. So the Fixes/Closes etc. do not really apply.

My current opinion is that we don't want this. (see vmalloc reasoning 
and unclear use)

I'm happy to be convinced otherwise.

-- 
Cheers

David / dhildenb

On Tue, Sep 02, 2025 at 08:23:06PM +0200, David Hildenbrand wrote:
> On 02.09.25 19:59, Vishal Moola (Oracle) wrote:
> > Commit 4ef905bda61f ("mm: tag kernel stack pages") began marking pages
> > that were being used for the kernel stack.
> > 
> > There are 3 cases where kernel pages are allocated for kernel stacks:
> > CONFIG_VMAP_STACK, THREAD_SIZE >= PAGE_SIZE, THREAD_SIZE < PAGE_SIZE.
> > These cases use vmalloc(), alloc_pages() and kmem_cache_alloc()
> > respectively.
> > 
> > In the first 2 cases, THREAD_SIZE / PAGE_SIZE will always be greater
> > than 0, and pages are tagged as expected. In the third case,
> > THREAD_SIZE / PAGE_SIZE evaluates to 0 and doesn't tag any pages at all.
> > This meant that in those configs, the stack tagging was a no-op, and led
> > to smatch build warnings.
> > 
> > We definitely have at least 1 page we want tagged at this point, so fix
> > it by using a do {} while loop instead of a for loop.
> > 
> > Fixes: 4ef905bda61f ("mm: tag kernel stack pages")
> > 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/
> > Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
> > ---
> 
> You sent the patch on August 20 and I replied on August 21.
> 
> I did not receive any reply so far.

Ah sorry, I didn't mean to miss your reply.

I can't find your reply in my inboxes so I definitely missed it somehow.
I'll go find it and respond.

> And now I realize that this patch is not upstream yet and the commit id not
> stable. So the Fixes/Closes etc. do not really apply.

Gotcha.

> My current opinion is that we don't want this. (see vmalloc reasoning and
> unclear use)
> 
> I'm happy to be convinced otherwise.
> 
> -- 
> Cheers
> 
> David / dhildenb
>

On 02.09.25 22:06, Vishal Moola (Oracle) wrote:
> On Tue, Sep 02, 2025 at 08:23:06PM +0200, David Hildenbrand wrote:
>> On 02.09.25 19:59, Vishal Moola (Oracle) wrote:
>>> Commit 4ef905bda61f ("mm: tag kernel stack pages") began marking pages
>>> that were being used for the kernel stack.
>>>
>>> There are 3 cases where kernel pages are allocated for kernel stacks:
>>> CONFIG_VMAP_STACK, THREAD_SIZE >= PAGE_SIZE, THREAD_SIZE < PAGE_SIZE.
>>> These cases use vmalloc(), alloc_pages() and kmem_cache_alloc()
>>> respectively.
>>>
>>> In the first 2 cases, THREAD_SIZE / PAGE_SIZE will always be greater
>>> than 0, and pages are tagged as expected. In the third case,
>>> THREAD_SIZE / PAGE_SIZE evaluates to 0 and doesn't tag any pages at all.
>>> This meant that in those configs, the stack tagging was a no-op, and led
>>> to smatch build warnings.
>>>
>>> We definitely have at least 1 page we want tagged at this point, so fix
>>> it by using a do {} while loop instead of a for loop.
>>>
>>> Fixes: 4ef905bda61f ("mm: tag kernel stack pages")
>>> 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/
>>> Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
>>> ---
>>
>> You sent the patch on August 20 and I replied on August 21.
>>
>> I did not receive any reply so far.
> 
> Ah sorry, I didn't mean to miss your reply.
> 
> I can't find your reply in my inboxes so I definitely missed it somehow.
> I'll go find it and respond.

I had a mail server config issue on one day last month (sending 
@redhat.com through kernel.org :) ), let me check if that was on that 
problematic day and it might have went straight into your spam folder 
due to dkim mismatch.

So the mailing list did not reject it:

https://lore.kernel.org/all/96148baf-f008-449b-988b-ea4f07d18528@redhat.com/

And yes, indeed, it was on that problemtic day, and there is:

	Received: from smtp.kernel.org

So, problem on my side. Willy already replied, but let me resend that mail.

> 
>> And now I realize that this patch is not upstream yet and the commit id not
>> stable. So the Fixes/Closes etc. do not really apply.
> 
> Gotcha.

If there are bigger changes it usually makes sense to send a v2, or a 
simple fixup as reply to the original patch (I prefer as inline reply).

Of course, once it's in mm-stable or upstream, things get more tricky :)

-- 
Cheers

David / dhildenb

On Wed, Sep 03, 2025 at 09:46:44AM +0200, David Hildenbrand wrote:
> On 02.09.25 22:06, Vishal Moola (Oracle) wrote:
> > On Tue, Sep 02, 2025 at 08:23:06PM +0200, David Hildenbrand wrote:
> > > On 02.09.25 19:59, Vishal Moola (Oracle) wrote:
> > > > Commit 4ef905bda61f ("mm: tag kernel stack pages") began marking pages
> > > > that were being used for the kernel stack.
> > > > 
> > > > There are 3 cases where kernel pages are allocated for kernel stacks:
> > > > CONFIG_VMAP_STACK, THREAD_SIZE >= PAGE_SIZE, THREAD_SIZE < PAGE_SIZE.
> > > > These cases use vmalloc(), alloc_pages() and kmem_cache_alloc()
> > > > respectively.
> > > > 
> > > > In the first 2 cases, THREAD_SIZE / PAGE_SIZE will always be greater
> > > > than 0, and pages are tagged as expected. In the third case,
> > > > THREAD_SIZE / PAGE_SIZE evaluates to 0 and doesn't tag any pages at all.
> > > > This meant that in those configs, the stack tagging was a no-op, and led
> > > > to smatch build warnings.
> > > > 
> > > > We definitely have at least 1 page we want tagged at this point, so fix
> > > > it by using a do {} while loop instead of a for loop.
> > > > 
> > > > Fixes: 4ef905bda61f ("mm: tag kernel stack pages")
> > > > 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/
> > > > Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
> > > > ---
> > > 
> > > You sent the patch on August 20 and I replied on August 21.
> > > 
> > > I did not receive any reply so far.
> > 
> > Ah sorry, I didn't mean to miss your reply.
> > 
> > I can't find your reply in my inboxes so I definitely missed it somehow.
> > I'll go find it and respond.
> 
> I had a mail server config issue on one day last month (sending @redhat.com
> through kernel.org :) ), let me check if that was on that problematic day
> and it might have went straight into your spam folder due to dkim mismatch.
> 
> So the mailing list did not reject it:
> 
> https://lore.kernel.org/all/96148baf-f008-449b-988b-ea4f07d18528@redhat.com/
> 
> And yes, indeed, it was on that problemtic day, and there is:
> 
> 	Received: from smtp.kernel.org
> 
> So, problem on my side. Willy already replied, but let me resend that mail.
> 
> > 
> > > And now I realize that this patch is not upstream yet and the commit id not
> > > stable. So the Fixes/Closes etc. do not really apply.
> > 
> > Gotcha.
> 
> If there are bigger changes it usually makes sense to send a v2, or a simple
> fixup as reply to the original patch (I prefer as inline reply).

Ok I'll keep that in mind for the future :). My mail client loves
attaching the fixup patches as additional files, but I'll find a workflow
for inlining them.

> Of course, once it's in mm-stable or upstream, things get more tricky :)
> 
> -- 
> Cheers
> 
> David / dhildenb
>

On 03.09.25 20:12, Vishal Moola (Oracle) wrote:
> On Wed, Sep 03, 2025 at 09:46:44AM +0200, David Hildenbrand wrote:
>> On 02.09.25 22:06, Vishal Moola (Oracle) wrote:
>>> On Tue, Sep 02, 2025 at 08:23:06PM +0200, David Hildenbrand wrote:
>>>> On 02.09.25 19:59, Vishal Moola (Oracle) wrote:
>>>>> Commit 4ef905bda61f ("mm: tag kernel stack pages") began marking pages
>>>>> that were being used for the kernel stack.
>>>>>
>>>>> There are 3 cases where kernel pages are allocated for kernel stacks:
>>>>> CONFIG_VMAP_STACK, THREAD_SIZE >= PAGE_SIZE, THREAD_SIZE < PAGE_SIZE.
>>>>> These cases use vmalloc(), alloc_pages() and kmem_cache_alloc()
>>>>> respectively.
>>>>>
>>>>> In the first 2 cases, THREAD_SIZE / PAGE_SIZE will always be greater
>>>>> than 0, and pages are tagged as expected. In the third case,
>>>>> THREAD_SIZE / PAGE_SIZE evaluates to 0 and doesn't tag any pages at all.
>>>>> This meant that in those configs, the stack tagging was a no-op, and led
>>>>> to smatch build warnings.
>>>>>
>>>>> We definitely have at least 1 page we want tagged at this point, so fix
>>>>> it by using a do {} while loop instead of a for loop.
>>>>>
>>>>> Fixes: 4ef905bda61f ("mm: tag kernel stack pages")
>>>>> 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/
>>>>> Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
>>>>> ---
>>>>
>>>> You sent the patch on August 20 and I replied on August 21.
>>>>
>>>> I did not receive any reply so far.
>>>
>>> Ah sorry, I didn't mean to miss your reply.
>>>
>>> I can't find your reply in my inboxes so I definitely missed it somehow.
>>> I'll go find it and respond.
>>
>> I had a mail server config issue on one day last month (sending @redhat.com
>> through kernel.org :) ), let me check if that was on that problematic day
>> and it might have went straight into your spam folder due to dkim mismatch.
>>
>> So the mailing list did not reject it:
>>
>> https://lore.kernel.org/all/96148baf-f008-449b-988b-ea4f07d18528@redhat.com/
>>
>> And yes, indeed, it was on that problemtic day, and there is:
>>
>> 	Received: from smtp.kernel.org
>>
>> So, problem on my side. Willy already replied, but let me resend that mail.
>>
>>>
>>>> And now I realize that this patch is not upstream yet and the commit id not
>>>> stable. So the Fixes/Closes etc. do not really apply.
>>>
>>> Gotcha.
>>
>> If there are bigger changes it usually makes sense to send a v2, or a simple
>> fixup as reply to the original patch (I prefer as inline reply).
> 
> Ok I'll keep that in mind for the future :). My mail client loves
> attaching the fixup patches as additional files, but I'll find a workflow
> for inlining them.

Oh, I really just format-patch, gedit to then copy and paste.

Just be careful if your mail client wraps at 80 chars as default. I have 
Thunderbird plugin where I can easily toggle that (Toggle Line Wrap).

-- 
Cheers

David / dhildenb