Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp15861pxb; Tue, 24 Aug 2021 18:38:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxwZswlmb4BQTGZVmEFT7mYMUyzegsDfqU6rRs6HDge98QumZQjJvntrEBBNPLFzutVvZ2z X-Received: by 2002:a05:6402:289b:: with SMTP id eg27mr41214037edb.106.1629855521172; Tue, 24 Aug 2021 18:38:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629855521; cv=none; d=google.com; s=arc-20160816; b=BeswnD+GnfeWxF/3f55qg5rucQSPm070HvFq2b8YtTQGpT1VnffK3WEjC914ht44YE z1QTcRwV1xX442y7jPhDR+yO2yuQlj5xePD6vNCHc411ipfCkeNzVeSszjLT8VJTscFv G6UbFVDcGnyppPWM2BztnVJF9v9LNH5KPOLOS1cRT6A4rgFXoWJi6Mor6woyyAt+WeNP B1PsLRridLTfFF+b0lEIfTbv+YelPmrRruK7TfttDT9xJHfOEwUnhHRAT5h+48kZNdfX sjCgQ43VhsIxxM6msdjgQ/AzDE1eYfcT53ltZXoPQC0NexUfK4Zd8oAgq8Qoqfw4r7yD 2CzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=LZG8RQPPkd0WONTQZn3QpqHSHRO84My8FkyOA40ypw0=; b=XPbDp+krHFK7MHnvuORarV6nHt3ScZJSlhfeb89fi3n3E3gAi8T9x6SmmjuJ8MXtYU HdAQjB7Z6T6FVQK+/7jZ0EcHWNRjSTzNDWcS+WJKOZ18IZoxw/cDSwo1oOxTqMd2Adw4 pzcNh02cOe89XLslFupR45KyyLHy72s983TUnAXFUGPhZY4uo/+yzHriDp0RNGtva6Kv A6ov08wFm7sVhOeUTUIX2juqxH7Hd7liqrbIKsiukHBbmqi+4LdkX8x7tEu0psK6mQpu yXN+v9wsRLwWAT2XzdRPnyf1p2S21H6ycGPVyBXqJD1QbJ/hiOY60hivk5qRj/MAWFH9 Z0Qg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cw1si3351827ejc.693.2021.08.24.18.38.10; Tue, 24 Aug 2021 18:38:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233459AbhHYBiw (ORCPT + 99 others); Tue, 24 Aug 2021 21:38:52 -0400 Received: from out30-130.freemail.mail.aliyun.com ([115.124.30.130]:37399 "EHLO out30-130.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231415AbhHYBiw (ORCPT ); Tue, 24 Aug 2021 21:38:52 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R551e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04420;MF=jefflexu@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0UlfSc9z_1629855485; Received: from admindeMacBook-Pro-2.local(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0UlfSc9z_1629855485) by smtp.aliyun-inc.com(127.0.0.1); Wed, 25 Aug 2021 09:38:06 +0800 Subject: Re: [PATCH v2] ext4: fix reserved space counter leakage To: Eric Whitney Cc: tytso@mit.edu, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, joseph.qi@linux.alibaba.com, hsiangkao@linux.alibaba.com References: <20210823061358.84473-1-jefflexu@linux.alibaba.com> <20210823203009.GA10429@localhost.localdomain> From: JeffleXu Message-ID: <77ac5ffe-9769-bcb4-0600-f72ddf0aa59a@linux.alibaba.com> Date: Wed, 25 Aug 2021 09:38:05 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20210823203009.GA10429@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On 8/24/21 4:30 AM, Eric Whitney wrote: > * Jeffle Xu : >> When ext4_insert_delayed block receives and recovers from an error from >> ext4_es_insert_delayed_block(), e.g., ENOMEM, it does not release the >> space it has reserved for that block insertion as it should. One effect >> of this bug is that s_dirtyclusters_counter is not decremented and >> remains incorrectly elevated until the file system has been unmounted. >> This can result in premature ENOSPC returns and apparent loss of free >> space. >> >> Another effect of this bug is that >> /sys/fs/ext4//delayed_allocation_blocks can remain non-zero even >> after syncfs has been executed on the filesystem. >> >> Besides, add check for s_dirtyclusters_counter when inode is going to be >> evicted and freed. s_dirtyclusters_counter can still keep non-zero until >> inode is written back in .evict_inode(), and thus the check is delayed >> to .destroy_inode(). >> >> Fixes: 51865fda28e5 ("ext4: let ext4 maintain extent status tree") >> Cc: >> Suggested-by: Gao Xiang >> Signed-off-by: Jeffle Xu >> --- >> changes since v1: >> - improve commit log suggested by Eric Whitney >> - update "Suggested-by" title for Gao Xian, who actually found this bug >> code >> - add check for s_dirtyclusters_counter in .destroy_inode() >> --- >> fs/ext4/inode.c | 5 +++++ >> fs/ext4/super.c | 6 ++++++ >> 2 files changed, 11 insertions(+) >> >> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c >> index d8de607849df..73daf9443e5e 100644 >> --- a/fs/ext4/inode.c >> +++ b/fs/ext4/inode.c >> @@ -1640,6 +1640,7 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) >> struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb); >> int ret; >> bool allocated = false; >> + bool reserved = false; >> >> /* >> * If the cluster containing lblk is shared with a delayed, >> @@ -1656,6 +1657,7 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) >> ret = ext4_da_reserve_space(inode); >> if (ret != 0) /* ENOSPC */ >> goto errout; >> + reserved = true; >> } else { /* bigalloc */ >> if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk)) { >> if (!ext4_es_scan_clu(inode, >> @@ -1668,6 +1670,7 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) >> ret = ext4_da_reserve_space(inode); >> if (ret != 0) /* ENOSPC */ >> goto errout; >> + reserved = true; >> } else { >> allocated = true; >> } >> @@ -1678,6 +1681,8 @@ static int ext4_insert_delayed_block(struct inode *inode, ext4_lblk_t lblk) >> } >> >> ret = ext4_es_insert_delayed_block(inode, lblk, allocated); >> + if (ret && reserved) >> + ext4_da_release_space(inode, 1); >> >> errout: >> return ret; >> diff --git a/fs/ext4/super.c b/fs/ext4/super.c >> index dfa09a277b56..61bf52b58fca 100644 >> --- a/fs/ext4/super.c >> +++ b/fs/ext4/super.c >> @@ -1351,6 +1351,12 @@ static void ext4_destroy_inode(struct inode *inode) >> true); >> dump_stack(); >> } >> + >> + if (EXT4_I(inode)->i_reserved_data_blocks) >> + ext4_msg(inode->i_sb, KERN_ERR, >> + "Inode %lu (%p): i_reserved_data_blocks (%u) not cleared!", >> + inode->i_ino, EXT4_I(inode), >> + EXT4_I(inode)->i_reserved_data_blocks); >> } >> >> static void init_once(void *foo) >> -- >> 2.27.0 >> > > Looks good, passed 4k xfstests-bld regression. Feel free to add: > > Reviewed-by: Eric Whitney Hi tytso, it's a bug fix and it would be great if it could be merged to 5.15. -- Thanks, Jeffle