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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.