From: Chao Yu <chao@kernel.org>
To: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Cc: linux-block <linux-block@vger.kernel.org>,
Jaegeuk Kim <jaegeuk@kernel.org>, Yi Zhang <yi.zhang@redhat.com>,
Bart Van Assche <bvanassche@acm.org>,
"linux-f2fs-devel@lists.sourceforge.net"
<linux-f2fs-devel@lists.sourceforge.net>
Subject: Re: [f2fs-dev] [bug report]WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51 iomap_iter+0x32b observed with blktests zbd/010
Date: Mon, 25 Mar 2024 11:06:02 +0800 [thread overview]
Message-ID: <bd72565c-052e-457a-ac08-7bf40077992c@kernel.org> (raw)
In-Reply-To: <l7n5vbvpfmeutotnznxubhdr3migk5kpxgm6j5n265dnfgdtzo@iod4gcsfy5om>
On 2024/3/25 10:14, Shinichiro Kawasaki wrote:
> On Mar 24, 2024 / 20:13, Chao Yu wrote:
> ...
>> Hi Shinichiro,
>>
>> Can you please check below diff? IIUC, for the case: f2fs_map_blocks()
>> returns zero blkaddr in non-primary device, which is a verified valid
>> block address, we'd better to check m_flags & F2FS_MAP_MAPPED instead
>> of map.m_pblk != NULL_ADDR to decide whether tagging IOMAP_MAPPED flag
>> or not.
>>
>> ---
>> fs/f2fs/data.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>> index 6f66e3e4221a..41a56d4298c8 100644
>> --- a/fs/f2fs/data.c
>> +++ b/fs/f2fs/data.c
>> @@ -4203,7 +4203,7 @@ static int f2fs_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
>> if (WARN_ON_ONCE(map.m_pblk == COMPRESS_ADDR))
>> return -EINVAL;
>>
>> - if (map.m_pblk != NULL_ADDR) {
>> + if (map.m_flags & F2FS_MAP_MAPPED) {
>> iomap->length = blks_to_bytes(inode, map.m_len);
>> iomap->type = IOMAP_MAPPED;
>> iomap->flags |= IOMAP_F_MERGED;
>>
>
> Thanks Chao, I confirmed that the diff above avoids the WARN and zbd/010
> failure. From that point of view, it looks good.
Thank you for the confirmation. :)
>
> One thing I noticed is that the commit message of 8d3c1fa3fa5ea ("f2fs:
> don't rely on F2FS_MAP_* in f2fs_iomap_begin") says that f2fs_map_blocks()
> might be setting F2FS_MAP_* flag on a hole, and that's why the commit
> avoided the F2FS_MAP_MAPPED flag check. So I was not sure if it is the
> right thing to reintroduce the flag check.
I didn't see such logic in previous f2fs_map_blocks(, F2FS_GET_BLOCK_DIO) codebase,
I doubt it hits the same case: map.m_pblk is valid zero blkaddr which locates in
the head of secondary device? What do you think?
Quoted commit message from 8d3c1fa3fa5ea:
When testing with a mixed zoned / convention device combination, there
are regular but not 100% reproducible failures in xfstests generic/113
where the __is_valid_data_blkaddr assert hits due to finding a hole.
Previous code:
- if (map.m_flags & (F2FS_MAP_MAPPED | F2FS_MAP_UNWRITTEN)) {
- iomap->length = blks_to_bytes(inode, map.m_len);
- if (map.m_flags & F2FS_MAP_MAPPED) {
- iomap->type = IOMAP_MAPPED;
- iomap->flags |= IOMAP_F_MERGED;
- } else {
- iomap->type = IOMAP_UNWRITTEN;
- }
- if (WARN_ON_ONCE(!__is_valid_data_blkaddr(map.m_pblk)))
- return -EINVAL;
Thanks,
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2024-03-25 3:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-18 16:58 [f2fs-dev] [bug report]WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51 iomap_iter+0x32b observed with blktests zbd/010 Yi Zhang
2024-02-28 11:08 ` Shinichiro Kawasaki via Linux-f2fs-devel
2024-02-28 12:08 ` Yi Zhang
[not found] ` <CAHj4cs_eOSafp0=cbwjNPR6X2342GF_cnUTcXf6RjrMnoOHSmQ@mail.gmail.com>
2024-03-01 16:33 ` Bart Van Assche
2024-03-12 2:52 ` Shinichiro Kawasaki via Linux-f2fs-devel
[not found] ` <CAHj4cs-DC7QQH1W3KSzXS8ERMPW-6XQ9-w_Mzr1zEGF7ZZ=K3w@mail.gmail.com>
2024-03-12 9:34 ` Shinichiro Kawasaki via Linux-f2fs-devel
2024-03-18 5:47 ` Shinichiro Kawasaki via Linux-f2fs-devel
2024-03-18 21:12 ` Daeho Jeong
2024-03-19 10:56 ` Shinichiro Kawasaki via Linux-f2fs-devel
2024-03-19 2:22 ` Chao Yu
2024-03-19 11:13 ` Shinichiro Kawasaki via Linux-f2fs-devel
2024-03-24 12:13 ` Chao Yu
2024-03-25 2:14 ` Shinichiro Kawasaki via Linux-f2fs-devel
2024-03-25 3:06 ` Chao Yu [this message]
2024-03-25 6:56 ` Shinichiro Kawasaki via Linux-f2fs-devel
2024-03-26 3:30 ` Chao Yu
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=bd72565c-052e-457a-ac08-7bf40077992c@kernel.org \
--to=chao@kernel.org \
--cc=bvanassche@acm.org \
--cc=jaegeuk@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=shinichiro.kawasaki@wdc.com \
--cc=yi.zhang@redhat.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