From: Baolin Liu <liubaolin12138@163.com>
To: linkinjeon@kernel.org, hyc.lee@gmail.com
Cc: ntfs@lists.linux.dev, linux-kernel@vger.kernel.org,
Baolin Liu <liubaolin@kylinos.cn>
Subject: [PATCH v1 0/5] ntfs: support O_TMPFILE
Date: Tue, 27 Oct 2026 17:35:10 +0800 [thread overview]
Message-ID: <20261027093515.344799-1-liubaolin12138@163.com> (raw)
From: Baolin Liu <liubaolin@kylinos.cn>
Hi all,
This series adds O_TMPFILE support to fs/ntfs. Applications can prepare a
regular file's contents and metadata without exposing a directory entry,
then publish the file with linkat(). Unpublished files are reclaimed when
their last reference is released. O_EXCL prevents publication.
O_TMPFILE reuses the existing inode creation, EA update and hard-link
paths. The first four patches fix existing bugs in those paths, so that
anonymous files can inherit ACLs, prepare metadata and be published
correctly:
1. ACLs must be initialized after allocating the MFT record. Otherwise,
an inherited ACL can appear correct in memory but disappear after
inode eviction. Anonymous creation uses the same initialization
path as ordinary file creation.
2. Publication through linkat() must preserve the file's atime and
mtime. The existing hard-link path resets both; the fix updates only
the required timestamps and marks the affected inodes dirty.
3. Files may already have ACLs or other EAs before publication. The
hard-link path currently leaves the new FILE_NAME's packed EA size
at zero. Initialize it from EA_INFORMATION when adding the link.
4. Attribute inodes initialized while the base file has zero links
also have zero links. They are evicted at the final iput(), discarding
dirty pages from nonresident EA writes. Synchronous nonresident
writes keep a successful EA update readable after that cache is dropped.
These bugs also affect ordinary creation, hard links and open-unlinked
files. Keeping the fixes separate allows independent review and use
without O_TMPFILE. Patch 5 builds on them to add anonymous creation,
VFS-controlled publication and documentation.
Named-stream ioctls can create or open streams after publication, but
not while the temporary file remains unpublished.
Tested this five-patch series in QEMU with four CPUs, NTFS debug and
lockdep. Tests cover creation, publication, permissions, idmapped mounts,
direct I/O, mmap, allocation, concurrent publication and ENOSPC. Checks
after cache eviction/remount/reboot covered file contents, EA values,
access ACL readability, mode and explicitly set atime/mtime. Injected
ENOSPC at five creation/publication/open sites and checked failure
behavior and release of the recorded base MFT records. Ordinary file
operations were also exercised. Individual patch notes describe the tests.
Based on ntfs-next commit e845077350df3862c733ed10a950d49ef4d64b0c.
Thanks,
Baolin
Baolin Liu (2):
ntfs: initialize inherited ACLs after allocating the MFT record
ntfs: support O_TMPFILE
Xuewen Wang (3):
ntfs: preserve timestamps when creating hard links
ntfs: initialize packed EA size when creating hard links
ntfs: write unlinked file attributes before dropping their cache
Documentation/filesystems/ntfs.rst | 15 ++++
fs/ntfs/inode.c | 8 ++
fs/ntfs/namei.c | 123 ++++++++++++++++++++++++-----
3 files changed, 126 insertions(+), 20 deletions(-)
base-commit: e845077350df3862c733ed10a950d49ef4d64b0c
next reply other threads:[~2026-10-27 9:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 9:35 Baolin Liu [this message]
2026-10-27 9:35 ` [PATCH v1 1/5] ntfs: initialize inherited ACLs after allocating the MFT record Baolin Liu
2026-10-27 9:35 ` [PATCH v1 2/5] ntfs: preserve timestamps when creating hard links Baolin Liu
2026-10-29 0:15 ` Hyunchul Lee
2026-10-29 1:44 ` wangxuewen
2026-10-29 1:49 ` liubaolin
2026-10-27 9:35 ` [PATCH v1 3/5] ntfs: initialize packed EA size " Baolin Liu
2026-10-27 9:35 ` [PATCH v1 4/5] ntfs: write unlinked file attributes before dropping their cache Baolin Liu
2026-10-27 9:35 ` [PATCH v1 5/5] ntfs: support O_TMPFILE Baolin Liu
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=20261027093515.344799-1-liubaolin12138@163.com \
--to=liubaolin12138@163.com \
--cc=hyc.lee@gmail.com \
--cc=linkinjeon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liubaolin@kylinos.cn \
--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®