linux.git/fs/exfat, branch v7.2-rc2

iomap: consolidate bio submission

2026-07-01T13:26:47+00:00

Add a iomap_bio_submit_read_endio helper factored out of
iomap_bio_submit_read to that all ->submit_read implementations for
iomap_read_ops that use iomap_bio_read_folio_range can shared the
logic.

Right now that logic is mostly trivial, but already has a bug for XFS
because the XFS version is too trivial:  file system integrity validation
needs a workqueue context and thus can't happen from the default iomap
bi_end_io I/O handler.  Unfortunately the iomap refactoring just before
fs integrity landed moved code around here and the call go misplaced,
meaning it never got called.  The PI information still is verified by
the block layer, but the offloading is less efficient (and the future
userspace interface can't get at it).

Fixes: 0b10a370529c ("iomap: support T10 protection information")
Cc: stable@vger.kernel.org # v7.1
Signed-off-by: Christoph Hellwig 
Link: https://patch.msgid.link/20260629121750.3392300-2-hch@lst.de
Acked-by: Namjae Jeon 
Reviewed-by: "Darrick J. Wong" 
Reviewed-by: Joanne Koong 
Signed-off-by: Christian Brauner (Amutable)

exfat: bound uniname advance in exfat_find_dir_entry()

2026-06-15T11:01:04+00:00

In exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the
output pointer by a fixed amount while the loop guard only tracks the
accumulated name length:

	if (++order == 2)
		uniname = p_uniname->name;
	else
		uniname += EXFAT_FILE_NAME_LEN;
	len = exfat_extract_uni_name(ep, entry_uniname);
	name_len += len;
	unichar = *(uniname+len);
	*(uniname+len) = 0x0;

uniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len
grows only by the actual extracted length, which is shorter when a name
fragment contains an early NUL.  The only guard is
`name_len >= MAX_NAME_LENGTH`, so a crafted directory with many short
name fragments lets uniname run far past the
p_uniname->name[MAX_NAME_LENGTH + 3] buffer while name_len stays small,
causing an out-of-bounds read and write at *(uniname+len).

The sibling extractor exfat_get_uniname_from_ext_entry() already stops
on a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard
added in commit d42334578eba ("exfat: check if filename entries exceeds
max filename length")); exfat_find_dir_entry() never got the
equivalent.  Track the per-entry write offset as a count and reject a
fragment once the offset, or the offset plus the extracted length, would
exceed MAX_NAME_LENGTH, before forming the output pointer.

Fixes: ca06197382bd ("exfat: add directory operations")
Cc: stable@vger.kernel.org
Suggested-by: Namjae Jeon 
Signed-off-by: Bryam Vargas 
Signed-off-by: Namjae Jeon

exfat: add swap_activate support

2026-06-15T11:01:00+00:00

Commit 07d67f3e9083 ("exfat: add iomap buffered I/O support")
converted exfat buffered I/O to iomap, but did not add a
.swap_activate handler to the address_space_operations.

swapon(2) on an exfat swapfile then fails with EINVAL, which causes
LTP swap tests to fail.

Add exfat_iomap_swap_activate() and hook it into exfat_aops so exfat
uses iomap_swapfile_activate() for swapfile activation.

Fixes: 614f71ca1bdf ("exfat: add iomap buffered I/O support")
Closes: https://lore.kernel.org/all/20260603110212.3020276-1-japo@linux.ibm.com/
Signed-off-by: Jan Polensky 
Signed-off-by: Namjae Jeon

exfat: preserve benign secondary entries during rename and move

2026-06-15T11:00:53+00:00

Commit 8258ef28001a ("exfat: handle unreconized benign secondary
entries") added cluster freeing for benign secondary entries inside
exfat_remove_entries().  However, exfat_remove_entries() is also called
from the rename and move paths (exfat_rename_file and exfat_move_file),
where the old entry set is being relocated rather than deleted.  This
causes benign secondary entries such as vendor extension entries to be
silently destroyed on rename or cross-directory move, violating the
exFAT spec requirement (section 8.2) that implementations preserve
unrecognized benign secondary entries.

Fix this by adding a free_benign parameter to exfat_remove_entries()
so callers can suppress cluster freeing during relocation, and
extending exfat_init_ext_entry() to copy trailing benign secondary
entries from the old entry set into the new one internally.  Also
clean up the error paths to delete newly allocated entries on failure.

Fixes: 8258ef28001a ("exfat: handle unreconized benign secondary entries")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/linux-fsdevel/CAG7tbBV--waov7XVu2FHQEc6paR92dufS=em9DW5Kzsrpu3iQg@mail.gmail.com/
Signed-off-by: Rochan Avlur 
Reviewed-by: Yuezhang Mo 
Signed-off-by: Namjae Jeon

exfat: serialize truncate against in-flight DIO

2026-06-15T11:00:49+00:00

exfat_setattr() did not call inode_dio_wait() before performing a size
change, leaving a window where a concurrent in-flight DIO write could be
operating on clusters that the truncate is about to free.

Add inode_dio_wait() before the truncate_setsize()/exfat_truncate()
sequence so that any in-flight DIO completes before cluster freeing
begins.

Signed-off-by: Namjae Jeon

exfat: add support for SEEK_HOLE and SEEK_DATA in llseek

2026-06-15T11:00:44+00:00

Adds exfat_file_llseek() that implements these whence values via
the iomap layer (iomap_seek_hole() and iomap_seek_data()) using the
existing exfat_read_iomap_ops.
Unlike many other modern filesystems, exFAT does not support sparse files
with unallocated clusters (holes). In exFAT, clusters are always fully
allocated once they are written or preallocated. In addition, exFAT
maintains a separate "Valid Data Length" (valid_size) that is distinct
from the logical file size. This affects how holes are reported during
seeking. In exfat_iomap_begin(), ranges where the offset is greater
than or equal to ei->valid_size are mapped as IOMAP_UNWRITTEN, while ranges
below valid_size are mapped as IOMAP_MAPPED. This mapping behavior is used
by the iomap seek functions to correctly report SEEK_HOLE and SEEK_DATA
positions.

   - Ranges with offset >= ei->valid_size are mapped as IOMAP_HOLE.
   - Ranges with offset < ei->valid_size are mapped as IOMAP_MAPPED.

Reviewed-by: Christoph Hellwig 
Acked-by: Christoph Hellwig 
Acked-by: "Darrick J. Wong" 
Signed-off-by: Namjae Jeon

exfat: add iomap direct I/O support

2026-06-15T11:00:40+00:00

Add iomap-based direct I/O support to the exfat filesystem. This replaces
the previous exfat_direct_IO() implementation that used
blockdev_direct_IO() with iomap_dio_rw() interface.

Reviewed-by: Christoph Hellwig 
Acked-by: Christoph Hellwig 
Acked-by: "Darrick J. Wong" 
Signed-off-by: Namjae Jeon

exfat: add iomap buffered I/O support

2026-06-15T11:00:23+00:00

Add full buffered I/O support using the iomap framework to the exfat
filesystem. This will replaces the old exfat_get_block(),
exfat_write_begin(), exfat_write_end(), and exfat_block_truncate_page()
with their iomap equivalents. Buffered writes now use
iomap_file_buffered_write(), read uses iomap_bio_read_folio() and
iomap_bio_readahead(), and writeback is handled through iomap_writepages().

Acked-by: Christoph Hellwig 
Acked-by: "Darrick J. Wong" 
Signed-off-by: Namjae Jeon

exfat: fix implicit declaration of brelse()

2026-06-15T10:55:52+00:00

exfat_cluster_walk() calls brelse(bh) without including the header that
declares the function, causing the following build error:

    fs/exfat/exfat_fs.h:542:9: error: implicit declaration of function ‘brelse’ [-Werror=implicit-function-declaration]

Fix this by adding the missing buffer_head.h in exfat_fs.h.

Acked-by: Christoph Hellwig 
Acked-by: "Darrick J. Wong" 
Signed-off-by: Namjae Jeon

exfat: add data_start_bytes and exfat_cluster_to_phys_bytes() helper

2026-06-15T10:55:47+00:00

This caches the data area start offset in bytes (data_start_bytes)
and introduces a helper function exfat_cluster_to_phys_bytes() to compute
the physical byte position of a given cluster.

Acked-by: Christoph Hellwig 
Acked-by: "Darrick J. Wong" 
Signed-off-by: Namjae Jeon