Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Oct 2019 09:56:16 -0400
From:      Mark Johnston <markj@freebsd.org>
To:        Hans Petter Selasky <hps@selasky.org>
Cc:        Yuri Pankov <yuripv@yuripv.net>, freebsd-net <freebsd-net@freebsd.org>, Gleb Smirnoff <glebius@freebsd.org>
Subject:   Re: panic: sleeping in an epoch section
Message-ID:  <20191009135616.GC66126@raichu>
In-Reply-To: <050ba95e-d0d5-dd1a-db6f-9a5c07142efe@selasky.org>
References:  <86cc5d82-50d0-93eb-5900-54e8b0032a08@yuripv.net> <050ba95e-d0d5-dd1a-db6f-9a5c07142efe@selasky.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191009135616.GC66126>