Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp289429imw; Fri, 8 Jul 2022 03:04:28 -0700 (PDT) X-Google-Smtp-Source: AGRyM1ujNfZdCXi+Cx2kMBD9D2wWYBwmvIg9dbe7wMAN77jSwTKAfqNViDLP9+sW4Hu8qBQZRilS X-Received: by 2002:a17:902:d2c5:b0:16a:5204:304f with SMTP id n5-20020a170902d2c500b0016a5204304fmr2889803plc.98.1657274668459; Fri, 08 Jul 2022 03:04:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657274668; cv=none; d=google.com; s=arc-20160816; b=S89NX53BghLlPsG6ONomQLcGkjTlc5bkBg86+BUcVncezFYqBUGPlFu3vrKFchVrqg DRW/BeQx7pIb+rujqDYhg9+LEK8OFFABWDMlfYXurvmUaQlYWiXWjWX1yAAMbDU48HAY IBvAa/i2ne8XH7s4C4jkYZOn6is+V+10C6U7nt7bHcufbkvVeIS/9JZ+MPdbX0W9MrYw HXLGVdWuqLywBCOU9khFAPqhHb5HNwDSbodnK0ePvI+lluxAfGJh+uRaMJOuW7lznq8u RmMSzmD4tDrC15u1m4QcgdKiv1P5b0PFy25Lu7Bk0QB4v4D6FX53AgTT0f7nYftW3dA6 Yggg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=Vdi/B2mPTnCMyO8HGcEgE0ipigaIaniIRr1AKwKskEA=; b=O1MBJIfkpIRoNd6GGtu6fnfsjl9FFEtyjtflBo5HYUM7dby/pbHLFIyMXFlASncypq zRt6JFqkDs/icdbe5t3SCre6YNrabq3u7SIIcT9+o/64yXwuHuruOUjVt7gaEKDMZt27 6mpRsicayY6LQHsdzMLv2AJaIEF/l3NP3yLu6MTD3VuBbpx6ZeLYCAwAEig9RJZleZIB tGVRpTdrCVU/T2zBNolZZcRe4dejFAYUlAgkOXvq4RPRtOo5NbJPR3bTPyAlJY+EuqUJ FvWOyK8Yyc0jmK5ez7QtNkI1Jbw79us96Ouhuju3uEVh7VRdvNARn4BmDvzzNEHzExDU hqpg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=BWLI9FKA; 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=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b7-20020a631b47000000b0040c8f91f3c9si53931115pgm.169.2022.07.08.03.04.12; Fri, 08 Jul 2022 03:04:28 -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=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=BWLI9FKA; 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=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237865AbiGHJuV (ORCPT + 99 others); Fri, 8 Jul 2022 05:50:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39722 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237709AbiGHJuT (ORCPT ); Fri, 8 Jul 2022 05:50:19 -0400 Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CD8783F07 for ; Fri, 8 Jul 2022 02:50:14 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id s206so21940976pgs.3 for ; Fri, 08 Jul 2022 02:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=Vdi/B2mPTnCMyO8HGcEgE0ipigaIaniIRr1AKwKskEA=; b=BWLI9FKAbTKydGoq1piX23lQ9ZpccEkEkE2A6rJmGmxGtChFUxhjRdQNw/rKHxLDK1 TrM9pd+l9h9AzZCgUC3hR2gg9gEXPP/RzbR0gfg5o3zdA7EzXHbLYos+sjX0nItakXd/ 2OUR0tx93irPrRZt69XIPqj2ewMDkftngms5vLJ05fmNTb7WfKx68hnnNT+nBOhPcE7M TMkEBrMAjz9GAJTHEFr3rf0S7pPL1cY68qOgMngdLsYZOMibOO4kenk0kzyPa0ZcKV9/ QdHLP8ZF+QGqLJBccYGVEoUInwLTXcOiHKt/ZOtvDsCBWml2TEn7UyMF097VN5VZrdu9 dmjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=Vdi/B2mPTnCMyO8HGcEgE0ipigaIaniIRr1AKwKskEA=; b=G0rsz4BEu6wAABUYLrO7oK1H55zSvqtgIM6ZOn4HW7zdpD7yb+tXPOsbdCG9IqF8ox fUE5DW9V5MDQqpzgcjTAuDfEh/jjyXeCbD/iCRbnHyGOkDC0Ms/b1rubEfuBLPP/W2QN YtdDtwQy6uUKJzI2YT7kBcVpFhROqDCT6UCPHI17YX9jJQ8h68vdLQ9g93hb2bkH0bZh hIl8P78D17dNQ8n9c1zAH+CeynBVRshQk4ysFa3V0KfOsliRdl7vu/HtuxLHjbdnudMi dJV9U86fboKD21hAFP2Ie1SLXbaduWHdN37VfunMIWFttqH6tQF+W52DPocU1PH3ocgJ 5jhQ== X-Gm-Message-State: AJIora9fCofTu/iGq9kzuRDrvix5Pc2lgY9lVk2vHh5//HXCfGus9x0V mQOaIoLgub7IK092+sFRaxsNUg== X-Received: by 2002:aa7:9985:0:b0:528:d798:1de2 with SMTP id k5-20020aa79985000000b00528d7981de2mr2877131pfh.84.1657273813593; Fri, 08 Jul 2022 02:50:13 -0700 (PDT) Received: from C02DW0BEMD6R.bytedance.net ([139.177.225.235]) by smtp.gmail.com with ESMTPSA id c18-20020a621c12000000b0051bbd79fc9csm28551035pfc.57.2022.07.08.02.50.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Jul 2022 02:50:12 -0700 (PDT) From: Qi Zheng To: arnd@arndb.de, catalin.marinas@arm.com, will@kernel.org Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Qi Zheng Subject: [PATCH v1 0/2] arm64: run softirqs on the per-CPU IRQ stack Date: Fri, 8 Jul 2022 17:49:48 +0800 Message-Id: <20220708094950.41944-1-zhengqi.arch@bytedance.com> X-Mailer: git-send-email 2.24.3 (Apple Git-128) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,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 Hi all, Currently arm64 supports per-CPU IRQ stack, but softirqs are still handled in the task context. Since any call to local_bh_enable() at any level in the task's call stack may trigger a softirq processing run, which could potentially cause a task stack overflow if the combined stack footprints exceed the stack's size. And we did encounter this situation in the real environment: Call trace: dump_backtrace+0x0/0x1cc, show_stack+0x14/0x1c, dump_stack+0xc4/0xfc, panic+0x150/0x2c8, panic+0x0/0x2c8, handle_bad_stack+0x11c/0x130, __bad_stack+0x88/0x8c, vsnprintf+0x2c/0x524, vscnprintf+0x38/0x7c, scnprintf+0x6c/0x90, /* ... */ __do_softirq+0x1e0/0x370, do_softirq+0x40/0x50, __local_bh_enable_ip+0x8c/0x90, _raw_spin_unlock_bh+0x1c/0x24, /* ... */ process_one_work+0x1dc/0x3e4, worker_thread+0x260/0x360, kthread+0x118/0x128, ret_from_fork+0x10/0x18, So let's run these softirqs on the IRQ stack as well. This series is based on next-20220707. Comments and suggestions are welcome. Thanks, Qi RFC: https://lore.kernel.org/lkml/20220707110511.52129-1-zhengqi.arch@bytedance.com/ Changelog in RFC -> v1: - fix conflicts with commit f2c5092190f2 ("arch/*: Disable softirq stacks on PREEMPT_RT.") Qi Zheng (2): arm64: run softirqs on the per-CPU IRQ stack arm64: support HAVE_IRQ_EXIT_ON_IRQ_STACK arch/arm64/Kconfig | 2 ++ arch/arm64/include/asm/exception.h | 4 +++- arch/arm64/kernel/entry-common.c | 30 ++++++++++++++++++++---------- arch/arm64/kernel/entry.S | 6 ++++-- arch/arm64/kernel/irq.c | 14 ++++++++++++++ 5 files changed, 43 insertions(+), 13 deletions(-) -- 2.20.1