en Copyright 2015 Java http://172.16.0.5:8080/history/linux-6.15/scripts/atomic/kerneldoc/add_unless#6dfee110 locking/atomic: scripts: Clarify ordering of conditional atomicsConditional atomic operations (e.g. cmpxchg()) only provide orderingwhen the condition holds; when the condition does not hold, the locationis not modified and relaxed ordering is provided. Where ordering isneeded for failed conditional atomics, it is necessary to usesmp_mb__before_atomic() and/or smp_mb__after_atomic().This is explained tersely in memory-barriers.txt, and is implied but notexplicitly stated in the kerneldoc comments for the conditionaloperations. The lack of an explicit statement has lead to some off-listqueries about the ordering semantics of failing conditional operations,so evidently this is confusing.Update the kerneldoc comments to explicitly describe the lack of orderingfor failed conditional atomic operations.For most conditional atomic operations, this is written as: | If (${condition}), atomically updates @v to (${new}) with ${desc_order} ordering. | Otherwise, @v is not modified and relaxed ordering is provided.For the try_cmpxchg() operations, this is written as: | If (${condition}), atomically updates @v to @new with ${desc_order} ordering. | Otherwise, @v is not modified, @old is updated to the current value of @v, | and relaxed ordering is provided.Signed-off-by: Mark Rutland <mark.rutland@arm.com>Signed-off-by: Ingo Molnar <mingo@kernel.org>Reviewed-by: Paul E. McKenney <paulmck@kernel.org>Reviewed-by: Nhat Pham <nphamcs@gmail.com>Link: https://lore.kernel.org/r/20240209124010.2096198-1-mark.rutland@arm.com List of files: /linux-6.15/scripts/atomic/kerneldoc/add_unless Fri, 09 Feb 2024 12:40:10 +0000 Mark Rutland <mark.rutland@arm.com> http://172.16.0.5:8080/history/linux-6.15/scripts/atomic/kerneldoc/add_unless#ad811070 locking/atomic: scripts: generate kerneldoc commentsCurrently the atomics are documented in Documentation/atomic_t.txt, andhave no kerneldoc comments. There are a sufficient number of gotchas(e.g. semantics, noinstr-safety) that it would be nice to have commentsto call these out, and it would be nice to have kerneldoc comments suchthat these can be collated.While it's possible to derive the semantics from the code, this can bepainful given the amount of indirection we currently have (e.g. fallbackpaths), 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 textshared, making it easy to extend these in future if necessary.I've tried to make these as consistent and clear as possible, and I'vedeliberately 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@kernel.org>Signed-off-by: Mark Rutland <mark.rutland@arm.com>Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>Reviewed-by: Kees Cook <keescook@chromium.org>Link: https://lore.kernel.org/r/20230605070124.3741859-26-mark.rutland@arm.com List of files: /linux-6.15/scripts/atomic/kerneldoc/add_unless Mon, 05 Jun 2023 07:01:22 +0000 Mark Rutland <mark.rutland@arm.com>