Date: Sun, 28 Jul 2013 05:30:01 GMT From: David Noel <david.i.noel@gmail.com> To: freebsd-amd64@FreeBSD.org Subject: Re: amd64/180894: rm -rf causes kernel panic Message-ID: <201307280530.r6S5U1da063412@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR amd64/180894; it has been noted by GNATS.
From: David Noel <david.i.noel@gmail.com>
To: bug-followup@FreeBSD.org
Cc:
Subject: Re: amd64/180894: rm -rf causes kernel panic
Date: Sun, 28 Jul 2013 00:20:58 -0500
From the freebsd-questions mailing list a solution was proposed by
Frank Leonhardt <frank2@fjl.co.uk>:
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.
----
Maybe something along these lines would be a reasonable fix?
-David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201307280530.r6S5U1da063412>