Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp2828826rwi; Tue, 11 Oct 2022 14:07:07 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6n8JJdk3hJ0m40sZv9UD+VkhSZwa9FiH9XcW9drjfE811NjWCc3Q2Q/wNuR9b5qheJbwiu X-Received: by 2002:a17:907:97c2:b0:78d:accc:c0a9 with SMTP id js2-20020a17090797c200b0078dacccc0a9mr11268133ejc.312.1665522427697; Tue, 11 Oct 2022 14:07:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665522427; cv=none; d=google.com; s=arc-20160816; b=pcl65TwW2hZeWUM3fZffshp+gembLg2BDDhMqua0WlDO+kAMH07b+XRlfahxoUj/x+ vDttD6lHLUpXdVzDPAdhpFb1Ma8y97Q+ZMwosPy0RNBUGpIeQ34kDX9FlysfskKxUoS/ feNuA3H4n9sF+uBZmFG/zDgAHAYJq4Bhnz7qLyWOCDo5PGnJcVprKbJCY6K9T3465lbl Y2Ok82+Iuak95yrrYF6W1vg7nOQ8thY+IkX0+wOJjyfB5e9+ExQxjk19qEQj5iGvuQtS iJ33YlN/KRiSStxq++Oo4vw2309esGajDlfPhLsLI/o9DStx4Q6P/RdBXWaijQ8KvvU+ qmrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=hXVOT4cLQG/UjKF5bxvScKtDt4JjDuPp0lInq7z6SZk=; b=lU4aCNerl7GcCSo0+VCNwGwF2WIXvUTZvFwQj907/n0hGVW4HFHDmaYqBG4Z/ku3On FF4pm6XNIBcpdYvXUuehw3psQcn6WT4/nuqQZD0M08zySNdHFXwwo5l4WsmpGRAi9Tfg tIE+C/TauBKg3gVvXyFEi0Wi0lOdhQkavtT0a0k/W3m7YddpLfC8PmjOu+C/bqUfuE6w 6fM5T7LErTjwACAkCOuo7Ct5GxMlHZeDYttjShmmLUEoDVPL+fLhMrC7OZqBgw57lmag j4dWbfvRuFqVACiPC1kwAXTGqnfaRSVtz10jO7vRUXaFSMexsRrH3WI9jM0rppsTLzf6 aNOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=sqIPnSdL; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s21-20020a508d15000000b00459ff7667b4si14217283eds.203.2022.10.11.14.06.41; Tue, 11 Oct 2022 14:07:07 -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=@google.com header.s=20210112 header.b=sqIPnSdL; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229729AbiJKUvI (ORCPT + 99 others); Tue, 11 Oct 2022 16:51:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47726 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229763AbiJKUu7 (ORCPT ); Tue, 11 Oct 2022 16:50:59 -0400 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C2E183062 for ; Tue, 11 Oct 2022 13:50:55 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id gf8so13494303pjb.5 for ; Tue, 11 Oct 2022 13:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hXVOT4cLQG/UjKF5bxvScKtDt4JjDuPp0lInq7z6SZk=; b=sqIPnSdL5hOAbhrVhdZG2o8sGZ+fwLZzLOdlefjOihqvUGgLaSJColzIKLls+fnmKc I+TNrBcbp3DxnXu9g+CwxTQBCR/0lXT18ueWRQ7SdpO5Jm+/4LysJaFEFJhAZ+nopXLE 1ZAsm9yxvKs6Z62XTHSFJGC/iB62BnYQcAg63vgJf9ZjDBLDmn6c7iWTQPD6bGwOhLu5 lObbFdm5P1qYkhBVE/wg3zrMywx6vg4lmS8fqA0fgqGn0Yipmuuqp+gC0/n5gUiJqSBM fLmw31GK/0DFXVXnvvEZSGO/eBt5F3sAdVV4i+DtzdT0TcfTs7hW0sfARTyGKIssnxUE Tjzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hXVOT4cLQG/UjKF5bxvScKtDt4JjDuPp0lInq7z6SZk=; b=AKZz2InGE1mmd0MRb6I/pC3HwYRETv8pygL5P+DMrgqpCmQH8Z29cUWh0DnzIFlAC5 nGPJNfsVmWkcutbZrcjRBFT5MO+onXXUho4X/q8D/qIX3QzTin6zuAmO7x9SVT67KaIX YO+xTzHcALpsTokF41WnY2UJB+Yxgwt/A7DGS34nm5cMHvQfDmN90nC6fx9wpyK+mn+U xTsSpoCqLBDfDEj++SNwl8OOT0JrhsDS614CkB127IkQFS+VxOUg/5XDbfTXaUjIJB89 p9O+SLiU7uiHZ9uvsY83uKdCqyvtBkJRdzbFulRjaAbKBJBQXfVanPuLt6Rn3j3BB9+h ltsg== X-Gm-Message-State: ACrzQf0+NseECW8hr53Skovb/EGe56w6ws5Wb9xsg4IV2+aF1E6vrCgs gat59qz7gauwzX3hezsUfPWWLta01z2b5ftwinjzkWASELSV7g== X-Received: by 2002:a17:90b:33c3:b0:20a:ebc3:6514 with SMTP id lk3-20020a17090b33c300b0020aebc36514mr1105208pjb.147.1665521454797; Tue, 11 Oct 2022 13:50:54 -0700 (PDT) MIME-Version: 1.0 References: <20190307090146.1874906-1-arnd@arndb.de> <20221006222124.aabaemy7ofop7ccz@google.com> In-Reply-To: From: Nick Desaulniers Date: Tue, 11 Oct 2022 13:50:43 -0700 Message-ID: Subject: Re: [PATCH] fs/select: avoid clang stack usage warning To: Andi Kleen Cc: Arnd Bergmann , 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 Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Fri, Oct 7, 2022 at 6:46 PM Andi Kleen wrote: > > > 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? Here's what I would have guessed, the pragma approach seems a little broken. https://godbolt.org/z/vY7fGYv7f Maybe I'm holding it wrong? > > > -Andi > > > -- Thanks, ~Nick Desaulniers