Date: Sat, 27 Jul 2013 16:02:09 +0100 From: Frank Leonhardt <frank2@fjl.co.uk> To: freebsd-questions@freebsd.org Subject: Re: Delete a directory, crash the system Message-ID: <51F3E0F1.3010401@fjl.co.uk> In-Reply-To: <CAHAXwYCnRDQqgRcvaEE1BmSJYYOidoQzzUoHX_QWdyJzYO3kKw@mail.gmail.com> References: <CAHAXwYDPMrdY-TP-5T1_6M_ot4gY09jo2_Wi_REOmE=%2Bu%2B_QuQ@mail.gmail.com> <CAGwOe2byRc4LVsyxvTJgxNGCbhvOEaeDXjmFJ7DoXThPQe1bcQ@mail.gmail.com> <CAHAXwYCj9AV8ZcDffNNGx-ivL=h_TK9zLQRTPknArX25HSfEag@mail.gmail.com> <CAGwOe2YCDRqHudovDB_Kz9WHppvB8v2L%2B0gkDnWgG88bgZTKSA@mail.gmail.com> <CAHAXwYCnRDQqgRcvaEE1BmSJYYOidoQzzUoHX_QWdyJzYO3kKw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27/07/2013 13:58, David Noel wrote: >> Post the stack trace of the core and maybe someone can help you. > panic: ufs_dirrem: Bad link count 2 on parent > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff808680fe at kdb_backtrace+0x5e > #1 0xffffffff80832cb7 at panic+0x187 > #2 0xffffffff80a700e3 at ufs_rmdir+0x1c3 > #3 0xffffffff80b7d484 at VOP_RMDIR_APV+0x34 > #4 0xffffffff808ca32a at kern_rmdirat+0x21a > #5 0xffffffff80b17cf0 at amd64_syscall+0x450 > #6 0xffffffff80b03427 at Xfast_syscall+0xf7 > I'm taking a guess here - the effective link count when it came to removing the parent directory was only two and it should have been three or more. This gets sanity checked this before proceeding, and panics if it is not. Why an effective link count of three? We're talking about the parent of the directory you're trying to zap, right? There's the link to the directory from its parent, and the '.' link and the ".." link from the directory you're trying to remove. There may be more if it contains other directories, but there can't be less. Anyway - if you only had a link count of just two effective links at the start of the delete process it suggests that the link count was messed up - either a link never existed or its count was wrong. Should the kernel panic? Well it's a situation that can never happen - it could simply remove the directory and pretend everything was okay but guess it was decided it was likely to be a symptom of impending disaster. Other anomalies return an error. In over ten years with FreeBSD systems I can't say I've ever seen this "cannot happen" situation arise. I'd guess you had an interrupted (by power failure) inode operation at some time which caused the corruption. removing a directory is a PITA as it can lead to a race - a context swap could create a file it it mid-way through the process. Regards, Frank.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51F3E0F1.3010401>