From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 962EFC433F5 for ; Wed, 8 Sep 2021 16:07:32 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 56C376113C for ; Wed, 8 Sep 2021 16:07:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 56C376113C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wBs0mi3Dhy0NCunzFEqwLxRUXzAqxA8zngE9IMidWcE=; b=KLR8es1+Kd7Uim 0+HucIjXwrso53wFLIDYIBByjwWEya2p8kogZIHtY33El6MBtYAy0yNyU6kZp+4Bgm1eSmQIe4rpS iP+5ivkY43gLNv47x0g1BegtQegds7nQ/2USXHI/fxxjy7v8vLi+1tuFYQk2oCmZfu4FH+ZzAAWDv 9i5m3kWdF7mPVM1LeAkMzNxU26hRak9o+wI3+C/+I2YDFU9H+ntTwxZgYdgFU8+hvJvSl9pyR0XHd O2wkDQXLh1S/+g0ElZNx2dAuxsCBtwoDZroT85yoMUTLyAKKG6M/rv+6oriSBHOz/BTW38Z4L/wiN RdU/aHfQcvWBIJRNYhOw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mO04o-007AR2-BC; Wed, 08 Sep 2021 16:05:30 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mO04k-007AQP-Um for linux-arm-kernel@bombadil.infradead.org; Wed, 08 Sep 2021 16:05:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Transfer-Encoding:Content-Type :MIME-Version:In-Reply-To:References:Message-ID:Date:Subject:CC:To:From: Sender:Reply-To:Content-ID:Content-Description; bh=nKYVHC+z+9alNgpJJkZubI+VGlC+7AgSTie9Pr013Bk=; b=GeICbVIRtWPYQDrWJMA5zB5DoU m6R184BJaF7vjgwlA/GSc8ur3AwCd40EETqrLksBP7CNRTN2xN/qmXN9UGkIybVRK/gSAu79jXZ/k h5wnXBZUlyrPI3fDegebMwUkDvba00wcMoesDDRkdAVTWV4yweLR3rLG/bZVKmra1nWZTAuVpsRIK PdQ1ZwM78YhNYXpjQSOZRNnPHRhw+QoKkfCflJVDpFRiwM6o5bF3IhFbVCw8VZQSaqBm8zrNNwylI qpPARBaCLsKjTEW6n/r2hXIP9XnIzQ40N4jXBMzv4IXWdUDbf9GpAFbJz+K4bqliSbFZUg0im3GtQ hUCpR02g==; Received: from eu-smtp-delivery-151.mimecast.com ([185.58.86.151]) by desiato.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mO04h-001fZk-NM for linux-arm-kernel@lists.infradead.org; Wed, 08 Sep 2021 16:05:25 +0000 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-193-6kt6kR_2ONqOOT2qFdPoMg-1; Wed, 08 Sep 2021 17:05:15 +0100 X-MC-Unique: 6kt6kR_2ONqOOT2qFdPoMg-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Wed, 8 Sep 2021 17:05:12 +0100 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.023; Wed, 8 Sep 2021 17:05:12 +0100 From: David Laight To: 'Wei Liu' CC: Linus Torvalds , Naresh Kamboju , Mathias Nyman , Johannes Berg , Jakub Kicinski , Shuah Khan , Brendan Higgins , Ariel Elior , "GR-everest-linux-l2@marvell.com" , "Linux ARM" , open list , Netdev , "lkft-triage@lists.linaro.org" , Arnd Bergmann , "David S. Miller" , Greg Kroah-Hartman , Nick Desaulniers , Nathan Chancellor , Daniel Borkmann , Alexei Starovoitov , Eric Dumazet Subject: RE: ipv4/tcp.c:4234:1: error: the frame size of 1152 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Thread-Topic: ipv4/tcp.c:4234:1: error: the frame size of 1152 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Thread-Index: AQHXpJjLHdBfxh/omUuYsxLT8U4Q1auaODzA///43ICAABV5QA== Date: Wed, 8 Sep 2021 16:05:12 +0000 Message-ID: References: <20210908100304.oknxj4v436sbg3nb@liuwe-devbox-debian-v2> <46be667d057f413aac7871ebe784e274@AcuMS.aculab.com> <20210908152351.asln63jxk43xffib@liuwe-devbox-debian-v2> In-Reply-To: <20210908152351.asln63jxk43xffib@liuwe-devbox-debian-v2> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210908_170523_891358_44CAE563 X-CRM114-Status: GOOD ( 25.06 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org From: Wei Liu > Sent: 08 September 2021 16:24 > > On Wed, Sep 08, 2021 at 02:51:21PM +0000, David Laight wrote: > > From: Wei Liu > > > Sent: 08 September 2021 11:03 > > ... > > > However calling into the allocator from that IPI path seems very heavy > > > weight. I will discuss with fellow engineers on how to fix it properly. > > > > Isn't the IPI code something that is likely to get called > > when a lot of stack has already been used? > > > > So you really shouldn't be using much stack at all?? > > I don't follow your questions. I don't dispute there is a problem. I > just think calling into the allocator is not a good idea in that > particular piece of code we need to fix. > > Hopefully we can come up with a solution to remove need for a cpumask in > that code -- discussion is on-going. I'm pretty sure the IPI interrupt is high priority so can nest with another interrupt. (You certainly want it to be that way.) So the kernel may already be running on the interrupt stack. If the interrupted ISR code has used a lot of stack then there may not be as much left as you might expect. Many years ago (nearly 40!) I wrote something that did static stack depth analysis for an embedded system. Since there were no (interesting) indirect calls an no recursion it wasn't completely impossible. What it showed was that the deepest stack use was in error trace paths that probably never happened. I suspect the same is true for Linux - the deepest points will be inside printk() in obscure error paths. Get an IPI while in a printk() from deep inside an ISR and you may not have the amount of stack you expect. It might be possible to use the clang 'control flow integrity' information to determine the actual maximum stack use even for indirectly called functions. I suspect that would be an eye-opener.... David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel