linux-kernel - Re: [PATCH v3] vmstat: Kernel stack usage histogram

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+CK2bBm4COW+jZifyjFEyJNcW1cAXWYzCpuO81jL3YziKxfRw@mail.gmail.com>
Date: Wed, 17 Jul 2024 12:50:00 -0400
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: Shakeel Butt <shakeel.butt@...ux.dev>
Cc: akpm@...ux-foundation.org, jpoimboe@...nel.org, kent.overstreet@...ux.dev, 
	peterz@...radead.org, nphamcs@...il.com, cerasuolodomenico@...il.com, 
	surenb@...gle.com, lizhijian@...itsu.com, willy@...radead.org, vbabka@...e.cz, 
	ziy@...dia.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v3] vmstat: Kernel stack usage histogram

On Wed, Jun 12, 2024 at 2:50 PM Shakeel Butt <shakeel.butt@...ux.dev> wrote:
>
>
> Hi Pasha, I think you might have missed the questions I had below. Your
> response would really be appreciated.

Hi Shakeel,

Sorry for the delayed reply. I was distracted by unrelated tasks and
did not make any progress on this project. To answer your questions:

>
> On Fri, May 31, 2024 at 03:42:34PM GMT, Shakeel Butt wrote:
> > On Thu, May 30, 2024 at 08:14:17PM GMT, Pasha Tatashin wrote:
> > > Hi Shakeel,
> > >
> > > > Couple of questions:
> > > >
> > > > 1. In future with your on-demand kstack allocation feature, will these
> > > > metrics still be useful? (I think so but I want to know your take)
> > >
> > > It depends on how on-demand allocation is implemented. On hardware
> > > that supports faults on kernel stacks,
> >
> > Which hardware supports faults on kernel stacks and which do not?

>From my understanding, both ARM64 architecture is capable and also
Intel FRED is capable of handling kernel faults within the kernel
itself, other variants of x86-64 are not.

However, my immediate goal is to provide a generic way to increase
kernel thread memory on demand, specifically when needed. If certain
architectures are capable of in-kernel fault handling, they could
potentially leverage my framework to further enhance their dynamic
stack fault handling support.

> >
> > > we will have other metrics that
> > > show the total number of pages allocated for stacks.
> >
> > Don't we already have a metric for that i.e. KernelStack in meminfo
> > which is in kB unit?

If we had true dynamic kernel stack support, then the metric in
meminfo would be enough to estimate the average stack size, it would
still not show the histogram of how large stacks get.

> >
> > One more question: Is there any concern in making
> > CONFIG_DEBUG_STACK_USAGE not a debug feature i.e. enable in default
> > kernels instead of just debug kernels?

We enabled it in Google ProdKernel. There is some overhead when
threads are exiting, because we are looking for the first non-zero
byte, but that is minimal. We haven't observed any performance impact
on our fleet.

Pasha