Messages in this thread | | | Date | Tue, 10 Nov 2020 21:03:16 +0000 | From | Matthew Wilcox <> | Subject | Re: [PATCH 01/13] seqnum_ops: Introduce Sequence Number Ops |
| |
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.
> +++ 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@linuxfoundation.org> > + > +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.
| |