From: Herbert Xu <herbert@gondor.apana.org.au>
To: Tejun Heo <tj@kernel.org>
Cc: Thomas Graf <tgraf@suug.ch>, David Vernet <void@manifault.com>,
Andrea Righi <arighi@nvidia.com>,
Changwoo Min <changwoo@igalia.com>,
Emil Tsalapatis <emil@etsalapatis.com>,
linux-crypto@vger.kernel.org, sched-ext@lists.linux.dev,
linux-kernel@vger.kernel.org, Florian Westphal <fw@strlen.de>,
netdev@vger.kernel.org
Subject: Re: [PATCH for-7.1-fixes 1/2] rhashtable: add no_sync_grow option
Date: Fri, 17 Apr 2026 15:51:20 +0800 [thread overview]
Message-ID: <aeHmeAz-Z-Rx2MqX@gondor.apana.org.au> (raw)
In-Reply-To: <aeHjjGEhlikSsxCX@slm.duckdns.org>
On Thu, Apr 16, 2026 at 09:38:52PM -1000, Tejun Heo wrote:
>
> Also, taking a step back, if rhashtable allows usage under raw spin locks,
> isn't this broken regardless of how easy or difficult it may be to reproduce
> the problem? Practically speaking, the scx_sched_hash one is unlikely to
> trigger in real world; however, it is still theoretically possible and I'm
> pretty positive that one would be able to create a repro case with the right
> interference workload. It'd be contrived for sure but should be possible.
rhashtable originated in networking where it tries very hard to
stop the hash table from ever degenerating into a linked list.
If your use-case is not as adversarial as that, and you're happy
for the hash table to degenerate into a linked-list in the worst
case, then yes it's aboslutely fine to not grow the table (or
try to grow it and fail with kmalloc_nolock).
It's just that we haven't had any users like this until now and
the feature that you want got removed because of that.
I'm more than happy to bring it back (commit 5f8ddeab10ce).
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
next prev parent reply other threads:[~2026-04-17 7:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260417002449.2290577-1-tj@kernel.org>
2026-04-17 1:22 ` [PATCH for-7.1-fixes 1/2] rhashtable: add no_sync_grow option Herbert Xu
[not found] ` <aeGCMkdg5Fgv8UMS@gondor.apana.org.au>
[not found] ` <aeGElQ-TcCclEHwo@slm.duckdns.org>
[not found] ` <aeGIsGi9fBqu9EZT@gondor.apana.org.au>
[not found] ` <aeHjjGEhlikSsxCX@slm.duckdns.org>
2026-04-17 7:51 ` Herbert Xu [this message]
2026-04-17 16:25 ` Tejun Heo
2026-04-18 0:44 ` Herbert Xu
2026-04-18 0:52 ` Tejun Heo
2026-04-18 0:53 ` Herbert Xu
2026-04-18 1:38 ` [PATCH] rhashtable: Restore insecure_elasticity toggle Herbert Xu
2026-04-18 1:41 ` [v2 PATCH] " Herbert Xu
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=aeHmeAz-Z-Rx2MqX@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=arighi@nvidia.com \
--cc=changwoo@igalia.com \
--cc=emil@etsalapatis.com \
--cc=fw@strlen.de \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sched-ext@lists.linux.dev \
--cc=tgraf@suug.ch \
--cc=tj@kernel.org \
--cc=void@manifault.com \
/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