panic: sleeping in an epoch section

[Xin Li]

On 2019-10-09 08:07, Gleb Smirnoff wrote:
> Yes, I we should allow sleep in ifioctl handlers. So this is my fault, I'll
> handle it today.

It seems that -CURRENT as of today would panic with:

(kgdb) #0  doadump (textdump=1) at src/sys/amd64/include/pcpu_aux.h:55
#1  0xffffffff80bbe550 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:479
#2  0xffffffff80bbe9a6 in vpanic (fmt=<value optimized out>,
    ap=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:908
#3  0xffffffff80bbe703 in panic (fmt=<value optimized out>)
    at /usr/src/sys/kern/kern_shutdown.c:835
#4  0xffffffff80e0d1f8 in in6ifa_llaonifp (ifp=<value optimized out>)
    at /usr/src/sys/netinet6/in6.c:1554
#5  0xffffffff84cb3bcd in lagg_ioctl (ifp=0xfffff80019322000,
    cmd=<value optimized out>, data=<value optimized out>)
    at /usr/src/sys/net/if_lagg.c:1427
#6  0xffffffff80d4c281 in in_control (cmd=2152229261,
    data=0xfffffe00e01fd7d0 "lagg0", ifp=0xfffff80019322000,
    td=0xfffff80019675000) at /usr/src/sys/netinet/in.c:262
#7  0xffffffff80ccc6be in ifioctl (so=0xfffff8001c15c710, cmd=2152229261,
    data=0xfffffe00e01fd7d0 "lagg0", td=0xfffff80019675000)
    at /usr/src/sys/net/if.c:3106
#8  0xffffffff80c2fc35 in kern_ioctl (td=<value optimized out>,
    fd=<value optimized out>, com=<value optimized out>,
    data=<value optimized out>) at src/sys/sys/file.h:340
#9  0xffffffff80c2f92c in sys_ioctl (td=0xfffff80019675000,
    uap=0xfffff800196753c8) at /usr/src/sys/kern/sys_generic.c:709
#10 0xffffffff8102ee45 in amd64_syscall (td=0xfffff80019675000, traced=0)
    at src/sys/amd64/amd64/../../kern/subr_syscall.c:144
#11 0xffffffff810054e0 in fast_syscall_common ()
    at /usr/src/sys/amd64/amd64/exception.S:581
#12 0x000000080047db8a in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal

My configuration is somewhat special:  I have a lagg0 (failover) group
containing em0 and wlan0:

ifconfig_wlan0="WPA"
ifconfig_em0="ether (ethernet address of wlan0) up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP"
ifconfig_lagg0_ipv6="inet6 accept_rtadv"

Without that lagg0 setup, with only wlan0 configured to DHCP and
accept_rtadv, the system would boot further and network access appears
to work.

By the way I think there are some recent change (not sure when, but it
happen since August) to either e1000 or iflib have made the driver to
expose its e1000_delay state quite a bit when ifconfig or dhclient is
trying to configure the lagg0 group, when the wired connection is not
available.

Cheers,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20191013/64d895f7/attachment.sig>