From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8913048C411 for ; Mon, 18 May 2026 14:29:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779114570; cv=none; b=JKH75GL/ilFTiEYEqt5z1FUm2KpBRIjVec/wtXJ5rU3A0rE7TpDftAbqBAZ6MNnuHQYQTT1PpQmjqrE2AcqoFqZNCucsizlz/us/wGVq42K64Z+zA54cbjqPdK6g6eioomcNv4TTESgGIyUusvB+gnChVffmzlWCvnvnwq4khdE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779114570; c=relaxed/simple; bh=7Uhpn95yDC6KTKBv3qxF7H5D7qOLmJxFlbYjUKcU7Rk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=BvMWGuvYZwrkUU+jxvXnkP14NCNQxxuLCjdxzZWu/PTS4BkfiDlixXnQfVpfZmZoYeGNl91NpMEqA8+5xb72ZH2dGnWgyS6x42Z/JIUjizY6DEbhvRYx/B2TLy04f3ctnNm5X3NqixY7JSYQ5Bk098Xe/coHTaEO9/ZnocMoPsI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=U/zhsp6C; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="U/zhsp6C" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-488af96f6b2so26435885e9.0 for ; Mon, 18 May 2026 07:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779114567; x=1779719367; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=nPQhIRrtPmCd7P8eK12osZS+TcFkrQkvKu8aRyvHkn8=; b=U/zhsp6CLQLX3Rit+FiyerJxou4ZZDnIGRMKFDUd90XpVOjgARdJ0nK4dzl+6kXTKS NHLoD5DsqdZcr12yN2lrMc2TpB4AfFn3cl8Z43Ov2bsRrzu1rUy+Vjmvvj93R4v8nKag y6QjpzVM159f6frscn8P9lH/0iVaLAOAHLAQKwcX+At2/BVmB3R17FVW0DqMcSKI/9IV lRNRTncGkFYvDzEOsEdxySxsgp6Vpb/pJ1AySIrc50rD9Hca3AyAMZT8dd4zZGtuH45/ rNbQT9ApNYhWmyKDI90DzxAELxlyEYaamKp57Ff0ApprkNeMYAMfUVfZU+WWfqkLxO8k 5Q/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779114567; x=1779719367; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=nPQhIRrtPmCd7P8eK12osZS+TcFkrQkvKu8aRyvHkn8=; b=OucT4GG/zLDNYmkFvDWUrLWaDTxN8MF3hPoKimRPVLFkpuEVNxiGxRUtECksWzwuU5 kw/2cz7PhNbSy0JmpIiMxvrHf/lnVGubhs0ircSGaHCZQkaSmLAA1bg54UXqZkupOORI uiRw4Jce6IST1zmnDzps0jXoJKpoW0PS9ks5IR84XGJoZ4Gq2ETdfvpkPF6XzLsSwMPA o2OosTPS5lg5RSvRseKZ0W5Z/ABbIGgjsvX3aEpX1LxQHzh6K/2MRknyQmlxGksiQVVF 0mwcbQ53xBcgmm5QC6mMisvnq6CKVa1zt8R0bFgINTal7Sv+2w2Q+H3nCM0tPZgXAo2O bc4A== X-Forwarded-Encrypted: i=1; AFNElJ/1TwldpDWfx5FMVLf7No3/9RMTBKp4RR6fOVx79i4Ej3/GSfvf9UErMSbutZQZtKN10syDhMN2VwGxPnU=@vger.kernel.org X-Gm-Message-State: AOJu0YxrcAjDeSUvLP2mk+a4PrQk8ezzd4hxWKA8PZg4at5c1M6u2tdI f7V7bjmNSeDUMzTf1GntvlG6ET9GG/N4AalEVBhNVuf+4VXsahfPhjHf X-Gm-Gg: Acq92OGWMTV7dItawwQpFGmV7OgNmGzZb7h0EX3NA5F34NSe9KWan+eeDC/UODPEBBX VRyZiAbbKt46G0Pa2Tf2x3AMWejzLoTmKao/bZQ1PvgngSlj1iWq4norvLzqClL2PPh44VQ1O9b 2kfP1B/8YyRPyZFxNwef+h8ZHJ+EsYtLhALE0VH342UXoZ3vgkIGHdyo44qDt6clLime2MQ7IEK 662cmDUlJAVFj7fg5iZk4+M+blz7U6DuOpXZIwwVqYA4vNxkJq6KcopYTZkVxXBsY8FJ0IX64uc W1S1GmUoW97Uga8kh5Vmyqa89liFOf7sUtKKR+duTnybCS2kFjEHwpK6X34jdsVZVQGxx4d2qof VWyn34FxbDua5NlI3b47SRXYM7Dz3NXo4eEkRKWSg06Nt5dgOCkadHeL7i/Can9ktwtK7mShR9W pNLruNdhd39gnLeB0IkJfqOnZzQNkrmF7sjCQRLSd3KqVAIpNSHtJQOXc1rz5D1TznkVemrIPSf Pc= X-Received: by 2002:a05:600c:4e46:b0:488:bc6a:528d with SMTP id 5b1f17b1804b1-48fe632243cmr252023375e9.22.1779114566837; Mon, 18 May 2026 07:29:26 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48febe79ce3sm86382405e9.31.2026.05.18.07.29.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 07:29:26 -0700 (PDT) Date: Mon, 18 May 2026 15:29:25 +0100 From: David Laight To: Will Deacon Cc: Yu Peng , Peter Zijlstra , Ingo Molnar , Boqun Feng , Waiman Long , linux-kernel@vger.kernel.org Subject: Re: [PATCH] locking/osq_lock: Use READ_ONCE() for node->prev Message-ID: <20260518152925.10ab8fab@pumpkin> In-Reply-To: References: <20260330013255.25937-1-pengyu@kylinos.cn> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 18 May 2026 11:29:53 +0100 Will Deacon wrote: > On Mon, Mar 30, 2026 at 09:32:55AM +0800, Yu Peng wrote: > > osq_lock() consults node->prev in the vcpu_is_preempted() heuristic while > > a concurrent predecessor may update it via WRITE_ONCE(next->prev, prev) > > during unqueue. > > > > This read only affects the decision to abort optimistic spinning; stale > > values do not affect queue linkage or lock correctness. Use READ_ONCE() > > to mark the shared read and match the concurrent WRITE_ONCE() update. > > > > No functional change intended. > > > > Signed-off-by: Yu Peng > > --- > > kernel/locking/osq_lock.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c > > index b4233dc2c2b04..db4545e7bb72c 100644 > > --- a/kernel/locking/osq_lock.c > > +++ b/kernel/locking/osq_lock.c > > @@ -144,7 +144,7 @@ bool osq_lock(struct optimistic_spin_queue *lock) > > * polling, be careful. > > */ > > if (smp_cond_load_relaxed(&node->locked, VAL || need_resched() || > > - vcpu_is_preempted(node_cpu(node->prev)))) > > + vcpu_is_preempted(node_cpu(READ_ONCE(node->prev))))) > > return true; > > Hmm, I wonder whether this is actually sufficient... > > Architectures with relaxed memory models won't order plain reads to > different addresses, so the read of 'node->locked' is unordered wrt the > read of 'node->prev' in this condition. Given that we're using > smp_cond_load_relaxed(), can we end up using a value of 'node->prev' > that was loaded in a previous iteration of the loop? > > I'd be much more comfortable if this was smp_cond_load_acquire(), in > addition to the READ_ONCE() that you are proposing. I've got a patch 'pending' for this file that tidied some things up. In particular it saves the cpu numbers not the per-cpu addresses. So the above check doesn't bounce a cache line. Perhaps it is time to resend it. Note that the vpu_is_preempted() path is horribly expensive and can't actually work reliably. And can't work at all on arm where 'mwait' (equivalent) is used. -- David > > Will >