From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D390C433EF for ; Fri, 27 May 2022 11:37:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D2A1A8D0005; Fri, 27 May 2022 07:37:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB5688D0002; Fri, 27 May 2022 07:37:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA32D8D0005; Fri, 27 May 2022 07:37:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A98B78D0002 for ; Fri, 27 May 2022 07:37:29 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 7CBB734048 for ; Fri, 27 May 2022 11:37:29 +0000 (UTC) X-FDA: 79511322618.16.22E2A1B Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf19.hostedemail.com (Postfix) with ESMTP id 6E5551A0046 for ; Fri, 27 May 2022 11:37:15 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 511E6219B3; Fri, 27 May 2022 11:37:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1653651447; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=+hHq1dpI0VYa05+VLZiztmS29cD052lJCNPI3wyITqE=; b=i1vncFC7FieoHBoLCNPtu07PZQ387ayBsgK2AZWTiI3CHQypr4cY0RL/8uvDg/HGRtS0rn mfaKBUUBHVHHV6CM2mhG5Smqi3I7iev8f3D1anHSnHCMn23+IaPPyGd7A/qkpLtg8zsu9m +HpqfkHMjhQAECsywFE5+4MwP9xGawE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1653651447; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=+hHq1dpI0VYa05+VLZiztmS29cD052lJCNPI3wyITqE=; b=9qo5Vlj+i7TW9t/JL+54OI0qlN7yQTgf2V2K6VhHk5DViMynpycv3iWNc1DR4GjG9M+PGv TuWFLkiO+j88fxCQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 33947139C4; Fri, 27 May 2022 11:37:27 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id +UYTDPe3kGKQDgAAMHmgww (envelope-from ); Fri, 27 May 2022 11:37:27 +0000 From: Vlastimil Babka To: Marco Elver , Alexander Potapenko , Linus Torvalds , linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Andrey Konovalov , Dmitry Vyukov , kasan-dev@googlegroups.com, Vlastimil Babka Subject: [RFC PATCH 0/1] stackdepot hash table autosizing Date: Fri, 27 May 2022 13:37:05 +0200 Message-Id: <20220527113706.24870-1-vbabka@suse.cz> X-Mailer: git-send-email 2.36.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: tykdtbykk8zmmr9qs7yh81rpk84iatg3 X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=i1vncFC7; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=9qo5Vlj+; dmarc=none; spf=pass (imf19.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6E5551A0046 X-HE-Tag: 1653651435-524008 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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