From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (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 835FA2EB87B for ; Sat, 7 Mar 2026 11:33:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772883181; cv=none; b=rPlbLDaecDdKl49oYUrQZ1ASmHo10DQKGrd1I7fTiLrM9ipNYSIpjr3st4x4H1xwJFoq0SRYjDbqQSbcJRik9KA1leQqZVYcdPysych79c0BHUJeorDmtSFwHytNWgsS3V6vfWm7LvkOla9ULSRYULP5ZsPwIbjxkczpOpBbyic= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772883181; c=relaxed/simple; bh=pcZgj+fY5hUVqaAGjXmS+nnbeC9Szu6RRosTAN8O+vU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=RhkU5IBrSNzwVcA1feGc+M6GVYi6bmRK6luLD3E6YCLAEXIcqFMhidtLzngoCn8v6DcIYrecKOHXYuKy5l7feGiYSZfFx8jq50EUH2KTcZk62Lu3TAwELx9xXjVn4FZtOktIMrvnTIZSpdeV18LnKf3reWgV5VbVTDRxFJvjAbw= 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=Ask8QakT; arc=none smtp.client-ip=209.85.128.41 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="Ask8QakT" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4852f8ac7e9so5118295e9.1 for ; Sat, 07 Mar 2026 03:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772883179; x=1773487979; 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=RInGfNINlpdgd07AvobjW4bmlo1od2szdiC5YGip0Yw=; b=Ask8QakTK9HH4oM6EeT3hZyCrNlxsdoQdodyPRBx4gjwYroL6wFS0Vbski+WFsbuWX 9BK6xEi4xCuKwHAgdU2lXtkCVsDxtsUPwpNOFm/BjAu8eGzFxqzRfSOzNXrD7DYzeHOP uvcjvPbHKIKOmNtMEJXEviacGCBorSXJhRUxyCfBm5m4+vTY6eCjW0UVWPy20SlJuu/W vEpXDabtqL8Kggl3qiuZsfrk5vA78gMRK/a2N3ZEzgl2IGpuFrW7EixL2zDBFfe7kttc xbCzFJh2bqPBMW7gd4wFs26XwSePA/Uw8aHicmHGeMprWlki+TNQ/HrfS+oh4rDaPD38 FLww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772883179; x=1773487979; 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=RInGfNINlpdgd07AvobjW4bmlo1od2szdiC5YGip0Yw=; b=YyR5xrRXqFHwwwj7GvWFuccG2az8O32T0gqzqeB9fgPqOcL7iozzyhzJlfKBPBGaFH czvoQxIVALKT7kN30VyaGZ3z2qdEd1Vc/Y7Yi1eBN6BYedm1/p5btzdAgO/GCZiadb4k Gpu5Rp+zgCzDbaJcxacp+pd6mvNi1xpFyxY7qYUVFlCLDy8h0IOFZq5hRFXFU44lKHGM fcwV8NQ3KyeSzexAtpwYe5RVc06Aa8vgQT6yAe1xBCb0hWrfAi5GlcehV8lkVoOCngao bqhOR/+8c/+zZbXZrb0RDNa00eckodOFGmxc+pVR3ByEI0U6QJZ6kajZhFoC+d0CfNVe SPXA== X-Forwarded-Encrypted: i=1; AJvYcCXbj4f/pNCTqaHhFGMwvz7d2oSKOTEr8B1q27lQlDcy8w8P3eWIo6NDIaKmJ0DNRUWk35QDu4pS22ZmGrE=@vger.kernel.org X-Gm-Message-State: AOJu0YzyKnzvSNysQLjHGG3rit9YcU/cNo8xYZ+DP9y1dmh2OGFnLutq KWEa9x9AAwoxitoVcKelLY80vcHIzVn/ovj/jwhPTZ0ddwltB6ZZUqy1 X-Gm-Gg: ATEYQzwVTXV6YeaJ1tYk5poy04vqhIjB/mkP0ZrFTbNs5Ia8rqQN/hJLTXWa+XI0X7A AVG2dYla9fnEeJnj9/OOEuLCsucy3fBYdl7O+EA6Vb9vpOV+PJpqbCik+JcjzsnX0/UA6sumeME hisgfi/TGsBtiONEmq/ZTO/EdvUSCVQPFnQgYnlBJAHmZU9nl9ixqJroQt7rxUQqlAyCa1I0Ss1 T7E/i4pu5PebHkesUTBUicxJ9l+MhN5tBPZCjY4AbMmAPbGeDBmIJTWkU7qftZKnLnO6fhFe1Hu hldvGHyMKrXTYKA6mbvMqB7SX9uKwQLVZvkF4xlQdn+6WZqFiLiDewrpqozGbp/FVlH6QyeHCrd ZLEItkqxSHYxCfOVHMl/Q5Q5Ibn551pJMFgsFJ2na39PA6xxUZDMR+4G3AYpg9NnKO8H+9Fja8y 9q/joSACXewd26xSdDx5fX5qd1o46KqeqTWgQ1y3jkp6hJxlq4VfZqMHbiFx5NG/Rv X-Received: by 2002:a05:600c:8712:b0:485:2ce2:4c87 with SMTP id 5b1f17b1804b1-4852ce24fddmr43617475e9.4.1772883178585; Sat, 07 Mar 2026 03:32:58 -0800 (PST) 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-4851fae00absm179271915e9.4.2026.03.07.03.32.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 07 Mar 2026 03:32:58 -0800 (PST) Date: Sat, 7 Mar 2026 11:32:57 +0000 From: David Laight To: Linus Torvalds Cc: Waiman Long , Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , linux-kernel@vger.kernel.org, Steven Rostedt , Yafang Shao Subject: Re: [PATCH v3 next 5/5] Avoid writing to node->next in the osq_lock() fast path Message-ID: <20260307113257.2c22f1c7@pumpkin> In-Reply-To: References: <20260306225150.93178-1-david.laight.linux@gmail.com> <20260306225150.93178-6-david.laight.linux@gmail.com> 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 Fri, 6 Mar 2026 16:06:25 -0800 Linus Torvalds wrote: > On Fri, 6 Mar 2026 at 14:52, wrote: > > > > From: David Laight > > > > When osq_lock() returns false or osq_unlock() returns static > > analysis shows that node->next should always be NULL. > > This explanation makes me nervous. > > *What* static analysis? It's very unclear. And the "should be NULL" > doesn't make me get the warm and fuzzies. The analysis was 'my brain' about two years ago :-) > For example, osq_unlock() does do > > node = this_cpu_ptr(&osq_node); > next = xchg(&node->next, NULL); > > so it's clearly NULL after that. But it's not obvious this will be > reached, because osq_unlock() does that > > /* > * Fast path for the uncontended case. > */ > if (atomic_try_cmpxchg_release(&lock->tail, &curr, OSQ_UNLOCKED_VAL)) > return; > > before it actually gets to this point. That is (should be) checking that the list only contains a single node. So the 'next' pointer can't be set. I'll drink 10 double-espressos and read the code again. I'll also check what happens if the code is hit by an ethernet interrupt just after the initial xchg(). Other cpu can also acquire the lock and then get preempted (so need to unlink themselves) as well as the holder trying to release the lock. It might be that the initial xchg needs to be a cmpxchg - which would massively simplify the 'lock' path. It does have the 'no forwards progress' issue. I can't remember whether xchg has to be implemented as cmpxchg on any architectures, if it does then the current complex locking code is unnecessary. David > > And yes, I'm very willing to believe that if we hit that fast-path, > node->next (which is "curr->next" in that path) is indeed NULL, but I > think this commit message really needs to spell it all out. > > No "should be NULL", in other words. I want a rock-solid "node->next > is always NULL because XYZ" explanation, not a wishy-washy "static > analysis says" without spelling it out. > > Linus