Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp9732529rwp; Thu, 20 Jul 2023 08:58:22 -0700 (PDT) X-Google-Smtp-Source: APBJJlF9eKcx8NwVuSykK3xJwfCpN8DKtK0yz7EEN83YfPiByS7E7sWVxkXwD8apnPmqTZc6wdCI X-Received: by 2002:a17:90a:aa04:b0:263:f776:8ba3 with SMTP id k4-20020a17090aaa0400b00263f7768ba3mr2265463pjq.9.1689868702280; Thu, 20 Jul 2023 08:58:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689868702; cv=none; d=google.com; s=arc-20160816; b=H5gOlwdY2olwmvpiGJZb2WhFZMCTQu2/GW8UzZo6+GtEB0AWrYRkcZeST80O+ob/hQ LmLo4OqCgZhAC0VzJwdiPb+YknEPJ/XCm+buimiG6bsBShXLrCSO+C8UYT+wkSYaEjkP Mpf8oo71gl7MZ1NMiBq5gQvRJgKb5EMlxMA6qY6K4IrzXhhp8+e3JZYLtG9KARTh3X2k /w06KHyIJE+Q9HSJJ9hcFMDPFTK+3UGVpcihiktx4RWSPuaYOIyn4k/oEoTuELNXghqn 3ajK0QNlqmQXcJs8GC3CF2qYYLPqFTPfSdorMiaihEqIliGEemtFtDx31375fpCZlvje n+oA== 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=NwVY/LiiggaGme0jWI+ZcS1i0Dbn9MG9/E1CJbQ8P08=; fh=0/diyN8lkaWv8O83jdtQkqh+yhWRMLbYOO1HdxXjMMY=; b=aynRTsM/FQXHpwLH8WDuXGDPMYm7UjUqJ44sQy9JTdizEAfPqvHHAQr2ZFD3cf5z3G U6K/aBjvLcTsH7ueNXH+Ly+xxE3/8PMGbHvuOU8jzmeReAQqiYqEjx0GAgjGNQHIf7Zz zFrydjUy9IDz2R4olRsRoIVlyz3mzA2NuShOsRTqxJQ+rvr24zNuF1lk5xVMAE0yAk4Q dMVXOChQzU5447jT8iemjlTF9H48crXC3xOnH2dvegnhVLcNuGPHd8X9fLQnmEviPC6z xlwfnr6M6ZHFvnzVX0/zGpUXHPB9XmnfJe+IuJQ3rQQ54uHQ6zz8wcagenFgHbXtSOo2 im/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=XzXvymy8; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lr12-20020a17090b4b8c00b0026404467b7dsi4050297pjb.110.2023.07.20.08.58.10; Thu, 20 Jul 2023 08:58:22 -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=@kernel.org header.s=k20201202 header.b=XzXvymy8; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232416AbjGTPGa (ORCPT + 99 others); Thu, 20 Jul 2023 11:06:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232390AbjGTPGa (ORCPT ); Thu, 20 Jul 2023 11:06:30 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A452426BB for ; Thu, 20 Jul 2023 08:06:27 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 21CC761B23 for ; Thu, 20 Jul 2023 15:06:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F9ABC433C9 for ; Thu, 20 Jul 2023 15:06:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689865586; bh=NwVY/LiiggaGme0jWI+ZcS1i0Dbn9MG9/E1CJbQ8P08=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=XzXvymy8m9SUHmSMziFhB91k8ukfkATqIdIigv9ENMpUo004JPU243e87dnxwLERL pnjAjbKW0vp3xAjIQTsp/A4HDEvdHcz0rmYup8Zb2if7yeJvj+V+2T73/o8fp7PfFT SFvtAgZjDlFp+kSvr2k/zoAQc0kV7pU3uRs6naTN5oiO0o2xF4q/G/PYlP6VVDhExH auHKCAL5fQDRgy9tSoTBNglXldzOVi6/qNHln2m3HpSnyCWUBDZwuUTI0LaaYdI/zv u/12td66yghWaM4ePFsniXExQ4q7yCyQqaSEoOzFev0QNw37rirWIduq7dv/M8O94P nO4mmze9tv/IA== Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-4fb96e2b573so1397652e87.3 for ; Thu, 20 Jul 2023 08:06:26 -0700 (PDT) X-Gm-Message-State: ABy/qLY2CmEM3DADUX4ur2YCbN+31nfG/b6dyJQKEKfvCT3c2c+kx5Qw 8fujxp4qBSRdm/ORizgd+Y0Aw+Kzu+2+ZCyYNeM= X-Received: by 2002:a05:6512:2525:b0:4f8:58ae:8ea8 with SMTP id be37-20020a056512252500b004f858ae8ea8mr2845132lfb.58.1689865584515; Thu, 20 Jul 2023 08:06:24 -0700 (PDT) MIME-Version: 1.0 References: <20221124094845.1907443-1-debug@rivosinc.com> <20230720001852.GA572618@google.com> In-Reply-To: <20230720001852.GA572618@google.com> From: Guo Ren Date: Thu, 20 Jul 2023 23:06:12 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] riscv: VMAP_STACK overflow detection thread-safe To: Sami Tolvanen Cc: Deepak Gupta , palmer@dabbelt.com, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Jisheng Zhang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, 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 On Thu, Jul 20, 2023 at 8:19=E2=80=AFAM Sami Tolvanen wrote: > > Hi Deepak, > > On Thu, Nov 24, 2022 at 01:48:45AM -0800, Deepak Gupta wrote: > > commit 31da94c25aea ("riscv: add VMAP_STACK overflow detection") added > > support for CONFIG_VMAP_STACK. If overflow is detected, CPU switches to > > `shadow_stack` temporarily before switching finally to per-cpu > > `overflow_stack`. > > > > If two CPUs/harts are racing and end up in over flowing kernel stack, o= ne > > or both will end up corrupting each other state because `shadow_stack` = is > > not per-cpu. This patch optimizes per-cpu overflow stack switch by > > directly picking per-cpu `overflow_stack` and gets rid of `shadow_stack= `. > > Are you planning on resending this patch? I see it didn't gain much > traction last time, but this looks like a much cleaner solution for > selecting the overflow stack than having a `shadow_stack` and calling > to C to compute the per-CPU offset. The asm_per_cpu macro also would > come in handy when implementing CONFIG_SHADOW_CALL_STACK, which we'd > like to have on RISC-V too. I remember we ended up with an atomic lock mechanism instead of percpu offset, so what's the benefit of percpu style in overflow_stack path? > > Sami --=20 Best Regards Guo Ren