On 11/10/20 2:03 PM, Matthew Wilcox wrote:
On Tue, Nov 10, 2020 at 12:53:27PM -0700, Shuah Khan wrote:
Sequence Numbers wrap around to INT_MIN when it overflows and should not
Why would sequence numbers be signed? I know they're built on top of
atomic_t, which is signed, but conceptually a sequence number is unsigned.
Yes we have some instances where unsigned is being used. I considered
going to unsigned. Changing the API to unsigned has other ramifications
and cascading changes to current atomic_t usages that are up counters.
git grep -E '\((unsigned|unsigned int|u32)\).*\batomic.*(read)' | wc -l
53
A total of 53 out of 6080 atomic_read() usages force return type to
unsigned.
git grep -E '\((unsigned|unsigned int|u32)\).*\batomic.*(inc_return)' |
wc -l
11
A total of 11 out of 620 atomic_inc_return() usages force return type
to unsigned.
Changing the API to unsigned has other ramifications and cascading
changes to current atomic_t usages that are up counters.
We could add unsigned to seqnum_ops though.
+++ b/Documentation/core-api/seqnum_ops.rst
@@ -0,0 +1,117 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: <isonum.txt>
+
+.. _seqnum_ops:
+
+==========================
+Sequence Number Operations
+==========================
+
+:Author: Shuah Khan
+:Copyright: |copy| 2020, The Linux Foundation
+:Copyright: |copy| 2020, Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>
+
+There are a number of atomic_t usages in the kernel where atomic_t api
+is used strictly for counting sequence numbers and other statistical
+counters and not for managing object lifetime.
You start by describing why this was introduced. I think rather, you
should start by describing what this is. You can compare and contrast
it with atomic_t later. Also, I don't think it's necessary to describe
its implementation in this document. This document should explain to
someone why they want to use this.
+Read interface
+--------------
+
+Reads and returns the current value. ::
+
+ seqnum32_read() --> atomic_read()
+ seqnum64_read() --> atomic64_read()
+
+Increment interface
+-------------------
+
+Increments sequence number and doesn't return the new value. ::
+
+ seqnum32_inc() --> atomic_inc()
+ seqnum64_inc() --> atomic64_inc()
That seems odd to me. For many things, I want to know what the
sequence number was incremented to. Obviously seqnum_inc(); followed
by seqnum_read(); is racy.
Do we really want to be explicit about seqnum32 being 32-bit?
I'd be inclined to have seqnum/seqnum64 instead of seqnum32/seqnum64.
+static inline int seqnum32_read(const struct seqnum32 *seq)
+{
+ return atomic_read(&seq->seqnum);
+}
+
+/*
+ * seqnum32_set() - set seqnum value
+ * @seq: struct seqnum32 pointer
+ * @val: new value to set
+ *
+ */
+static inline void
+seqnum32_set(struct seqnum32 *seq, int val)
> You have some odd formatting like the above line split.
+static inline void seqnum64_dec(
+ struct seqnum64 *seq)
That one is particularly weird.
Thanks for catching these. This code needed cleanup after the
rename from a looong names from previous version.
thanks,
-- Shuah
