Date: Mon, 4 Mar 2019 10:09:38 -0500 From: Nick Rogers <ncrogers@gmail.com> To: Andriy Gapon <avg@freebsd.org> Cc: FreeBSD STABLE <freebsd-stable@freebsd.org> Subject: Re: 12.0-RELEASE zfs/vnode deadlock issue Message-ID: <CAKOb=Yb_4bVa1WQSD8A2Yq5CWOTAfLhkYdJ-V05BBGeGOUM6uw@mail.gmail.com> In-Reply-To: <233f3723-a78e-91db-ebe6-9e13c1c9b50d@FreeBSD.org> References: <CAKOb=YaLSPPRrLWGPbcDt0tKqS2h3mT2dLo92aK3r-8O%2B3SHTw@mail.gmail.com> <233f3723-a78e-91db-ebe6-9e13c1c9b50d@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the insight, it does appear that in all instances of this problem there is always one thread stuck on zfs_znode_alloc. Unfortunately its always a different application (e.g., perl, sh, postgres). I will post more information in the bug. On Sat, Mar 2, 2019 at 12:48 PM Andriy Gapon <avg@freebsd.org> wrote: > On 01/03/2019 17:00, Nick Rogers wrote: > > 36704 101146 perl - mi_switch+0xe1 > > sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_xlock_hard+0x19c > VOP_LOCK1_APV+0x7e > > _vn_lock+0x40 zfs_znode_alloc+0x434 zfs_mknode+0xa9d > > zfs_freebsd_create+0x512 VOP_CREATE_APV+0x78 vn_open_cred+0x2c9 > > kern_openat+0x20c amd64_syscall+0x369 fast_syscall_common+0x101 > > I suspect that this thread is a root cause of the problem. > In this place, the vnode should be freshly created and not visible to > anything > but the current thread. So, vn_lock() should always immediately succeed. > I > cannot understand how the vnode lock could be held by another thread. > > -- > Andriy Gapon >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKOb=Yb_4bVa1WQSD8A2Yq5CWOTAfLhkYdJ-V05BBGeGOUM6uw>