[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+fCnZfp7V411qf_6miCzSg_5w7HwkHwH+NWLLy8C62P0hEN-g@mail.gmail.com>
Date: Mon, 23 Oct 2023 18:16:33 +0200
From: Andrey Konovalov <andreyknvl@...il.com>
To: Alexander Potapenko <glider@...gle.com>
Cc: andrey.konovalov@...ux.dev, Marco Elver <elver@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>, kasan-dev@...glegroups.com,
Evgenii Stepanov <eugenis@...gle.com>,
Oscar Salvador <osalvador@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
Andrey Konovalov <andreyknvl@...gle.com>
Subject: Re: [PATCH v2 07/19] lib/stackdepot: rework helpers for depot_alloc_stack
On Mon, Oct 9, 2023 at 11:00 AM Alexander Potapenko <glider@...gle.com> wrote:
>
> > +static void depot_keep_next_pool(void **prealloc)
> > {
> > /*
> > - * If the next pool is already initialized or the maximum number of
> > + * If the next pool is already saved or the maximum number of
> > * pools is reached, do not use the preallocated memory.
> > */
> > if (!next_pool_required)
> It's not mentioned at the top of the file that next_pool_required is
> protected by pool_lock, but it is, correct?
> Can you please update the comment to reflect that?
I'll add a clarifying comment above this access to the previous patch.
I don't think it's worth to describe all locking intricacies of the
existing code in other places, as atomic accesses are removed
altogether later in the series anyway.
Thanks!
Powered by blists - more mailing lists