[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210519112029.3jbw74fuqe4p2tjm@gondor.apana.org.au>
Date: Wed, 19 May 2021 19:20:29 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: sharathv@...eaurora.org
Cc: tgraf@...g.ch, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, edumazet@...gle.com
Subject: Re: Internal error: Oops from inet_frag_find, when inserting a IP
frag into a rhashtable
On Wed, May 19, 2021 at 12:52:27AM +0530, sharathv@...eaurora.org wrote:
>
> 784.185172: <2> (2)[71:kworker/2:1][20210408_17:01:54.754415]@2
> __get_vm_area_node.llvm.17374696036975823682+0x1ac/0x1c8
> 784.185179: <2> (2)[71:kworker/2:1][20210408_17:01:54.754422]@2
> __vmalloc_node_flags_caller+0xb4/0x170
> 784.185189: <2> (2)[71:kworker/2:1][20210408_17:01:54.754432]@2
> kvmalloc_node+0x40/0xa8
> 784.185199: <2> (2)[71:kworker/2:1][20210408_17:01:54.754442]@2
> rhashtable_insert_rehash+0x84/0x264
Something very fishy is going on here.
The code path in rhashtable_insert_rehash cannot possibly trigger
vmalloc because it uses GFP_ATOMIC. Is this a pristine upstream
kernel or are there patches that may change things?
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists