Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp2736160rwb; Mon, 15 Aug 2022 10:27:10 -0700 (PDT) X-Google-Smtp-Source: AA6agR4b9czcetFY48C4fUB65QSUKWIUYdgH4ICPl/Dj2iVEs4rqnoHkSEO1ewt1lSu3LjJMsRd4 X-Received: by 2002:a63:1c11:0:b0:41d:89d5:8ef0 with SMTP id c17-20020a631c11000000b0041d89d58ef0mr14640493pgc.403.1660584430366; Mon, 15 Aug 2022 10:27:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660584430; cv=none; d=google.com; s=arc-20160816; b=Z70GGeMjxhHPNEIjYh2K85sqTLkGo2b4Qqa9Dnz+sBsisMbgXLEnRL4ty2OsryrCkW C34GuTJNkxlcVbxr1QQZFy4m0/Vswgm+C+4bFbeC/ZH760vPJ21iMQWEEPu+0esG1Z+1 REVG7FIPnKACAUSTLYKObhpB3F5P4oENM3BNHIpLgogudwtuA7G7fjViTjs9BDc/tLAX oC3NbUTAN6Z2BKmc41c+wL/vPe8jQG9pkgFqdHqU7wRWr2RuJvwN/c/M08UZ0as8+Cp/ q1489VZEdBVIaNLQ1QzptoDdMHA/4xDfHds66tPOyEHfj5nDwxfs/GsLj7fHKrX9pc+N 4PzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=lYQovjjJo6XXCWKWLvP8oJ2ID1q47eQZLViUIMf/7So=; b=q8XFTSjLByo+E48k5Rd0wTuFL1G0ZlEtmHB+AkoaP++eh8YSKV/sTfAcAkAE0VwSBX mfrN8c/gtguN4145Y+KU3Z47ctcLjTjDpiYUeMg4rykLucYphoVdFIh1cCriIuRuHKaL mSaVR8kWk2cvN0pX3qj9Plnjhr01g+JLJN2AzlXEnk1fpZerwd6oLYQa9ndHsU13L/AM z/VhQ8KSFj4NakYipnwHvvU+XDGmVqpagJtZ+68nNAWBR+USyFo3mneGv2bry81+nTva om2QW4ZdaGp9wDQLryfSfRcPu6V6oMYTELvFV8dYLXG56FOF7/+pXoyHciySUYEh+YkB umnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BAuaf25b; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u9-20020a170903124900b0016ecc118debsi12580133plh.428.2022.08.15.10.26.59; Mon, 15 Aug 2022 10:27:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BAuaf25b; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232566AbiHORLc (ORCPT + 99 others); Mon, 15 Aug 2022 13:11:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229883AbiHORL3 (ORCPT ); Mon, 15 Aug 2022 13:11:29 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 231AF25E8A for ; Mon, 15 Aug 2022 10:11:28 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 60DF7CE115E for ; Mon, 15 Aug 2022 17:11:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 782C0C433D6; Mon, 15 Aug 2022 17:11:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1660583484; bh=bRUgZYlvzDD/pptSlNy1eAs06Vr+nJrjAzYkrLulvyM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BAuaf25b2NdNXWi04fOoG9yv+2Kq5CV/qoRpBT49uScalWi+dIEbl6WXuReYzV9n3 I2zuTIakQEwypk+02Z+9ewswCdIanzslKzS+RlTbE4thPI1pcdi/eJQt4g6xixQJSe NWuXxPju+/fXuqAw6Z51IPXM7Lu1+h+C5eDVmLb8uLzo+yFfy7jKdPr0UVKyQBvfl1 VqAYrEh95SXG0ROs2UoysTGN2C5EyeK3x1PpIDMarFH0jhah4W4dNZkbUm6iy/spCN f8X/L2YRd8sv7W27x3jIlWChIcOKL3cfL7fTBNix9K561L8R4jG+CjuSvwqv0MTQ4/ xfPvqWy1MCkYg== Date: Mon, 15 Aug 2022 10:11:22 -0700 From: Nathan Chancellor To: Arnd Bergmann Cc: Matthew Wilcox , kernel test robot , 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' Message-ID: References: <202208140835.W6F1j6Da-lkp@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 15, 2022 at 04:37:09PM +0200, Arnd Bergmann wrote: > On Mon, Aug 15, 2022 at 3:48 PM Arnd Bergmann 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