From owner-freebsd-current@freebsd.org Tue Dec 8 15:30:48 2020 Return-Path: Delivered-To: freebsd-current@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 8B8EE4A2DCD for ; Tue, 8 Dec 2020 15:30:48 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Cr3zX1gTsz4Swy for ; Tue, 8 Dec 2020 15:30:48 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 378684A2DCC; Tue, 8 Dec 2020 15:30:48 +0000 (UTC) Delivered-To: current@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 3629A4A2E44 for ; Tue, 8 Dec 2020 15:30:48 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Cr3zX08T1z4T0X; Tue, 8 Dec 2020 15:30:47 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qv1-xf30.google.com with SMTP id a13so3287271qvv.0; Tue, 08 Dec 2020 07:30:47 -0800 (PST) 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; bh=UNX6XQgQ47dgYHV4Bmv6M6AB5P9o/MnRWf7p4gaaU2M=; b=ZmgWLZv2DEdLvLW1SBGL6d7bVQ95Kd4+zuhhK4UF7++xngGCVjbVuhoMN5E8KyLX9Q u/BrZ9rSPoDe5arJHEQpJ89g8/o0/vDNG9cl+P61ZeyByem4Jv+NJXCLdMAPV6nvHfEa CCBxhoz2Oy18tg/Hwm06mKbOlZ4b7WHgnyK/K377LLuf/tCZxh5BRRtFxMf8z2hWJC/r /wcFaRpuHBdpJu/pliBzGGbaK4cjGY7jwn5f6Fq/XALTqflmw0/7T3kl57KiFZu/mDq+ RUiSzvvEfyty2Y5/Tay2p/AJ+wnctq8JKclyBMyU0vOVKKvdrQWLEb+UoNvICc2fuXDm kstA== X-Gm-Message-State: AOAM531Kv+/bOwlD+GbIr9y038NlgS1RDsj0AUsPQVZRNODY/uj6gsXK epYYTVYmo0ovuB7//2eDwJCcEnyMgK8= X-Google-Smtp-Source: ABdhPJyk/icsoywsYqqMd/aNSJaesWFqh734IKIEzORUJZXjmrlSoQadJTDIO3bcP7DwPs9srMr/+g== X-Received: by 2002:a05:6214:a03:: with SMTP id dw3mr11874429qvb.24.1607441446792; Tue, 08 Dec 2020 07:30:46 -0800 (PST) Received: from raichu ([142.126.164.150]) by smtp.gmail.com with ESMTPSA id q27sm4936908qkj.131.2020.12.08.07.30.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Dec 2020 07:30:45 -0800 (PST) Sender: Mark Johnston Date: Tue, 8 Dec 2020 10:30:41 -0500 From: Mark Johnston To: Peter Holm Cc: current@freebsd.org Subject: Re: panic: general protection fault from uipc_sockaddr+0x4c Message-ID: References: <20201208114718.GA33199@x8.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201208114718.GA33199@x8.osted.lan> X-Rspamd-Queue-Id: 4Cr3zX08T1z4T0X X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 15:30:48 -0000 On Tue, Dec 08, 2020 at 12:47:18PM +0100, Peter Holm wrote: > I just got this panic: > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 9; apic id = 09 > instruction pointer = 0x20:0xffffffff80bc6e22 > stack pointer = 0x28:0xfffffe0698887630 > frame pointer = 0x28:0xfffffe06988876b0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 45966 (fstat) > trap number = 9 > panic: general protection fault > cpuid = 9 > time = 1607416693 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0698887340 > vpanic() at vpanic+0x181/frame 0xfffffe0698887390 > panic() at panic+0x43/frame 0xfffffe06988873f0 > trap_fatal() at trap_fatal+0x387/frame 0xfffffe0698887450 > trap() at trap+0xa4/frame 0xfffffe0698887560 > calltrap() at calltrap+0x8/frame 0xfffffe0698887560 > --- trap 0x9, rip = 0xffffffff80bc6e22, rsp = 0xfffffe0698887630, rbp = 0xfffffe06988876b0 --- > __mtx_lock_sleep() at __mtx_lock_sleep+0xd2/frame 0xfffffe06988876b0 > __mtx_lock_flags() at __mtx_lock_flags+0xe5/frame 0xfffffe0698887700 > uipc_sockaddr() at uipc_sockaddr+0x4c/frame 0xfffffe0698887730 > soo_fill_kinfo() at soo_fill_kinfo+0x11e/frame 0xfffffe0698887770 > kern_proc_filedesc_out() at kern_proc_filedesc_out+0xb57/frame 0xfffffe0698887810 > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x7d/frame 0xfffffe0698887890 > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame 0xfffffe06988878e0 > sysctl_root() at sysctl_root+0x20d/frame 0xfffffe0698887960 > userland_sysctl() at userland_sysctl+0x180/frame 0xfffffe0698887a10 > sys___sysctl() at sys___sysctl+0x5f/frame 0xfffffe0698887ac0 > amd64_syscall() at amd64_syscall+0x147/frame 0xfffffe0698887bf0 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0698887bf0 > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8003948ea, rsp = 0x7fffffffc138, rbp = 0x7fffffffc170 --- > > https://people.freebsd.org/~pho/stress/log/log0004.txt So here the unpcb is freed, and indeed the file itself has been closed: $3 = {f_flag = 0x3, f_count = 0x0, f_data = 0x0, f_ops = 0xffffffff81901f50 , f_vnode = 0x0, f_cred = 0xfffff80248beb600, f_type = 0x2, f_vnread_flags = 0x0, {f_seqcount = {0x0, 0x0}, f_pipegen = 0x0}, f_nextoff = {0x0, 0x0}, f_vnun = {fvn_cdevpriv = 0x0, fvn_advice = 0x0}, f_offset = 0x0} However, it must have happened very recently because soo_fill_kinfo() dereferences fp->f_data and yet we did not panic due to a null dereference. kern_proc_filedesc_out() holds the fdtable shared lock thoughout all of this, which is supposed to prevent the table entry from being freed since that requires the exclusive lock. Could you show fdp->fd_ofiles[3] and fdp->fd_map[0] from frame 26?