From owner-freebsd-questions@FreeBSD.ORG Sat Jul 27 20:09:33 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 92E486AA for ; Sat, 27 Jul 2013 20:09:33 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2153B22F6 for ; Sat, 27 Jul 2013 20:09:32 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id t10so2159564eei.41 for ; Sat, 27 Jul 2013 13:09:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=YqzwJFaoLhONB+UpLGEHpI13+Xu/A2SruaWq1Bh7x2U=; b=A6IBgXMlDyg4JfhdETR8SlcegSc2YV8qzULiIDRZ6pzW7FCbOaT7Ra09gRIY/ln2c+ miGkpXt0IMjtN2n5Lg8tqAuJ/hkFVl9E/JQ0DQ3oZtPdvZ4kBig2haxvfaJLccbsjDfz OBgKHYGt1OwJeVKS15ta+vptkPogeLkTW5ue4f24WyfUvMy49IyjtLPkwYlb05fDi3WA VucJv30D71TGyfsMf+4VicZ7pe855xlrxy5p6RForofkxI3aT+AicvHUip6ZRCQgMwg/ eJjikGaiaNxkG6ksCAplkuln5kF8Bjc7NVIk78OLuNjm3Ast6q0bRV9Xs7pW40bdckr8 VtQA== X-Received: by 10.15.111.135 with SMTP id cj7mr52906758eeb.144.1374952374978; Sat, 27 Jul 2013 12:12:54 -0700 (PDT) Received: from phenom.cordula.ws (p5DDDB58C.dip0.t-ipconnect.de. [93.221.181.140]) by mx.google.com with ESMTPSA id p49sm89761168eeu.2.2013.07.27.12.12.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Jul 2013 12:12:54 -0700 (PDT) Message-ID: <51F41BAF.8070506@cordula.ws> Date: Sat, 27 Jul 2013 21:12:47 +0200 From: cpghost User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130711 Thunderbird/17.0.7 MIME-Version: 1.0 To: David.I.Noel@gmail.com Subject: Re: Delete a directory, crash the system References: <51F3F290.9020004@cordula.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlGUXaO7mDjW3GOles3Uyg74xsiO7QxayradArCXIg0Lx2zsOLG1WygKE7j4lvhIlDU8Elk Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 20:09:33 -0000 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@. 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/