[Bug 254514] vnet: /sbin/ifconfig epair10b vnet $name getting stuck if one CPU is busy

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254514

            Bug ID: 254514
           Summary: vnet: /sbin/ifconfig epair10b vnet $name getting stuck
                    if one CPU is busy
           Product: Base System
           Version: 13.0-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: misc
          Assignee: bugs at FreeBSD.org
          Reporter: me at igalic.co

This bug bubbled up as a side-effect to:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254513

jail startup is stuck at:

/sbin/ifconfig epair10b vnet $name

when we run procstat kstack, we see for the different jails:

  913 100682 ifconfig            -                   mi_switch _sx_xlock_hard
epoch_drain_callbacks if_detach_internal if_vmove ifhwioctl ifioctl kern_ioctl
sys_ioctl amd64_syscall fast_syscall_common 

  835 100475 ifconfig            -                   mi_switch sched_bind
epoch_drain_callbacks if_detach_internal if_vmove ifhwioctl ifioctl kern_ioctl
sys_ioctl amd64_syscall fast_syscall_common 

similarly, trying to destroy an epair also gets stuck:

 1119 100988 ifconfig            -                   mi_switch _sx_xlock_hard
epoch_drain_callbacks if_detach_internal if_detach epair_clone_destroy
if_clone_destroyif if_clone_destroy ifioctl kern_ioctl sys_ioctl amd64_syscall
fast_syscall_common 

given that this is a side-effect of 1 CPU core being 100% busy, does this mean
that draining callbacks needs all CPUs?

-- 
You are receiving this mail because:
You are the assignee for the bug.