On Mon, Oct 9, 2023 at 10:59 AM Alexander Potapenko <glider@xxxxxxxxxx> wrote:
>
> On Wed, Sep 13, 2023 at 7:15 PM <andrey.konovalov@xxxxxxxxx> wrote:
> >
> > From: Andrey Konovalov <andreyknvl@xxxxxxxxxx>
> >
> > Split code in depot_alloc_stack and depot_init_pool into 3 functions:
> >
> > 1. depot_keep_next_pool that keeps preallocated memory for the next pool
> > if required.
> >
> > 2. depot_update_pools that moves on to the next pool if there's no space
> > left in the current pool, uses preallocated memory for the new current
> > pool if required, and calls depot_keep_next_pool otherwise.
> >
> > 3. depot_alloc_stack that calls depot_update_pools and then allocates
> > a stack record as before.
> >
> > This makes it somewhat easier to follow the logic of depot_alloc_stack
> > and also serves as a preparation for implementing the eviction of stack
> > records from the stack depot.
> >
> > Signed-off-by: Andrey Konovalov <andreyknvl@xxxxxxxxxx>
> Reviewed-by: Alexander Potapenko <glider@xxxxxxxxxx>
>
>
> > +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?
You're adding lockdep annotations in patch 11, which are pretty
self-descriptive.
Feel free to ignore my comment above.
