All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ankur Arora" <ankur.a.arora@oracle.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v13 07/15] atomic: Add atomic_cond_read_*_timeout()
Date: Thu, 02 Jul 2026 01:48:09 +0000	[thread overview]
Message-ID: <20260702014810.5B88A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260702013334.140905-8-ankur.a.arora@oracle.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Documentation introduces misleading API grouping and broken grammar.
--

commit aa3c9c6efe8c1dbd47a496d3ac3a6bd26a933d98
Author: Ankur Arora <ankur.a.arora@oracle.com>

atomic: Add atomic_cond_read_*_timeout()

This commit adds atomic load wrappers for conditional load timeout interfaces.
It also provides short documentation updates for the relaxed and acquire 
variants of the atomic_cond_read interfaces.

> diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt
> index bee3b1bca9a7b..0e53f6ccb5580 100644
> --- a/Documentation/atomic_t.txt
> +++ b/Documentation/atomic_t.txt
> @@ -16,6 +16,10 @@ Non-RMW ops:
>    atomic_read(), atomic_set()
>    atomic_read_acquire(), atomic_set_release()
>  
> +Non-RMW, non-atomic_t ops:
> +
> +  atomic_cond_read_{relaxed,acquire}()

[Severity: Low]
This isn't a bug, but should atomic_cond_read_{relaxed,acquire}() be grouped
under "non-atomic_t ops"? They still take an atomic_t pointer as their primary
argument, so this heading seems misleading.

> +  atomic_cond_read_{relaxed,acquire}_timeout()

[ ... ]

> @@ -79,11 +83,11 @@ SEMANTICS
>  
>  Non-RMW ops:
>  
> -The non-RMW ops are (typically) regular LOADs and STOREs and are canonically
> -implemented using READ_ONCE(), WRITE_ONCE(), smp_load_acquire() and
> -smp_store_release() respectively. Therefore, if you find yourself only using
> -the Non-RMW operations of atomic_t, you do not in fact need atomic_t at all
> -and are doing it wrong.
> +The non-RMW ops are (typically) regular, or conditional LOADs and STOREs and
> +are canonically implemented using READ_ONCE(), WRITE_ONCE(),
> +smp_load_acquire() and smp_store_release() respectively.

[Severity: Low]
This isn't a bug, but does adding "conditional LOADs" here break the 
"respectively" mapping? 

The text continues to list READ_ONCE(), WRITE_ONCE(), smp_load_acquire() and 
smp_store_release() as the canonical implementations, but doesn't add the 
smp_cond_load_* macros to match the newly added conditional LOADs.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702013334.140905-1-ankur.a.arora@oracle.com?part=7

  reply	other threads:[~2026-07-02  1:48 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02  1:33 [PATCH v13 00/15] barrier: Add smp_cond_load_{relaxed,acquire}_timeout() Ankur Arora
2026-07-02  1:33 ` [PATCH v13 01/15] asm-generic: barrier: Add smp_cond_load_relaxed_timeout() Ankur Arora
2026-07-02  1:46   ` sashiko-bot
2026-07-02  2:11   ` bot+bpf-ci
2026-07-02  1:33 ` [PATCH v13 02/15] arm64: barrier: Support smp_cond_load_relaxed_timeout() Ankur Arora
2026-07-02  1:50   ` sashiko-bot
2026-07-02  1:33 ` [PATCH v13 03/15] arm64/delay: move some constants out to a separate header Ankur Arora
2026-07-02  1:47   ` sashiko-bot
2026-07-02  1:33 ` [PATCH v13 04/15] arm64: support WFET in smp_cond_load_relaxed_timeout() Ankur Arora
2026-07-02  1:52   ` sashiko-bot
2026-07-02  1:33 ` [PATCH v13 05/15] arm64: rqspinlock: Remove private copy of smp_cond_load_acquire_timewait() Ankur Arora
2026-07-02  1:33 ` [PATCH v13 06/15] asm-generic: barrier: Add smp_cond_load_acquire_timeout() Ankur Arora
2026-07-02  1:53   ` sashiko-bot
2026-07-02  1:33 ` [PATCH v13 07/15] atomic: Add atomic_cond_read_*_timeout() Ankur Arora
2026-07-02  1:48   ` sashiko-bot [this message]
2026-07-02  1:33 ` [PATCH v13 08/15] locking/atomic: scripts: build atomic_long_cond_read_*_timeout() Ankur Arora
2026-07-02  1:33 ` [PATCH v13 09/15] bpf/rqspinlock: switch check_timeout() to a clock interface Ankur Arora
2026-07-02  1:33 ` [PATCH v13 10/15] bpf/rqspinlock: Use smp_cond_load_acquire_timeout() Ankur Arora
2026-07-02  1:33 ` [PATCH v13 11/15] sched: add need-resched timed wait interface Ankur Arora
2026-07-02  1:33 ` [PATCH v13 12/15] cpuidle/poll_state: Wait for need-resched via tif_need_resched_relaxed_wait() Ankur Arora
2026-07-02  1:33 ` [PATCH v13 13/15] arm64/delay: enable testing smp_cond_load_relaxed_timeout() Ankur Arora
2026-07-02  1:57   ` sashiko-bot
2026-07-02  1:33 ` [PATCH v13 14/15] barrier: add tests for smp_cond_load_*_timeout() Ankur Arora
2026-07-03 18:16   ` Julian Braha
2026-07-06 19:18     ` Ankur Arora
2026-07-02  1:33 ` [PATCH v13 15/15] barrier: add clock tests for smp_cond_load_relaxed_timeout() Ankur Arora
2026-07-02  2:11   ` bot+bpf-ci

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260702014810.5B88A1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ankur.a.arora@oracle.com \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.