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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6FEEC433E0 for ; Wed, 31 Mar 2021 07:13:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B8CB1619E7 for ; Wed, 31 Mar 2021 07:13:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234052AbhCaHM6 (ORCPT ); Wed, 31 Mar 2021 03:12:58 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:39941 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234049AbhCaHMX (ORCPT ); Wed, 31 Mar 2021 03:12:23 -0400 Received: from mail-ot1-f41.google.com ([209.85.210.41]) by mrelayeu.kundenserver.de (mreue011 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MlNYj-1ltOCO0s3R-00lkAd; Wed, 31 Mar 2021 09:12:21 +0200 Received: by mail-ot1-f41.google.com with SMTP id 31-20020a9d00220000b02901b64b9b50b1so18031279ota.9; Wed, 31 Mar 2021 00:12:20 -0700 (PDT) X-Gm-Message-State: AOAM532bQTsnUGyigP0s3eh2YvOR3hUzUGBBUtc+R2nMMlYZyQAdxsdV GAQp7GxTR0iltHiQL5A5FPq35xW3UQgXop3xM+M= X-Google-Smtp-Source: ABdhPJyDDdJN4bOkBUX/6z8TQTYJT7CTrMHBr52q+GIbBO0fps9qLwpUyqCwRyTxF2TfGzWqXN6oPJ/d9KksN2Qfcso= X-Received: by 2002:a9d:758b:: with SMTP id s11mr1622938otk.305.1617174739722; Wed, 31 Mar 2021 00:12:19 -0700 (PDT) MIME-Version: 1.0 References: <1616868399-82848-1-git-send-email-guoren@kernel.org> <1616868399-82848-4-git-send-email-guoren@kernel.org> In-Reply-To: From: Arnd Bergmann Date: Wed, 31 Mar 2021 09:12:05 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 3/4] locking/qspinlock: Add ARCH_USE_QUEUED_SPINLOCKS_XCHG32 To: Guo Ren Cc: Peter Zijlstra , linux-riscv , Linux Kernel Mailing List , linux-csky@vger.kernel.org, linux-arch , Guo Ren , Will Deacon , Ingo Molnar , Waiman Long , Anup Patel , Sebastian Andrzej Siewior Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:2DyaxPUAz+RptwI9Ku7FGAF0b+L3WKMSYl8jBJ7nLVS3NCFt+Y9 epHIOuq46qnputgSXY2FeS4dWcLPByTIhUDdoucYGR55qnhqdGF8KZ4TUp/VHDAqssKTCjs ctlkF0Edf6qfF2IDITbj05lXESoRCSZPpRmdSntuPHXMPyV0bfjm5bEUmWDrwsZRQ/B86hz BJarld8qxKWiI4nfn9GxQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:zY+hQ+YCRp4=:jzbxuh3vaXmenlvenWzG78 MqJiAj/Pzm9HebecbpFAAZRcXo0UNzKcbuOSuHXGycgczQjIplWoC/36afoY6h4DvOgIeaxN7 3hd8BPK5TlUz4pEIVjs+q7y+LUL2vCgdXyUTUK5A83sSCs4A+D+keJ4Cu0Z+f3uQimR+8Fwdw mrf9J3125qbeCUXB2jYIFzBHZ+isc5Eyi+MsyqYG0p0Wv52r2X4nKfVJp24iuzjiCcLExfWjC gH48IH8fjc8NaQEoTBBUUiI/+tEqBmUhUIW5TAUBXJMkQYEO9zwS5+7IdiKEshLIH/eUylBnI BlxQb76AZ2q3pkkxYYXpkIklGymtUEo/HOqkubssgKtIfBjG9IkdwLSTcu4DTiLuuH85tKndL qp/hQaNFL9e5m37HddR3PcQMu5TXqFWKs6JGZDZepc5TvxVJ3fM3sfqjYRzN8I+7rlsHoLlN3 +y9PFwyRyUCfHZ5ZvDzoRrjkBcp8vZEomCwNf9QYVve/M1NOxUI/WL6N4xLsYnXPuBSrXn6UA pBbt3GQytgocHC2+tgHkgIrgb4f2cM8hYTtALYi5duKA6GVKYS3HjeHS5rsKWq+4L1N22asqC QU+dajR66w2zs1lC2yoywaighhIDKL9ab8 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 31, 2021 at 8:44 AM Guo Ren wrote: > On Wed, Mar 31, 2021 at 12:18 PM Guo Ren wrote: > > On Tue, Mar 30, 2021 at 3:12 PM Arnd Bergmann wrote: > > > On Tue, Mar 30, 2021 at 4:26 AM Guo Ren wrote: > > > As I understand, this example must not cause a deadlock on > > > a compliant hardware implementation when the underlying memory > > > has RsrvEventual behavior, but could deadlock in case of > > > RsrvNonEventual > > Thx for the nice explanation: > > - RsrvNonEventual - depends on software fall-back mechanisms, and > > just I'm worried about. > > - RsrvEventual - HW would provide the eventual success guarantee. > In riscv-spec 8.3 Eventual Success of Store-Conditional Instructions > > I found: > "As a consequence of the eventuality guarantee, if some harts in an > execution environment are > executing constrained LR/SC loops, and no other harts or devices in > the execution environment > execute an unconditional store or AMO to that reservation set, then at > least one hart will > eventually exit its constrained LR/SC loop. *** By contrast, if other > harts or devices continue to > write to that reservation set, it ***is not guaranteed*** that any > hart will exit its LR/SC loop.*** " > > Seems RsrvEventual couldn't solve the code's problem I've mentioned. Ok, got it. Arnd