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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 6565EC433DB for ; Tue, 30 Mar 2021 22:36:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 33266619D2 for ; Tue, 30 Mar 2021 22:36:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232965AbhC3Wfw (ORCPT ); Tue, 30 Mar 2021 18:35:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232985AbhC3WfS (ORCPT ); Tue, 30 Mar 2021 18:35:18 -0400 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D8C0C061574; Tue, 30 Mar 2021 15:35:18 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id w8so8487932pjf.4; Tue, 30 Mar 2021 15:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=MIKmUtb8xO+Dq6yKmOyCR/vq4cKBspfYEllac90t9ag=; b=u7XY8xoVgbo8DgwHawUEw/3qA/7IKbnKlWt2hjLE7MtthU8JObswEgN2cDtIX89igu UFK/ZOQwBENrZIH3xfFYVhXUCz4yRASvQOOaLFjaxHjXZJ2Twn/zgR0DDpGv/pG6w5M7 slD9Sc9vt5A1uiHNm64YralGtKOZ9mgov1MEdGTdmo58K+i/OudXj5gpQa0wXILTk5gp 8NIXyPBtIhKuIJj4zDqsqMNBjSWys1s0jknABPSDMKoPnKFPLjzZ6Ak1TpIlgcC+nCdw nCKwHJ8Xa8vTgufrtKp3xnHcO0IIxI5f2uDnJVhIpIvzfDOwv+v4prtROYXsoCZbXaCl H/GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=MIKmUtb8xO+Dq6yKmOyCR/vq4cKBspfYEllac90t9ag=; b=BA2iEaGuJHYvhpw8BAW4EzdC21R19+WZDXJ3veT8pjYg/dJ15iRddeeLCv5m0Fca/L dQhg6ACGDNYYNy1mTmuB99pYUPZFmH9WLmLejzDIcfon4FdmHAz67BAVHT5C/KB6UoIm TbEJeBMsKA0t2Uh1ltW1x0+yY3//4fasnTENgKt7mova3l9SyeBxzvnhCNhPR+jGRbZi 5OsrZvAwzymLFSP7PRI21fSlSA23bAIDjEy6aXBlajWhqpH2rSbKIulktnycbKIFyio0 xG0TIJKQ+CMQqLqdqxlKMqxqE24WySfaCWzmTiPfx3ysTtFomYCsgFRY4aG3ZiyU6jS9 q+2g== X-Gm-Message-State: AOAM5325bJ5BmL2IdVbe/mhPWNzFO5ocob7ZBheoThuvmd8GJJVeHZFV jtqFkgKGrnxrTwq/w2BDZ/8= X-Google-Smtp-Source: ABdhPJxqxS2YDuahl9PNg4VAillcg0SzefNJodUtgbgZj+qPO8g6vAlXW4UHUCHopV7NROqeoTUwOw== X-Received: by 2002:a17:90a:c902:: with SMTP id v2mr511004pjt.144.1617143717745; Tue, 30 Mar 2021 15:35:17 -0700 (PDT) Received: from localhost (g139.124-45-193.ppp.wakwak.ne.jp. [124.45.193.139]) by smtp.gmail.com with ESMTPSA id w5sm218189pge.55.2021.03.30.15.35.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Mar 2021 15:35:16 -0700 (PDT) Date: Wed, 31 Mar 2021 07:35:14 +0900 From: Stafford Horne To: Peter Zijlstra Cc: Guo Ren , linux-riscv , Linux Kernel Mailing List , linux-csky@vger.kernel.org, linux-arch , Guo Ren , Will Deacon , Ingo Molnar , Waiman Long , Arnd Bergmann , Anup Patel Subject: Re: [PATCH v4 3/4] locking/qspinlock: Add ARCH_USE_QUEUED_SPINLOCKS_XCHG32 Message-ID: <20210330223514.GE1171117@lianli.shorne-pla.net> References: <1616868399-82848-1-git-send-email-guoren@kernel.org> <1616868399-82848-4-git-send-email-guoren@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-csky@vger.kernel.org On Tue, Mar 30, 2021 at 06:08:40PM +0200, Peter Zijlstra wrote: > On Tue, Mar 30, 2021 at 11:13:55AM +0800, Guo Ren wrote: > > On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote: > > > > > > On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote: > > > > u32 a = 0x55aa66bb; > > > > u16 *ptr = &a; > > > > > > > > CPU0 CPU1 > > > > ========= ========= > > > > xchg16(ptr, new) while(1) > > > > WRITE_ONCE(*(ptr + 1), x); > > > > > > > > When we use lr.w/sc.w implement xchg16, it'll cause CPU0 deadlock. > > > > > > Then I think your LL/SC is broken. > > > > > > That also means you really don't want to build super complex locking > > > primitives on top, because that live-lock will percolate through. > > > Do you mean the below implementation has live-lock risk? > > +static __always_inline u32 xchg_tail(struct qspinlock *lock, u32 tail) > > +{ > > + u32 old, new, val = atomic_read(&lock->val); > > + > > + for (;;) { > > + new = (val & _Q_LOCKED_PENDING_MASK) | tail; > > + old = atomic_cmpxchg(&lock->val, val, new); > > + if (old == val) > > + break; > > + > > + val = old; > > + } > > + return old; > > +} > > That entirely depends on the architecture (and cmpxchg() impementation). > > There are a number of cases: > > * architecture has cmpxchg() instruction (x86, s390, sparc, etc.). > > - architecture provides fwd progress (x86) > - architecture requires backoff for progress (sparc) > > * architecture does not have cmpxchg, and implements it using LL/SC. > > and here things get *really* interesting, because while an > architecture can have LL/SC fwd progress, that does not translate into > cmpxchg() also having the same guarantees and all bets are off. > > The real bummer is that C can do cmpxchg(), but there is no way it can > do LL/SC. And even if we'd teach C how to do LL/SC, it couldn't be > generic because architectures lacking it can't emulate it using > cmpxchg() (there's a fun class of bugs there). > > So while the above code might be the best we can do in generic code, > it's really up to the architecture to make it work. I just want to chime in here, there may be a better spot in the thread to mention this but, for OpenRISC I did implement some generic 8/16-bit xchg code which I have on my todo list somwhere to replace the other generic implementations like that in mips. arch/openrisc/include/asm/cmpxchg.h The idea would be that architectures just implement these methods: long cmpxchg_u32(*ptr,old,new) long xchg_u32(*ptr,val) Then the rest of the generic header would implement cmpxchg. -Stafford