Re: [PATCH v2 25/27] locking/atomic: scripts: generate kerneldoc comments

From: Mark Rutland
Date: Fri Jun 16 2023 - 04:57:36 EST


On Thu, Jun 15, 2023 at 07:07:13AM -0700, Paul E. McKenney wrote:
> On Mon, Jun 05, 2023 at 08:01:22AM +0100, Mark Rutland wrote:
> > Currently the atomics are documented in Documentation/atomic_t.txt, and
> > have no kerneldoc comments. There are a sufficient number of gotchas
> > (e.g. semantics, noinstr-safety) that it would be nice to have comments
> > to call these out, and it would be nice to have kerneldoc comments such
> > that these can be collated.
> >
> > While it's possible to derive the semantics from the code, this can be
> > painful given the amount of indirection we currently have (e.g. fallback
> > paths), and it's easy to be mislead by naming, e.g.
> >
> > * The unconditional void-returning ops *only* have relaxed variants
> > without a _relaxed suffix, and can easily be mistaken for being fully
> > ordered.
> >
> > It would be nice to give these a _relaxed() suffix, but this would
> > result in significant churn throughout the kernel.
> >
> > * Our naming of conditional and unconditional+test ops is rather
> > inconsistent, and it can be difficult to derive the name of an
> > operation, or to identify where an op is conditional or
> > unconditional+test.
> >
> > Some ops are clearly conditional:
> > - dec_if_positive
> > - add_unless
> > - dec_unless_positive
> > - inc_unless_negative
> >
> > Some ops are clearly unconditional+test:
> > - sub_and_test
> > - dec_and_test
> > - inc_and_test
> >
> > However, what exactly those test is not obvious. A _test_zero suffix
> > might be clearer.
> >
> > Others could be read ambiguously:
> > - inc_not_zero // conditional
> > - add_negative // unconditional+test
> >
> > It would probably be worth renaming these, e.g. to inc_unless_zero and
> > add_test_negative.
> >
> > As a step towards making this more consistent and easier to understand,
> > this patch adds kerneldoc comments for all generated *atomic*_*()
> > functions. These are generated from templates, with some common text
> > shared, making it easy to extend these in future if necessary.
> >
> > I've tried to make these as consistent and clear as possible, and I've
> > deliberately ensured:
> >
> > * All ops have their ordering explicitly mentioned in the short and long
> > description.
> >
> > * All test ops have "test" in their short description.
> >
> > * All ops are described as an expression using their usual C operator.
> > For example:
> >
> > andnot: "Atomically updates @v to (@v & ~@i)"
> > inc: "Atomically updates @v to (@v + 1)"
> >
> > Which may be clearer to non-naative English speakers, and allows all
> > the operations to be described in the same style.
> >
> > * All conditional ops have their condition described as an expression
> > using the usual C operators. For example:
> >
> > add_unless: "If (@v != @u), atomically updates @v to (@v + @i)"
> > cmpxchg: "If (@v == @old), atomically updates @v to @new"
> >
> > Which may be clearer to non-naative English speakers, and allows all
> > the operations to be described in the same style.
> >
> > * All bitwise ops (and,andnot,or,xor) explicitly mention that they are
> > bitwise in their short description, so that they are not mistaken for
> > performing their logical equivalents.
> >
> > * The noinstr safety of each op is explicitly described, with a
> > description of whether or not to use the raw_ form of the op.
> >
> > There should be no functional change as a result of this patch.
> >
> > Reported-by: Paul E. McKenney <paulmck@xxxxxxxxxx>
> > Signed-off-by: Mark Rutland <mark.rutland@xxxxxxx>
> > Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx>
> > Cc: Boqun Feng <boqun.feng@xxxxxxxxx>
> > Cc: Jonathan Corbet <corbet@xxxxxxx>
> > Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > Cc: Will Deacon <will@xxxxxxxxxx>
>
> With the dec_if_positive fix:
>
> Reviewed-by: Paul E. McKenney <paulmck@xxxxxxxxxx>

Thanks! This is already queued in the tip tree's locking/core branch:

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=locking/core

... so I was assuming that the dec_if_positive patch would be picked up atop
that.

Regardless, thanks for checking I hadn't missed anything else here! :)

Mark.