Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp6106484iob; Tue, 10 May 2022 10:26:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxwmhg+PVHhQ36XzCZBvXUoojDsUOGVt0kx+FcQoFa5KkmFZ3MnikqygbXAIyTql1zr1Jcl X-Received: by 2002:a17:907:e92:b0:6fa:8125:c92a with SMTP id ho18-20020a1709070e9200b006fa8125c92amr9216464ejc.45.1652203561062; Tue, 10 May 2022 10:26:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652203561; cv=none; d=google.com; s=arc-20160816; b=vvkjpzcyVfCaXrwshxfHLTKnSpxtT3l2KXZm8eNgtoEfBUJNlQCvdCIVqxfyE5IXQ8 ZjrXyFc9bFJuxZr9uCMSb0EimmELzmCK5YBR5XRH5orDc4xlnl/kpfUD0/Nt16h0byHw hQxIw/ZQiWILlmix7b4Ad4yU8peYu2JvO33MiJ9cDyuk6taDn8k0DcdjwLrarWoz5EkW YDJ+liIZ4xIPj8wW+vaGogB4qfW2s0ovt28DZIBbKeqpkjgz74iX/K83Xv/8pJMBnM/T DmUnw+Uu81tdrK5hehHlbKYB31BCAYSYad9aZklquYBY5ladfWDvmTi4IQE/Zz1fFDHQ 5TRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=m530FIvjWmEMnlGSnNjQw6gITRFm2Wzq1TGizdkwBeE=; b=MF+xxvMGbrMKIMmxoRf+Yivc6HS/M0JQ032U63MOF6d6Cm7Z7qJ/2ABKQ/o5lIXNNS lbBa20Mm0MLnODpT5ZrjWbG0nl4+LdH53UIUhmDnTz656grqtqF5fXIs2EgbnhBXsFCp whWS063YgnhqvqWxjG5hXXwxEH5ZL5MNLqho0QBWqJJnYluOa7ARnKd0Q43hqAWmbMHg I8oskX8+LiroMi8Az82pMRkKIPPCdQcA5m09sK/dgYmXqHJHwJ2bAmc231C0+MKi4VGU OE1VDLyaS+zaRWKc7sGKILponVg4PJ6bc6EggJyyaTi7vop4T/Jgax9GafQBYboyg8tM P7Zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=c0yqUvXk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sg44-20020a170907a42c00b006f4a2263d1fsi16060439ejc.560.2022.05.10.10.25.34; Tue, 10 May 2022 10:26:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=c0yqUvXk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245620AbiEJNsC (ORCPT + 99 others); Tue, 10 May 2022 09:48:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243895AbiEJNcU (ORCPT ); Tue, 10 May 2022 09:32:20 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0B4217DDE5; Tue, 10 May 2022 06:23:26 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6C0116170D; Tue, 10 May 2022 13:23:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F062C385A6; Tue, 10 May 2022 13:23:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1652189005; bh=r5sYN3Ve8fxr1EeToSe7lqlaLLlbjVcQXAz6ebv863E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=c0yqUvXk6Y7bcm97E9gjmwRKU8P8CEVNcSBTFwOR7JE+moiZmLppapEbm7WtsJ/3n zcOKKnbyWo4AcYQuzo7Y+LgCG5aBFKKw0asS9P+fJvejQYNIn54gk6JZm9BkcDa6q5 jGCZn+b0Pu8knzjQJTOcpAmAqBzUnFBuVsaadNr8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Filipe Manana , David Sterba Subject: [PATCH 5.4 32/52] btrfs: always log symlinks in full mode Date: Tue, 10 May 2022 15:08:01 +0200 Message-Id: <20220510130730.792504982@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220510130729.852544477@linuxfoundation.org> References: <20220510130729.852544477@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Filipe Manana commit d0e64a981fd841cb0f28fcd6afcac55e6f1e6994 upstream. On Linux, empty symlinks are invalid, and attempting to create one with the system call symlink(2) results in an -ENOENT error and this is explicitly documented in the man page. If we rename a symlink that was created in the current transaction and its parent directory was logged before, we actually end up logging the symlink without logging its content, which is stored in an inline extent. That means that after a power failure we can end up with an empty symlink, having no content and an i_size of 0 bytes. It can be easily reproduced like this: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ mkdir /mnt/testdir $ sync # Create a file inside the directory and fsync the directory. $ touch /mnt/testdir/foo $ xfs_io -c "fsync" /mnt/testdir # Create a symlink inside the directory and then rename the symlink. $ ln -s /mnt/testdir/foo /mnt/testdir/bar $ mv /mnt/testdir/bar /mnt/testdir/baz # Now fsync again the directory, this persist the log tree. $ xfs_io -c "fsync" /mnt/testdir $ mount /dev/sdc /mnt $ stat -c %s /mnt/testdir/baz 0 $ readlink /mnt/testdir/baz $ Fix this by always logging symlinks in full mode (LOG_INODE_ALL), so that their content is also logged. A test case for fstests will follow. CC: stable@vger.kernel.org # 4.9+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/tree-log.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -5295,6 +5295,18 @@ static int btrfs_log_inode(struct btrfs_ } /* + * For symlinks, we must always log their content, which is stored in an + * inline extent, otherwise we could end up with an empty symlink after + * log replay, which is invalid on linux (symlink(2) returns -ENOENT if + * one attempts to create an empty symlink). + * We don't need to worry about flushing delalloc, because when we create + * the inline extent when the symlink is created (we never have delalloc + * for symlinks). + */ + if (S_ISLNK(inode->vfs_inode.i_mode)) + inode_only = LOG_INODE_ALL; + + /* * a brute force approach to making sure we get the most uptodate * copies of everything. */ @@ -5707,7 +5719,7 @@ process_leaf: } ctx->log_new_dentries = false; - if (type == BTRFS_FT_DIR || type == BTRFS_FT_SYMLINK) + if (type == BTRFS_FT_DIR) log_mode = LOG_INODE_ALL; ret = btrfs_log_inode(trans, root, BTRFS_I(di_inode), log_mode, 0, LLONG_MAX, ctx);