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=-6.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_HIGH,USER_AGENT_GIT 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 9EAF9C28CC2 for ; Thu, 30 May 2019 04:35:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 74F70257BF for ; Thu, 30 May 2019 04:35:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559190913; bh=5cIoNPrYoOfe6SHmkc6fk808rFkjGP3Hjmm2cmWKvu8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=u/v209gTATq4VGhziDmK/0POn24DCa9vaN3TUhoWiers9b4a0vLuSckukjHdS0EP8 qLSgyeua4pPsN071X7j9kddcOKu/DyE0RznJEI81u+vaeWXWLfGFb/lh3wOxfL9Ept 54e4ibvyXMAlQcnHA9e4n30BBmscDPW/NqrQr8mg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729565AbfE3EfM (ORCPT ); Thu, 30 May 2019 00:35:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:57836 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729384AbfE3DNQ (ORCPT ); Wed, 29 May 2019 23:13:16 -0400 Received: from localhost (ip67-88-213-2.z213-88-67.customer.algx.net [67.88.213.2]) (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 0075221BE2; Thu, 30 May 2019 03:13:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559185995; bh=5cIoNPrYoOfe6SHmkc6fk808rFkjGP3Hjmm2cmWKvu8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Gp7tqwgTeqPLAW0w4R5RWloce3JH8LeSQLfxvbOeaYT2I0l75DHKcNB+n+SvcA9zU OBI/BlbjNnycy+SaPL1BnLcm1ET27Dxq5ZgcoVC2v1LS02KfVPsaYQK+tQ2TyLuZ6r AD3/RaV9pwPl4X0zPrrLcjKTUVgW8XrYpIj+A/ps= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , David Sterba Subject: [PATCH 5.0 041/346] Revert "btrfs: Honour FITRIM range constraints during free space trim" Date: Wed, 29 May 2019 20:01:54 -0700 Message-Id: <20190530030542.936701328@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190530030540.363386121@linuxfoundation.org> References: <20190530030540.363386121@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: David Sterba This reverts commit b9ee627187491547791aacf96d4dd8f4d9afbf1c. There is currently no corresponding patch in master due to additional changes that would be significantly different from plain revert in the respective stable branch. The range argument was not handled correctly and could cause trim to overlap allocated areas or reach beyond the end of the device. The address space that fitrim normally operates on is in logical coordinates, while the discards are done on the physical device extents. This distinction cannot be made with the current ioctl interface and caused the confusion. The bug depends on the layout of block groups and does not always happen. The whole-fs trim (run by default by the fstrim tool) is not affected. Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/extent-tree.c | 25 ++++++------------------- 1 file changed, 6 insertions(+), 19 deletions(-) --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -11191,9 +11191,9 @@ int btrfs_error_unpin_extent_range(struc * held back allocations. */ static int btrfs_trim_free_extents(struct btrfs_device *device, - struct fstrim_range *range, u64 *trimmed) + u64 minlen, u64 *trimmed) { - u64 start = range->start, len = 0; + u64 start = 0, len = 0; int ret; *trimmed = 0; @@ -11236,8 +11236,8 @@ static int btrfs_trim_free_extents(struc if (!trans) up_read(&fs_info->commit_root_sem); - ret = find_free_dev_extent_start(trans, device, range->minlen, - start, &start, &len); + ret = find_free_dev_extent_start(trans, device, minlen, start, + &start, &len); if (trans) { up_read(&fs_info->commit_root_sem); btrfs_put_transaction(trans); @@ -11250,16 +11250,6 @@ static int btrfs_trim_free_extents(struc break; } - /* If we are out of the passed range break */ - if (start > range->start + range->len - 1) { - mutex_unlock(&fs_info->chunk_mutex); - ret = 0; - break; - } - - start = max(range->start, start); - len = min(range->len, len); - ret = btrfs_issue_discard(device->bdev, start, len, &bytes); mutex_unlock(&fs_info->chunk_mutex); @@ -11269,10 +11259,6 @@ static int btrfs_trim_free_extents(struc start += len; *trimmed += bytes; - /* We've trimmed enough */ - if (*trimmed >= range->len) - break; - if (fatal_signal_pending(current)) { ret = -ERESTARTSYS; break; @@ -11356,7 +11342,8 @@ int btrfs_trim_fs(struct btrfs_fs_info * mutex_lock(&fs_info->fs_devices->device_list_mutex); devices = &fs_info->fs_devices->devices; list_for_each_entry(device, devices, dev_list) { - ret = btrfs_trim_free_extents(device, range, &group_trimmed); + ret = btrfs_trim_free_extents(device, range->minlen, + &group_trimmed); if (ret) { dev_failed++; dev_ret = ret;