All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>,
	kernel test robot <lkp@intel.com>,
	llvm@lists.linux.dev, kbuild-all@lists.01.org,
	linux-kernel@vger.kernel.org
Subject: Re: fs/ntfs/aops.c:378:12: warning: stack frame size (2216) exceeds limit (1024) in 'ntfs_read_folio'
Date: Mon, 15 Aug 2022 10:11:22 -0700	[thread overview]
Message-ID: <Yvp+OnhAAQI5Zvj9@dev-arch.thelio-3990X> (raw)
In-Reply-To: <CAK8P3a0TPYs2cbcx+0QGk=y8xjFrspdwnTHDxQCtsSwJmfvF6Q@mail.gmail.com>

On Mon, Aug 15, 2022 at 04:37:09PM +0200, Arnd Bergmann wrote:
> On Mon, Aug 15, 2022 at 3:48 PM Arnd Bergmann <arnd@kernel.org> wrote:
> 
> > I have no problems with a patch removing support for 256KB pages if that
> > helps, as Hexagon is the only architecture to support this and there are close
> > to zero Linux users anway. This would leave only three warnings for 64KB

Right, I had brought up at least adjusting the dependencies of 256KB
pages so that it could not be selected with CONFIG_COMPILE_TEST to
reduce the number of warnings that would appear in randconfigs.

https://lore.kernel.org/YoAlvnyjEbYV4T1L@dev-arch.thelio-3990X/

I suspect removing it outright would be fine too.

> > pages in allmodconfig:
> >
> > fs/mpage.c:131:20: error: stack frame size (1128) exceeds limit (1024)
> > in 'do_mpage_readpage' [-Werror,-Wframe-larger-than]
> > fs/mpage.c:447:12: error: stack frame size (1264) exceeds limit (1024)
> > in '__mpage_writepage' [-Werror,-Wframe-larger-than]
> > fs/ext4/readpage.c:223:5: error: stack frame size (1208) exceeds limit
> > (1024) in 'ext4_mpage_readpages' [-Werror,-Wframe-larger-than]
> 
> I looked into these a bit more and found that these are arrays of sector_t,
> which could be either 32-bit or 64-bit wide before 72deb455b5ec
> ("block: remove CONFIG_LBDAF"), but is now always 64-bit, so having
> an array of 128 of these (65536/512) adds a 1KB to the stack and will
> cause a warning. It's only slightly over the limit, and there are very few
> 32-bit systems that allow 64KB pages to trigger that warning.
> 
> I see now that ppc440 also supports 256KB pages and has the same
> problem as hexagon, but also has been broken since the start of the
> git history in this regard:
> 
> fs/mpage.c:638:1: error: the frame size of 4280 bytes is larger than
> 2048 bytes [-Werror=frame-larger-than=]
> 
> I don't know if anyone strongly cares about 256KB pages on
> ppc44x any more, but given this, I'm fairly sure that they are
> not using block based file systems. So we could just make
> CONFIG_BLOCK depend on PAGE_SIZE_LESS_THAN_256KB
> globally instead of dropping 256KB pages everywhere.

That doesn't sound like an unreasonable solution.

Cheers,
Nathan

WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org>
To: kbuild-all@lists.01.org
Subject: Re: fs/ntfs/aops.c:378:12: warning: stack frame size (2216) exceeds limit (1024) in 'ntfs_read_folio'
Date: Mon, 15 Aug 2022 10:11:22 -0700	[thread overview]
Message-ID: <Yvp+OnhAAQI5Zvj9@dev-arch.thelio-3990X> (raw)
In-Reply-To: <CAK8P3a0TPYs2cbcx+0QGk=y8xjFrspdwnTHDxQCtsSwJmfvF6Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

On Mon, Aug 15, 2022 at 04:37:09PM +0200, Arnd Bergmann wrote:
> On Mon, Aug 15, 2022 at 3:48 PM Arnd Bergmann <arnd@kernel.org> wrote:
> 
> > I have no problems with a patch removing support for 256KB pages if that
> > helps, as Hexagon is the only architecture to support this and there are close
> > to zero Linux users anway. This would leave only three warnings for 64KB

Right, I had brought up at least adjusting the dependencies of 256KB
pages so that it could not be selected with CONFIG_COMPILE_TEST to
reduce the number of warnings that would appear in randconfigs.

https://lore.kernel.org/YoAlvnyjEbYV4T1L(a)dev-arch.thelio-3990X/

I suspect removing it outright would be fine too.

> > pages in allmodconfig:
> >
> > fs/mpage.c:131:20: error: stack frame size (1128) exceeds limit (1024)
> > in 'do_mpage_readpage' [-Werror,-Wframe-larger-than]
> > fs/mpage.c:447:12: error: stack frame size (1264) exceeds limit (1024)
> > in '__mpage_writepage' [-Werror,-Wframe-larger-than]
> > fs/ext4/readpage.c:223:5: error: stack frame size (1208) exceeds limit
> > (1024) in 'ext4_mpage_readpages' [-Werror,-Wframe-larger-than]
> 
> I looked into these a bit more and found that these are arrays of sector_t,
> which could be either 32-bit or 64-bit wide before 72deb455b5ec
> ("block: remove CONFIG_LBDAF"), but is now always 64-bit, so having
> an array of 128 of these (65536/512) adds a 1KB to the stack and will
> cause a warning. It's only slightly over the limit, and there are very few
> 32-bit systems that allow 64KB pages to trigger that warning.
> 
> I see now that ppc440 also supports 256KB pages and has the same
> problem as hexagon, but also has been broken since the start of the
> git history in this regard:
> 
> fs/mpage.c:638:1: error: the frame size of 4280 bytes is larger than
> 2048 bytes [-Werror=frame-larger-than=]
> 
> I don't know if anyone strongly cares about 256KB pages on
> ppc44x any more, but given this, I'm fairly sure that they are
> not using block based file systems. So we could just make
> CONFIG_BLOCK depend on PAGE_SIZE_LESS_THAN_256KB
> globally instead of dropping 256KB pages everywhere.

That doesn't sound like an unreasonable solution.

Cheers,
Nathan

  reply	other threads:[~2022-08-15 17:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-14  0:21 fs/ntfs/aops.c:378:12: warning: stack frame size (2216) exceeds limit (1024) in 'ntfs_read_folio' kernel test robot
2022-08-15 12:29 ` Matthew Wilcox
2022-08-15 12:29   ` Matthew Wilcox
2022-08-15 12:56   ` Arnd Bergmann
2022-08-15 12:56     ` Arnd Bergmann
2022-08-15 13:05     ` Matthew Wilcox
2022-08-15 13:05       ` Matthew Wilcox
2022-08-15 13:48       ` Arnd Bergmann
2022-08-15 13:48         ` Arnd Bergmann
2022-08-15 14:37         ` Arnd Bergmann
2022-08-15 14:37           ` Arnd Bergmann
2022-08-15 17:11           ` Nathan Chancellor [this message]
2022-08-15 17:11             ` Nathan Chancellor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yvp+OnhAAQI5Zvj9@dev-arch.thelio-3990X \
    --to=nathan@kernel.org \
    --cc=arnd@kernel.org \
    --cc=kbuild-all@lists.01.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.