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 2D6B6C433FE for ; Fri, 21 Oct 2022 15:18:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230263AbiJUPSD (ORCPT ); Fri, 21 Oct 2022 11:18:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49410 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230041AbiJUPSB (ORCPT ); Fri, 21 Oct 2022 11:18:01 -0400 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED5EA23E94 for ; Fri, 21 Oct 2022 08:17:59 -0700 (PDT) Received: from dggemv711-chm.china.huawei.com (unknown [172.30.72.56]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Mv7Lr1JgvzJn3N; Fri, 21 Oct 2022 23:15:16 +0800 (CST) Received: from kwepemm600017.china.huawei.com (7.193.23.234) by dggemv711-chm.china.huawei.com (10.1.198.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 21 Oct 2022 23:17:54 +0800 Received: from [10.174.179.234] (10.174.179.234) by kwepemm600017.china.huawei.com (7.193.23.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 21 Oct 2022 23:17:53 +0800 Message-ID: <41608bda-3c20-060e-a9b4-afa2fe615b41@huawei.com> Date: Fri, 21 Oct 2022 23:17:52 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH] riscv: fix race when vmap stack overflow To: Guo Ren CC: Andrea Parri , Jisheng Zhang , Paul Walmsley , Palmer Dabbelt , Albert Ou , , References: <20221019154727.2395-1-jszhang@kernel.org> From: Tong Tiangen In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.234] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemm600017.china.huawei.com (7.193.23.234) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2022/10/21 22:41, Guo Ren 写道: > On Fri, Oct 21, 2022 at 9:46 PM Tong Tiangen wrote: >> >> >> >> 在 2022/10/21 21:22, Andrea Parri 写道: >>> Hi Tong, >>> >>>>>> I use atomic_set_release here, because I need earlier memory >>>>>> operations finished to make sure the sp is ready then set the spin >>>>>> flag. >>> >>>> Consider this implementation:) >>>> >>>> smp_store_mb(&spin_shadow_stack, 0); >>> >>> smp_store_mb() has "WRITE_ONCE(); smp_mb()" semantics; so it doesn't >>> guarantee that the store to spin_shadow_stack is ordered after program >>> -order earlier memory accesses. >>> >>> Andrea >>> . >> >> Hi Andrea: >> >> IIUC, the earlier memory access amoswap.aqrl, here .aqrl guarantee it. >> But anyway, consider we don't care about performance here, using >> smp_store_release()(add barrier()) surely right. > We use smp_store_release() is for: > //load per-cpu overflow stack > REG_L sp, -8(sp) Oh, missing that, you're right. This guarantee the spin flag is set after the sp is used. > > Not amoswap. > > Actually, amoswap.aqrl guarantees nothing because all instructions > depend on the sp register. right. Thanks, Tong. > >> >> Thanks, >> Tong. > > >