From nobody Sun Dec 14 12:14:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5B68C215065; Fri, 18 Apr 2025 17:30:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744997403; cv=none; b=hxBvqv1SFDANwV1StzUdV8dwdwgM2AobluXW326V/d3CrafGCEokoz1Sx19LVac3A0PO0t4AC3Ueni5+pX5JLyZ2eMLGK1E927QjRrI0FLB5SL75dLHodYnP5WqG/r0f1HemEzJBVy3TwNpBjbwIINsPiVxa/ChlbriP4yDVXP8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744997403; c=relaxed/simple; bh=IjhDfmevSmYVsiWymcxWZN+vN/2vH0mMRUw1OxtDFe8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=kPGeJ57OG9kBcM+KzPd7PNHaQXTDN/Bsuj75yZQg2ffC9A/NntpzvrUGihC+jWdVPhdhBUaufTRFoflH41vrp9SFbyAo/67QcbiWwPpgXosYIqIGOstedrkEibU3ELsKSsXIJUOFmumCI0R9ik9NlLvXQk+Omqr1QnswL/G8Ubk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=buJY8eO3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="buJY8eO3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D160BC4CEEA; Fri, 18 Apr 2025 17:30:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744997402; bh=IjhDfmevSmYVsiWymcxWZN+vN/2vH0mMRUw1OxtDFe8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=buJY8eO3wX3i2ol/qlUB/JyrMlnGFYFIRxMf59woDvHHIgBjhYEbzmVXmhTbmyH9P e8Tp8yQ/XfBUdBxAzwlQdytxuuAA1RZj2PAm4vmVyhXPsllP0/PPQUR0ar8Hp7cU5O QWa0PW8H8dpdhhcsbJXEhPM+14f5wvMcdZMPXALmJDX2JnEYH6U+q7FA8ntd2++F81 RqT9zD9gG8ogaFk2+7a62iJ65EUIfIkjTV3OfwWKt7Srr0trk7QqRPocpjFwDmYhaF k2JTg51yAbKx+OtNNxqp94kZUdbwWJcvQ/jfJapak9GK3ewlEb+IYAtW5c4caVPFFh nAoXkm+SthokA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 788CCCE077B; Fri, 18 Apr 2025 10:30:02 -0700 (PDT) From: "Paul E. McKenney" To: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, lkmm@lists.linux.dev, kernel-team@meta.com, mingo@kernel.org Cc: stern@rowland.harvard.edu, parri.andrea@gmail.com, will@kernel.org, peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, akiyks@gmail.com, "Paul E . McKenney" Subject: [PATCH 1/4] tools/memory-model: docs/README: Update introduction of locking.txt Date: Fri, 18 Apr 2025 10:29:57 -0700 Message-Id: <20250418173000.1188561-1-paulmck@kernel.org> X-Mailer: git-send-email 2.40.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Akira Yokosawa Commit 9bc931e9e161 ("tools/memory-model: Add locking.txt and glossary.txt to README") failed to mention the relation of the "Locking" section in recipes.txt and locking.txt. The latter is a detailed version of the former intended to be read on its own. Reword the description in README and add notes in locking.txt and recipes.txt to clarify their relationship. [ paulmck: Wordsmithing. ] Signed-off-by: Akira Yokosawa Signed-off-by: Paul E. McKenney Acked-by: Andrea Parri --- tools/memory-model/Documentation/README | 7 +++++-- tools/memory-model/Documentation/locking.txt | 5 +++++ tools/memory-model/Documentation/recipes.txt | 4 ++++ 3 files changed, 14 insertions(+), 2 deletions(-) diff --git a/tools/memory-model/Documentation/README b/tools/memory-model/D= ocumentation/README index 9999c1effdb65..88870b0bceea8 100644 --- a/tools/memory-model/Documentation/README +++ b/tools/memory-model/Documentation/README @@ -23,8 +23,11 @@ o You are familiar with the Linux-kernel concurrency pri= mitives that you need, and just want to get started with LKMM litmus tests: litmus-tests.txt =20 -o You would like to access lock-protected shared variables without - having their corresponding locks held: locking.txt +o You need to locklessly access shared variables that are otherwise + protected by a lock: locking.txt + + This locking.txt file expands on the "Locking" section in + recipes.txt, but is self-contained. =20 o You are familiar with Linux-kernel concurrency, and would like a detailed intuitive understanding of LKMM, including diff --git a/tools/memory-model/Documentation/locking.txt b/tools/memory-mo= del/Documentation/locking.txt index 65c898c64a93a..d6dc3cc34ab65 100644 --- a/tools/memory-model/Documentation/locking.txt +++ b/tools/memory-model/Documentation/locking.txt @@ -1,3 +1,8 @@ +[!] Note: + This file expands on the "Locking" section of recipes.txt, + focusing on locklessly accessing shared variables that are + otherwise protected by a lock. + Locking =3D=3D=3D=3D=3D=3D=3D =20 diff --git a/tools/memory-model/Documentation/recipes.txt b/tools/memory-mo= del/Documentation/recipes.txt index 03f58b11c2525..52115ee5f3939 100644 --- a/tools/memory-model/Documentation/recipes.txt +++ b/tools/memory-model/Documentation/recipes.txt @@ -61,6 +61,10 @@ usual) some things to be careful of: Locking ------- =20 +[!] Note: + locking.txt expands on this section, providing more detail on + locklessly accessing lock-protected shared variables. + Locking is well-known and straightforward, at least if you don't think about it too hard. And the basic rule is indeed quite simple: Any CPU that has acquired a given lock sees any changes previously seen or made by any --=20 2.40.1 From nobody Sun Dec 14 12:14:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0CC6621ADC5; Fri, 18 Apr 2025 17:30:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744997403; cv=none; b=T9pSVVA6YxgfrIxJI/oiiwhBdsELX6ynQOkDdWqCbC39GajqfAyb8S2skXp9/Z88qSOKQiZMb+A6IOp4O6SQWVFhxxYKxpY9hbyV7MszrvgbHgKsYFdoMQfLdDVGh9Uj74BESPDDq3i7h1o2Ubo6Ybvr5nOL27gg5lvm6ZjPwN8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744997403; c=relaxed/simple; bh=jigIBvyZJZT7zaW2SNgxWJiDXAQDl7mSnIDxYmHZA6k=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=DHNS0MJThq3PwVDbdSryhqCFzXd1hSp/E6yiZTzsca0W5q9swRrAZW6uZZwIDtNGSlaJY3NoCISoEjcKNh52BfzxIEkY7tQuHGozyFBTQnxDzEk1mBD59J8lYEXT1Fb+N1bbBg1vSZXs7uK8Cy2U/W/C1eUJ8WVE4P3RQ4fOwnc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LCoCSXiI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LCoCSXiI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD32AC4CEE2; Fri, 18 Apr 2025 17:30:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744997402; bh=jigIBvyZJZT7zaW2SNgxWJiDXAQDl7mSnIDxYmHZA6k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LCoCSXiIZY152OyQPerSLbLIL3sylyrp+Km0lpSWSJ330dfyi8f9JR+fT8Hz2bkLQ eARU7FubXB1nHO6NUwHHxs+oDC2rCzt41QnoaJTXBf0pU/w+wLoKEy81O7rsCVTWrc JLJms4b7NdQJBTBHJ5ry7BClb5eeXMDOzpPkilcfgN6eMBUzSlY3n3N92cSUmQsf3U +r8tO9d0OSQ0go65NvsyCW3ON8SRz02VsWOsfzmn9RzKCwkOZTEBqifuyGuuGnyBCp mg6C3LJbv/jDYz8fyCF5blYTPzn30kemZYxNJo7HHbHiNqhJmSepUXq//9uL90DtCO aB9BUICqiKEOQ== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 7C4FCCE09FA; Fri, 18 Apr 2025 10:30:02 -0700 (PDT) From: "Paul E. McKenney" To: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, lkmm@lists.linux.dev, kernel-team@meta.com, mingo@kernel.org Cc: stern@rowland.harvard.edu, parri.andrea@gmail.com, will@kernel.org, peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, akiyks@gmail.com, "Paul E . McKenney" Subject: [PATCH 2/4] tools/memory-model: docs/simple.txt: Fix trivial typos Date: Fri, 18 Apr 2025 10:29:58 -0700 Message-Id: <20250418173000.1188561-2-paulmck@kernel.org> X-Mailer: git-send-email 2.40.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Akira Yokosawa Signed-off-by: Akira Yokosawa Signed-off-by: Paul E. McKenney Acked-by: Andrea Parri --- tools/memory-model/Documentation/simple.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/memory-model/Documentation/simple.txt b/tools/memory-mod= el/Documentation/simple.txt index 21f06c1d1b70d..2df148630cdcd 100644 --- a/tools/memory-model/Documentation/simple.txt +++ b/tools/memory-model/Documentation/simple.txt @@ -134,7 +134,7 @@ Packaged primitives: Sequence locking Lockless programming is considered by many to be more difficult than lock-based programming, but there are a few lockless design patterns that have been built out into an API. One of these APIs is sequence locking. -Although this APIs can be used in extremely complex ways, there are simple +Although this API can be used in extremely complex ways, there are simple and effective ways of using it that avoid the need to pay attention to memory ordering. =20 @@ -205,7 +205,7 @@ If you want to keep things simple, use the initializati= on and read-out operations from the previous section only when there are no racing accesses. Otherwise, use only fully ordered operations when accessing or modifying the variable. This approach guarantees that code prior -to a given access to that variable will be seen by all CPUs has having +to a given access to that variable will be seen by all CPUs as having happened before any code following any later access to that same variable. =20 Please note that per-CPU functions are not atomic operations and --=20 2.40.1 From nobody Sun Dec 14 12:14:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5B6EA21B180; Fri, 18 Apr 2025 17:30:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744997403; cv=none; b=lR4dY2duVzBvRMx5V9gpN6C7ksTbZW8IjVOK3mmTTGoDy2OeGaGKtUJlsfxS78IP0Kc9BzS9DQQSQG2mnAh1f5znx4kmU1V1pzdwY5+7zTgJYwZZL0SFa1namKxm0jJJeyxhC9a1p3zZAmvA8ucjoL9Yu3WUlen2tCUqERmqjM8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744997403; c=relaxed/simple; bh=bIGvjbRKpxLkpSw3c++ottiUztM75QDoZdCAB6uB9i8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=DUuxELmt5bYgS1ttefd74T8SklUTBMeLC0ZUbGI0yrpZ0wC2oa3PIGDK0nwqi2XHfshH//z01UTtr9CR0nVNc/ePw5iG7TNvLRHxgdPoofPb7S6iysC+Vu0MahTxh/J2tphrT0aHwfZ6q2LDzGSRdXyI2eyE54p3idKD6qh3C3M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=foD5UtHq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="foD5UtHq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3F03C4CEEC; Fri, 18 Apr 2025 17:30:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744997403; bh=bIGvjbRKpxLkpSw3c++ottiUztM75QDoZdCAB6uB9i8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=foD5UtHqiV5A2pVbJk5KS7xtU/2/x8DE7A9FMhmVD2r8G2TPBvXCb2Ex7JZr6dSH6 Evq6FXmN3J2lXzEPiP1suWDKqCIXoR2XX2XQYwUTw4WxbOrAQ4QfHppYFqM0g3xBn/ TLESZChSKlHLhZEeY8/SqNn+p67ZzxWLcIa+7pqmzGjtmcnmKNohZ9N94tRzGNfW2E R9tTq34EmiL1pwPiE1GoMjwYTpAUkT8rI4PfAOMCOj2PUrhPrAhhaso8rlkrwMZkZX LA+CxkrFPjDPt2SliHtO0p6CXMRcLrERPMCcb9zUWEePJVXfkWn3Ni4tiQEXU0Dd+n MvXJiEAlvKrVA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 7FA13CE0A6C; Fri, 18 Apr 2025 10:30:02 -0700 (PDT) From: "Paul E. McKenney" To: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, lkmm@lists.linux.dev, kernel-team@meta.com, mingo@kernel.org Cc: stern@rowland.harvard.edu, parri.andrea@gmail.com, will@kernel.org, peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, akiyks@gmail.com, "Paul E . McKenney" Subject: [PATCH 3/4] tools/memory-model: docs/ordering: Fix trivial typos Date: Fri, 18 Apr 2025 10:29:59 -0700 Message-Id: <20250418173000.1188561-3-paulmck@kernel.org> X-Mailer: git-send-email 2.40.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Akira Yokosawa Fix trivial typos including: - Repeated "a call to" - Inconsistent forms of referencing functions of rcu_dereference() and rcu_assign_pointer() - Past tense used in describing normal behavior and other minor ones. [ paulmck: Wordsmith plus recent LWN RCU API URL. ] Signed-off-by: Akira Yokosawa Signed-off-by: Paul E. McKenney Acked-by: Andrea Parri --- tools/memory-model/Documentation/ordering.txt | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/tools/memory-model/Documentation/ordering.txt b/tools/memory-m= odel/Documentation/ordering.txt index 9b0949d3f5ec2..7ab3744929d87 100644 --- a/tools/memory-model/Documentation/ordering.txt +++ b/tools/memory-model/Documentation/ordering.txt @@ -223,7 +223,7 @@ The Linux kernel's compiler barrier is barrier(). This= primitive prohibits compiler code-motion optimizations that might move memory references across the point in the code containing the barrier(), but does not constrain hardware memory ordering. For example, this can be -used to prevent to compiler from moving code across an infinite loop: +used to prevent the compiler from moving code across an infinite loop: =20 WRITE_ONCE(x, 1); while (dontstop) @@ -274,7 +274,7 @@ different pieces of the concurrent algorithm. The vari= able stored to by the smp_store_release(), in this case "y", will normally be used in an acquire operation in other parts of the concurrent algorithm. =20 -To see the performance advantages, suppose that the above example read +To see the performance advantages, suppose that the above example reads from "x" instead of writing to it. Then an smp_wmb() could not guarantee ordering, and an smp_mb() would be needed instead: =20 @@ -394,17 +394,17 @@ from the value returned by the rcu_dereference() or s= rcu_dereference() to that subsequent memory access. =20 A call to rcu_dereference() for a given RCU-protected pointer is -usually paired with a call to a call to rcu_assign_pointer() for that -same pointer in much the same way that a call to smp_load_acquire() is -paired with a call to smp_store_release(). Calls to rcu_dereference() -and rcu_assign_pointer are often buried in other APIs, for example, +usually paired with a call to rcu_assign_pointer() for that same pointer +in much the same way that a call to smp_load_acquire() is paired with +a call to smp_store_release(). Calls to rcu_dereference() and +rcu_assign_pointer() are often buried in other APIs, for example, the RCU list API members defined in include/linux/rculist.h. For more information, please see the docbook headers in that file, the most -recent LWN article on the RCU API (https://lwn.net/Articles/777036/), +recent LWN article on the RCU API (https://lwn.net/Articles/988638/), and of course the material in Documentation/RCU. =20 If the pointer value is manipulated between the rcu_dereference() -that returned it and a later dereference(), please read +that returned it and a later rcu_dereference(), please read Documentation/RCU/rcu_dereference.rst. It can also be quite helpful to review uses in the Linux kernel. =20 @@ -457,7 +457,7 @@ described earlier in this document. These operations come in three categories: =20 o Marked writes, such as WRITE_ONCE() and atomic_set(). These - primitives required the compiler to emit the corresponding store + primitives require the compiler to emit the corresponding store instructions in the expected execution order, thus suppressing a number of destructive optimizations. However, they provide no hardware ordering guarantees, and in fact many CPUs will happily @@ -465,7 +465,7 @@ o Marked writes, such as WRITE_ONCE() and atomic_set().= These operations, unless these operations are to the same variable. =20 o Marked reads, such as READ_ONCE() and atomic_read(). These - primitives required the compiler to emit the corresponding load + primitives require the compiler to emit the corresponding load instructions in the expected execution order, thus suppressing a number of destructive optimizations. However, they provide no hardware ordering guarantees, and in fact many CPUs will happily @@ -506,7 +506,7 @@ of the old value and the new value. =20 Unmarked C-language accesses are unordered, and are also subject to any number of compiler optimizations, many of which can break your -concurrent code. It is possible to used unmarked C-language accesses for +concurrent code. It is possible to use unmarked C-language accesses for shared variables that are subject to concurrent access, but great care is required on an ongoing basis. The compiler-constraining barrier() primitive can be helpful, as can the various ordering primitives discussed --=20 2.40.1 From nobody Sun Dec 14 12:14:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5DC9821B183; Fri, 18 Apr 2025 17:30:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744997403; cv=none; b=b0CqTd521fpcapcKvyUe0ntgepdb4t0Sps/8Nc8Rn02BmvJlVUyBYqyVVV4VnO10aYPsWe1DoNVUDnqUYE9J29SS+9oz/Q24+NGXOCm7Irt/1zbGvXTgkc/chPSKFq4tnVsQm2Ba025il7dkw41gmZ31MV+6E7P1dS1W8H/E5nQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744997403; c=relaxed/simple; bh=7Zm1ra4Kkx6UNSYjT29unnZNFRlLSicJjp5B6B/BV+A=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=YHLQazxJ4s6reFBkH8/yMM6TASxWBoSEl+ZcTv3Ho5KADLuWiY8LU8HeKAiIprjwli67/Byrr5DbiapMUKMJt8Fra0aQhWgyxnkDZISpqTvtethyydzONMJtSGkX652K1TZxcoZ+xPBB2564k3Mt1JmUQPAGpVK4lfz350uO57s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=j8YqGgud; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="j8YqGgud" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E85F5C4CEED; Fri, 18 Apr 2025 17:30:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744997403; bh=7Zm1ra4Kkx6UNSYjT29unnZNFRlLSicJjp5B6B/BV+A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=j8YqGgud6bXMOt9tmL0kDrUaneJ8QaMHsZTX9zjJjwPuuHm5pePhhmSigkrhG88c/ F3GTMHYkkUl13oBlIQUmzivaihkiGa3NgH2smndPQ3a3r1RDIZE+aN/8hN5vhVOtPI YNfe1+5oB7VNFzMU9EqWFBTPeAKPYgJcz0tJLqBLPnSCR80o1cUKNdqXK4uvO/b+QE wDao5+krXX01UI5+6JxNFePw1OYo6/9V3vxcd3strcN8gf02g1c2s1rwoVozepwjns /im55CP522eBu75TN77r8v5279yuXrZQP/tJW0wxojopxpNj8Zeow29BnIByfNJiZY B/nkS1TH+ruaw== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 82830CE0F4D; Fri, 18 Apr 2025 10:30:02 -0700 (PDT) From: "Paul E. McKenney" To: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, lkmm@lists.linux.dev, kernel-team@meta.com, mingo@kernel.org Cc: stern@rowland.harvard.edu, parri.andrea@gmail.com, will@kernel.org, peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, akiyks@gmail.com, "Paul E . McKenney" Subject: [PATCH 4/4] tools/memory-model: docs/references: Remove broken link to imgtec.com Date: Fri, 18 Apr 2025 10:30:00 -0700 Message-Id: <20250418173000.1188561-4-paulmck@kernel.org> X-Mailer: git-send-email 2.40.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Akira Yokosawa MIPS documents are not provided at imgtec.com any more. Get rid of useless link. Signed-off-by: Akira Yokosawa Signed-off-by: Paul E. McKenney Acked-by: Andrea Parri --- tools/memory-model/Documentation/references.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/memory-model/Documentation/references.txt b/tools/memory= -model/Documentation/references.txt index c5fdfd19df240..d691390620b3b 100644 --- a/tools/memory-model/Documentation/references.txt +++ b/tools/memory-model/Documentation/references.txt @@ -46,8 +46,7 @@ o ARM Ltd. (Ed.). 2014. "ARM Architecture Reference Manua= l (ARMv8, =20 o Imagination Technologies, LTD. 2015. "MIPS(R) Architecture For Programmers, Volume II-A: The MIPS64(R) Instruction, - Set Reference Manual". Imagination Technologies, - LTD. https://imgtec.com/?do-download=3D4302. + Set Reference Manual". Imagination Technologies, LTD. =20 o Shaked Flur, Kathryn E. Gray, Christopher Pulte, Susmit Sarkar, Ali Sezgin, Luc Maranget, Will Deacon, and Peter --=20 2.40.1