Date: Tue, 8 Dec 2020 17:12:35 +0100 From: Mateusz Guzik <mjguzik@gmail.com> To: Mark Johnston <markj@freebsd.org> Cc: Peter Holm <pho@freebsd.org>, current@freebsd.org Subject: Re: panic: general protection fault from uipc_sockaddr+0x4c Message-ID: <CAGudoHEczkVKQnQ---2YcXEZi0YB_=B%2BefmTBemNJk7JukxOVg@mail.gmail.com> In-Reply-To: <X8%2BkTeiw7tBeRKOv@raichu> References: <20201208114718.GA33199@x8.osted.lan> <X8%2BcIUFKzzOSnl4L@raichu> <CAGudoHEdFaaYb9QjZBad%2BVzFjyvzB1cxXGsv8kB0rNqSfFzY3A@mail.gmail.com> <X8%2BkTeiw7tBeRKOv@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/8/20, Mark Johnston <markj@freebsd.org> wrote: > On Tue, Dec 08, 2020 at 04:40:16PM +0100, Mateusz Guzik wrote: >> 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. > > I think it is fallout from r367777: before that, fdescfree() acquired > and released the exclusive fd table lock between decrementing > fdp->fd_refcount and calling fdescfree_fds(). This would serialize with > the loop in kern_proc_fildesc_out(), which checks fdp->fd_refcount > 0 > at the beginning of each iteration. Now there is no serialization and > they can race. > Oh I forgot consumers keep checking for fd_refcount. In that case probably would be best to add sx_wait_unlocked. >> 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. > -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHEczkVKQnQ---2YcXEZi0YB_=B%2BefmTBemNJk7JukxOVg>