Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp13477731ybl; Sun, 29 Dec 2019 12:51:50 -0800 (PST) X-Google-Smtp-Source: APXvYqzLPEqZs6QInTiFr/04uBi/0Bqz8dbI57OjjvrTmicqw7sTyxZQkZI4fHQU/X4gd740sDM6 X-Received: by 2002:a9d:6a41:: with SMTP id h1mr37037898otn.279.1577652710744; Sun, 29 Dec 2019 12:51:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577652710; cv=none; d=google.com; s=arc-20160816; b=eL+7Ps0FEezHy2IYiSIXnzRHYpXO014W/yxiVaiIC9RsjkRxOQr69FMhO3K9cWC796 1fhW6FuhIdoSxByR5MJIabF0lq6C5FVfM0hHC5j36rGnClkPCvEBybcCtJhxx7WTTApQ 2CZ0EDWlfL+9hW6TewiE6szQ2p8fO+SJ9pzrzpTxhTCpNJE1pNiYbrzztUsgVqMwncMu GNIPUzhHF113mfpxfbScuIOR82HMrUBrxt6895U6Zr2wmFOCudy9SC2FhHEU48go7vtU DCn+AYK5VkNlpMLPwvjUJSl6aBPum1420RNxUVgzvzqYhUN8MJ68N73LvSbrtUvDfMS7 2TQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=6nj0YfEQXjJdewKIdQmg32cVd1lx+cQVb9KlsjsKIvM=; b=Jd55DnEpnEqYhpUqFq0usUz3fb6NCNumMHvTvIqlJHlELBySxlAkQw/mECPEAY9b70 U1zzk8qans2sIQFK9N9CmZ+YMCQKD38QaRLqIjTLHKQQpWD9DMTk2PQyc4K8CZ7oHH1t SyVWrkfw1p0Nd1P3ZXaBDRSrXoNr+061upYjViwhfgdTOv4uQXMjf3vq6o6UqIdBevoV dgPbb0S4zEENBH/IKCnSmhU3y3Ae45t1KfVvae1nAYypn769Ozc1ui3s/YVgt3+MJFCa KW/OkdnUFNviIqbvqTJVfx4UvQTCy3Fqw9EAaL2xrxBXuYQCfCpV+l4njEJAvFHqQNNX Iq/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ZtIbfLQP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p20si20229380otk.73.2019.12.29.12.51.39; Sun, 29 Dec 2019 12:51:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ZtIbfLQP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730688AbfL2SNf (ORCPT + 99 others); Sun, 29 Dec 2019 13:13:35 -0500 Received: from mail.kernel.org ([198.145.29.99]:51230 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727704AbfL2R2J (ORCPT ); Sun, 29 Dec 2019 12:28:09 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CF37E222C2; Sun, 29 Dec 2019 17:28:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1577640488; bh=iHeHwJ0mrJ2YNVqux37eQpSctb0AIrXFU5exwWDr3ls=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZtIbfLQP4AFFrNO4nQR9RgFImTFkCkirveDXCzLFDoIdexTiISx9fanQOXEGs9FCS b5KZpJiAd+EyR+sRTtopP0VQ3Zbi07psmBHbBmV107HIszgp7DXpVSk2ibema4QeqK s8oHBvY07DGHR4zcFJLtfm+cMB1Z1E3p52uK87eQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Christoph Anton Mitterer , Filipe Manana , Anand Jain , David Sterba Subject: [PATCH 4.19 017/219] btrfs: send: remove WARN_ON for readonly mount Date: Sun, 29 Dec 2019 18:16:59 +0100 Message-Id: <20191229162511.656751723@linuxfoundation.org> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20191229162508.458551679@linuxfoundation.org> References: <20191229162508.458551679@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Anand Jain commit fbd542971aa1e9ec33212afe1d9b4f1106cd85a1 upstream. We log warning if root::orphan_cleanup_state is not set to ORPHAN_CLEANUP_DONE in btrfs_ioctl_send(). However if the filesystem is mounted as readonly we skip the orphan item cleanup during the lookup and root::orphan_cleanup_state remains at the init state 0 instead of ORPHAN_CLEANUP_DONE (2). So during send in btrfs_ioctl_send() we hit the warning as below. WARN_ON(send_root->orphan_cleanup_state != ORPHAN_CLEANUP_DONE); WARNING: CPU: 0 PID: 2616 at /Volumes/ws/btrfs-devel/fs/btrfs/send.c:7090 btrfs_ioctl_send+0xb2f/0x18c0 [btrfs] :: RIP: 0010:btrfs_ioctl_send+0xb2f/0x18c0 [btrfs] :: Call Trace: :: _btrfs_ioctl_send+0x7b/0x110 [btrfs] btrfs_ioctl+0x150a/0x2b00 [btrfs] :: do_vfs_ioctl+0xa9/0x620 ? __fget+0xac/0xe0 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x49/0x130 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reproducer: mkfs.btrfs -fq /dev/sdb mount /dev/sdb /btrfs btrfs subvolume create /btrfs/sv1 btrfs subvolume snapshot -r /btrfs/sv1 /btrfs/ss1 umount /btrfs mount -o ro /dev/sdb /btrfs btrfs send /btrfs/ss1 -f /tmp/f The warning exists because having orphan inodes could confuse send and cause it to fail or produce incorrect streams. The two cases that would cause such send failures, which are already fixed are: 1) Inodes that were unlinked - these are orphanized and remain with a link count of 0. These caused send operations to fail because it expected to always find at least one path for an inode. However this is no longer a problem since send is now able to deal with such inodes since commit 46b2f4590aab ("Btrfs: fix send failure when root has deleted files still open") and treats them as having been completely removed (the state after an orphan cleanup is performed). 2) Inodes that were in the process of being truncated. These resulted in send not knowing about the truncation and potentially issue write operations full of zeroes for the range from the new file size to the old file size. This is no longer a problem because we no longer create orphan items for truncation since commit f7e9e8fc792f ("Btrfs: stop creating orphan items for truncate"). As such before these commits, the WARN_ON here provided a clue in case something went wrong. Instead of being a warning against the root::orphan_cleanup_state value, it could have been more accurate by checking if there were actually any orphan items, and then issue a warning only if any exists, but that would be more expensive to check. Since orphanized inodes no longer cause problems for send, just remove the warning. Reported-by: Christoph Anton Mitterer Link: https://lore.kernel.org/linux-btrfs/21cb5e8d059f6e1496a903fa7bfc0a297e2f5370.camel@scientia.net/ CC: stable@vger.kernel.org # 4.19+ Suggested-by: Filipe Manana Reviewed-by: Filipe Manana Signed-off-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/send.c | 6 ------ 1 file changed, 6 deletions(-) --- a/fs/btrfs/send.c +++ b/fs/btrfs/send.c @@ -6639,12 +6639,6 @@ long btrfs_ioctl_send(struct file *mnt_f spin_unlock(&send_root->root_item_lock); /* - * This is done when we lookup the root, it should already be complete - * by the time we get here. - */ - WARN_ON(send_root->orphan_cleanup_state != ORPHAN_CLEANUP_DONE); - - /* * Userspace tools do the checks and warn the user if it's * not RO. */