[1/2] Btrfs: fix return value on rename exchange failure

Commit Message

Filipe Manana June 11, 2018, 6:24 p.m. UTC

From: Filipe Manana <[e-mail]>

If we failed during a rename exchange operation after starting/joining a
transaction, we would end up replacing the return value, stored in the
local 'ret' variable, with the return value from btrfs_end_transaction().
So this could end up returning 0 (success) to user space despite the
operation having failed and aborted the transaction, because if there are
multiple tasks having a reference on the transaction at the time
btrfs_end_transaction() is called by the rename exchange, that function
returns 0 (otherwise it returns -EIO and not the original error value).
So fix this by not overwriting the return value on error after getting
a transaction handle.

Signed-off-by: Filipe Manana <[e-mail]>
---
 fs/btrfs/inode.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

David Sterba June 19, 2018, 1:38 p.m. UTC | #1

On Mon, Jun 11, 2018 at 07:24:16PM +0100, [e-mail] wrote:
> From: Filipe Manana <[e-mail]>
> 
> If we failed during a rename exchange operation after starting/joining a
> transaction, we would end up replacing the return value, stored in the
> local 'ret' variable, with the return value from btrfs_end_transaction().
> So this could end up returning 0 (success) to user space despite the
> operation having failed and aborted the transaction, because if there are
> multiple tasks having a reference on the transaction at the time
> btrfs_end_transaction() is called by the rename exchange, that function
> returns 0 (otherwise it returns -EIO and not the original error value).
> So fix this by not overwriting the return value on error after getting
> a transaction handle.
> 
> Signed-off-by: Filipe Manana <[e-mail]>

1 and 2 queued for 4.18, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Filipe Manana June 21, 2018, 4:36 p.m. UTC | #2

On Tue, Jun 19, 2018 at 2:38 PM, David Sterba <[e-mail]> wrote:
> On Mon, Jun 11, 2018 at 07:24:16PM +0100, [e-mail] wrote:
>> From: Filipe Manana <[e-mail]>
>>
>> If we failed during a rename exchange operation after starting/joining a
>> transaction, we would end up replacing the return value, stored in the
>> local 'ret' variable, with the return value from btrfs_end_transaction().
>> So this could end up returning 0 (success) to user space despite the
>> operation having failed and aborted the transaction, because if there are
>> multiple tasks having a reference on the transaction at the time
>> btrfs_end_transaction() is called by the rename exchange, that function
>> returns 0 (otherwise it returns -EIO and not the original error value).
>> So fix this by not overwriting the return value on error after getting
>> a transaction handle.
>>
>> Signed-off-by: Filipe Manana <[e-mail]>
>
> 1 and 2 queued for 4.18, thanks.

Please removed the 2nd patch, because I just ran into a deadlock
between syncing the log and transaction kthread commiting the
transaction while a rename was in progress.
I'll send a v2 once I understand better the problem and have a fix. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 89b208201783..2bb893aa54da 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -9445,6 +9445,7 @@  static int btrfs_rename_exchange(struct inode *old_dir,
 	u64 new_idx = 0;
 	u64 root_objectid;
 	int ret;
+	int ret2;
 	bool root_log_pinned = false;
 	bool dest_log_pinned = false;
 
@@ -9641,7 +9642,8 @@  static int btrfs_rename_exchange(struct inode *old_dir,
 			dest_log_pinned = false;
 		}
 	}
-	ret = btrfs_end_transaction(trans);
+	ret2 = btrfs_end_transaction(trans);
+	ret = ret ? ret : ret2;
 out_notrans:
 	if (new_ino == BTRFS_FIRST_FREE_OBJECTID)
 		up_read(&fs_info->subvol_sem);