From owner-freebsd-net@freebsd.org Wed Oct 9 14:47:09 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CAE1914DFDA for ; Wed, 9 Oct 2019 14:47:09 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46pH9m4vtbz4X1r; Wed, 9 Oct 2019 14:47:08 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x744.google.com with SMTP id f16so2432973qkl.9; Wed, 09 Oct 2019 07:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=vgCjQRZ+0VjtRZjNB7/4afgaaeIyNKgMfS7K5DX9W40=; b=atnvshNRIAKJOP9ysB9DUsOct/F25IOp8vq9EldKjCcE3/Bve2pywcm0BIq6DSaBbb InfY7muCLuYXPZDp9sjbM/kZEslaYuPlxHtfWO3jeWgeKilaJJ6dTwJkd8otPbYcAac1 ZqQOeFCHpP4SYT/8BnOI8Gdz0kKyWIbU2CrMVPVBIDmv6kAuHavg2atkgfgFV3mgcMsz 2iGHQ+1JDo41LoKVVS1VPcVmH/iU3k4kUc1tWaQpJSkX8FE1SjH6kQpd9Rmejj9+Qcli +s9ZnJHVVZ8l2dCFf/jT03kVcVfriVNwqO4XeDsbJHAIxZDESL9i2v6BHqxqJya8X7hP DXSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=vgCjQRZ+0VjtRZjNB7/4afgaaeIyNKgMfS7K5DX9W40=; b=CRC5W77yCyLWeI0VpTbMFAYJLlEd7NWcctFYqhiJt57opdjovAU6wKQs2bVvEjFOd0 tD0QCNGut8GQbvHYN3D7iq6u7rkdxYkNnF8Zjk+fIGdEdYwNcwKNV8mEbB7mOGbQvnTc imih91w/brecHuLc5czjJVrNZxcxlYus46g8tDTwQsTnH0goio7TmDEcxG8IpU3qcZBt M6ECoNMhe4e9V5OiIuu1Uw0EgIuu8TL7MZejGMRKFOuau/beEGCpO2CNJOa73QL/mk3e IznpP+lblD5QTgAnK8mQGtKl5CIz/y+AflXKgpovd6LzwZdnQhqRNW6yG0H6tXyE1+YR mg4g== X-Gm-Message-State: APjAAAUhzOOz4D0CexxD794cHszjoVOJByQEDt//a1oxQ3MiLGBQxp5T bH8VkyQz89AV32AxFp2FbqQ1hvJh X-Google-Smtp-Source: APXvYqy1QipoMmQByDP1wzIE2k7u+7oP6QnUyJiiL664LQ8PgFHRa2TUPYbXNSAPKU8vwzr00WhFCQ== X-Received: by 2002:a37:7c42:: with SMTP id x63mr4039420qkc.332.1570632427515; Wed, 09 Oct 2019 07:47:07 -0700 (PDT) Received: from raichu (toroon0560w-lp130-05-69-158-183-252.dsl.bell.ca. [69.158.183.252]) by smtp.gmail.com with ESMTPSA id x59sm1141036qte.20.2019.10.09.07.47.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Oct 2019 07:47:06 -0700 (PDT) Sender: Mark Johnston Date: Wed, 9 Oct 2019 10:47:04 -0400 From: Mark Johnston To: Hans Petter Selasky Cc: Yuri Pankov , freebsd-net , glebius@freebsd.org Subject: Re: panic: sleeping in an epoch section Message-ID: <20191009144704.GD66126@raichu> References: <86cc5d82-50d0-93eb-5900-54e8b0032a08@yuripv.net> <050ba95e-d0d5-dd1a-db6f-9a5c07142efe@selasky.org> <20191009135616.GC66126@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 46pH9m4vtbz4X1r X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=atnvshNR; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::744 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.19 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_IN_DNSWL_NONE(0.00)[4.4.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.49)[ip: (2.25), ipnet: 2607:f8b0::/32(-2.53), asn: 15169(-2.14), country: US(-0.05)]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 14:47:09 -0000 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.