Date: Sun, 13 Jan 2019 23:56:14 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 234906] kernel panic: softdep_setup_inomapdep: dependency 0xfffff80107d15c00 for newinode already exists Message-ID: <bug-234906-3630-LFPaz2xJem@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-234906-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-234906-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234906 --- Comment #16 from Conrad Meyer <cem@freebsd.org> --- Re secondary panic, we drop UMP lock around setup_inomapdep, but that shoul= d be ok because we still hold the CG buf exclusively -- no one else should be ab= le to allocate the same inode number. I think the panic could be explained by the inode being allocated but unreferenced in the CG bitmap. Possibly due to violation of ordering constraints implied by the first panic =E2=80=94 e.g., inode and directory = entry written, but CG bitmap stale. Or perhaps dirent is stale. Or possibly due= to write-cache enabled disk (which is another way SU ordering constraints can = be violated). But the handle_written_bmsafemap <-> softdep_setup_inomapdep li= nk is suspicious to me and I suspect they are directly related. I would guess CG bitmap accuracy is enforced for non-SU filesystems by a mo= re thorough fsck on dirty mount, but might be mistaken. On non-SU we would not hit this panic because the inodedep would not exist, of course. But we wou= ld hit 'ffs_valloc: dup alloc' shortly afterwards when we noticed the dinode w= as already initialized. Either way, (as far as I can tell) path lookup does not confirm that an ino= de referred to by a directory entry is actually allocated in the CG bitmap. I= t is simply assumed to be consistent. So you might have an active UFS vnode with that inode number with inodedeps for a variety of reasons, and some thread comes along and tries to create a file; that number is free in the CG bitma= p, so the second thread acquires it; and then the creating thread collides with the existing softdep work. I don't know of a good way to fix the secondary panic. A good next step would be to determine if your drives have write caching disabled, and if the drive model is known to respect that bit or not. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-234906-3630-LFPaz2xJem>