Skip site navigation (1)Skip section navigation (2)
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>