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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8442C4332F for ; Thu, 24 Nov 2022 09:00:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229668AbiKXJAB (ORCPT ); Thu, 24 Nov 2022 04:00:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33656 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229518AbiKXI77 (ORCPT ); Thu, 24 Nov 2022 03:59:59 -0500 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E907EBB9CC for ; Thu, 24 Nov 2022 00:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1669280394; x=1700816394; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=SYMn1xjyNPJRlpfzzjpdSX05OnXmyIiSsLWKetV8rHk=; b=ww/WBPwqFgt66dcjS4xXW8l5B75j7OSpgaDrm0GT8DHwJXcmmpAzc6PW y5k/31TGcSxqDyEbBxkRQIvToWWqNTs72xvsQXG8eC9/C9lIQ6Gd+9jfQ 2dsV+fOfu3UHVAquRfoD7I37QeTRnRRsCztT+SxSBa1qvWYyq34xlhiJk s7g2xv2qrDTigE05Qpf/adZAH5Vj4SWLXELikUG/7oWUAuiKSx/gAIn+i 3R1xZqX1mptJXVMqkUsWk4C8I+Hw1gKfXhHOe3PHsotb1TBRHWQgFreis mWzrbI0Ct8M/GTr7Fg3yVSXD/AGIjm9BNmi833VgwsWAQvVBb5ZrZTjaT w==; X-IronPort-AV: E=Sophos;i="5.96,190,1665471600"; d="scan'208";a="124918613" Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa6.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 24 Nov 2022 01:59:53 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.85.144) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.12; Thu, 24 Nov 2022 01:59:51 -0700 Received: from wendy (10.10.115.15) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.12 via Frontend Transport; Thu, 24 Nov 2022 01:59:50 -0700 Date: Thu, 24 Nov 2022 08:59:32 +0000 From: Conor Dooley To: Deepak Gupta CC: Guo Ren , , , , , Jisheng Zhang Subject: Re: [PATCH] riscv: VMAP_STACK overflow detection thread-safe Message-ID: References: <20221124005006.1788315-1-debug@rivosinc.com> <20221124071022.GA1149630@debug.ba.rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20221124071022.GA1149630@debug.ba.rivosinc.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 23, 2022 at 11:10:22PM -0800, Deepak Gupta wrote: > On Thu, Nov 24, 2022 at 02:31:25PM +0800, Guo Ren wrote: > > On Thu, Nov 24, 2022 at 1:57 PM Deepak Gupta wrote: > > > On Wed, Nov 23, 2022 at 5:28 PM Guo Ren wrote: > > > > On Thu, Nov 24, 2022 at 8:50 AM Deepak Gupta wrote: > > > >> Fixes: 31da94c25aea835ceac00575a9fd206c5a833fed > > > > > > > > The patch gives more significant change than the Fixes, and Fixes would expand to the previous stable versions. Please don't set it as a Fixes, but an improved OVERSTACK dead path performance feature. > > > > > > > > > > Not a performance feature but more like correctness. > > > If kernel died and two CPUs raced to kernel stack overflow, > > > death post-mortem should be straightforward. > > We already have had a fixup, and your patch likes a feature with a > > significant change. > > https://lore.kernel.org/linux-riscv/20221030124517.2370-1-jszhang@kernel.org/ > > If it is for correctness, the simple lock is enough. > > Sure lock is enough. It's different way to solve the problem. But I don't > think it qualifies as significant change. Something to bear in mind is where in the cycle we are - there's likely just over a week left before v6.1. Since the lock is sufficient to fix the problem for v6.1, it's easy to view this patch as an optimisation or improvement that should go on top of that, smaller, patch. Especially when you have some questions yourself about the correctness for 32 bit! I've got no technical comment to make about the discussion here, but looking in from the "outside", that's the easy conclusion to jump to. > REG_S x31, TASK_TI_SPILL_REG(tp) > asm_per_cpu sp, overflow_stack, x31 > li x31, OVERFLOW_STACK_SIZE > add sp, sp, x31 > REG_L x31, TASK_TI_SPILL_REG(tp) btw, for this sort of thing, could you please use some whitespace to align the operands? Makes things significantly more readable. Thanks, Conor.