Received: by 2002:a05:6a10:6d25:0:0:0:0 with SMTP id gq37csp1972023pxb; Mon, 13 Sep 2021 09:13:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyphWncArfen1fg9iFro3sPslGQTeXSuykBoH+k/viUHdsWCQcu3HcZlD6x3qEzaMIKaeAS X-Received: by 2002:a05:6638:2611:: with SMTP id m17mr8251730jat.85.1631549637597; Mon, 13 Sep 2021 09:13:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631549637; cv=none; d=google.com; s=arc-20160816; b=p/x9BODbdBvB5IIsZLMsKweVD8Rlfd70s+oqMkcUHayI0T0nlgcQBlc3DnWMAT9c/I e0mOuqvLTtfeHiQkmv1RLs4uFunLPZW05O6LEZl5bIvUVzkMK3Xtu3R3GxM7hxemBBUE ZcuXq4iXnN/WgbQklWymUK3jXxquIyyGLav4sWuH5XD6wk4JfDgsDdjZOMcWIUmVHSxC UXl375J/+niJySH6vGx3wg7SWcs4dCMEoU3j9kDiZZfdm9ygYwujfu8MgNmAChk7cIsK WTVjYjqPbAw2c4HnE+ARRe/xkp4rAw1LLhQo3SlLpCgjCD2zu4NCzSfAAWStpmcx7kuf DOSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to:sender:dkim-signature; bh=pF05lJj4lNy2tE9FXorSLt5VhlGQ+NsTtocuOEsRASU=; b=Kc+Hp6gE1mqovS1Gwckf/mgOPqeKDFjaw3k3R5zqQ2uV8nWDmRbwqT+B8wwTc9dMcO JqjSOn1ABQJ7ITjJLSwTLVHAptlzds96XbqeBe5BiGx/uHJagIRkx/1mB2oEaNqG0BBp kMT6aXR02I0yGzgvDZ3xEJRMUFFoNKzIgzn+QbcTkFYjonQ+wPZLS5vmQi1tvJTLGvkU 3KCj82sBhsLc5KxkobIbjP9PLmS6VjXa9la1qSp4ZGrFuwVf3CJA47XdhuXKLzu09LGi fbMcHapQVHnJDvK0V0Fgnmaid2ft6el2KvmU/jBqQg0jiG/hmNYlZa6hqOyzLRbRAf1Z 3O0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=nUn0QCbJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s26si7090130iov.21.2021.09.13.09.13.45; Mon, 13 Sep 2021 09:13:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=nUn0QCbJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345587AbhIMQM4 (ORCPT + 99 others); Mon, 13 Sep 2021 12:12:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235710AbhIMQMz (ORCPT ); Mon, 13 Sep 2021 12:12:55 -0400 Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81AE7C061574 for ; Mon, 13 Sep 2021 09:11:39 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id c42-20020a05683034aa00b0051f4b99c40cso14057183otu.0 for ; Mon, 13 Sep 2021 09:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=pF05lJj4lNy2tE9FXorSLt5VhlGQ+NsTtocuOEsRASU=; b=nUn0QCbJ0IAMISgDmqkAYu1iK2EWcDmRXhy0FCpX2QZE0CNs+xak6z+P6NU1Xbo27K vB4cdBZJ6i+9nIl99sZcFI91QoKrJLwtK0QoPAd6HMlzlfON18pDJZA9f6HuYjXoc9JQ l0w7qpUoIfr21ochi8bBpVSlzsMt7rBvuWBEnBlo40xBl2gPOLjbmrfO2ATWeg0h5jry RwhBWmdluIk2MMA5Q69hPhPpvaIMdyF8SrE6LmRkgXv0OHPBnXw1Ce0DFhqMXsAjCXEY hkOwjrY1hnENZ5vpfASN4TQdIxvb0d6H0uo/5BTgIsQusq7jf9R2MuaRMYNAy69nq8LC ByNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:to:cc:references:from:subject:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pF05lJj4lNy2tE9FXorSLt5VhlGQ+NsTtocuOEsRASU=; b=QQhsy9LKde64RVxMcx8UY6+Zxg/gOckkjbAZT08qJcDZokl9dEDaSu7XcERiw1Wc9G EtPmqkEs2amZ8QnMU57G9cUc2X1E15JNd1MKHqrO9deCY1ybByArEc9id9pi4+ht1tc1 GQK1q+nDRW578MKNmBQCllr5+yghNPIUPIyRLGZhld/oQOa0NdP0rfGU+j0OoSVZT+6B K9af9tGbWJFNabJUb3lwacyYb2k9wi+xlPwWVVZcYNSZ7iCpaC+SG/fQDdkguOw8vuTZ FymrZWU7VmTnaH1PP8LiXZG63NOfyfUnfjS4qtVqy7WgKTEBk+xNW+uGEgJiw4pj4S/p mnvw== X-Gm-Message-State: AOAM530mbKNtsk6qosu4ys9VXzEZltN2t0jhI9NctxOgzH83uF0y+Z9n u03aH/8UNtgMH5SUV7m9ICY= X-Received: by 2002:a9d:38d:: with SMTP id f13mr10299861otf.66.1631549498900; Mon, 13 Sep 2021 09:11:38 -0700 (PDT) Received: from server.roeck-us.net ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id b24sm1796190oic.33.2021.09.13.09.11.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Sep 2021 09:11:38 -0700 (PDT) Sender: Guenter Roeck To: David Laight , Andrew Morton Cc: Masahiro Yamada , "linux-xtensa@linux-xtensa.org" , "linux-kernel@vger.kernel.org" , Chris Zankel , Max Filippov References: <20210912025235.3514761-1-linux@roeck-us.net> <315e4a23990444f585a15d2e23a39b8f@AcuMS.aculab.com> From: Guenter Roeck Subject: Re: [PATCH] xtensa: Increase size of gcc stack frame check Message-ID: <46f59bf8-f243-b65c-07b3-8ecbf7b410fa@roeck-us.net> Date: Mon, 13 Sep 2021 09:11:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <315e4a23990444f585a15d2e23a39b8f@AcuMS.aculab.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/13/21 8:57 AM, David Laight wrote: > From: Guenter Roeck >> Sent: 12 September 2021 03:53 >> >> xtensa frame size is larger than the frame size for almost all other >> architectures. This results in more than 50 "the frame size of is >> larger than 1024 bytes" errors when trying to build xtensa:allmodconfig. >> >> Increase frame size for xtensa to 1536 bytes to avoid compile errors >> due to frame size limits. > > Have you done anything to check what happens at run-time? > I'd guess that the deepest stack use is inside printk() in > some obscure error path. > > In reality all these 1k+ stack frames need killing > rather than the limit for the compiler warning increased. > > While it may be sensible for a system call entry function > so allocate a reasonable size buffer on stack (as poll() > and sendmsg() probably do) allocating big buffers way > down the call stack could easily cause stack overflow. > Even a 1k stack frame is huge. > The functions I checked typically have pretty large local data (like, more than 700-800 bytes). The errors are only observed with xtensa:allmodconfig test builds. While it may be arguable if those functions really need that much data on the stack, it is unreasonable to assume that all those errors (again, more than 50) are ever going to get fixed, especially since the errors are only seen with xtensa and not with any other architecture (including parisc; setting a stack limit of 1024 works just fine with that architecture, at least with gcc 11.x). So the realistic options are: 1) accept this or a similar patch 2) stop build testing xtensa:allmodconfig 3) Manually disable CONFIG_WERROR when test building xtensa:allmodconfig As it looks like, I'll probably implement option 3) in my test builds. I planned to start doing that around v5.15-rc4/rc5, but I may do it earlier if it is becoming obvious that the now-errors won't get fixed. Guenter