Re: [PATCH 01/13] seqnum_ops: Introduce Sequence Number Ops

[Shuah Khan]

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