From: Luis Henriques <luis.henriques@linux.dev>
To: Zhang Yi <yi.zhang@huaweicloud.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
adilger.kernel@dilger.ca, jack@suse.cz, ritesh.list@gmail.com,
hch@infradead.org, djwong@kernel.org, willy@infradead.org,
zokeefe@google.com, yi.zhang@huawei.com,
chengzhihao1@huawei.com, yukuai3@huawei.com,
wangkefeng.wang@huawei.com
Subject: Re: [PATCH v3 03/26] ext4: correct the hole length returned by ext4_map_blocks()
Date: Fri, 10 May 2024 10:41:45 +0100 [thread overview]
Message-ID: <87seyquhpi.fsf@brahms.olymp> (raw)
In-Reply-To: <b9b93ad2-2253-6850-da38-afc42370303e@huaweicloud.com> (Zhang Yi's message of "Fri, 10 May 2024 11:39:48 +0800")
On Fri 10 May 2024 11:39:48 AM +08, Zhang Yi wrote;
> On 2024/5/10 1:23, Luis Henriques wrote:
>> On Thu 09 May 2024 12:39:53 PM -04, Theodore Ts'o wrote;
>>
>>> On Thu, May 09, 2024 at 04:16:34PM +0100, Luis Henriques wrote:
>>>>
>>>> It's looks like it's easy to trigger an infinite loop here using fstest
>>>> generic/039. If I understand it correctly (which doesn't happen as often
>>>> as I'd like), this is due to an integer overflow in the 'if' condition,
>>>> and should be fixed with the patch below.
>>>
>>> Thanks for the report. However, I can't reproduce the failure, and
>>> looking at generic/039, I don't see how it could be relevant to the
>>> code path in question. Generic/039 creates a test symlink with two
>>> hard links in the same directory, syncs the file system, and then
>>> removes one of the hard links, and then drops access to the block
>>> device using dmflakey. So I don't see how the extent code would be
>>> involved at all. Are you sure that you have the correct test listed?
>>
>> Yep, I just retested and it's definitely generic/039. I'm using a simple
>> test environment, with virtme-ng.
>>
>>> Looking at the code in question in fs/ext4/extents.c:
>>>
>>> again:
>>> ext4_es_find_extent_range(inode, &ext4_es_is_delayed, hole_start,
>>> hole_start + len - 1, &es);
>>> if (!es.es_len)
>>> goto insert_hole;
>>>
>>> * There's a delalloc extent in the hole, handle it if the delalloc
>>> * extent is in front of, behind and straddle the queried range.
>>> */
>>> - if (lblk >= es.es_lblk + es.es_len) {
>>> + if (lblk >= ((__u64) es.es_lblk) + es.es_len) {
>>> /*
>>> * The delalloc extent is in front of the queried range,
>>> * find again from the queried start block.
>>> len -= lblk - hole_start;
>>> hole_start = lblk;
>>> goto again;
>>>
>>> lblk and es.es_lblk are both __u32. So the infinite loop is
>>> presumably because es.es_lblk + es.es_len has overflowed. This should
>>> never happen(tm), and in fact we have a test for this case which
>>
>> If I instrument the code, I can see that es.es_len is definitely set to
>> EXT_MAX_BLOCKS, which will overflow.
>>
>
> Thanks for the report. After looking at the code, I think the root
> cause of this issue is the variable es was not initialized on replaying
> fast commit. ext4_es_find_extent_range() will return directly when
> EXT4_FC_REPLAY flag is set, and then the es.len becomes stall.
>
> I can always reproduce this issue on generic/039 with
> MKFS_OPTIONS="-O fast_commit".
>
> This uninitialization problem originally existed in the old
> ext4_ext_put_gap_in_cache(), but it didn't trigger any real problem
> since we never check and use extent cache when replaying fast commit.
> So I suppose the correct fix would be to unconditionally initialize
> the es variable.
Oh, you're absolutely right -- the extent_status 'es' struct isn't being
initialized in that case. I totally failed to see that. And yes, I also
failed to mention I had 'fast_commit' feature enabled, sorry!
Thanks a lot for figuring this out, Yi. I'm looking at this code and
trying to understand if it would be safe to call __es_find_extent_range()
when EXT4_FC_REPLAY is in progress. Probably not, and probably better to
simply do:
es->es_lblk = es->es_len = es->es_pblk = 0;
in that case. I'll send out a patch later today.
Cheers,
--
Luis
next prev parent reply other threads:[~2024-05-10 9:41 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-27 1:57 [RFC PATCH v3 00/26] ext4: use iomap for regular file's buffered IO path and enable large foilo Zhang Yi
2024-01-27 1:58 ` [PATCH v3 01/26] ext4: refactor ext4_da_map_blocks() Zhang Yi
2024-02-03 17:56 ` Theodore Ts'o
2024-01-27 1:58 ` [PATCH v3 02/26] ext4: convert to exclusive lock while inserting delalloc extents Zhang Yi
2024-02-03 17:56 ` Theodore Ts'o
2024-01-27 1:58 ` [PATCH v3 03/26] ext4: correct the hole length returned by ext4_map_blocks() Zhang Yi
2024-02-03 17:56 ` Theodore Ts'o
2024-05-09 15:16 ` Luis Henriques
2024-05-09 16:39 ` Theodore Ts'o
2024-05-09 17:23 ` Luis Henriques
2024-05-10 3:39 ` Zhang Yi
2024-05-10 9:41 ` Luis Henriques [this message]
2024-05-10 11:40 ` Zhang Yi
2024-01-27 1:58 ` [PATCH v3 04/26] ext4: add a hole extent entry in cache after punch Zhang Yi
2024-02-03 17:56 ` Theodore Ts'o
2024-01-27 1:58 ` [PATCH v3 05/26] ext4: make ext4_map_blocks() distinguish delalloc only extent Zhang Yi
2024-02-03 17:57 ` Theodore Ts'o
2024-01-27 1:58 ` [PATCH v3 06/26] ext4: make ext4_set_iomap() recognize IOMAP_DELALLOC map type Zhang Yi
2024-02-03 17:57 ` Theodore Ts'o
2024-01-27 1:58 ` [RFC PATCH v3 07/26] iomap: don't increase i_size if it's not a write operation Zhang Yi
2024-02-13 5:46 ` Christoph Hellwig
2024-02-17 8:55 ` Zhang Yi
2024-02-18 23:30 ` Dave Chinner
2024-02-19 1:14 ` Zhang Yi
2024-02-28 8:53 ` Zhang Yi
2024-02-28 22:13 ` Christoph Hellwig
2024-02-29 9:20 ` Zhang Yi
2024-02-28 22:25 ` Dave Chinner
2024-02-29 8:59 ` Zhang Yi
2024-02-29 23:19 ` Dave Chinner
2024-02-29 23:29 ` Darrick J. Wong
2024-03-01 3:26 ` Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 08/26] iomap: add pos and dirty_len into trace_iomap_writepage_map Zhang Yi
2024-02-12 6:02 ` Christoph Hellwig
2024-02-19 1:27 ` Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 09/26] ext4: allow inserting delalloc extents with multi-blocks Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 10/26] ext4: correct delalloc extent length Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 11/26] ext4: also mark extent as delalloc if it's been unwritten Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 12/26] ext4: factor out bh handles to ext4_da_get_block_prep() Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 13/26] ext4: use reserved metadata blocks when splitting extent in endio Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 14/26] ext4: factor out ext4_map_{create|query}_blocks() Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 15/26] ext4: introduce seq counter for extent entry Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 16/26] ext4: add a new iomap aops for regular file's buffered IO path Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 17/26] ext4: implement buffered read iomap path Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 18/26] ext4: implement buffered write " Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 19/26] ext4: implement writeback " Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 20/26] ext4: implement mmap " Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 21/26] ext4: implement zero_range " Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 22/26] ext4: writeback partial blocks before zero range Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 23/26] ext4: fall back to buffer_head path for defrag Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 24/26] ext4: partially enable iomap for regular file's buffered IO path Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 25/26] filemap: support disable large folios on active inode Zhang Yi
2024-01-27 1:58 ` [RFC PATCH v3 26/26] ext4: enable large folio for regular file with iomap buffered IO path Zhang Yi
2024-02-12 6:18 ` [RFC PATCH v3 00/26] ext4: use iomap for regular file's buffered IO path and enable large foilo Darrick J. Wong
2024-02-12 9:16 ` Ritesh Harjani
2024-02-12 10:24 ` Matthew Wilcox
2024-02-17 9:31 ` Zhang Yi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87seyquhpi.fsf@brahms.olymp \
--to=luis.henriques@linux.dev \
--cc=adilger.kernel@dilger.ca \
--cc=chengzhihao1@huawei.com \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
--cc=yi.zhang@huawei.com \
--cc=yi.zhang@huaweicloud.com \
--cc=yukuai3@huawei.com \
--cc=zokeefe@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).