[Bug 234906] kernel panic: softdep_setup_inomapdep: dependency 0xfffff80107d15c00 for newinode already exists

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sun Jan 13 23:56:16 UTC 2019


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234906

--- Comment #16 from Conrad Meyer <cem at 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.


More information about the freebsd-fs mailing list