Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp2255343ybg; Sun, 27 Oct 2019 14:30:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqwD6LgnRQ9vJ4wxSFs+dr7CGrkBWkes9NWXCj6rGGJHg1E+2aD+bur4ZllRitp73RCZ/4G9 X-Received: by 2002:aa7:d8c6:: with SMTP id k6mr16197153eds.87.1572211831848; Sun, 27 Oct 2019 14:30:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572211831; cv=none; d=google.com; s=arc-20160816; b=cRnmTSfQ24qDwfCXOoMm3B4s5mAqSHTRMb8AMLXnEKdvnhRzMU6RTnlSRuWscI1njI rv7FxOAyhE+4XjWub6UXSRUaQAN6CoJQl6HtnvoLEnPgJ7KOQludxBBh9OIAaMus5nJF R78hgcieo+3iPAEnIjbcMVxjG9dudPnXfKCKaSXuVmOYkYlPN3Mu8Up2Ca0y8KwoffvZ KJ/37mdSsnw2LBimDYOL1V/CRCBzvYnXBuA5joiO9GbkaWUwEa1463EWcBzv+Hjf+TFL 4Cf+FYwOmc4C2PxzdI82RFbalYSJtYT7xr7pcPO30ff/7wfCQHsQXIryDZ+r031A35by cv5A== 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=UAKpeqSIqdfuQeBu1pXUqX+Tbv1gVO+qflRW+PslFRc=; b=G7cBgy8K43giaMqMSQNIZaHdr2T+BcvpHBFvDwNXD0LZISJJRnTpT1WHgLa/KPPw6V ZFktlyA3UuIvlxDJTcOC3ErAgs8qCbJVgmFrOx6k2b1K7850dCndWb4NFlrQQ6dRCfKd blbj0U9Tj9a8eESay/BpI3wt05HdPSrGvrNsw0ty65A1amAxMN7sK9UnPVA1IMIIXMvl id1gmJThqYQgfMxifGUR4w7JDhoYGfeuk42Ya7Ida1DKVglMpZFyAi5R7Ym4dMmGix5v pNTX5sADuDosYjf+RKcFyrlTxCxOY2AjQPCeallTSfHfjwrtCqFJ8wBPvQZVXde95/7z cTMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=SaRpvUvc; 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 x51si5636563edd.393.2019.10.27.14.30.07; Sun, 27 Oct 2019 14:30:31 -0700 (PDT) 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=SaRpvUvc; 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 S1732936AbfJ0V01 (ORCPT + 99 others); Sun, 27 Oct 2019 17:26:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:48256 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732303AbfJ0V0U (ORCPT ); Sun, 27 Oct 2019 17:26:20 -0400 Received: from localhost (100.50.158.77.rev.sfr.net [77.158.50.100]) (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 DBAAF21783; Sun, 27 Oct 2019 21:26:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572211579; bh=hbpNcqxQDK0OWpfQVYW4AhZUFNc95v1G8MDdnovzsCQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SaRpvUvc3Lya9YQE0mh8XKsdviPhAFyCX5L4u3cXX4EpYoh3McPaGfWb3e8XvuN/0 InWCoG9rEJt+KVKLdMxjVibjRoJwmy7CI4MsW08kEhXn/36jT1EhKfm4EyDnRbQOVl No1tjY93f+1C6QWtTPQP4/9uq7LMsm7viFkD58nQ= 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.3 185/197] Btrfs: check for the full sync flag while holding the inode lock during fsync Date: Sun, 27 Oct 2019 22:01:43 +0100 Message-Id: <20191027203406.473024332@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191027203351.684916567@linuxfoundation.org> References: <20191027203351.684916567@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: Filipe Manana commit ba0b084ac309283db6e329785c1dc4f45fdbd379 upstream. We were checking for the full fsync flag in the inode before locking the inode, which is racy, since at that that time it might not be set but after we acquire the inode lock some other task set it. One case where this can happen is on a system low on memory and some concurrent task failed to allocate an extent map and therefore set the full sync flag on the inode, to force the next fsync to work in full mode. A consequence of missing the full fsync flag set is hitting the problems fixed by commit 0c713cbab620 ("Btrfs: fix race between ranged fsync and writeback of adjacent ranges"), BUG_ON() when dropping extents from a log tree, hitting assertion failures at tree-log.c:copy_items() or all sorts of weird inconsistencies after replaying a log due to file extents items representing ranges that overlap. So just move the check such that it's done after locking the inode and before starting writeback again. Fixes: 0c713cbab620 ("Btrfs: fix race between ranged fsync and writeback of adjacent ranges") CC: stable@vger.kernel.org # 5.2+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/file.c | 36 +++++++++++++++++------------------- 1 file changed, 17 insertions(+), 19 deletions(-) --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -2067,25 +2067,7 @@ int btrfs_sync_file(struct file *file, l struct btrfs_trans_handle *trans; struct btrfs_log_ctx ctx; int ret = 0, err; - u64 len; - /* - * If the inode needs a full sync, make sure we use a full range to - * avoid log tree corruption, due to hole detection racing with ordered - * extent completion for adjacent ranges, and assertion failures during - * hole detection. - */ - if (test_bit(BTRFS_INODE_NEEDS_FULL_SYNC, - &BTRFS_I(inode)->runtime_flags)) { - start = 0; - end = LLONG_MAX; - } - - /* - * The range length can be represented by u64, we have to do the typecasts - * to avoid signed overflow if it's [0, LLONG_MAX] eg. from fsync() - */ - len = (u64)end - (u64)start + 1; trace_btrfs_sync_file(file, datasync); btrfs_init_log_ctx(&ctx, inode); @@ -2112,6 +2094,19 @@ int btrfs_sync_file(struct file *file, l atomic_inc(&root->log_batch); /* + * If the inode needs a full sync, make sure we use a full range to + * avoid log tree corruption, due to hole detection racing with ordered + * extent completion for adjacent ranges, and assertion failures during + * hole detection. Do this while holding the inode lock, to avoid races + * with other tasks. + */ + if (test_bit(BTRFS_INODE_NEEDS_FULL_SYNC, + &BTRFS_I(inode)->runtime_flags)) { + start = 0; + end = LLONG_MAX; + } + + /* * Before we acquired the inode's lock, someone may have dirtied more * pages in the target range. We need to make sure that writeback for * any such pages does not start while we are logging the inode, because @@ -2138,8 +2133,11 @@ int btrfs_sync_file(struct file *file, l /* * We have to do this here to avoid the priority inversion of waiting on * IO of a lower priority task while holding a transaction open. + * + * Also, the range length can be represented by u64, we have to do the + * typecasts to avoid signed overflow if it's [0, LLONG_MAX]. */ - ret = btrfs_wait_ordered_range(inode, start, len); + ret = btrfs_wait_ordered_range(inode, start, (u64)end - (u64)start + 1); if (ret) { up_write(&BTRFS_I(inode)->dio_sem); inode_unlock(inode);