* Re: [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio'
2022-05-14 21:57 ` [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio' Nathan Chancellor
@ 2022-05-15 0:30 ` Matthew Wilcox
2022-05-16 10:09 ` [kbuild-all] " Chen, Rong A
2022-05-17 4:16 ` Brian Cain
2 siblings, 0 replies; 5+ messages in thread
From: Matthew Wilcox @ 2022-05-15 0:30 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Brian Cain, kernel test robot, llvm, kbuild-all,
Linux Memory Management List, linux-hexagon
On Sat, May 14, 2022 at 02:57:18PM -0700, Nathan Chancellor wrote:
> On Sat, May 14, 2022 at 05:28:33PM +0100, Matthew Wilcox wrote:
> > On Sun, May 15, 2022 at 12:23:46AM +0800, kernel test robot wrote:
> > > commit: 2c69e2057962b6bd76d72446453862eb59325b49 [9995/11651] fs: Convert block_read_full_page() to block_read_full_folio()
> > > config: hexagon-randconfig-r041-20220513 (https://download.01.org/0day-ci/archive/20220515/202205150051.3RzuooAG-lkp@intel.com/config)
> > > compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 38189438b69ca27b4c6ce707c52dbd217583d046)
> > ...
> > > All warnings (new ones prefixed by >>):
> > >
> > > >> fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio' [-Wframe-larger-than]
> > > int block_read_full_folio(struct folio *folio, get_block_t *get_block)
> > > ^
> > > 1 warning generated.
> >
> > Now show the warnings that were removed. This patch renames the
> > function, and I bet there was a similar warning before this patch.
> >
> > But basically, I don't care about stack usage on hexagon with clang.
> > AIUI, it's a known bug.
>
> For what it's worth, it seems like this is just 256K pages being 256K
> pages... MAX_BUF_PER_PAGE is PAGE_SIZE / 512 so *arr is 2048 bytes big
> in this configuration. You'd see a similar warning with PowerPC but that
> configuration is non-standard:
Ahh! Yes, I'd forgotten that Hexagon has that crazy config option.
I think I can get rid of that enormous array of pointers, it just wasn't
a high priority for me.
> fs/buffer.c: In function ‘block_read_full_page’:
> fs/buffer.c:2337:1: warning: the frame size of 2064 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> 2337 | }
> | ^
>
> It would be nice if the Intel folks could look at recognizing a function
> rename so that you are not bothered by reports like this.
>
> As a side note... Brian, is there any reason for 256K pages to exist for
> Hexagon? This has been an option since Hexagon's introduction but is it
> actually used? 4K pages is the default and the help text says "use with
> caution". Perhaps the choice should be turned off altogether for
> CONFIG_COMPILE_TEST so that we cannot select this configuration and
> bother developers with these reports.
>
> Cheers,
> Nathan
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kbuild-all] Re: [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio'
2022-05-14 21:57 ` [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio' Nathan Chancellor
2022-05-15 0:30 ` Matthew Wilcox
@ 2022-05-16 10:09 ` Chen, Rong A
2022-05-17 4:16 ` Brian Cain
2 siblings, 0 replies; 5+ messages in thread
From: Chen, Rong A @ 2022-05-16 10:09 UTC (permalink / raw)
To: Nathan Chancellor, Matthew Wilcox, Brian Cain
Cc: kernel test robot, llvm, kbuild-all, Linux Memory Management List,
linux-hexagon
On 5/15/2022 5:57 AM, Nathan Chancellor wrote:
> On Sat, May 14, 2022 at 05:28:33PM +0100, Matthew Wilcox wrote:
>> On Sun, May 15, 2022 at 12:23:46AM +0800, kernel test robot wrote:
>>> commit: 2c69e2057962b6bd76d72446453862eb59325b49 [9995/11651] fs: Convert block_read_full_page() to block_read_full_folio()
>>> config: hexagon-randconfig-r041-20220513 (https://download.01.org/0day-ci/archive/20220515/202205150051.3RzuooAG-lkp@intel.com/config)
>>> compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 38189438b69ca27b4c6ce707c52dbd217583d046)
>> ...
>>> All warnings (new ones prefixed by >>):
>>>
>>>>> fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio' [-Wframe-larger-than]
>>> int block_read_full_folio(struct folio *folio, get_block_t *get_block)
>>> ^
>>> 1 warning generated.
>>
>> Now show the warnings that were removed. This patch renames the
>> function, and I bet there was a similar warning before this patch.
>>
>> But basically, I don't care about stack usage on hexagon with clang.
>> AIUI, it's a known bug.
>
> For what it's worth, it seems like this is just 256K pages being 256K
> pages... MAX_BUF_PER_PAGE is PAGE_SIZE / 512 so *arr is 2048 bytes big
> in this configuration. You'd see a similar warning with PowerPC but that
> configuration is non-standard:
>
> fs/buffer.c: In function ‘block_read_full_page’:
> fs/buffer.c:2337:1: warning: the frame size of 2064 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> 2337 | }
> | ^
>
> It would be nice if the Intel folks could look at recognizing a function
> rename so that you are not bothered by reports like this.
Hi Nathan, Matthew,
Sorry about this, we'll take a look.
Best Regards,
Rong Chen
>
> As a side note... Brian, is there any reason for 256K pages to exist for
> Hexagon? This has been an option since Hexagon's introduction but is it
> actually used? 4K pages is the default and the help text says "use with
> caution". Perhaps the choice should be turned off altogether for
> CONFIG_COMPILE_TEST so that we cannot select this configuration and
> bother developers with these reports.
>
> Cheers,
> Nathan
> _______________________________________________
> kbuild-all mailing list -- kbuild-all@lists.01.org
> To unsubscribe send an email to kbuild-all-leave@lists.01.org
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio'
2022-05-14 21:57 ` [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio' Nathan Chancellor
2022-05-15 0:30 ` Matthew Wilcox
2022-05-16 10:09 ` [kbuild-all] " Chen, Rong A
@ 2022-05-17 4:16 ` Brian Cain
2022-05-17 4:48 ` Matthew Wilcox
2 siblings, 1 reply; 5+ messages in thread
From: Brian Cain @ 2022-05-17 4:16 UTC (permalink / raw)
To: Nathan Chancellor, Matthew Wilcox
Cc: kernel test robot, llvm@lists.linux.dev, kbuild-all@lists.01.org,
Linux Memory Management List, linux-hexagon@vger.kernel.org,
Sid Manning
> -----Original Message-----
> From: Nathan Chancellor <nathan@kernel.org>
...
> As a side note... Brian, is there any reason for 256K pages to exist for
> Hexagon? This has been an option since Hexagon's introduction but is it
> actually used? 4K pages is the default and the help text says "use with
> caution". Perhaps the choice should be turned off altogether for
> CONFIG_COMPILE_TEST so that we cannot select this configuration and
> bother developers with these reports.
It's not the most commonly used page size, yeah. Ok, we will disable it for CONFIG_COMPILE_TEST.
-Brian
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio'
2022-05-17 4:16 ` Brian Cain
@ 2022-05-17 4:48 ` Matthew Wilcox
0 siblings, 0 replies; 5+ messages in thread
From: Matthew Wilcox @ 2022-05-17 4:48 UTC (permalink / raw)
To: Brian Cain
Cc: Nathan Chancellor, kernel test robot, llvm@lists.linux.dev,
kbuild-all@lists.01.org, Linux Memory Management List,
linux-hexagon@vger.kernel.org, Sid Manning
On Tue, May 17, 2022 at 04:16:45AM +0000, Brian Cain wrote:
> > -----Original Message-----
> > From: Nathan Chancellor <nathan@kernel.org>
> ...
> > As a side note... Brian, is there any reason for 256K pages to exist for
> > Hexagon? This has been an option since Hexagon's introduction but is it
> > actually used? 4K pages is the default and the help text says "use with
> > caution". Perhaps the choice should be turned off altogether for
> > CONFIG_COMPILE_TEST so that we cannot select this configuration and
> > bother developers with these reports.
>
> It's not the most commonly used page size, yeah. Ok, we will disable it for CONFIG_COMPILE_TEST.
Maybe the stack size limit could be raised for 256KB page size?
Presumably the minimum stack size is 256KB, so it's not a problem for an
individual function to consume 16KB of stack space?
^ permalink raw reply [flat|nested] 5+ messages in thread