[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+fCnZeBzs+PQP8SQGorSsOe2e_NzDnqP_KksjfLwkUu+aVTZQ@mail.gmail.com>
Date: Fri, 3 Nov 2023 21:37:20 +0100
From: Andrey Konovalov <andreyknvl@...il.com>
To: Marco Elver <elver@...gle.com>
Cc: andrey.konovalov@...ux.dev,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>, kasan-dev@...glegroups.com,
Evgenii Stepanov <eugenis@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
Andrey Konovalov <andreyknvl@...gle.com>
Subject: Re: [PATCH 1/1] lib/stackdepot: print disabled message only if truly disabled
On Fri, Oct 27, 2023 at 2:54 PM Marco Elver <elver@...gle.com> wrote:
>
> stack_bucket_number_order seems like a redundant variable, that should
> at least be __ro_after_init. All code that does "if
> (stack_bucket_number_order) ..." could just do "if (kasan_enabled())
> ..." and use STACK_BUCKET_NUMBER_ORDER_MAX constant directly instead.
>
> The code here could be simplified if it was removed. No idea why it
> was introduced in the first place. I think f9987921cb541 introduced it
> and there it said "complemented with a boot-time kernel parameter",
> but that never happened.
>
> So I'd be in favor of removing that variable, which will also simplify
> this code.
On the first thought, this seems reasonable with the current code.
On the second though, I think I will soon add a command-line parameter
to allow controlling how much memory is used for the stack depot hash
table.
I propose we keep the code as is for now, but I've taken a note to
either drop this variable or mark it as __ro_after_init when
implementing memory bounding controls for stack depot.
Thanks!
Powered by blists - more mailing lists