Delete a directory, crash the system

[Frank Leonhardt]

On 27/07/2013 19: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.
>

I was going to raise an issue when the discussion had died down to a 
concensus. I also don't think it's reasonable for the kernel to bomb 
when it encounters corruption on a disk.

If you want to patch it yourself, edit sys/ufs/ufs/ufs_vnops.c at around 
line 2791 change:

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

To

         if (dp->i_effnlink < 3) {
                 error = EINVAL;
                 goto out;
         }

The ufs_link() call has a similar issue.

I can't see why my mod will break anything, but there's always 
unintended consequences. By returning invalid argument, any code above 
it should already be handling that condition although the user will be 
scratching their head wondering what's wrong with it. Returning ENOENT 
or EACCES or ENOTDIR may be better ("No such directory", "Access denied" 
or "Not a valid directory").

The trouble is that it's tricky to test properly without finding a good 
way to corrupt the link count :-)

Regards, Frank.