linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: andrey.konovalov@linux.dev
Cc: Alexander Potapenko <glider@google.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	kasan-dev@googlegroups.com, Evgenii Stepanov <eugenis@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andrey Konovalov <andreyknvl@google.com>
Subject: Re: [PATCH 06/15] stackdepot: fix and clean-up atomic annotations
Date: Wed, 30 Aug 2023 10:34:18 +0200	[thread overview]
Message-ID: <ZO7/CqwhzqulWP7K@elver.google.com> (raw)
In-Reply-To: <8ad8f778b43dab49e4e6214b8d90bed31b75436f.1693328501.git.andreyknvl@google.com>

On Tue, Aug 29, 2023 at 07:11PM +0200, andrey.konovalov@linux.dev wrote:
> From: Andrey Konovalov <andreyknvl@google.com>
> 
> Simplify comments accompanying the use of atomic accesses in the
> stack depot code.
> 
> Also turn smp_load_acquire from next_pool_required in depot_init_pool
> into READ_ONCE, as both depot_init_pool and the all smp_store_release's
> to this variable are executed under the stack depot lock.
> 
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> 
> ---
> 
> This patch is not strictly required, as the atomic accesses are fully
> removed in one of the latter patches. However, I decided to keep the
> patch just in case we end up needing these atomics in the following
> iterations of this series.
> ---
>  lib/stackdepot.c | 27 +++++++++++++--------------
>  1 file changed, 13 insertions(+), 14 deletions(-)
> 
> diff --git a/lib/stackdepot.c b/lib/stackdepot.c
> index 93191ee70fc3..9ae71e1ef1a7 100644
> --- a/lib/stackdepot.c
> +++ b/lib/stackdepot.c
> @@ -226,10 +226,10 @@ static void depot_init_pool(void **prealloc)
>  	/*
>  	 * If the next pool is already initialized or the maximum number of
>  	 * pools is reached, do not use the preallocated memory.
> -	 * smp_load_acquire() here pairs with smp_store_release() below and
> -	 * in depot_alloc_stack().
> +	 * READ_ONCE is only used to mark the variable as atomic,
> +	 * there are no concurrent writes.

This doesn't make sense. If there are no concurrent writes, we should
drop the marking, so that if there are concurrent writes, tools like
KCSAN can tell us about it if our assumption was wrong.

>  	 */
> -	if (!smp_load_acquire(&next_pool_required))
> +	if (!READ_ONCE(next_pool_required))
>  		return;
>  
>  	/* Check if the current pool is not yet allocated. */
> @@ -250,8 +250,8 @@ static void depot_init_pool(void **prealloc)
>  		 * At this point, either the next pool is initialized or the
>  		 * maximum number of pools is reached. In either case, take
>  		 * note that initializing another pool is not required.
> -		 * This smp_store_release pairs with smp_load_acquire() above
> -		 * and in stack_depot_save().
> +		 * smp_store_release pairs with smp_load_acquire in
> +		 * stack_depot_save.
>  		 */
>  		smp_store_release(&next_pool_required, 0);
>  	}
> @@ -275,15 +275,15 @@ depot_alloc_stack(unsigned long *entries, int size, u32 hash, void **prealloc)
>  		/*
>  		 * Move on to the next pool.
>  		 * WRITE_ONCE pairs with potential concurrent read in
> -		 * stack_depot_fetch().
> +		 * stack_depot_fetch.
>  		 */
>  		WRITE_ONCE(pool_index, pool_index + 1);
>  		pool_offset = 0;
>  		/*
>  		 * If the maximum number of pools is not reached, take note
>  		 * that the next pool needs to initialized.
> -		 * smp_store_release() here pairs with smp_load_acquire() in
> -		 * stack_depot_save() and depot_init_pool().
> +		 * smp_store_release pairs with smp_load_acquire in
> +		 * stack_depot_save.
>  		 */
>  		if (pool_index + 1 < DEPOT_MAX_POOLS)
>  			smp_store_release(&next_pool_required, 1);
> @@ -414,8 +414,7 @@ depot_stack_handle_t __stack_depot_save(unsigned long *entries,
>  
>  	/*
>  	 * Fast path: look the stack trace up without locking.
> -	 * The smp_load_acquire() here pairs with smp_store_release() to
> -	 * |bucket| below.
> +	 * smp_load_acquire pairs with smp_store_release to |bucket| below.
>  	 */
>  	found = find_stack(smp_load_acquire(bucket), entries, nr_entries, hash);
>  	if (found)
> @@ -425,8 +424,8 @@ depot_stack_handle_t __stack_depot_save(unsigned long *entries,
>  	 * Check if another stack pool needs to be initialized. If so, allocate
>  	 * the memory now - we won't be able to do that under the lock.
>  	 *
> -	 * The smp_load_acquire() here pairs with smp_store_release() to
> -	 * |next_pool_inited| in depot_alloc_stack() and depot_init_pool().
> +	 * smp_load_acquire pairs with smp_store_release
> +	 * in depot_alloc_stack and depot_init_pool.

Reflow comment to match 80 cols used by comments elsewhere.

>  	 */
>  	if (unlikely(can_alloc && smp_load_acquire(&next_pool_required))) {
>  		/*
> @@ -452,8 +451,8 @@ depot_stack_handle_t __stack_depot_save(unsigned long *entries,
>  		if (new) {
>  			new->next = *bucket;
>  			/*
> -			 * This smp_store_release() pairs with
> -			 * smp_load_acquire() from |bucket| above.
> +			 * smp_store_release pairs with smp_load_acquire
> +			 * from |bucket| above.
>  			 */
>  			smp_store_release(bucket, new);
>  			found = new;
> -- 
> 2.25.1
> 


  reply	other threads:[~2023-08-30  8:34 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-29 17:11 [PATCH 00/15] stackdepot: allow evicting stack traces andrey.konovalov
2023-08-29 17:11 ` [PATCH 01/15] stackdepot: check disabled flag when fetching andrey.konovalov
2023-08-30  7:40   ` Alexander Potapenko
2023-08-29 17:11 ` [PATCH 02/15] stackdepot: simplify __stack_depot_save andrey.konovalov
2023-08-30  7:41   ` Alexander Potapenko
2023-08-29 17:11 ` [PATCH 03/15] stackdepot: drop valid bit from handles andrey.konovalov
2023-08-30  7:43   ` Alexander Potapenko
2023-08-29 17:11 ` [PATCH 04/15] stackdepot: add depot_fetch_stack helper andrey.konovalov
2023-08-30  7:47   ` Alexander Potapenko
2023-08-29 17:11 ` [PATCH 05/15] stackdepot: use fixed-sized slots for stack records andrey.konovalov
2023-08-30  8:21   ` Alexander Potapenko
2023-09-13 17:07     ` Andrey Konovalov
2023-09-15 10:36       ` Alexander Potapenko
2023-08-29 17:11 ` [PATCH 06/15] stackdepot: fix and clean-up atomic annotations andrey.konovalov
2023-08-30  8:34   ` Marco Elver [this message]
2023-09-04 18:45     ` Andrey Konovalov
2023-08-29 17:11 ` [PATCH 07/15] stackdepot: rework helpers for depot_alloc_stack andrey.konovalov
2023-08-29 17:11 ` [PATCH 08/15] stackdepot: rename next_pool_required to new_pool_required andrey.konovalov
2023-08-30  8:29   ` Alexander Potapenko
2023-08-29 17:11 ` [PATCH 09/15] stackdepot: store next pool pointer in new_pool andrey.konovalov
2023-08-29 17:11 ` [PATCH 10/15] stackdepot: store free stack records in a freelist andrey.konovalov
2023-08-29 17:11 ` [PATCH 11/15] stackdepot: use read/write lock andrey.konovalov
2023-08-30  9:13   ` Marco Elver
2023-09-04 18:46     ` Andrey Konovalov
2023-09-05 16:19       ` Marco Elver
2023-09-13 17:08         ` Andrey Konovalov
2024-01-02 12:59           ` Marco Elver
2024-01-09  3:27             ` Andrey Konovalov
2023-08-29 17:11 ` [PATCH 12/15] stackdepot: add refcount for records andrey.konovalov
2023-08-30  9:32   ` Marco Elver
2023-09-04 18:46     ` Andrey Konovalov
2023-09-04 18:55       ` Marco Elver
2023-09-13 17:07         ` Andrey Konovalov
2023-09-01 13:06   ` Kuan-Ying Lee (李冠穎)
2023-09-04 18:46     ` Andrey Konovalov
2023-08-29 17:11 ` [PATCH 13/15] stackdepot: add backwards links to hash table buckets andrey.konovalov
2023-08-30  9:24   ` Marco Elver
2023-09-13 17:07     ` Andrey Konovalov
2023-08-29 17:11 ` [PATCH 14/15] stackdepot: allow users to evict stack traces andrey.konovalov
2023-08-30  9:20   ` Marco Elver
2023-09-04 18:47     ` Andrey Konovalov
2023-08-29 17:11 ` [PATCH 15/15] kasan: use stack_depot_evict for tag-based modes andrey.konovalov
2023-08-30  9:38   ` Marco Elver
2023-09-04 18:48     ` Andrey Konovalov
2023-09-04 18:58       ` Marco Elver
2023-09-13 17:08         ` Andrey Konovalov
2023-08-30  7:46 ` [PATCH 00/15] stackdepot: allow evicting stack traces Vlastimil Babka
2023-09-04 18:45   ` Andrey Konovalov
2023-09-05  2:48     ` Kuan-Ying Lee (李冠穎)
2023-09-13 17:10       ` Andrey Konovalov

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=ZO7/CqwhzqulWP7K@elver.google.com \
    --to=elver@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrey.konovalov@linux.dev \
    --cc=andreyknvl@gmail.com \
    --cc=andreyknvl@google.com \
    --cc=dvyukov@google.com \
    --cc=eugenis@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=vbabka@suse.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox