From: Vlastimil Babka <vbabka@suse.cz>
To: Marco Elver <elver@google.com>,
Alexander Potapenko <glider@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
Andrey Konovalov <andreyknvl@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
kasan-dev@googlegroups.com, Vlastimil Babka <vbabka@suse.cz>
Subject: [RFC PATCH 0/1] stackdepot hash table autosizing
Date: Fri, 27 May 2022 13:37:05 +0200 [thread overview]
Message-ID: <20220527113706.24870-1-vbabka@suse.cz> (raw)
Hi,
in response to Linus [1] I have been looking a bit into using
rhashtables in stackdepot, as stackdepot is gaining new users and the
config option-based static hash table size becomes unwieldy.
With rhashtables it would just scale fully automatically, and we could
also consider creating separate stackdepot instances (including own
rhashtable) for each user, as each will have a distinct set of stack
trackes to store, so there's no benefit of storing them together.
However, AFAIU stackdepot was initially created for KASAN, and is
sometimes called from restricted contexts, i.e. via
kasan_record_aux_stack_noalloc() where it avoids allocations, and it's
also why stackdepot uses raw_spin_lock.
rhashtable offloads allocations to a kthread, so that's fine, but uses
non-raw spinlock, so that would be a problem for some of the stackdepot
contexts. It also uses RCU read lock, while some of
kasan_record_aux_stack_noalloc() callsites are in the RCU implementation
code, so that could be also an issue (haven't investigated it in detail).
For the SLUB_DEBUG context specifically, rhashtable uses kmalloc() and
variants, so there's potential recursion issue. While it's expected
those allocations will eventually become large enough to be passed to
kmalloc_large() and avoid slab, we would have to make sure all of them
do.
So my impression is that we could convert some stackdepot users to
rhashtable, but not all. So maybe we could create a second stackdepot
API for those, but KASAN would have to use the original one anyway. As
such it makes sense to me to improve the existing API to replace the
problematic CONFIG_STACK_HASH_ORDER with something that is also not
resizable on the fly, but doesn't require build-time configuration
anymore, and picks automatically a size depending on the system memory
size. Hence I'm proposing the following patch, regardless of whether
we proceed with rhashtables for the other stackdepot users.
Vlastimil
[1] https://lore.kernel.org/all/CAHk-=wjC5nS+fnf6EzRD9yQRJApAhxx7gRB87ZV+pAWo9oVrTg@mail.gmail.com/
Vlastimil Babka (1):
lib/stackdepot: replace CONFIG_STACK_HASH_ORDER with automatic sizing
lib/Kconfig | 9 ---------
lib/stackdepot.c | 47 ++++++++++++++++++++++++++++++++++++-----------
2 files changed, 36 insertions(+), 20 deletions(-)
--
2.36.1
next reply other threads:[~2022-05-27 11:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-27 11:37 Vlastimil Babka [this message]
2022-05-27 11:37 ` [RFC PATCH 1/1] lib/stackdepot: replace CONFIG_STACK_HASH_ORDER with automatic sizing Vlastimil Babka
2022-05-27 12:02 ` Dmitry Vyukov
2022-06-20 12:00 ` Vlastimil Babka
2022-06-20 12:02 ` Dmitry Vyukov
2022-06-20 15:02 ` [PATCH] " Vlastimil Babka
2022-06-21 7:37 ` Dmitry Vyukov
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=20220527113706.24870-1-vbabka@suse.cz \
--to=vbabka@suse.cz \
--cc=andreyknvl@gmail.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=torvalds@linux-foundation.org \
/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