From: Ritesh Harjani <riteshh@linux.ibm.com>
To: linux-ext4@vger.kernel.org
Cc: jack@suse.cz, tytso@mit.edu, adilger@dilger.ca,
darrick.wong@oracle.com, hch@infradead.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Dan Carpenter <dan.carpenter@oracle.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
Ritesh Harjani <riteshh@linux.ibm.com>,
Murphy Zhou <jencce.kernel@gmail.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Amir Goldstein <amir73il@gmail.com>,
linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org
Subject: [PATCH 0/5] ext4/overlayfs: fiemap related fixes
Date: Thu, 23 Apr 2020 16:17:52 +0530 [thread overview]
Message-ID: <cover.1587555962.git.riteshh@linux.ibm.com> (raw)
Hello All,
Here are some changes, which as I understand, takes the right approach in fixing
the offset/length bounds check problem reported in threads [1]-[2].
These warnings in iomap_apply/ext4 path are reported after ext4_fiemap()
was moved to use iomap framework and when overlayfs is mounted on top of ext4.
Though the issues were identified after ext4 moved to iomap framework, but
these changes tries to fix the problem which are anyways present in current code
irrespective of ext4 using iomap framework for fiemap or not.
Patch 1 & 4 commit msg may give more details of the problem.
Tests done
==========
1. Tested xfstest-suite with "-g quick" & "-overlay -g quick" configuration
on a 4k blocksize on x86 & Power. There were no new failures reported
due to these changes.
2. Tested syzcaller reported problem with this change. [1]
3. Tested below change which was reported by Murphy. [2]
The minimal reproducer is:
-------------------------------------
fallocate -l 256M test.img
mkfs.ext4 -Fq -b 4096 -I 256 test.img
mkdir -p test
mount -o loop test.img test || exit
pushd test
rm -rf l u w m
mkdir -p l u w m
mount -t overlay -o lowerdir=l,upperdir=u,workdir=w overlay m || exit
xfs_io -f -c "pwrite 0 4096" -c "fiemap" m/tf
umount m
rm -rf l u w m
popd
umount -d test
rm -rf test test.img
-------------------------------------
Comments/feedback are much welcome!!
References
==========
[1]: https://lkml.org/lkml/2020/4/11/46
[2]: https://patchwork.ozlabs.org/project/linux-ext4/patch/20200418233231.z767yvfiupy7hwgp@xzhoux.usersys.redhat.com/
Ritesh Harjani (5):
ext4: Fix EXT4_MAX_LOGICAL_BLOCK macro
ext4: Rename fiemap_check_ranges() to make it ext4 specific
vfs: EXPORT_SYMBOL for fiemap_check_ranges()
overlayfs: Check for range bounds before calling i_op->fiemap()
ext4: Get rid of ext4_fiemap_check_ranges
fs/ext4/ext4.h | 2 +-
fs/ext4/ioctl.c | 23 -----------------------
fs/ioctl.c | 5 +++--
fs/overlayfs/inode.c | 7 ++++++-
include/linux/fs.h | 2 ++
5 files changed, 12 insertions(+), 27 deletions(-)
--
2.21.0
next reply other threads:[~2020-04-23 10:48 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 10:47 Ritesh Harjani [this message]
2020-04-23 10:47 ` [PATCH 1/5] ext4: Fix EXT4_MAX_LOGICAL_BLOCK macro Ritesh Harjani
2020-04-23 11:16 ` Jan Kara
2020-04-23 10:47 ` [PATCH 2/5] ext4: Rename fiemap_check_ranges() to make it ext4 specific Ritesh Harjani
2020-04-23 11:17 ` Jan Kara
2020-04-23 10:47 ` [PATCH 3/5] vfs: EXPORT_SYMBOL for fiemap_check_ranges() Ritesh Harjani
2020-04-23 11:18 ` Jan Kara
2020-04-23 10:47 ` [PATCH 4/5] overlayfs: Check for range bounds before calling i_op->fiemap() Ritesh Harjani
2020-04-23 11:19 ` Jan Kara
2020-04-25 8:54 ` Amir Goldstein
2020-04-23 10:47 ` [PATCH 5/5] ext4: Get rid of ext4_fiemap_check_ranges Ritesh Harjani
2020-04-23 11:20 ` Jan Kara
2020-04-24 10:11 ` [PATCH 0/5] ext4/overlayfs: fiemap related fixes Christoph Hellwig
2020-04-24 23:20 ` Ritesh Harjani
2020-04-25 9:11 ` Amir Goldstein
2020-04-25 9:43 ` Christoph Hellwig
2020-04-25 10:49 ` Amir Goldstein
2020-04-25 11:14 ` Ritesh Harjani
2020-04-27 6:28 ` Christoph Hellwig
2020-04-27 10:15 ` Amir Goldstein
2020-04-27 10:38 ` Christoph Hellwig
2020-04-25 17:32 ` Andreas Dilger
2020-04-27 6:42 ` Christoph Hellwig
2020-04-25 9:44 ` Ritesh Harjani
2020-05-19 2:43 ` Murphy Zhou
2020-05-21 6:08 ` Ritesh Harjani
2020-05-22 4:56 ` Murphy Zhou
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=cover.1587555962.git.riteshh@linux.ibm.com \
--to=riteshh@linux.ibm.com \
--cc=adilger@dilger.ca \
--cc=amir73il@gmail.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=dan.carpenter@oracle.com \
--cc=darrick.wong@oracle.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jencce.kernel@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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).