Re: riscv gcc-13 allyesconfig error the frame size of 2064 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
Kent Overstreet <[email protected]>
| Newsgroups | org.kernel.vger.linux-bcache,dev.linux.lists.regressions,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <tr3y27pqkm4d6txcqwh4eiwvcr4limzzwnbaybwuigfjcbw43f@krfnu37d5zd7> |
On Sun, May 25, 2025 at 06:47:57PM +0100, David Laight wrote: > On Sun, 25 May 2025 13:36:16 -0400 > Kent Overstreet <[email protected]> wrote: > > > +cc Steve > ... > > > I've a cunning plan to do a proper static analysis of stack usage. > > > It is a 'simple' matter of getting objtool to output all calls with > > > the stack offset. > > > Indirect calls need the function hashes from fine-ibt, but also need > > > clang to support 'hash seeds' to disambiguate all the void (*)(void *) > > > functions. > > > That'll first barf at all recursion, and then, I expect, show a massive > > > stack use inside snprintf() in some error path. > > > > I suspect recursion will make the results you get with that approach > > useless. > > Recursion is an issue, but the kernel really doesn't support recursion. > So you actually want to know the possible recursion loops anyway. > I suspect (hope) most will be the 'recurses only once' type. > If not they need some other bound. Recursion is a fact of life when you get different subsystems interacting in unpredictable ways. You can be in one filesystem, and then end up in a fault handler (gup(), or a simple copy to/from user), and then end up in a completely different filesystem - and then you call into the block layer, or networking if it's NFS. Static analysis might get you some useful data within a subsystem, but it won't tell you much about the kernel as a whole as people are actually running it.