Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp231754pxu; Thu, 7 Jan 2021 03:32:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJya/+YzkThbhmaXwk5n3hJv2Ml3Y3Fx/0lK6ktho5MECfSDBcy+YoCLhmDvznchpzln+OpZ X-Received: by 2002:a50:955b:: with SMTP id v27mr1353343eda.324.1610019139978; Thu, 07 Jan 2021 03:32:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610019139; cv=none; d=google.com; s=arc-20160816; b=ZsZahLc8waETrVqcB7FUKWkLT6mwXE4fRhFZf0RGEAQCUeQAW3q7cmQByboboHln9V AVMBKmK7MJLyo/CRU7aEjxrepmCNiqXT0SpFy9CRaAQjw9KwoPpsfZLxDAzV9m8iZEuf SmqvrVabUVoyzXpHXa7QLo7wmSi2dOhle058gyMUctHDc1sxK7yXbaDoN83j8ZWA2M1x GpXHbKTT0mWRuMS3YoqsOg1aQtSlF2zHRF+jpnoAAdNq3n9r+hYsSszKKshSgFLWXTso VtdrxmddLex8z2n5p+BN0WoSYaQJxacA/cjzryUs7soqHpjxyQzys4WFR8DdotKM2xbo Vx2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=s2dcIVFXx5jnrpJ4/sSQHG0PrWpjBXRVzmxvb665HxI=; b=sPv0xeTobl5zxb7n0Cm5szFYxBQ1ZQu+btHbFTFVWHl758pxSOIU+LEkNKj35s6vDd yUIhKPTGYEWGsv2Dt6eXlM8afVYR5VzxiWNiWDys9uOPfJQUJePCLpDHj1R62hbptvqv 6Z3tozHstolEx7ZmuOcXCG/ktn7oKLx1uQkOvrAWUgnoPcFaH3fAGcgFZVuPzL+BwJMf gV2/Sxu5XmnhOoxYeNebe6gRLtG3BLdSdqh30kj6MJD/EqaRe7rzQidm/bDnXbMu+cZz jQVkr5GOlJWc+o5xCernDnI3bAV6yaSx18tCyCrPZifl86pGVVTLVxUK5yAwlsgqbh90 oV1Q== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s15si2231260edw.158.2021.01.07.03.31.56; Thu, 07 Jan 2021 03:32:19 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726754AbhAGL3z (ORCPT + 99 others); Thu, 7 Jan 2021 06:29:55 -0500 Received: from foss.arm.com ([217.140.110.172]:58462 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726151AbhAGL3y (ORCPT ); Thu, 7 Jan 2021 06:29:54 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2EC8D31B; Thu, 7 Jan 2021 03:29:09 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.34.174]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 656C73F719; Thu, 7 Jan 2021 03:29:06 -0800 (PST) Date: Thu, 7 Jan 2021 11:29:03 +0000 From: Mark Rutland To: Maninder Singh Cc: catalin.marinas@arm.com, will@kernel.org, broonie@kernel.org, vincenzo.frascino@arm.com, samitolvanen@google.com, ardb@kernel.org, maz@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, v.narang@samsung.com, a.sahrawat@samsung.com Subject: Re: [PATCH 1/1] arm64/entry.S: check for stack overflow in el1 case only Message-ID: <20210107112903.GB7523@C02TD0UTHF1T.local> References: <1607678131-20347-1-git-send-email-maninder1.s@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1607678131-20347-1-git-send-email-maninder1.s@samsung.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 11, 2020 at 02:45:31PM +0530, Maninder Singh wrote: > current code checks for sp bit flip in all exceptions, > but only el1 exceptions requires this. el0 can not enter > into stack overflow case directly. > > it will improve performance for el0 exceptions and interrupts. > > Signed-off-by: Maninder Singh > Signed-off-by: Vaneet Narang I did consider doing this at the time Ard and I wrote the overflow detection, but there was no measureable impact on the workloads that I tested, and it seemed worthwhile to have this as a sanity check in case the SP was somehow corrupted (and to avoid any surprizing differences between the EL0 and EL1 entry paths). When you say "it will improve performance for el0 exceptions and interrupts", do you have a workload where this has a measureable impact, or was this found by inspection? Unless this is causing a real issue, I'd prefer to leave it as-is for now. Thanks, Mark. > --- > arch/arm64/kernel/entry.S | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > index 2a93fa5..cad8faf 100644 > --- a/arch/arm64/kernel/entry.S > +++ b/arch/arm64/kernel/entry.S > @@ -77,6 +77,7 @@ alternative_else_nop_endif > > sub sp, sp, #S_FRAME_SIZE > #ifdef CONFIG_VMAP_STACK > + .if \el == 1 > /* > * Test whether the SP has overflowed, without corrupting a GPR. > * Task and IRQ stacks are aligned so that SP & (1 << THREAD_SHIFT) > @@ -118,6 +119,7 @@ alternative_else_nop_endif > /* We were already on the overflow stack. Restore sp/x0 and carry on. */ > sub sp, sp, x0 > mrs x0, tpidrro_el0 > + .endif > #endif > b el\()\el\()_\label > .endm > -- > 1.9.1 >