From patchwork Sun Dec 6 10:32:31 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Lyakas X-Patchwork-Id: 7778651 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id CA26D9F39B for ; Sun, 6 Dec 2015 10:32:37 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D3C66203DC for ; Sun, 6 Dec 2015 10:32:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 93E87203DB for ; Sun, 6 Dec 2015 10:32:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753518AbbLFKcc (ORCPT ); Sun, 6 Dec 2015 05:32:32 -0500 Received: from mail-yk0-f172.google.com ([209.85.160.172]:33130 "EHLO mail-yk0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753144AbbLFKcb (ORCPT ); Sun, 6 Dec 2015 05:32:31 -0500 Received: by ykdv3 with SMTP id v3so167086118ykd.0 for ; Sun, 06 Dec 2015 02:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zadarastorage-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MOS1XJsNKEgM5OKlGGJrh7/Alt8ytBQxZsgqq0lckrk=; b=nve1mtV8sTpi3n/kAjxYCOWRpvJkiabOTFmLD0e47wJtwSHEjcw7lssc9xYD7cYrrV iuovPLZbwXnw7uk55RtnBxPfZ2FKtnSdHkuZexdsUSfGSz7u8SYz2dJolbaZYpbNFtoy OU80bAWRyyYvG8g7NUbrykV8ZiegoBZsRwD7oUZS9oGarMn96JOxIt1uQVNhG5Dn1+ga KdSTYBiDLgz2NxP0jBv7Q73WDKKiWvp8rD8omX/cWh6mO/KX1or81D6rn8y8LzCPEN6+ 2fjQrz3+Oc2s4QmrMl9jIMzcaes/NAHeqa+FFE/PZPP0owNLGTNfdKoFYRPaeVrwwfxu tK5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MOS1XJsNKEgM5OKlGGJrh7/Alt8ytBQxZsgqq0lckrk=; b=R+brbXuC9uIf5MfAmY3PR3ZdRrKCVpe508jAJGSYf/FisYRN0HnJEoyeBSsbMXtd9s AjIwGUe+MHgF9GTLIvrG7Ib/MtrcNyYQIEo9RG2hPznKdjhG+s//j6Ikjyb8uKTzCqlg /Fjl+cLmpVNBm7kr/RfDgXeVVhNCWponGeIB94SCC4ikCy4xiGSiNgpGtno5AXj9Jo3/ y6kHrYfQjDuA820Z1g9GQ+8AAXNfK8nXFgviczHbH39gQb8Qm5FJ227+xo/StFE4fUfP 5o/r36YIGN/2UnBdhU4/dv/Qn61EB4/SmlDQ04Qx6Fggo1lznaI69f8weGx/yAncU8a2 gTGw== X-Gm-Message-State: ALoCoQmz7uJBpuu4ocJXZ6NfWGjAqiluFany8jPfAIRjZoDc5rj/D1WPwr7lvgXzPfvi+gnlqOF0 MIME-Version: 1.0 X-Received: by 10.13.248.65 with SMTP id i62mr19920428ywf.1.1449397951301; Sun, 06 Dec 2015 02:32:31 -0800 (PST) Received: by 10.37.55.130 with HTTP; Sun, 6 Dec 2015 02:32:31 -0800 (PST) In-Reply-To: References: <20151203181428.GA19589@localhost.localdomain> Date: Sun, 6 Dec 2015 12:32:31 +0200 Message-ID: Subject: Re: [RFC PATCH] btrfs: flush_space: treat return value of do_chunk_alloc properly From: Alex Lyakas To: Liu Bo Cc: linux-btrfs Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP do_chunk_alloc returns 1 when it succeeds to allocate a new chunk. But flush_space will not convert this to 0, and will also return 1. As a result, reserve_metadata_bytes will think that flush_space failed, and may potentially return this value "1" to the caller (depends how reserve_metadata_bytes was called). The caller will also treat this as an error. For example, btrfs_block_rsv_refill does: int ret = -ENOSPC; ... ret = reserve_metadata_bytes(root, block_rsv, num_bytes, flush); if (!ret) { block_rsv_add_bytes(block_rsv, num_bytes, 0); return 0; } return ret; So it will return -ENOSPC. Signed-off-by: Alex Lyakas Reviewed-by: Josef Bacik On Sun, Dec 6, 2015 at 12:19 PM, Alex Lyakas wrote: > Hi Liu, > I was studying on how block reservation works, and making some > modifications in reserve_metadata_bytes to understand better what it > does. Then suddenly I saw this problem. I guess it depends on which > value of "flush" parameter is passed to reserve_metadata_bytes. > > Alex. > > > On Thu, Dec 3, 2015 at 8:14 PM, Liu Bo wrote: >> On Thu, Dec 03, 2015 at 06:51:03PM +0200, Alex Lyakas wrote: >>> do_chunk_alloc returns 1 when it succeeds to allocate a new chunk. >>> But flush_space will not convert this to 0, and will also return 1. >>> As a result, reserve_metadata_bytes will think that flush_space failed, >>> and may potentially return this value "1" to the caller (depends how >>> reserve_metadata_bytes was called). The caller will also treat this as an error. >>> For example, btrfs_block_rsv_refill does: >>> >>> int ret = -ENOSPC; >>> ... >>> ret = reserve_metadata_bytes(root, block_rsv, num_bytes, flush); >>> if (!ret) { >>> block_rsv_add_bytes(block_rsv, num_bytes, 0); >>> return 0; >>> } >>> >>> return ret; >>> >>> So it will return -ENOSPC. >> >> It will return 1 instead of -ENOSPC. >> >> The patch looks good, I noticed this before, but I didn't manage to trigger a error for this, did you catch a error like that? >> >> Thanks, >> >> -liubo >> >>> >>> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c >>> index 4b89680..1ba3f0d 100644 >>> --- a/fs/btrfs/extent-tree.c >>> +++ b/fs/btrfs/extent-tree.c >>> @@ -4727,7 +4727,7 @@ static int flush_space(struct btrfs_root *root, >>> btrfs_get_alloc_profile(root, 0), >>> CHUNK_ALLOC_NO_FORCE); >>> btrfs_end_transaction(trans, root); >>> - if (ret == -ENOSPC) >>> + if (ret > 0 || ret == -ENOSPC) >>> ret = 0; >>> break; >>> case COMMIT_TRANS: >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html Reviewed-by: Liu Bo --- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 4b89680..1ba3f0d 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -4727,7 +4727,7 @@ static int flush_space(struct btrfs_root *root, btrfs_get_alloc_profile(root, 0), CHUNK_ALLOC_NO_FORCE); btrfs_end_transaction(trans, root); - if (ret == -ENOSPC) + if (ret > 0 || ret == -ENOSPC) ret = 0; break; case COMMIT_TRANS: