From: Matthias Goergens <matthias.goergens@gmail.com>
To: Namjae Jeon <linkinjeon@kernel.org>, Hyunchul Lee <hyc.lee@gmail.com>
Cc: Baolin Liu <liubaolin12138@163.com>,
ntfs@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/6] ntfs: fix the $MFT bootstrap hang and reads of unmapped runlist ranges
Date: Wed, 30 Sep 2026 11:48:29 +0800 [thread overview]
Message-ID: <cover.1790684177.git.matthias.goergens@gmail.com> (raw)
Hi Hyunchul,
This is v3, with your review of v2 and Baolin's applied:
- Patch 1: a failed retry for a vcn at or beyond allocated_size returns
the runlist end again, as in ntfs-next; only lookups below it fail
with -EIO. On its own, v2's patch 1 also failed lookups past EOF,
for instance when reading a file's last folio with 512-byte clusters
(Baolin). Baolin suggested moving patch 4's allocated_size check
before the retry instead, but that skips a retry ntfs-next makes: on
a corrupt volume whose allocated_size is cut to where a file's last
extent record starts, the rest of the file was then read as zeros,
where ntfs-next and v3's patch 1 read the data (with the whole series,
patch 6 rejects that file).
- Patch 4: the if statement you asked me to merge is gone, as the
allocated_size check now sits in patch 1, and in
ntfs_attr_vcn_to_rl() patch 4 only extends patch 1's -EIO to
LCN_ENOENT. The expansion rollback restores allocated_size under
size_lock.
- Patch 6: the comment is gone, and $MFT's own non-resident attribute
list is checked too (Baolin); a volume where that list claims more
data than its allocation used to mount and now fails to.
Patches 2, 3 and 5 are unchanged.
The series fixes a hang at mount when $MFT needs its own extent records
(patch 3, which needs patch 1). Patches 1 and 2 fix reads and writes
of a runlist range held in an extent record that cannot be read, which
returned zeros with no error or silently lost buffered writes, and
patch 4 does the same for a runlist that ends before allocated_size.
Patches 5 and 6 check the sizes of $MFT's data and of every non-resident
attribute against their allocation, as fs/ntfs3 does.
Tested under qemu with KASAN and the hung-task detector on ntfs-next,
with and without the series. Nine crafted images that hang or crash
the mount without it fail to mount with it, and six that read zeros
that are not on disk return errors instead. Eighteen images that mount
without the series, among them eight public test volumes written by
Windows or mkntfs, read every file the same with it, and six small
mkntfs images still mount. v3 gives the same results as v2 on all of
them. The images and the scripts that generate them are at
https://github.com/matthiasgoergens/linux/tree/reproducer/2026-09-26-ntfs-mft-runlist
and, for the ordinary file of patch 4, the unaligned allocated_size of
patch 6 and three of the eighteen volumes that mount, at
https://github.com/matthiasgoergens/linux/tree/reproducer/2026-09-26-ntfs-v2-extra
and, for v3's changes, at
https://github.com/matthiasgoergens/linux/tree/reproducer/2026-09-30-ntfs-v3
v2: https://lore.kernel.org/all/cover.1790417653.git.matthias.goergens@gmail.com/
v1: https://lore.kernel.org/all/20260922153931.1976405-1-matthias.goergens@gmail.com/
Thanks,
Matthias
Matthias Goergens (6):
ntfs: do not map an unmappable runlist fragment as a hole
ntfs: do not turn an unmappable runlist fragment into delalloc on
write
ntfs: fail the mount when $MFT needs its own extent records
ntfs: do not map a vcn as a hole when its runlist lookup failed
ntfs: fail the mount when $MFT's data size exceeds its allocation
ntfs: reject non-resident attributes whose sizes exceed their
allocation
fs/ntfs/attrib.c | 51 +++++++++++++++++++++++++++++++++++++++++-----
fs/ntfs/attrlist.c | 8 ++++++--
fs/ntfs/inode.c | 46 +++++++++++++++++++++++++++++++++++++++++
fs/ntfs/iomap.c | 16 +++++++++++++--
fs/ntfs/layout.h | 13 +++++++-----
fs/ntfs/volume.h | 3 +++
6 files changed, 123 insertions(+), 14 deletions(-)
base-commit: 259abb551e2944998cad4214c201954ab1ac5c8d
--
2.55.0
next reply other threads:[~2026-09-30 3:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 3:48 Matthias Goergens [this message]
2026-09-30 3:48 ` [PATCH v3 1/6] ntfs: do not map an unmappable runlist fragment as a hole Matthias Goergens
2026-09-30 3:48 ` [PATCH v3 2/6] ntfs: do not turn an unmappable runlist fragment into delalloc on write Matthias Goergens
2026-09-30 3:48 ` [PATCH v3 3/6] ntfs: fail the mount when $MFT needs its own extent records Matthias Goergens
2026-09-30 3:48 ` [PATCH v3 4/6] ntfs: do not map a vcn as a hole when its runlist lookup failed Matthias Goergens
2026-09-30 3:48 ` [PATCH v3 5/6] ntfs: fail the mount when $MFT's data size exceeds its allocation Matthias Goergens
2026-09-30 3:48 ` [PATCH v3 6/6] ntfs: reject non-resident attributes whose sizes exceed their allocation Matthias Goergens
2026-09-30 9:03 ` [PATCH v3 0/6] ntfs: fix the $MFT bootstrap hang and reads of unmapped runlist ranges Hyunchul Lee
2026-09-30 10:16 ` Namjae Jeon
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.1790684177.git.matthias.goergens@gmail.com \
--to=matthias.goergens@gmail.com \
--cc=hyc.lee@gmail.com \
--cc=linkinjeon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liubaolin12138@163.com \
--cc=ntfs@lists.linux.dev \
/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
all inboxes | Powered by JetHome®