From owner-freebsd-current@freebsd.org Tue Dec 8 15:40:21 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 1FF0B4A3856 for ; Tue, 8 Dec 2020 15:40:21 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4Cr4BX6Yhlz4VRr for ; Tue, 8 Dec 2020 15:40:20 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id DEFDC4A33FB; Tue, 8 Dec 2020 15:40:20 +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 DEC464A33FA for ; Tue, 8 Dec 2020 15:40:20 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 4Cr4BX5RZlz4VML; Tue, 8 Dec 2020 15:40:20 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wr1-x431.google.com with SMTP id i9so1093641wrc.4; Tue, 08 Dec 2020 07:40:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eGwouswWLx+VuTsnhgvIb9qp97TQDL+AvtCIdI+YVJY=; b=se4KbeLTnOrDgJb/qz/U8PIi3evEyo63yeCYaWxe2OXsI9KZ3M/zsXsQhWDznlFTu9 SUfkIr6aese0gQz0YmZQ4OooC0wr3fjPj8g+Fv8SAUQFwFQe31do8FhR+OBTeEZfQGA+ FPeheiyhQFdw1eToZVYgF5x8jHGDMNMjeRaX5MiT11TBqzvpVVkJE2+tMN7G7M5qCord IRxc+4HLHudil56RzelNbUNH+dcqD+vy0PdrWm55dRP0ZRsh8InvI+zaSdBsJ1mikyP/ 3sE28pbbiJK3TjEYdSez5e2ykntIsT8mVAg/n/DUF0Nr+6SYjqWGvH/lGFUOVxg6K7jV nwIQ== X-Gm-Message-State: AOAM530B+rPMWx4p+q1GSDJ9wBhgnGO+v0+zMAOY1PrZQ+G9DVPt/i8p wQkczLNj81URhh0csu5pxrR0aG4lyX0pU8Nwaz3uZh1M/AE= X-Google-Smtp-Source: ABdhPJyqbdQSQZ9uOJm8GXLobBd0o3eTYOmSDMryLeDxonpnOfTIu+W6uX12PMUZMRyh77bs+99ZZCSxsLn9+eHIfdY= X-Received: by 2002:adf:ec86:: with SMTP id z6mr8890796wrn.17.1607442017937; Tue, 08 Dec 2020 07:40:17 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a5d:4d47:0:0:0:0:0 with HTTP; Tue, 8 Dec 2020 07:40:16 -0800 (PST) In-Reply-To: References: <20201208114718.GA33199@x8.osted.lan> From: Mateusz Guzik Date: Tue, 8 Dec 2020 16:40:16 +0100 Message-ID: Subject: Re: panic: general protection fault from uipc_sockaddr+0x4c To: Mark Johnston Cc: Peter Holm , current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Cr4BX5RZlz4VML 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:40:21 -0000 I think this is a long standing bug against exiting processes. filedesc_out only increments *hold* count, but that does not prevent fdescfree_fds from progressing and freeing everything without any locks held. A hotfix (for mfc) would add locking around it, but a long term fix should wait for hold count to drain. By that point there can't be any new arrivals due to: PROC_LOCK(p); p->p_fd = NULL; PROC_UNLOCK(p); I'll code both later today. On 12/8/20, Mark Johnston wrote: > 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? > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Mateusz Guzik