Delete a directory, crash the system

[cpghost]

On 07/27/13 20:57, David Noel wrote:
>> So the system panics in ufs_rmdir(). Maybe the filesystem is
>> corrupt? Have you tried to fsck(8) it manually?
> 
> fsck worked, though I had to boot from a USB image because I couldn't
> get into single user.. for some odd reason.
> 
>> Even if the filesystem is corrupt, ufs_rmdir() shouldn't
>> panic(), IMHO, but fail gracefully. Hmmm...
> 
> Yeah, I was pretty surprised. I think I tried it like 3 times to be
> sure... and yeah, each time... kaboom! Who'd have thought. Do I just
> post this to the mailing list and hope some benevolent developer
> stumbles upon it and takes it upon him/herself to "fix" this, or where
> do I find the FreeBSD Suggestion Box? I guess I should file a Problem
> Report and see what happens from there.

Maybe you could ask on freebsd-fs at . That's the list where the
filesystem hackers are hanging around.

Basically, from /usr/src/sys/ufs/ufs/ufs_vnops.c:ufs_rmdir():

if (dp->i_effnlink < 3)
  panic("ufs_dirrem: Bad link count %d on parent", dp->i_effnlink);

if (!ufs_dirempty(ip, dp->i_number, cnp->cn_cred)) {
                error = ENOTEMPTY;
                goto out;
        }

(...)

Basically, the parent directory has less than 3 entries, but
since 2 entries are mandatory ("." and ".."), the 3rd entry
that is missing must belong to the directory being removed.

This is inconsistent. And if the parent directory is inconsistent,
other bad things could happen. The kernel errs on the side of
caution, and panic()s instead of silently returning EINVAL.
Actually, this is a sensible thing to do in this context.

A more robust file system would halt all processes, and perform
an in-kernel fsck on the filesystem and its internal (in-memory)
structures to repair the damage... and THEN resume the processes.

However, this is a major project, and we don't have a self-healing
filesystem / kernel (... yet). ;-)

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/