From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,T_DKIMWL_WL_HIGH,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B5D4C28CC6 for ; Tue, 4 Jun 2019 08:15:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E736824DB4 for ; Tue, 4 Jun 2019 08:15:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559636113; bh=UXyDcbHp/97BLFrG3mYGn5laJBxEtF55eCRdW+1UPf8=; h=Subject:To:Cc:From:Date:List-ID:From; b=ZbbgsrS0Uby8WFXbnn9axyeev4XEwRzZCzv+Yy63Ou9zS8ngh9ku+uNn8Pn4IvhjJ ldzh1N6uoj9DChy0+UkjZedSIZzSJCiRUi+z3rJUOgOS6Fv0qkT1GLWrAffTKWGdcr pG8UweEu6AR3n0PtkPpZyOXFbna4NuN9seLS0D04= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727133AbfFDIPL (ORCPT ); Tue, 4 Jun 2019 04:15:11 -0400 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:40121 "EHLO wout1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727118AbfFDIPK (ORCPT ); Tue, 4 Jun 2019 04:15:10 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 760862919; Tue, 4 Jun 2019 04:15:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 04 Jun 2019 04:15:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=1BRnAs 2DHvawFs7l+Sq5z8ekpSzYZYDKaNcPSnakFpo=; b=NINaUDkYTaBtQ+ghd/2pSp d8wulgwnhQXxovLjVXfN7meYFCTC+kTMMwocvR4iR2ZYU06phHZZ4l2AT/VU+7W+ LlRSOmWV/hhFlTpM6WlEk0QkUh+zJGXLr5wjTQVJstvLy5WMC5Phuy9Ia80PJ919 5SjGiD+fEl1NfPASJ7ibKzmfF37Go+XNG8nT0OHb7IeaObADDhSTAsfkammDbbzK RjWQjckMDZJ3Cgd99gKQFcxFuN10MvHhgBT98QR3qpdXJhXU9qhFORXh1C+U6F+v 1QcCL/exwnbrOMAVSxyov4PBTQ6R4QJiTg/cKG8Mcl79hsi19AYphJsrxUsj0zjQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefledgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvffhfffkgggtgfesthekredttd dtlfenucfhrhhomhepoehgrhgvghhkhheslhhinhhugihfohhunhgurghtihhonhdrohhr gheqnecukfhppeekfedrkeeirdekledruddtjeenucfrrghrrghmpehmrghilhhfrhhomh epghhrvghgsehkrhhorghhrdgtohhmnecuvehluhhsthgvrhfuihiivgepvd X-ME-Proxy: Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) by mail.messagingengine.com (Postfix) with ESMTPA id 8D0B380064; Tue, 4 Jun 2019 04:15:08 -0400 (EDT) Subject: FAILED: patch "[PATCH] Btrfs: fix fsync not persisting changed attributes of a" failed to apply to 4.9-stable tree To: fdmanana@suse.com, dsterba@suse.com Cc: From: Date: Tue, 04 Jun 2019 10:15:07 +0200 Message-ID: <155963610714289@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 60d9f50308e5df19bc18c2fefab0eba4a843900a Mon Sep 17 00:00:00 2001 From: Filipe Manana Date: Thu, 16 May 2019 15:48:55 +0100 Subject: [PATCH] Btrfs: fix fsync not persisting changed attributes of a directory While logging an inode we follow its ancestors and for each one we mark it as logged in the current transaction, even if we have not logged it. As a consequence if we change an attribute of an ancestor, such as the UID or GID for example, and then explicitly fsync it, we end up not logging the inode at all despite returning success to user space, which results in the attribute being lost if a power failure happens after the fsync. Sample reproducer: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ mkdir /mnt/dir $ chown 6007:6007 /mnt/dir $ sync $ chown 9003:9003 /mnt/dir $ touch /mnt/dir/file $ xfs_io -c fsync /mnt/dir/file # fsync our directory after fsync'ing the new file, should persist the # new values for the uid and gid. $ xfs_io -c fsync /mnt/dir $ mount /dev/sdb /mnt $ stat -c %u:%g /mnt/dir 6007:6007 --> should be 9003:9003, the uid and gid were not persisted, despite the explicit fsync on the directory prior to the power failure Fix this by not updating the logged_trans field of ancestor inodes when logging an inode, since we have not logged them. Let only future calls to btrfs_log_inode() to mark inodes as logged. This could be triggered by my recent fsync fuzz tester for fstests, for which an fstests patch exists titled "fstests: generic, fsync fuzz tester with fsstress". Fixes: 12fcfd22fe5b ("Btrfs: tree logging unlink/rename fixes") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index 6c47f6ed3e94..de729acee738 100644 --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -5478,7 +5478,6 @@ static noinline int check_parent_dirs_for_sync(struct btrfs_trans_handle *trans, { int ret = 0; struct dentry *old_parent = NULL; - struct btrfs_inode *orig_inode = inode; /* * for regular files, if its inode is already on disk, we don't @@ -5498,16 +5497,6 @@ static noinline int check_parent_dirs_for_sync(struct btrfs_trans_handle *trans, } while (1) { - /* - * If we are logging a directory then we start with our inode, - * not our parent's inode, so we need to skip setting the - * logged_trans so that further down in the log code we don't - * think this inode has already been logged. - */ - if (inode != orig_inode) - inode->logged_trans = trans->transid; - smp_mb(); - if (btrfs_must_commit_transaction(trans, inode)) { ret = 1; break; @@ -6384,7 +6373,6 @@ void btrfs_record_unlink_dir(struct btrfs_trans_handle *trans, * if this directory was already logged any new * names for this file/dir will get recorded */ - smp_mb(); if (dir->logged_trans == trans->transid) return;