Received: by 2002:a05:6512:3d0e:0:0:0:0 with SMTP id d14csp42098lfv; Tue, 12 Apr 2022 16:29:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1NOa0K0eaM0XKKZk1XO83Q3M4i3Zqe+qlvKxA2M2v50/W0owL6irwYdAfdLpiBvjj6Qdx X-Received: by 2002:a17:903:205:b0:157:c51:12cd with SMTP id r5-20020a170903020500b001570c5112cdmr28496657plh.94.1649806156449; Tue, 12 Apr 2022 16:29:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649806156; cv=none; d=google.com; s=arc-20160816; b=Fv/VYiYljTHPSCyUwBrxTQ3ohNZ8tNOazRopjoZL42RR+dGNybZZKSCpGyTj698fLd KsTKRYvgYPhfIBGyXWouWlzKaXFL9gH4ERYiK0MX+MCoenDJ3R+FX3l3kvv3CPnSOLn5 O5NBmgAQCvKr8ik8oJoT7Yah0AZ7jC18op+Ot/pe+qa2qRP3a430zyCy3TWlCzt18zvh fvIo0bS6RwYpi8knC9gK6tVvUMA7L4caHJ8FfbMpqLiJ4sevR/mHdxS5KGfpA0scvKyY dBeFrVFihMiadbeY2T2YmmFKGE+niDAghsB10Q0500EI0i8P426fwvviGeEm4IQg95BX 0yjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=2i6eKRQVo02n/5n9R8za0GNm2V+As4aoG0hw9A+SL+c=; b=DnGXb+u5rDHb/g0BAPGOaoNFIAD5LGHEWs/zxIJSmC3EfOwLZX43OIl0OXUgsKeB9Q eWHcJV1THyDgMl8yMst8FYDMs00TfUhtjknEnWj9Jsl/MYz2yDynQq5KtyDlchxiaus1 MQw+4LzDFHy1XbTfxG66959huP8XOIQTk7JCrBJp2/lIk0/KMYNHy1l34a2XYOlxo5e9 9ZHWgAScTfxge0qeAqpR8OwQ7Ut5u/3kQUjG05iEsYDDrMFfljEQCcFqtqpTvTyLwEqC 83pgksreWB4+rMu+ZEB35D85Ndqqn6Ovx3BvqCVwE7Gga3/UKyUmL9Xhe4QDsIcm3Frj jm/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=YnDPz1bB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id s5-20020a170902b18500b0015873700316si4944665plr.45.2022.04.12.16.29.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 16:29:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=YnDPz1bB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A252E1820CC; Tue, 12 Apr 2022 14:21:32 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350614AbiDLG4j (ORCPT + 99 others); Tue, 12 Apr 2022 02:56:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350641AbiDLGsy (ORCPT ); Tue, 12 Apr 2022 02:48:54 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09A4827B08; Mon, 11 Apr 2022 23:39:43 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id E6692CE1C0A; Tue, 12 Apr 2022 06:39:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A92CC385A6; Tue, 12 Apr 2022 06:39:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649745580; bh=3fNIY7gj5O8iP3OpJo6RDD0wS09r6SQuyal2PHvLmwU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YnDPz1bB2AOJUykW8HSK4hem29pbehvkRDqRLs//39rAFikEeTRkaJGOLyfPXZnIk MheCvfTLDSKZnnQ2Fd+tO5//BjQJkb9p2LrwZCkH9PDkAJGqv3IAwH6dXFGfK5OLFH H96KiakNuIm2r7raS/B/hw5x+4vMmM4GkHFkb33Q= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Qu Wenruo , Ethan Lien , David Sterba Subject: [PATCH 5.10 144/171] btrfs: fix qgroup reserve overflow the qgroup limit Date: Tue, 12 Apr 2022 08:30:35 +0200 Message-Id: <20220412062932.057649062@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220412062927.870347203@linuxfoundation.org> References: <20220412062927.870347203@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ethan Lien commit b642b52d0b50f4d398cb4293f64992d0eed2e2ce upstream. We use extent_changeset->bytes_changed in qgroup_reserve_data() to record how many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the bytes_changed is set as "unsigned int", and it will overflow if we try to fallocate a range larger than 4GiB. The result is we reserve less bytes and eventually break the qgroup limit. Unlike regular buffered/direct write, which we use one changeset for each ordered extent, which can never be larger than 256M. For fallocate, we use one changeset for the whole range, thus it no longer respects the 256M per extent limit, and caused the problem. The following example test script reproduces the problem: $ cat qgroup-overflow.sh #!/bin/bash DEV=/dev/sdj MNT=/mnt/sdj mkfs.btrfs -f $DEV mount $DEV $MNT # Set qgroup limit to 2GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT # Try to fallocate a 3GiB file. This should fail. echo echo "Try to fallocate a 3GiB file..." fallocate -l 3G $MNT/3G.file # Try to fallocate a 5GiB file. echo echo "Try to fallocate a 5GiB file..." fallocate -l 5G $MNT/5G.file # See we break the qgroup limit. echo sync btrfs qgroup show -r $MNT umount $MNT When running the test: $ ./qgroup-overflow.sh (...) Try to fallocate a 3GiB file... fallocate: fallocate failed: Disk quota exceeded Try to fallocate a 5GiB file... qgroupid         rfer         excl     max_rfer --------         ----         ----     -------- 0/5           5.00GiB      5.00GiB      2.00GiB Since we have no control of how bytes_changed is used, it's better to set it to u64. CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Qu Wenruo Signed-off-by: Ethan Lien Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/extent_io.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/btrfs/extent_io.h +++ b/fs/btrfs/extent_io.h @@ -121,7 +121,7 @@ struct extent_buffer { */ struct extent_changeset { /* How many bytes are set/cleared in this operation */ - unsigned int bytes_changed; + u64 bytes_changed; /* Changed ranges */ struct ulist range_changed;