Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp6277326iob; Tue, 10 May 2022 14:42:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyneulXEerv/DLdyKuqVWd2XI22AUM1hWkdYzHSKBPuJQjbMyw/P7VzPbHV6uNK0JEwoTH6 X-Received: by 2002:a63:1a5c:0:b0:3c1:9a7c:3739 with SMTP id a28-20020a631a5c000000b003c19a7c3739mr18499238pgm.272.1652218926799; Tue, 10 May 2022 14:42:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652218926; cv=none; d=google.com; s=arc-20160816; b=yYeNOK+TRQ3YDJt86G5aSmL2zyD5pDA3VRAHghc2FRo+/ovdkyUqeG0yS5BpVQJfo0 SjWKms4d/np7qYSLShKNyg/ILlAOfiY1lhEkl5mCr/HFvnxnk69R2rHdbhAu9N1Rz40j r3mYOxkgQ6YE4uQKamZ5ah3U9EmM7pzWmbb/RbkO9H5YhhdwKRsGdaMX6liIn36pifYK MNP1J9nRKUS42fyFqIsGvKlI+JqdaCq4rrsdav1DvgoeVzVBI1pH/CMKHaLvW+3dpGLw p3Q+2EJ9qvx6XkpRCapze7hXRBkd3M9Gu1mzjVc40owMpMwnId8r1TGQRuLb9kvwD9z5 pn2A== 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=DLg06ZdtUP/bb8XmS9g47ciWKyUY2hKLYClLAZ4oP54=; b=nPXnaHngxMKKej03NLXf9pE7ql4Hy4C8f3Hc81Ci8KOTy0upEfgdol7wtHr4/oOInL JaGQ9V7mkHXpxXwqlFHAYHbY8TI12ToPbWlwVwNGGeJpd+nF1V5pyQZ8zk2UKlqTr96T ld7fXvwrXv9+UYGhbji3QtsSLElAtRJxgUcuTHM8MVBlr3ULtQ87XrA1yrqcQG6uinn3 NB8seT0Mgg291n5t7oEXvbuIt5lQLxJEHsj3S/6ONmbdUbBcpsvJHX4bZznpXgDMJ7Ro zREouxT/3W1aruk9Z/h25ietv3NJI19IlSNHSsL2mYl3NnyB8H4hSWmzRtykX1691nIh yoVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=yn6h+2UU; 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 bi1-20020a170902bf0100b0015862deeb9dsi275364plb.117.2022.05.10.14.41.44; Tue, 10 May 2022 14:42:06 -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=yn6h+2UU; 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 S245172AbiEJN5Q (ORCPT + 99 others); Tue, 10 May 2022 09:57:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56258 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245139AbiEJNie (ORCPT ); Tue, 10 May 2022 09:38:34 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14956246427; Tue, 10 May 2022 06:27:22 -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 ams.source.kernel.org (Postfix) with ESMTPS id C33D4B81DA2; Tue, 10 May 2022 13:27:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB42CC385C2; Tue, 10 May 2022 13:27:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1652189239; bh=ak1PU6vYkC/9zG/U/L+QP5Hp2f2tGX4tEkjKfUlRCH0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yn6h+2UUVX65cv7X90bmt4N1CNQ9q4XH7wyEWEdKI+V74SM0p2shASaORxKfgQJCx R9krx2yvpBlQ6HdmcKTD99EGKo1/0QGJ4NIi0aqFpGZ9gjFN5fjsq84ae2BFR2PyOI eofsHTf+3MfmW/eUmBmKy/V23a+1vUCt5FX/7pBA= 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.10 56/70] btrfs: always log symlinks in full mode Date: Tue, 10 May 2022 15:08:15 +0200 Message-Id: <20220510130734.506158628@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220510130732.861729621@linuxfoundation.org> References: <20220510130732.861729621@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 @@ -5335,6 +5335,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. */ @@ -5724,7 +5736,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, ctx);