From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Ritesh Harjani <riteshh@linux.ibm.com>
Cc: Murphy Zhou <jencce.kernel@gmail.com>,
Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] ext4: validate fiemap iomap begin offset and length value
Date: Sun, 19 Apr 2020 00:42:24 -0400 [thread overview]
Message-ID: <20200419044224.GA311394@mit.edu> (raw)
In-Reply-To: <20200419015654.F2061A4051@d06av23.portsmouth.uk.ibm.com>
On Sun, Apr 19, 2020 at 07:26:53AM +0530, Ritesh Harjani wrote:
> ++ mailing list.
> Sorry somehow it got dropped.
>
>
> On 4/19/20 7:21 AM, Ritesh Harjani wrote:
> > Hello Murphy,
> >
> > I guess the patch to fix this issue was recently submitted.
> > Could you please test your reproducer, xfstest and ltp
> > tests on below patch too. And let me know if we can add your Tested-by:
> >
> > https://patchwork.ozlabs.org/project/linux-ext4/patch/1a2dc8f198e1225ddd40833de76b60c7ee20d22d.1587024137.git.riteshh@linux.ibm.com/
His reproducer is still failing with your patch. In order to for his
reproducer to succeed, we need to constrain lblk and last_lblk more
strictly than what is done in:
[PATCHv2 1/1] ext4: fix overflow case for map.m_len in ext4_iomap_begin_*
His patch does fix the issue.
ext4_map_block() is returning EFSCORRUPTED when lblk is
EXT4_MAX_LOGICAL_BLOCK, which is why he's constraining lblk to
EXT4_MAX_LOGICAL_BLOCK. I haven't looked into this more closely yet,
but it looks we have some overflow/wraparound issue when lblk is
0xFFFFFFFF. Which might mean that in fact EXT4_MAX_LOGICAL_BLOCK
might need to be 0xFFFFFFFE, or we need to look very closely our code
paths to make sure the right thing happes when we call
ext4_map_blocks() with m_lblk == 0xFFFFFFFF and m_len == 1.
I think we need to take his patch, and make a simialr change to
ext4_iomap_begin(). Ritesh, do you agree?
- Ted
next prev parent reply other threads:[~2020-04-19 4:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-18 23:32 [PATCH] ext4: validate fiemap iomap begin offset and length value Murphy Zhou
2020-04-19 1:56 ` Ritesh Harjani
2020-04-19 4:42 ` Theodore Y. Ts'o [this message]
2020-04-19 4:46 ` Theodore Y. Ts'o
2020-04-19 16:19 ` Ritesh Harjani
2020-04-20 2:57 ` Murphy Zhou
2020-04-20 4:16 ` Ritesh Harjani
2020-04-20 7:03 ` Ritesh Harjani
2020-04-20 7:27 ` Murphy Zhou
2020-04-20 13:48 ` Ritesh Harjani
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=20200419044224.GA311394@mit.edu \
--to=tytso@mit.edu \
--cc=jencce.kernel@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=riteshh@linux.ibm.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