Re: [PATCH 4/4] rhashtable: fix vmalloc() deadlock in atomic rehash

[Herbert Xu]

On Thu, Nov 05, 2026 at 01:02:35PM -0800, Linus Torvalds wrote:
> 
> I don't think that in_serving_softirq() makes any sense.
> 
> If I read this code correctly - and it's possible I didn't - this is
> always called under local_bh_disable().
> 
> And local_bh_disable() will have increased the preempt-count exactly
> so that it looks like it's in_serving_softirq().
> 
> Maybe I got lost somewhere, but it basically looks like that test will
> always be true and is pointless (and misleading).

You're absolutely right.

Even if there was a way to tell whether you're in a real softirq
context, it's crazy to change how locking is done in br_fdb when
the real issue is caused by a kvmalloc call that is made through
rhashtables.

Now if we did the same test within kvmalloc and simply fell back to
kmalloc it might work.  But then again, why are we trying to support
GFP_ATOMIC vmalloc when there appears to be zero users of it, a
whole year after it was introduced?

Cheers,
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt