From owner-freebsd-net@freebsd.org Wed Mar 24 15:42:50 2021 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 A3FE15B8F10 for ; Wed, 24 Mar 2021 15:42:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5CDV458yz4dmP for ; Wed, 24 Mar 2021 15:42:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 8BBF45B8BB3; Wed, 24 Mar 2021 15:42:50 +0000 (UTC) Delivered-To: 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 8B8325B8F0F for ; Wed, 24 Mar 2021 15:42:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F5CDV3TPnz4dVd for ; Wed, 24 Mar 2021 15:42:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6A94616E88 for ; Wed, 24 Mar 2021 15:42:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 12OFgo2Y026697 for ; Wed, 24 Mar 2021 15:42:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 12OFgoF6026696 for net@FreeBSD.org; Wed, 24 Mar 2021 15:42:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 254478] Panic when using ipfw and divert sockets Date: Wed, 24 Mar 2021 15:42:50 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.2-RELEASE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: daniel+freebsd@kempkens.io X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable13? mfc-stable12? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 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, 24 Mar 2021 15:42:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254478 --- Comment #3 from Daniel Kempkens --- (In reply to Andrey V. Elsukov from comment #1) > I think such problem can be reproduced if you will do open/close divert s= ocket in a loop. Is it possible that your application sometimes does that? We were not able to confirm that this actually happens (yet), but we're fai= rly certain that under the right conditions what you described can indeed happe= n. We have added some logging to confirm our suspicions. Sadly no ETA on when we can try this in production again. We're still worki= ng on a setup to reproduce this in our development environment. > Can you show what contains inp in the last kgdb command? Sure! (kgdb) print *inp $6 =3D {inp_hash =3D {cle_next =3D 0xfffff804bfdd5b70, cle_prev =3D 0xfffff8012784ae20}, inp_pcbgrouphash =3D {cle_next =3D 0x0, cle_prev =3D 0= x0}, inp_lock =3D {lock_object =3D { lo_name =3D 0xffffffff82515931 "divinp", lo_flags =3D 90898432, lo_da= ta =3D 0, lo_witness =3D 0x0}, rw_lock =3D 33}, inp_hpts =3D {tqe_next =3D 0x0, tqe_p= rev =3D 0x0}, inp_hpts_request =3D 0, inp_in_hpts =3D 0 '____preserved_4____00', inp_in= _input =3D 0 '____preserved_4____00', inp_hpts_cpu =3D 0, inp_refcount =3D 1, inp_flag= s =3D 8388616, inp_flags2 =3D 16, inp_input_cpu =3D 0, inp_hpts_cpu_set =3D 0 '____preserved_4____00', inp_input_cpu_set =3D 0 '____preserved_4____00', inp_hpts_calls =3D 0 '____preserved_4____00', inp_input_calls =3D 0 '____preserved_4____00', inp_spare_bits2 =3D 0 '____preserved_4____00', inp_spare_byte =3D 0 '____preserved_4____00', inp_ppcb =3D 0x0, inp_socket =3D 0x0, inp_hptsslot =3D 0, inp_hpts_drop_r= eas =3D 0, inp_input =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, inp_pcbinfo =3D 0xfffff= e00006f4538, inp_pcbgroup =3D 0x0, inp_pcbgroup_wild =3D {cle_next =3D 0x0, cle_prev = =3D 0x0}, inp_cred =3D 0xfffff801318fa200, inp_flow =3D 0, inp_vflag =3D 1 '____preserved_4____01', inp_ip_ttl =3D 0 '____preserved_4____00', inp_ip_p =3D 2 '____preserved_4____02', inp_ip_minttl =3D 0 '____preserved_4____00', inp_flowid =3D 0, inp_snd_tag =3D 0x0, inp_flowtyp= e =3D 0, inp_rss_listen_bucket =3D 0, inp_inc =3D {inc_flags =3D 0 '____preserved_4_= ___00', inc_len =3D 0 '____preserved_4____00', inc_fibnum =3D 0, inc_ie =3D {ie= _fport =3D 0, ie_lport =3D 10787, ie_dependfaddr =3D {id46_addr =3D {ia46_pad32 =3D {0= , 0, 0}, ia46_addr4 =3D {s_addr =3D 0}}, id6_addr =3D { __u6_addr =3D {__u6_addr8 =3D '____preserved_4____00' , __u6_addr16 =3D {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 =3D {0, 0, 0, 0}}}}, ie_dependladdr =3D {id46_addr =3D { ia46_pad32 =3D {0, 0, 0}, ia46_addr4 =3D {s_addr =3D 0}}, id6_add= r =3D {__u6_addr =3D {__u6_addr8 =3D '____preserved_4____00' , __u6_addr16 =3D {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 =3D {0, 0, 0, 0}}}}, ie6_zoneid =3D 0}}, inp_label = =3D 0x0, inp_sp =3D 0xfffff80127913ee0, {inp_ip_tos =3D 0 '____preserved_4____00', inp_options =3D 0x0, inp_moptions =3D 0x0}, { in6p_options =3D 0x0, in6p_outputopts =3D 0x0, in6p_moptions =3D 0x0, in6p_icmp6filt =3D 0x0, in6p_cksum =3D 0, in6p_hops =3D 0}, inp_portlist = =3D {cle_next =3D 0x0, cle_prev =3D 0xfffff80127c450a0}, inp_phd =3D 0xfffff80127c45080, inp_g= encnt =3D 74, spare_ptr =3D 0x0, inp_rt_cookie =3D 0, {inp_route =3D {ro_rt =3D 0x0, = ro_lle =3D 0x0, ro_prepend =3D 0x0, ro_plen =3D 0, ro_flags =3D 256, ro_mtu =3D 0, sp= are =3D 0, ro_dst =3D {sa_len =3D 0 '____preserved_4____00', sa_family =3D 0 '____preserved_4____00', sa_data =3D '____preserved_4____00' }}, inp_route6 =3D {ro_rt =3D 0x0, ro_lle =3D 0x0, ro_prepend =3D 0x0, ro_p= len =3D 0, ro_flags =3D 256, ro_mtu =3D 0, spare =3D 0, ro_dst =3D {sin6_len =3D 0 '____preserved_4____00', sin6_family =3D 0 '____preserved_4____00', sin6_port =3D 0, sin6_flowinfo =3D 0, sin6_addr =3D {__u6_addr =3D = {__u6_addr8 =3D '____preserved_4____00' , __u6_addr16 =3D {0, 0, 0, 0= , 0, 0, 0, 0}, __u6_addr32 =3D {0, 0, 0, 0}}}, sin6_scope_id =3D 0}}}, inp_list =3D {cle_next =3D 0xfffff804bfdd5b70, cle_prev =3D 0xfffffe00006f4530}, inp_epoch_ctx =3D {da= ta =3D { 0xffffffff80d43b00 , 0xfffff80127c45088}}} --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.=