Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4845884pxu; Wed, 21 Oct 2020 06:51:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy3evB9mDTdATQNUPQlve0p0UVoI4NSMzObrTpJLtFGU442gDs9rRI6ZWycDguIJqtx+WYq X-Received: by 2002:a17:906:f2d2:: with SMTP id gz18mr3589496ejb.542.1603288304003; Wed, 21 Oct 2020 06:51:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603288303; cv=none; d=google.com; s=arc-20160816; b=mqWAPq20gexKTJJbOy/3EQb8kZGWs9y+51DrBkaoodWuSIzffOaUyyPVDMIrqkm2cw +qNhmKy4hYCHQDNAigtlv+kyHGSqjxEElDNlgkKCYk0/JOIkh0KzdqObeCzOvgHzrMEF /4XbAynEdtD/PEvTK5eIybaMwCwzYJN3BoflNbe/BuvLrFQ4wd2QDC+qt58LGmygwoYB QUyhW7ZOXZBJYZLcCXWLWiZjf7mt9emxzGTXuIEIJD++rvjq6mYhVYq2YrioGiBOgsU5 2fv5ZECp5hwnmE09oD+b8E453WrRmuQDHjlj0VofAuaEwLX/LtEb0oN3q0gSlB8o4f28 i6Wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=GGVUiwZ9pli4XrmAOJkPxUgsCqSFmuPB9kwRHn8mWnI=; b=KhJ45ttAXcIW5yq6/icGPvlJP3M8yiw1HWzLXdyZZrnbqtMmFnjvUciXfB36cX1X8d YB/CCXtlZ8P74g2oHItsZvcgN4Gt4NRLeK2854Khnp5pwjslIfN8iBISovWaVyKzWPvO cHNLntXaN5ZA26sPE4OPIkcRuzTEnMQamAUBxuDQaOsomQj9gHNNXJ2Mi5mnGgW7B8gm /EjOM4S7QiqeSowFKpCENzXVXkJ6G/5EOtL1kp6w7IP4h3JPZjhTQ9X3+6EAgu7/iCIM t5/J8i2DMV2CAd3Phx0//MqU519meGyK4neG3feKgcdvDher4nFvXYyBdnzyxP9UXxGw 8Izw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=srKfKdqr; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lj15si1345712ejb.612.2020.10.21.06.51.21; Wed, 21 Oct 2020 06:51:43 -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=@kernel.org header.s=default header.b=srKfKdqr; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2439774AbgJUL6k (ORCPT + 99 others); Wed, 21 Oct 2020 07:58:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:51524 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2393832AbgJUL6j (ORCPT ); Wed, 21 Oct 2020 07:58:39 -0400 Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EA41122251 for ; Wed, 21 Oct 2020 11:58:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603281519; bh=wsmfCYJA1G5W18rhe1i3zWsYQ3eg08pCP9xHDplvS6A=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=srKfKdqrcpEmy/AMoOlSfXqIxVMzQpvZSnQrGmRq5zPV4JwMBMSeURkdtbYDTKylB 4O2RtKuAAOeX2lyGjdAyjzpgXoPAYf93jMtuPSetIWXNoUL/iepVPgAjWiKBvOhUm7 kn7XprIS4XIHFMPNg+PWQ9drNOdMFppItuGB1scU= Received: by mail-qk1-f181.google.com with SMTP id r7so2035709qkf.3 for ; Wed, 21 Oct 2020 04:58:38 -0700 (PDT) X-Gm-Message-State: AOAM533wf5Yr/NYTckcn8NzTmqLLB1ui4mca/p6M78+pfHWOA3nwOqym PkagqwFRc25TDlMqIqdGeIZImPIjoIOI5HPheQk= X-Received: by 2002:a37:2dc6:: with SMTP id t189mr2722030qkh.394.1603281517886; Wed, 21 Oct 2020 04:58:37 -0700 (PDT) MIME-Version: 1.0 References: <1602141333-17822-1-git-send-email-maninder1.s@samsung.com> <20201008083015.GK1551@shell.armlinux.org.uk> In-Reply-To: From: Arnd Bergmann Date: Wed, 21 Oct 2020 13:58:21 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/3] IRQ stack support for ARM To: Russell King - ARM Linux admin Cc: Maninder Singh , v.narang@samsung.com, a.sahrawat@samsung.com, Andrew Morton , Marc Zyngier , Sebastian Andrzej Siewior , Vincent Whitchurch , Nick Desaulniers , "linux-kernel@vger.kernel.org" , Valentin Schneider , Dmitry Safonov <0x7f454c46@gmail.com>, Thomas Gleixner , Nathan Huckleberry , Will Deacon , Jian Cai , Linux ARM , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (replying to my own mail, apparently my normal outgoing email server is blacklisted, so resending from @kernel.org) On Fri, Oct 16, 2020 at 12:09 PM Arnd Bergmann wrote: > > On Thu, Oct 8, 2020 at 10:32 AM Russell King - ARM Linux admin > wrote: > > On Thu, Oct 08, 2020 at 12:45:30PM +0530, Maninder Singh wrote: > > > Observed Stack Overflow on 8KB kernel stack on ARM specially > > > incase on network interrupts, which results in undeterministic behavi= our. > > > So there is need for per cpu dedicated IRQ stack for ARM. > > > > > > As ARm does not have extra co-processor register > > > to save thread info pointer, IRQ stack will be at some > > > performance cost, so code is under CONFIG_IRQ_STACK. > > > > > > and we don't have much knowledge and set up for CLANG > > > and ARM_UNWIND, so dependency added for both cases. > > > > > > Tested patch set with QEMU for latest kernel > > > and 4.1 kernel for ARM target with same patch set. > > > > You need to investigate and show where and why this is happening. My > > guess is you have a network driver that uses a lot of kernel stack > > space, which itself would be a bug. > > Agreed. > > > Note that there are compiler versions out there that mis-optimise and > > eat stack space - the kernel build should be warning if a function > > uses a large amount of stack. > > Some more ideas for figuring it out: > > CONFIG_DEBUG_STACK_USAGE may also be helpful in identifying > code paths that are deeply nested with multiple functions taking a > lot of stack space, but each one staying under the limit. > > CONFIG_DEBUG_STACKOVERFLOW would also help here but > is not supported on Arm at the moment. There was a patch[1] from > Uwe Kleine-K=C3=B6nig to add this, and I suppose we should still add > that, in particular if it helps debug this problem. > > CONFIG_VMAP_STACK is probably the best way to debug > random runtime stack overflows because using a guard page > turns random memory corruption into an immediate oops, > but I don't think there is an implementation for Arm yet and > using a lot of vmalloc space means we might not be able to > default to this. > > Regardless of identifying and fixing the bug Maninder found, I > also think that supporting separate async stacks on Arm is useful > for determinism. Most of the popular architectures use irqstack > for this reason, and I was actually surprised that we don't do it > on arch/arm/. > > Arnd > > [1] https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kle= ine-koenig@pengutronix.de/