From patchwork Fri Aug 5 16:48:28 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Fasheh X-Patchwork-Id: 1038972 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter1.kernel.org (8.14.4/8.14.4) with ESMTP id p75GmWBe031720 for ; Fri, 5 Aug 2011 16:48:32 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754384Ab1HEQs3 (ORCPT ); Fri, 5 Aug 2011 12:48:29 -0400 Received: from cantor2.suse.de ([195.135.220.15]:44565 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754316Ab1HEQs3 (ORCPT ); Fri, 5 Aug 2011 12:48:29 -0400 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 9864A8EFD4; Fri, 5 Aug 2011 18:48:28 +0200 (CEST) Date: Fri, 5 Aug 2011 09:48:28 -0700 From: Mark Fasheh To: linux-btrfs@vger.kernel.org Cc: chris.mason@oracle.com Subject: [PATCH] btrfs: Handle NULL inode return from btrfs_lookup_dentry() Message-ID: <20110805164828.GB8482@wotan.suse.de> Reply-To: Mark Fasheh Mime-Version: 1.0 Content-Disposition: inline Organization: SUSE Labs User-Agent: Mutt/1.5.9i Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Fri, 05 Aug 2011 16:48:33 +0000 (UTC) Right now in create_snapshot(), we'll BUG() if btrfs_lookup_dentry() returns a NULL inode (negative dentry). Getting a negative dentry here probably isn't ever expected to happen however two things lead me to believe that we should trap this anyway: - I don't see any possiblity of serious fs corruption from handling the error. I do wonder though if we could have an "orphaned" snapshot? Even if we did that doesn't strike me as needing to crash the machine. (Q: Perhaps going read-only is the eventual solution here?) - It's very trivial to pass an -ENOENT back to userspace as we're pretty high up the call path at this point. Signed-off-by: Mark Fasheh --- fs/btrfs/ioctl.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 7cf0133..fc9525f 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -498,14 +498,16 @@ static int create_snapshot(struct btrfs_root *root, struct dentry *dentry, if (ret) goto fail; + ret = 0; inode = btrfs_lookup_dentry(dentry->d_parent->d_inode, dentry); if (IS_ERR(inode)) { ret = PTR_ERR(inode); goto fail; - } - BUG_ON(!inode); + } else if (inode == NULL) + ret = -ENOENT; + d_instantiate(dentry, inode); - ret = 0; + fail: kfree(pending_snapshot); return ret;