Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp1791344rwb; Fri, 7 Oct 2022 19:17:57 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4u/edFkQ85kszt0y4ezwZImsdtjDEhwWxNLdqxc8f19ZK70+86HwNoL1hMpARQEbxpLuA0 X-Received: by 2002:a17:907:a052:b0:78d:8531:92b with SMTP id gz18-20020a170907a05200b0078d8531092bmr3962402ejc.37.1665195477379; Fri, 07 Oct 2022 19:17:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665195477; cv=none; d=google.com; s=arc-20160816; b=P8/+v8OuIxySrt6q4JgOBvQGtUjiOSj68/RGO59s1ufDVOhUKJXGgsZ6+MP2h7viFx Bz4C8vOE8gEvRD+/vU/MeQjoU0Een+Eh/M1dFhtzkQUmsvcrfMxuOck1gk/PFvAXswO/ LQDIT77wsT06tRygkiExiWPnZqZPLiU/eZQ/mhFvUS22ZEfJfRjTqz9u1W7P8y7CqosM W/Uc8eapL6s9zsx6taZGz+qYyQfC1coa4EiMSchcLzc3t8L7VbMVU+f+mL30vBu19lZ4 kIafGhSwHFHb9TxkH8H+SJBe3MSOKnj4Wih6Ln92i6BdU5HjODNS+ww3xXZQE3xwLaWn WXDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=xpqExMKuBAZ4nanV0ACDIwX3JKRh9Lzr9tC9UZ4wosQ=; b=Ip+mdy3zsxLGWnTt5H7+OM1f01P75PV3SMB2qr2WVEvKfmEpvz7wGVBDuhMZ2BOP1f W+2c3HgU/iwHiMAbHX9ALVphO8SVV6R/xMwZvU9bWvj/Nj+lSENFj81QyndoYvDNwlvI P67vTIWl64zFDNT6oIw0XhRP/tXODqIyuYtr+zPiSZ7fpRWf08A3tFLdwYGoZwpDo4BW DNxsp9rnk2wO9XQwpYxhZLJvUAWvdPlUr5a7EI5MFVwq/0oN7CdESy8o82WOLNGEwvEu YRXTVEysXm6/gXopl4bjD0+VoJfeOIfdc0SqnNuZJ/O7SyEHZV7iukkMdp2j5KCkfL4R /TZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=aOUd2Xdt; 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=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jz3-20020a170906bb0300b00780620030b3si3630823ejb.928.2022.10.07.19.17.29; Fri, 07 Oct 2022 19:17:57 -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=@intel.com header.s=Intel header.b=aOUd2Xdt; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229592AbiJHBqw (ORCPT + 99 others); Fri, 7 Oct 2022 21:46:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229582AbiJHBqv (ORCPT ); Fri, 7 Oct 2022 21:46:51 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 000936292E; Fri, 7 Oct 2022 18:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1665193610; x=1696729610; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=oQxjNLOcMJZGWcwR/V6EOum5AghG2IhHdI8FHMASetQ=; b=aOUd2Xdtt+WypifyPR7E7aQjzFpAa/ckBXpEJ04HxdRh/irT9cHvg327 q+DQW+ic1MSFNFLeQGvK2XAvRxiXM3UikskWj5+ladF3Qqeq7nbwwoSWA 6MrrSfnu3kpYlEWhw+Ez7mpmkxjR1BDTgohDiCaWgF2ZVkNdWrBAH/9fr +V0mne6+O3yi6cYsms0nM3mgzvRoOHNute8PvrkTXFktCSyZasqgGgTnt oH0tzWOpE8+W6BvHiOlOAa8Pcdk0VPmSUeKJDGsxTF0zyYGiTwzHNGGjs S3KJ1sXQsdKnHWY5oT8+RwR+s7SlRVqxgGIvLmwum74rK5Izw+0P/4yni Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10493"; a="365826650" X-IronPort-AV: E=Sophos;i="5.95,168,1661842800"; d="scan'208";a="365826650" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2022 18:46:49 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10493"; a="625358200" X-IronPort-AV: E=Sophos;i="5.95,168,1661842800"; d="scan'208";a="625358200" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.212.234.20]) ([10.212.234.20]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2022 18:46:49 -0700 Message-ID: Date: Fri, 7 Oct 2022 18:46:48 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH] fs/select: avoid clang stack usage warning Content-Language: en-US To: Nick Desaulniers , Arnd Bergmann Cc: linux-fsdevel@vger.kernel.org, Alexander Viro , Andrew Morton , Christoph Hellwig , Eric Dumazet , "Darrick J. Wong" , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, llvm@lists.linux.dev References: <20190307090146.1874906-1-arnd@arndb.de> <20221006222124.aabaemy7ofop7ccz@google.com> From: Andi Kleen In-Reply-To: <20221006222124.aabaemy7ofop7ccz@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE 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 10/6/2022 3:21 PM, Nick Desaulniers wrote: > On Thu, Mar 07, 2019 at 10:01:36AM +0100, Arnd Bergmann wrote: >> The select() implementation is carefully tuned to put a sensible amount >> of data on the stack for holding a copy of the user space fd_set, >> but not too large to risk overflowing the kernel stack. >> >> When building a 32-bit kernel with clang, we need a little more space >> than with gcc, which often triggers a warning: >> >> fs/select.c:619:5: error: stack frame size of 1048 bytes in function 'core_sys_select' [-Werror,-Wframe-larger-than=] >> int core_sys_select(int n, fd_set __user *inp, fd_set __user *outp, >> >> I experimentally found that for 32-bit ARM, reducing the maximum >> stack usage by 64 bytes keeps us reliably under the warning limit >> again. >> >> Signed-off-by: Arnd Bergmann >> --- >> include/linux/poll.h | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/include/linux/poll.h b/include/linux/poll.h >> index 7e0fdcf905d2..1cdc32b1f1b0 100644 >> --- a/include/linux/poll.h >> +++ b/include/linux/poll.h >> @@ -16,7 +16,11 @@ >> extern struct ctl_table epoll_table[]; /* for sysctl */ >> /* ~832 bytes of stack space used max in sys_select/sys_poll before allocating >> additional memory. */ >> +#ifdef __clang__ >> +#define MAX_STACK_ALLOC 768 > Hi Arnd, > Upon a toolchain upgrade for Android, our 32b x86 image used for > first-party developer VMs started tripping -Wframe-larger-than= again > (thanks -Werror) which is blocking our ability to upgrade our toolchain. I wonder if there is a way to disable the warning or increase the threshold just for this function. I don't think attribute optimize would work, but perhaps some pragma? -Andi