Am 09.10.2019 um 16:47 schrieb Mark Johnston:
On Wed, Oct 09, 2019 at 04:18:34PM +0200, Hans Petter Selasky wrote:
On 2019-10-09 15:56, Mark Johnston wrote:
On Wed, Oct 09, 2019 at 10:40:04AM +0200, Hans Petter Selasky wrote:
On 2019-10-09 06:36, Yuri Pankov wrote:
Tried updating from r353072 to r353334 and getting the following panic
reproducibly on boot (starting dhclient?):
panic: sleeping in an epoch section
cpuid = 5
time = 1570591558
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfffffe00af780140
vpanic() at vpanic+0x19d/frame 0xfffffe00af780190
panic() at panic+0x43/frame 0xfffffe00af7801f0
_sleep() at _sleep+0x463/frame 0xfffffe00af780290
pause_sbt() at pause_sbt+0x10f/frame 0xfffffe00af7802d0
e1000_write_phy_reg_mdic() at e1000_write_phy_reg_mdic+0xee/frame
0xfffffe00af780310
e1000_enable_phy_wakeup_reg_access_bm() at
e1000_enable_phy_wakeup_reg_access_bm+0x2b/frame 0xfffffe00af780330
e1000_update_mc_addr_list_pch2lan() at
e1000_update_mc_addr_list_pch2lan+0x3a/frame 0xfffffe00af780370
em_if_multi_set() at em_if_multi_set+0x1d4/frame 0xfffffe00af7803c0
iflib_if_ioctl() at iflib_if_ioctl+0x100/frame 0xfffffe00af780430
if_addmulti() at if_addmulti+0x2af/frame 0xfffffe00af7804d0
in_joingroup_locked() at in_joingroup_locked+0x235/frame 0xfffffe00af780570
in_joingroup() at in_joingroup+0x5c/frame 0xfffffe00af7805d0
in_control() at in_control+0xadf/frame 0xfffffe00af780680
ifioctl() at ifioctl+0x40f/frame 0xfffffe00af780750
kern_ioctl() at kern_ioctl+0x295/frame 0xfffffe00af7807b0
sys_ioctl() at sys_ioctl+0x15d/frame 0xfffffe00af780880
amd64_syscall() at amd64_syscall+0x2b9/frame 0xfffffe00af7809b0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe00af7809b0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80048051a, rsp =
0x7fffffffe3e8, rbp = 0x7fffffffe430 ---
The SIOCADDMULTI if_ioctl() is not allowed to sleep, because it can be
called from the fast-path, so this is a bug in e1000 driver. Does the
attached patch workaround the issue?
What fast path are you referring to? The locking protocol used by the
multicast code was changed specifically to allow for sleeps in driver
ioctl handlers.
I recall a long time ago seeing that input packet processing may end up
calling if_ioctl's . Things may have changed since then though.
That may be true in general, but I can't see any instances of that
for SIOCADDMULTI or SIOCDELMULTI. I think we should always permit ioctl
handlers to sleep. In particular, the panic reported above is a bug in
r353292.
Hope you don't ming hijacking your attention to something problably
related, but definitely not to r353292:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240609
Thanks,
-harry
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
