From patchwork Sat May 30 08:59:26 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 6512571 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 5F2D5C0020 for ; Sat, 30 May 2015 09:00:08 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4B0B4207CD for ; Sat, 30 May 2015 09:00:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5323820606 for ; Sat, 30 May 2015 09:00:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752574AbbE3I7z (ORCPT ); Sat, 30 May 2015 04:59:55 -0400 Received: from mail-pd0-f178.google.com ([209.85.192.178]:35486 "EHLO mail-pd0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750756AbbE3I7w (ORCPT ); Sat, 30 May 2015 04:59:52 -0400 Received: by pdbnf5 with SMTP id nf5so9373929pdb.2 for ; Sat, 30 May 2015 01:59:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=NTlRTobK2DrNUg8wNL14BHmIu38zt7DEzVbCxOSseYU=; b=HKSqm2/rSsf/+y6nb1U35wNN0m9XFlU0ecpU+pV3KxK7izLL+3jGBPvK5QwR0qKnxm /9ZiI+lGWY5CFLlEdlwIPm1kB5CzeUBpcJ9YOeL/6AmK/T84vpGnigFnxXWj8gQZmoNi ppzczuox6Jiwcr2LSYGT2vsTcFPpGNwVA0Di9d8lS/8GB3PyWg72uOgq6c/EHvXuuY66 15GoxJlFu/DUuLtaZ/UMVPKWGk17pccbz02JDRM7EhfSF9wdH2c7Nfz3rBrPfqyzjDnU ljWXo2g0qw9+8bObSLeFW449/UhcjIyMugY4xcDYNJBoMUvKPQ77STTP1iBUX4AGF5iR qZWg== X-Gm-Message-State: ALoCoQluNpGoayefWxxCDxXWEmB1yGTK453D52jM0S7LkXiLIcYorfM0S+QdYIYiqTItY/FPyH0R X-Received: by 10.70.51.67 with SMTP id i3mr22339248pdo.145.1432976392500; Sat, 30 May 2015 01:59:52 -0700 (PDT) Received: from mew.localdomain (c-76-104-211-44.hsd1.wa.comcast.net. [76.104.211.44]) by mx.google.com with ESMTPSA id fd3sm8004544pdb.0.2015.05.30.01.59.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 30 May 2015 01:59:51 -0700 (PDT) From: Omar Sandoval To: linux-btrfs@vger.kernel.org Cc: Markus Schauler , Omar Sandoval , Subject: [PATCH] Btrfs: don't invalidate root dentry when subvolume deletion fails Date: Sat, 30 May 2015 01:59:26 -0700 Message-Id: X-Mailer: git-send-email 2.4.2 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Since commit bafc9b754f75 ("vfs: More precise tests in d_invalidate"), mounted subvolumes can be deleted because d_invalidate() won't fail. However, we run into problems when we attempt to delete the default subvolume while it is mounted as the root filesystem: # btrfs subvol list / ID 257 gen 306 top level 5 path rootvol ID 267 gen 334 top level 5 path snap1 # btrfs subvol get-default / ID 267 gen 334 top level 5 path snap1 # btrfs inspect-internal rootid / 267 # mount -o subvol=/ /dev/vda1 /mnt # btrfs subvol del /mnt/snap1 Delete subvolume (no-commit): '/mnt/snap1' ERROR: cannot delete '/mnt/snap1' - Operation not permitted # findmnt / findmnt: can't read /proc/mounts: No such file or directory # ls /proc # Markus reported that this same scenario simply led to a kernel oops. This happens because in btrfs_ioctl_snap_destroy(), we call d_invalidate() before we check may_destroy_subvol(), which means that we detach the submounts and drop the dentry before erroring out. Instead, we should only invalidate the dentry once we know that we're going through with the deletion. Cc: Fixes: bafc9b754f75 ("vfs: More precise tests in d_invalidate") Reported-by: Markus Schauler Signed-off-by: Omar Sandoval --- The other fix for preventing all mounted subvolumes from being deleted would preclude this, but it sounded like we were leaning towards enforcing that in userspace once subvolume info becomes available in /proc/mounts, so this should be fixed separately. fs/btrfs/ioctl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 1c22c6518504..8edb8544088b 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -2413,14 +2413,14 @@ static noinline int btrfs_ioctl_snap_destroy(struct file *file, goto out_unlock_inode; } - d_invalidate(dentry); - down_write(&root->fs_info->subvol_sem); err = may_destroy_subvol(dest); if (err) goto out_up_write; + d_invalidate(dentry); + btrfs_init_block_rsv(&block_rsv, BTRFS_BLOCK_RSV_TEMP); /* * One for dir inode, two for dir entries, two for root