[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <221220f299ac4e6af858ce4e5d877d43@codeaurora.org>
Date: Wed, 26 May 2021 20:06:55 +0530
From: sharathv@...eaurora.org
To: Herbert Xu <herbert@...dor.apana.org.au>
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 2021-05-19 16:50, Herbert Xu wrote:
> 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,
Thanks for the reply Herbert, we have got this crash reported from
external
folks and I am trying to get the answers for your questions.
Powered by blists - more mailing lists