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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE3E7C4345F for ; Sun, 28 Apr 2024 03:00:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E8F1F6B0085; Sat, 27 Apr 2024 23:00:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E3F776B0087; Sat, 27 Apr 2024 23:00:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D06976B0088; Sat, 27 Apr 2024 23:00:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B1DD76B0085 for ; Sat, 27 Apr 2024 23:00:48 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 542B31406F4 for ; Sun, 28 Apr 2024 03:00:48 +0000 (UTC) X-FDA: 82057438176.15.A161C2A Received: from dggsgout12.his.huawei.com (unknown [45.249.212.56]) by imf08.hostedemail.com (Postfix) with ESMTP id 9398216001E for ; Sun, 28 Apr 2024 03:00:44 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf08.hostedemail.com: domain of yi.zhang@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=yi.zhang@huaweicloud.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714273246; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9PvjPoh1sz8e3lXocMveQZVBwcbCjg2PglTAHR/X9Hw=; b=S+pte9ECo7spYRSzvncAMVBMWLitPhYkCN2iyEXOPZcNZGW3hGY03aCcNZYLutIxs7FZfg 19B/h5rLctLZprF/GFom3O54n8FYq4RD78GEwsiLEu9dQiVcC95+Hm7D/3W1ie7u1ETDWb qwng+XKPurWWyoF9g56aLjXTNd5q5Qk= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf08.hostedemail.com: domain of yi.zhang@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=yi.zhang@huaweicloud.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714273246; a=rsa-sha256; cv=none; b=5aRad86MpPXshg0iRE1etf+Ep3lvicoERLoPwJh0F7lPdZRpl5JmPEkR1OQirQwk1gR88d Qa9sX5T0Mred2T1ULzzNcDTSTg6J14iX3yjgcjbQ3oYX7sUsX5VCfbAXjd59N1k9anupaI horpFzC7sl0qorAcWjKPmFNcfEuoMKQ= Received: from mail.maildlp.com (unknown [172.19.163.216]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4VRrmv4sK5z4f3kjH for ; Sun, 28 Apr 2024 11:00:31 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 6B9111A1200 for ; Sun, 28 Apr 2024 11:00:39 +0800 (CST) Received: from [10.174.179.80] (unknown [10.174.179.80]) by APP2 (Coremail) with SMTP id Syh0CgBHaw7Uuy1mTwCoLQ--.14367S3; Sun, 28 Apr 2024 11:00:39 +0800 (CST) Subject: Re: [PATCH v4 02/34] ext4: check the extent status again before inserting delalloc block To: "Ritesh Harjani (IBM)" , linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, hch@infradead.org, djwong@kernel.org, david@fromorbit.com, willy@infradead.org, zokeefe@google.com, yi.zhang@huawei.com, chengzhihao1@huawei.com, yukuai3@huawei.com, wangkefeng.wang@huawei.com References: <87cyqcyt6t.fsf@gmail.com> From: Zhang Yi Message-ID: <3243c67d-e783-4ec5-998f-0b6170f36e35@huaweicloud.com> Date: Sun, 28 Apr 2024 11:00:36 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <87cyqcyt6t.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CM-TRANSID:Syh0CgBHaw7Uuy1mTwCoLQ--.14367S3 X-Coremail-Antispam: 1UD129KBjvJXoW3Jw47Gr1rXrW7tryxAFy7Wrg_yoW7Aw4Up3 90k3WUKr4kXw1kCan7t3Z5Xr10ga18tF4agr13Kr1UZFZ0yFyxWFnFqF15uFyYkrs7Jr1j vayY9ryxua4UJ3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvIb4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7Mxk0xIA0c2IE e2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r4a 6rW5MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf 9x07UZ18PUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9398216001E X-Stat-Signature: wq9zygjfdrtt46irnqc96xpnehuec58e X-Rspam-User: X-HE-Tag: 1714273244-982216 X-HE-Meta: U2FsdGVkX19grb7lYcwqlPW/Di+crWzy2+DsRC99jsABiaDPo3RuSyVneORT5PeD0zR3sBabzLl+xxQh1cMf9eRtdGpqQ4JE1t1dN4v1QgVF4BygLN0C4iurcEblaISlZsoE0STWqeuKwlj3NYFJtXuf1AHlVJsP7noQ+0g2VbwNwkDbTVdiraQNz6iN5nDlclpjGfARQKuOZNJINRn6C5KGN7elxELmDckBwAXaOPyXsqbuq8FPoWKyV7/RuQTN0PWtXz4hG21oYfNJ88MC11nINtVTivdEStVtJD/mqRpvN/5I5m2hVMdC4yoWWVzggHqh1o28FvINagA+ccxkafcavCS9jqosu0ASyR+Ukf1NadK1BSDuSMXVt9QND6DYy6tbTKxFE5SknmbY6nj1Lk8u2aKPmo788l29kSpj0UMMJvN+WcAU11ajWQOVbIZn0lMe8LYo/E1/E3ME/NXRZNbaKofsfAglG18zKpVXOBYRVP0/B1iMnCsNYDKze7LMNamIWP5z2/2HSVNTu80MH6SnQgYDYfjcCf2OBd+e7jgQplsbZfYm77Zy+4lzl4I0fysJ1W0xYtlUsAdBvAM7EkCNS4ZVA+H7anv9fDB9cJsDxVn9xr1v/dbJxqO9aFi87n7BYjDwqk2Ygkt2hzxQERS7e2x+NfXdPOXtW++MRulmc8Yqyp7aO0IxBRb1K9dNi8EUh5ULCK7pRnnaI1dyQiFyteJkQbwCPDdkYVFnYu+F7Rh+zmy29EpdodeQhRMV7IxAycS/iro2jbLsjuuYL4il3FugvmptXLEqjtzUdphb60fGf5bje1pvOoddgGUZK2i62BL3mOsfeQVeDsDkUZ0VFFHFAEM4Uws4O6AgSYnvbEqYAvwOUr8ESb8CQJRaHr8ZSCal40ZevmyoA23mSx48tLVgHWaekfz3Bd0vSvakjIy6iSb6idaxwUnbyS/d X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2024/4/27 0:39, Ritesh Harjani (IBM) wrote: > Zhang Yi writes: > >> On 2024/4/26 20:57, Ritesh Harjani (IBM) wrote: >>> Ritesh Harjani (IBM) writes: >>> >>>> Zhang Yi writes: >>>> >>>>> From: Zhang Yi >>>>> >>>>> Now we lookup extent status entry without holding the i_data_sem before >>>>> inserting delalloc block, it works fine in buffered write path and >>>>> because it holds i_rwsem and folio lock, and the mmap path holds folio >>>>> lock, so the found extent locklessly couldn't be modified concurrently. >>>>> But it could be raced by fallocate since it allocate block whitout >>>>> holding i_rwsem and folio lock. >>>>> >>>>> ext4_page_mkwrite() ext4_fallocate() >>>>> block_page_mkwrite() >>>>> ext4_da_map_blocks() >>>>> //find hole in extent status tree >>>>> ext4_alloc_file_blocks() >>>>> ext4_map_blocks() >>>>> //allocate block and unwritten extent >>>>> ext4_insert_delayed_block() >>>>> ext4_da_reserve_space() >>>>> //reserve one more block >>>>> ext4_es_insert_delayed_block() >>>>> //drop unwritten extent and add delayed extent by mistake >>>>> >>>>> Then, the delalloc extent is wrong until writeback, the one more >>>>> reserved block can't be release any more and trigger below warning: >>>>> >>>>> EXT4-fs (pmem2): Inode 13 (00000000bbbd4d23): i_reserved_data_blocks(1) not cleared! >>>>> >>>>> Hold i_data_sem in write mode directly can fix the problem, but it's >>>>> expansive, we should keep the lockless check and check the extent again >>>>> once we need to add an new delalloc block. >>>> >>>> Hi Zhang, >>>> >>>> It's a nice finding. I was wondering if this was caught in any of the >>>> xfstests? >>>> >> >> Hi, Ritesh >> >> I caught this issue when I tested my iomap series in generic/344 and >> generic/346. It's easy to reproduce because the iomap's buffered write path >> doesn't hold folio lock while inserting delalloc blocks, so it could be raced >> by the mmap page fault path. But the buffer_head's buffered write path can't >> trigger this problem, > > ya right! That's the difference between how ->map_blocks() is called > between buffer_head v/s iomap path. In iomap the ->map_blocks() call > happens first to map a large extent and then it iterate over all the > locked folios covering the mapped extent for doing writes. > Whereas in buffer_head while iterating, we first instantiate/lock the > folio and then call ->map_blocks() to map an extent for the given folio. > > ... So this opens up this window for a race between iomap buffered write > path v/s page mkwrite path for inserting delalloc blocks entries. > >> the race between buffered write path and fallocate path >> was discovered while I was analyzing the code, so I'm not sure if it could >> be caught by xfstests now, at least I haven't noticed this problem so far. >> > > Did you mean the race between page fault path and fallocate path here? > Because buffered write path and fallocate path should not have any race > since both takes the inode_lock. I guess you meant page fault path and > fallocate path for which you wrote this patch too :) Yep. > > I am surprised, why we cannot see the this race between page mkwrite and > fallocate in fstests for inserting da entries to extent status cache. > Because the race you identified looks like a legitimate race and is > mostly happening since ext4_da_map_blocks() was not doing the right > thing. > ... looking at the src/holetest, it doesn't really excercise this path. > So maybe we can writing such fstest to trigger this race. > I guess the stress tests and smoke tests in fstests have caught it, e.g. generic/476. Since there is only one error message in ext4_destroy_inode() when the race issue happened, we can't detect it unless we go and check the logs manually. I suppose we need to add more warnings, something like this, how does it sound? diff --git a/fs/ext4/super.c b/fs/ext4/super.c index c8b691e605f1..4b6fd9b63b12 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -1255,6 +1255,8 @@ static void ext4_percpu_param_destroy(struct ext4_sb_info *sbi) percpu_counter_destroy(&sbi->s_freeclusters_counter); percpu_counter_destroy(&sbi->s_freeinodes_counter); percpu_counter_destroy(&sbi->s_dirs_counter); + WARN_ON_ONCE(!ext4_forced_shutdown(sbi->s_sb) && + percpu_counter_sum(&sbi->s_dirtyclusters_counter)); percpu_counter_destroy(&sbi->s_dirtyclusters_counter); percpu_counter_destroy(&sbi->s_sra_exceeded_retry_limit); percpu_free_rwsem(&sbi->s_writepages_rwsem); @@ -1476,7 +1478,8 @@ static void ext4_destroy_inode(struct inode *inode) dump_stack(); } - if (EXT4_I(inode)->i_reserved_data_blocks) + if (!ext4_forced_shutdown(inode->i_sb) && + WARN_ON_ONCE(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), Thanks, Yi. > >>>> I have reworded some of the commit message, feel free to use it if you >>>> think this version is better. The use of which path uses which locks was >>>> a bit confusing in the original commit message. >>>> >> >> Thanks for the message improvement, it looks more clear then mine, I will >> use it. >> > > Glad, it was helpful. > > -ritesh >