Bug 218314 - stackdepot, KASAN (tags): allow bounding memory usage via command line
Summary: stackdepot, KASAN (tags): allow bounding memory usage via command line
Status: NEW
Alias: None
Product: Memory Management
Classification: Unclassified
Component: Sanitizers (show other bugs)
Hardware: All Linux
: P3 normal
Assignee: MM/Sanitizers virtual assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-12-25 17:15 UTC by Andrey Konovalov
Modified: 2023-12-25 17:25 UTC (History)
1 user (show)

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Andrey Konovalov 2023-12-25 17:15:09 UTC
We should allow limiting the total amount of memory used to store stack traces for tag-based KASAN mode via command-line parameters. This includes memory for the stack depot hash table, the stack depot storage pages, and the stack ring used by the tag-based KASAN modes.

For the stack ring, we already have kasan.stack_ring_size with current the default value of 32768.

For the stack depot, currently, when KASAN is enabled, the hash table takes up 8 MB and the storage pages are allocated dynamically with total size up to 32 MB. (However, with the "stackdepot: allow evicting stack traces" series (will likely be merged into 6.8), as the tag-based modes evict unneeded stack traces from the stack depot, the actual memory usage for the storage pages is significantly lower.)

We need to add a command-line parameter for the stack depot, which limits the total size of the hash table and the storage pages. We can limit both via a single parameter: e.g. add a parameter for the maximum number of storage pages and figure out how large the hash table needs to be accordingly.

It also makes sense to update the default value for kasan.stack_ring_size to work well together with the default values for the other added parameter. E.g. keep just enough stack traces in the stack ring to exhaust half of the stack depot storage on average.

As a part of this change, we should also mark stack_bucket_number_order as __ro_after_init or drop it completely (suggested by Marco in https://lore.kernel.org/lkml/CA+fCnZeBzs+PQP8SQGorSsOe2e_NzDnqP_KksjfLwkUu+aVTZQ@mail.gmail.com/)

We should also replace the WARNING on reaching the stack depot capacity limit with a normal console message.

Note You need to log in before you can comment on or make changes to this bug.