[linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio'

[linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head:   1e1b28b936aed946122b4e0991e7144fdbbfd77e
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)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=2c69e2057962b6bd76d72446453862eb59325b49
        git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
        git fetch --no-tags linux-next master
        git checkout 2c69e2057962b6bd76d72446453862eb59325b49
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=hexagon SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

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.


vim +/block_read_full_folio +2254 fs/buffer.c

  2246	
  2247	/*
  2248	 * Generic "read_folio" function for block devices that have the normal
  2249	 * get_block functionality. This is most of the block device filesystems.
  2250	 * Reads the folio asynchronously --- the unlock_buffer() and
  2251	 * set/clear_buffer_uptodate() functions propagate buffer state into the
  2252	 * folio once IO has completed.
  2253	 */
> 2254	int block_read_full_folio(struct folio *folio, get_block_t *get_block)
  2255	{
  2256		struct inode *inode = folio->mapping->host;
  2257		sector_t iblock, lblock;
  2258		struct buffer_head *bh, *head, *arr[MAX_BUF_PER_PAGE];
  2259		unsigned int blocksize, bbits;
  2260		int nr, i;
  2261		int fully_mapped = 1;
  2262	
  2263		VM_BUG_ON_FOLIO(folio_test_large(folio), folio);
  2264	
  2265		head = create_page_buffers(&folio->page, inode, 0);
  2266		blocksize = head->b_size;
  2267		bbits = block_size_bits(blocksize);
  2268	
  2269		iblock = (sector_t)folio->index << (PAGE_SHIFT - bbits);
  2270		lblock = (i_size_read(inode)+blocksize-1) >> bbits;
  2271		bh = head;
  2272		nr = 0;
  2273		i = 0;
  2274	
  2275		do {
  2276			if (buffer_uptodate(bh))
  2277				continue;
  2278	
  2279			if (!buffer_mapped(bh)) {
  2280				int err = 0;
  2281	
  2282				fully_mapped = 0;
  2283				if (iblock < lblock) {
  2284					WARN_ON(bh->b_size != blocksize);
  2285					err = get_block(inode, iblock, bh, 0);
  2286					if (err)
  2287						folio_set_error(folio);
  2288				}
  2289				if (!buffer_mapped(bh)) {
  2290					folio_zero_range(folio, i * blocksize,
  2291							blocksize);
  2292					if (!err)
  2293						set_buffer_uptodate(bh);
  2294					continue;
  2295				}
  2296				/*
  2297				 * get_block() might have updated the buffer
  2298				 * synchronously
  2299				 */
  2300				if (buffer_uptodate(bh))
  2301					continue;
  2302			}
  2303			arr[nr++] = bh;
  2304		} while (i++, iblock++, (bh = bh->b_this_page) != head);
  2305	
  2306		if (fully_mapped)
  2307			folio_set_mappedtodisk(folio);
  2308	
  2309		if (!nr) {
  2310			/*
  2311			 * All buffers are uptodate - we can set the folio uptodate
  2312			 * as well. But not if get_block() returned an error.
  2313			 */
  2314			if (!folio_test_error(folio))
  2315				folio_mark_uptodate(folio);
  2316			folio_unlock(folio);
  2317			return 0;
  2318		}
  2319	
  2320		/* Stage two: lock the buffers */
  2321		for (i = 0; i < nr; i++) {
  2322			bh = arr[i];
  2323			lock_buffer(bh);
  2324			mark_buffer_async_read(bh);
  2325		}
  2326	
  2327		/*
  2328		 * Stage 3: start the IO.  Check for uptodateness
  2329		 * inside the buffer lock in case another process reading
  2330		 * the underlying blockdev brought it uptodate (the sct fix).
  2331		 */
  2332		for (i = 0; i < nr; i++) {
  2333			bh = arr[i];
  2334			if (buffer_uptodate(bh))
  2335				end_buffer_async_read(bh, 1);
  2336			else
  2337				submit_bh(REQ_OP_READ, 0, bh);
  2338		}
  2339		return 0;
  2340	}
  2341	EXPORT_SYMBOL(block_read_full_folio);
  2342	

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

Re: [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio'

[Matthew Wilcox]

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.

Re: [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]

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.

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

Re: [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio'

[Matthew Wilcox]

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

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'

[Chen, Rong A]

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
> 

RE: [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio'

[Brian Cain]

> -----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

Re: [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio'

[Matthew Wilcox]

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?