All of lore.kernel.org
 help / color / mirror / Atom feed
From: sharathv@codeaurora.org
To: tgraf@suug.ch, herbert@gondor.apana.org.au,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	edumazet@google.com
Subject: Internal error: Oops  from inet_frag_find, when inserting a IP frag into a rhashtable
Date: Wed, 19 May 2021 00:52:27 +0530	[thread overview]
Message-ID: <997dfef63f2bd14acc2e478758bfc425@codeaurora.org> (raw)

Hi,

We are observing BUG_ON from the __get_vm_area_node when processing the 
IP fragments in the context of NET_RX.

When the rehashing is in progress and an insertion is attempted, we may 
end up doing a bucket_table_alloc, which results in BUG_ON if in 
interrupt context.
Is it the case that the slow path code has to be executed only in the 
context of rht_deferred_worker and not in any other context? OR are 
these scenario's not anticipated and is a missed handling?

Please provide your suggestions on proceeding further with this issue.

  static struct vm_struct *__get_vm_area_node(unsigned long size,
            unsigned long align, unsigned long flags, unsigned long 
start,
            unsigned long end, int node, gfp_t gfp_mask, const void 
*caller)
  {
     struct vmap_area *va;
     struct vm_struct *area;

       BUG_ON(in_interrupt()); --> Point of panic.

Panic stack:

784.185010:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754253]@2 
Workqueue: events rht_deferred_worker
    784.185020:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754262]@2 
pstate: 00c00005 (nzcv daif +PAN +UAO)
    784.185032:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754274]@2 pc 
: __get_vm_area_node.llvm.17374696036975823682+0x1ac/0x1c8
    784.185041:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754283]@2 lr 
: __vmalloc_node_flags_caller+0xb4/0x170
    784.185046:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754289]@2 sp 
: ffffffc0104135a0
    784.185052:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754295]@2 
x29: ffffffc0104135a0 x28: ffffff82ccbcae50
    784.185060:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754303]@2 
x27: ffffff82eea8d3c0 x26: ffffff800ad044b0
    784.185067:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754311]@2 
x25: fffffffffffffffe x24: fffffffffffffff5
    784.185075:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754318]@2 
x23: 0000000000001000 x22: 0068000000000f13
    784.185082:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754326]@2 
x21: 00000000ffffffff x20: 0000000000008040
    784.185090:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754333]@2 
x19: 0000000000002b20 x18: ffffffc0103ad0c0
    784.185097:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754340]@2 
x17: 00000000e1ba4003 x16: d101500000cf012a
    784.185104:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754347]@2 
x15: 52d39bfeffbfebd0 x14: 3130393837363534
    784.185111:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754355]@2 
x13: 000000003b1ad624 x12: 0000000000000000
    784.185118:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754362]@2 
x11: 000000000000002e x10: 0000000000000600
    784.185126:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754369]@2 x9 
: 00000000002c022a x8 : 0000000000000101
    784.185133:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754376]@2 x7 
: f6da030000000000 x6 : ffffffe14adb3990
    784.185140:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754384]@2 x5 
: 0000000000002b20 x4 : fffffffebfff0000
    784.185148:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754391]@2 x3 
: ffffffc010000000 x2 : 0000000000000022
    784.185155:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754398]@2 x1 
: 0000000000000001 x0 : 0000000000009000
    784.185164:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754406]@2 
Call trace:
   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
    784.185206:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754449]@2  
rhashtable_try_insert+0x3fc/0x478
    784.185213:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754455]@2  
rhashtable_insert_slow+0x34/0x5c
    784.185223:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754466]@2  
__rhashtable_insert_fast+0x368/0x4f0
    784.185234:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754476]@2  
inet_frag_find+0x21c/0x2a8
    784.185244:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754486]@2  
nf_ct_frag6_gather+0x1f4/0x2a0
    784.185252:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754494]@2  
ipv6_defrag+0x58/0x7c
    784.185262:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754504]@2  
nf_hook_slow+0xa8/0x148
    784.185272:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754514]@2  
ipv6_rcv+0x80/0xe4
    784.185282:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754524]@2  
__netif_receive_skb+0x84/0x17c
    784.185290:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754532]@2  
process_backlog+0x15c/0x1b8
    784.185297:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754539]@2  
napi_poll+0x88/0x284
    784.185304:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754547]@2  
net_rx_action+0xbc/0x23c
    784.185314:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754557]@2  
__do_softirq+0x1e8/0x44c
    784.185325:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754567]@2  
__local_bh_enable_ip+0xb8/0xc8
    784.185333:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754576]@2  
local_bh_enable+0x1c/0x28
    784.185340:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754583]@2  
rhashtable_rehash_chain+0x12c/0x1ec
    784.185347:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754590]@2  
rht_deferred_worker+0x13c/0x200
    784.185357:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754600]@2  
process_one_work+0x2cc/0x568
    784.185365:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754607]@2  
worker_thread+0x28c/0x524
    784.185373:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754616]@2  
kthread+0x184/0x194
    784.185381:   <2>  (2)[71:kworker/2:1][20210408_17:01:54.754623]@2  
ret_from_fork+0x10/0x18



             reply	other threads:[~2021-05-18 19:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-18 19:22 sharathv [this message]
2021-05-19 11:20 ` Internal error: Oops from inet_frag_find, when inserting a IP frag into a rhashtable Herbert Xu
2021-05-26 14:36   ` sharathv

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=997dfef63f2bd14acc2e478758bfc425@codeaurora.org \
    --to=sharathv@codeaurora.org \
    --cc=edumazet@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tgraf@suug.ch \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.