From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio' Date: Sun, 15 May 2022 01:30:52 +0100 Message-ID: References: <202205150051.3RzuooAG-lkp@intel.com> Mime-Version: 1.0 Content-Transfer-Encoding: base64 Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=eZAXC+k+tR5S6s/jXIC4fOUMN3Hkrv/eDiD122qcZmE=; b=V4rcHE1nZ/iUOgz2JH94xXYXdh 9DN+XVybbo5oROzliqtOxHNkttQKTrf7dx1TfIPaI/JzsxJpog1jgoS16c/IoUd9vGQyCKJ9oMrHx B77VTJwExqH5TmcA5kQd8pqvx+GV+XMl0EjNtqMoQMcgjqPTXwl9jNSmFakfr3xJN0Kxf8hpirOEq bPe4BldG+V7MS+ZPnmmaFXME+QzflpnvbXOKDkMR/dmbHSFjUIJKIc6OGLNfI2MoUcxKngSXjft0Y 5pO4eFcJQPdQfAvhJIPOkk0zQfYPiL5meibUw2/6s4GdMQw6tdl/5CyuBznYiymCd2hzKD2htpIBn l4RyhFsg==; Content-Disposition: inline In-Reply-To: List-ID: Content-Type: text/plain; charset="windows-1254" To: Nathan Chancellor Cc: Brian Cain , kernel test robot , llvm@lists.linux.dev, kbuild-all@lists.01.org, Linux Memory Management List , linux-hexagon@vger.kernel.org T24gU2F0LCBNYXkgMTQsIDIwMjIgYXQgMDI6NTc6MThQTSAtMDcwMCwgTmF0aGFuIENoYW5jZWxs b3Igd3JvdGU6Cj4gT24gU2F0LCBNYXkgMTQsIDIwMjIgYXQgMDU6Mjg6MzNQTSArMDEwMCwgTWF0 dGhldyBXaWxjb3ggd3JvdGU6Cj4gPiBPbiBTdW4sIE1heSAxNSwgMjAyMiBhdCAxMjoyMzo0NkFN ICswODAwLCBrZXJuZWwgdGVzdCByb2JvdCB3cm90ZToKPiA+ID4gY29tbWl0OiAyYzY5ZTIwNTc5 NjJiNmJkNzZkNzI0NDY0NTM4NjJlYjU5MzI1YjQ5IFs5OTk1LzExNjUxXSBmczogQ29udmVydCBi bG9ja19yZWFkX2Z1bGxfcGFnZSgpIHRvIGJsb2NrX3JlYWRfZnVsbF9mb2xpbygpCj4gPiA+IGNv bmZpZzogaGV4YWdvbi1yYW5kY29uZmlnLXIwNDEtMjAyMjA1MTMgKGh0dHBzOi8vZG93bmxvYWQu MDEub3JnLzBkYXktY2kvYXJjaGl2ZS8yMDIyMDUxNS8yMDIyMDUxNTAwNTEuM1J6dW9vQUctbGtw QGludGVsLmNvbS9jb25maWcpCj4gPiA+IGNvbXBpbGVyOiBjbGFuZyB2ZXJzaW9uIDE1LjAuMCAo aHR0cHM6Ly9naXRodWIuY29tL2xsdm0vbGx2bS1wcm9qZWN0IDM4MTg5NDM4YjY5Y2EyN2I0YzZj ZTcwN2M1MmRiZDIxNzU4M2QwNDYpCj4gPiAuLi4KPiA+ID4gQWxsIHdhcm5pbmdzIChuZXcgb25l cyBwcmVmaXhlZCBieSA+Pik6Cj4gPiA+IAo+ID4gPiA+PiBmcy9idWZmZXIuYzoyMjU0OjU6IHdh cm5pbmc6IHN0YWNrIGZyYW1lIHNpemUgKDIxNDQpIGV4Y2VlZHMgbGltaXQgKDEwMjQpIGluICdi bG9ja19yZWFkX2Z1bGxfZm9saW8nIFstV2ZyYW1lLWxhcmdlci10aGFuXQo+ID4gPiAgICBpbnQg YmxvY2tfcmVhZF9mdWxsX2ZvbGlvKHN0cnVjdCBmb2xpbyAqZm9saW8sIGdldF9ibG9ja190ICpn ZXRfYmxvY2spCj4gPiA+ICAgICAgICBeCj4gPiA+ICAgIDEgd2FybmluZyBnZW5lcmF0ZWQuCj4g PiAKPiA+IE5vdyBzaG93IHRoZSB3YXJuaW5ncyB0aGF0IHdlcmUgcmVtb3ZlZC4gIFRoaXMgcGF0 Y2ggcmVuYW1lcyB0aGUKPiA+IGZ1bmN0aW9uLCBhbmQgSSBiZXQgdGhlcmUgd2FzIGEgc2ltaWxh ciB3YXJuaW5nIGJlZm9yZSB0aGlzIHBhdGNoLgo+ID4gCj4gPiBCdXQgYmFzaWNhbGx5LCBJIGRv bid0IGNhcmUgYWJvdXQgc3RhY2sgdXNhZ2Ugb24gaGV4YWdvbiB3aXRoIGNsYW5nLgo+ID4gQUlV SSwgaXQncyBhIGtub3duIGJ1Zy4KPiAKPiBGb3Igd2hhdCBpdCdzIHdvcnRoLCBpdCBzZWVtcyBs aWtlIHRoaXMgaXMganVzdCAyNTZLIHBhZ2VzIGJlaW5nIDI1NksKPiBwYWdlcy4uLiBNQVhfQlVG X1BFUl9QQUdFIGlzIFBBR0VfU0laRSAvIDUxMiBzbyAqYXJyIGlzIDIwNDggYnl0ZXMgYmlnCj4g aW4gdGhpcyBjb25maWd1cmF0aW9uLiBZb3UnZCBzZWUgYSBzaW1pbGFyIHdhcm5pbmcgd2l0aCBQ b3dlclBDIGJ1dCB0aGF0Cj4gY29uZmlndXJhdGlvbiBpcyBub24tc3RhbmRhcmQ6CgpBaGghICBZ ZXMsIEknZCBmb3Jnb3R0ZW4gdGhhdCBIZXhhZ29uIGhhcyB0aGF0IGNyYXp5IGNvbmZpZyBvcHRp b24uCkkgdGhpbmsgSSBjYW4gZ2V0IHJpZCBvZiB0aGF0IGVub3Jtb3VzIGFycmF5IG9mIHBvaW50 ZXJzLCBpdCBqdXN0IHdhc24ndAphIGhpZ2ggcHJpb3JpdHkgZm9yIG1lLgoKPiBmcy9idWZmZXIu YzogSW4gZnVuY3Rpb24g4oCYYmxvY2tfcmVhZF9mdWxsX3BhZ2XigJk6Cj4gZnMvYnVmZmVyLmM6 MjMzNzoxOiB3YXJuaW5nOiB0aGUgZnJhbWUgc2l6ZSBvZiAyMDY0IGJ5dGVzIGlzIGxhcmdlciB0 aGFuIDEwMjQgYnl0ZXMgWy1XZnJhbWUtbGFyZ2VyLXRoYW49XQo+ICAyMzM3IHwgfQo+ICAgICAg IHwgXgo+IAo+IEl0IHdvdWxkIGJlIG5pY2UgaWYgdGhlIEludGVsIGZvbGtzIGNvdWxkIGxvb2sg YXQgcmVjb2duaXppbmcgYSBmdW5jdGlvbgo+IHJlbmFtZSBzbyB0aGF0IHlvdSBhcmUgbm90IGJv dGhlcmVkIGJ5IHJlcG9ydHMgbGlrZSB0aGlzLgo+IAo+IEFzIGEgc2lkZSBub3RlLi4uIEJyaWFu LCBpcyB0aGVyZSBhbnkgcmVhc29uIGZvciAyNTZLIHBhZ2VzIHRvIGV4aXN0IGZvcgo+IEhleGFn b24/IFRoaXMgaGFzIGJlZW4gYW4gb3B0aW9uIHNpbmNlIEhleGFnb24ncyBpbnRyb2R1Y3Rpb24g YnV0IGlzIGl0Cj4gYWN0dWFsbHkgdXNlZD8gNEsgcGFnZXMgaXMgdGhlIGRlZmF1bHQgYW5kIHRo ZSBoZWxwIHRleHQgc2F5cyAidXNlIHdpdGgKPiBjYXV0aW9uIi4gUGVyaGFwcyB0aGUgY2hvaWNl IHNob3VsZCBiZSB0dXJuZWQgb2ZmIGFsdG9nZXRoZXIgZm9yCj4gQ09ORklHX0NPTVBJTEVfVEVT VCBzbyB0aGF0IHdlIGNhbm5vdCBzZWxlY3QgdGhpcyBjb25maWd1cmF0aW9uIGFuZAo+IGJvdGhl ciBkZXZlbG9wZXJzIHdpdGggdGhlc2UgcmVwb3J0cy4KPiAKPiBDaGVlcnMsCj4gTmF0aGFuCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 60CEF627 for ; Sun, 15 May 2022 00:31:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=eZAXC+k+tR5S6s/jXIC4fOUMN3Hkrv/eDiD122qcZmE=; b=V4rcHE1nZ/iUOgz2JH94xXYXdh 9DN+XVybbo5oROzliqtOxHNkttQKTrf7dx1TfIPaI/JzsxJpog1jgoS16c/IoUd9vGQyCKJ9oMrHx B77VTJwExqH5TmcA5kQd8pqvx+GV+XMl0EjNtqMoQMcgjqPTXwl9jNSmFakfr3xJN0Kxf8hpirOEq bPe4BldG+V7MS+ZPnmmaFXME+QzflpnvbXOKDkMR/dmbHSFjUIJKIc6OGLNfI2MoUcxKngSXjft0Y 5pO4eFcJQPdQfAvhJIPOkk0zQfYPiL5meibUw2/6s4GdMQw6tdl/5CyuBznYiymCd2hzKD2htpIBn l4RyhFsg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nq29s-008eag-Be; Sun, 15 May 2022 00:30:52 +0000 Date: Sun, 15 May 2022 01:30:52 +0100 From: Matthew Wilcox To: Nathan Chancellor Cc: Brian Cain , kernel test robot , llvm@lists.linux.dev, kbuild-all@lists.01.org, Linux Memory Management List , linux-hexagon@vger.kernel.org Subject: Re: [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio' Message-ID: References: <202205150051.3RzuooAG-lkp@intel.com> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0980218007192643358==" MIME-Version: 1.0 From: Matthew Wilcox To: kbuild-all@lists.01.org Subject: Re: [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio' Date: Sun, 15 May 2022 01:30:52 +0100 Message-ID: In-Reply-To: List-Id: --===============0980218007192643358== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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: Con= vert block_read_full_page() to block_read_full_folio() > > > config: hexagon-randconfig-r041-20220513 (https://download.01.org/0da= y-ci/archive/20220515/202205150051.3RzuooAG-lkp(a)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_bl= ock) > > > ^ > > > 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 =E2=80=98block_read_full_page=E2=80=99: > fs/buffer.c:2337:1: warning: the frame size of 2064 bytes is larger than = 1024 bytes [-Wframe-larger-than=3D] > 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 --===============0980218007192643358==--