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=234906 --- Comment #16 from Conrad Meyer <cem@freebsd.org> --- Re secondary panic, we drop UMP lock around setup_inomapdep, but that should be ok because we still hold the CG buf exclusively -- no one else should be able 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 — 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 link 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 more 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 would hit 'ffs_valloc: dup alloc' shortly afterwards when we noticed the dinode was already initialized. Either way, (as far as I can tell) path lookup does not confirm that an inode referred to by a directory entry is actually allocated in the CG bitmap. It 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 bitmap, 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. -- 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>