[for 26.04_linux-nvidia]: fs/ntfs3: fix mount failure on 64K page-size kernels

[jamieNguyenNVIDIA]

Summary

Backport linux-next commit b7a9125cac8645245d2473c6c0a50e338280ad23
to fix an ntfs3 mount failure on 64K page-size kernels.

The original failure was reproduced by LTP fsconfig01 using the new mount
API path:

• fsopen("ntfs")
• fsconfig(FSCONFIG_CMD_CREATE)
• kernel ntfs3 driver

On 64K kernels, small NTFS volumes could fail with EINVAL because
log_replay() used PAGE_SIZE for the initial NTFS log page-size probe.
For a 64K kernel this inflated the minimum accepted $LogFile size from
about 200 KiB to about 3.2 MiB. A 300 MiB NTFS filesystem, such as the one
created by LTP fsconfig01, has a smaller log file and was rejected.

The fix makes the initial probe use the NTFS default log page size and makes
read_log_page() pass the actual log page size to ntfs_fix_post_read().

Backport Provenance

The patch cherry-picked cleanly from linux-next.

• Upstream commit: b7a9125cac8645245d2473c6c0a50e338280ad23
• 26.04_linux-nvidia commit: 0ce2a315dcedf6ba58e975d973ddefc9cb7b8a9a

Test Methodology

• Test execution: QEMU/KVM aarch64 guest
• Kernel under test: locally built target branch Image
• Filesystem module under test: matching locally built ntfs3.ko
• Test binary: LTP fsconfig01 from LTP 20260130
• Test mode: LTP_SINGLE_FS_TYPE=ntfs
• Test device: fresh 300 MiB virtio disk per run
• Guest page-size assertion:
  • 4K runs verified PAGE_SIZE=4096
  • 64K runs verified PAGE_SIZE=65536

LTP Results

Branch	Kernel	Page Size	LTP fsconfig01 ntfs Result
26.04_linux-nvidia	7.0.0-1010-nvidia	4K	PASS: passed 1, failed 0, LTP_EXIT=0
26.04_linux-nvidia	7.0.0-1010-nvidia-64k	64K	PASS: passed 1, failed 0, LTP_EXIT=0

Validation Summary

The reported 64K ntfs3 failure is fixed on both target branches: LTP
fsconfig01 now passes for ntfs with PAGE_SIZE=65536.

The same LTP fsconfig01 ntfs test also passes on 4K kernels for both
target branches, so no regression was observed in the fixed ntfs3 code path.

LP: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-7.0/+bug/2155467

[github-actions]

PR Validation Report

Patchscan ✅ No Missing Fixes

All cherry-picked commits checked — no missing upstream fixes found.

PR Lint ❌ Errors found

Details

Checking 1 commits...

Cherry-pick digest:
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local        │ Referenced upstream / Patch subject                              │ Patch-ID   │ Subject │ SoB chain                 │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 0ce2a315dced │ [SAUCE] fs/ntfs3: fix mount failure on 64k page-size kernels     │ N/A        │ N/A     │ jamien, alexandr, jamien  │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘

Lint results:
E: 0ce2a315dced ("fs/ntfs3: fix mount failure on 64K page-size kerne"): not SAUCE/UBUNTU/Revert but has no upstream reference trailer (cherry picked from commit ... or backported from ...)

[nvmochs]

LGTM!

Acked-by: Matthew R. Ochs <mochs@nvidia.com>

[sforshee]

Looks good!

Acked-by: Seth Forshee <sforshee@nvidia.com>

[nirmoy]

Boro review

Summary

No issues found across the reviewed commits.

Findings: no problems found

Latest watcher review: open review

Kernel deb build: successful (download debs, 4 files)

Head: 0ce2a315dced

This comment is maintained by nv-pr-bot. It is updated when the GitHub watcher publishes a newer review.

[clsotog]

I got this from codex:
Resize one_page_buf when log->page_size grows. The patch now starts with a 4 KiB page size at nv-kernels-pr450-review/fs/ntfs3/fslog.c:3789, and one_page_buf is allocated at that size at nv-kernels-pr450-review/fs/ntfs3/fslog.c:3795. For an existing dirty log whose restart header
has sys_page_size/page_size larger than 4 KiB, nv-kernels-pr450-review/fs/ntfs3/fslog.c:3928 updates log->page_size to the larger on-disk value without reallocating one_page_buf. Later unaligned read_log_page() calls can read log->page_size bytes into that 4 KiB scratch buffer at nv-
kernels-pr450-review/fs/ntfs3/fslog.c:1167. On a 64 KiB log page this becomes a 64 KiB write into a 4 KiB allocation. Please grow/reallocate one_page_buf after the on-disk page size is adopted, or allocate it large enough for the maximum possible final size.

[jamieNguyenNVIDIA]

I got this from codex: Resize one_page_buf when log->page_size grows. The patch now starts with a 4 KiB page size at nv-kernels-pr450-review/fs/ntfs3/fslog.c:3789, and one_page_buf is allocated at that size at nv-kernels-pr450-review/fs/ntfs3/fslog.c:3795. For an existing dirty log whose restart header has sys_page_size/page_size larger than 4 KiB, nv-kernels-pr450-review/fs/ntfs3/fslog.c:3928 updates log->page_size to the larger on-disk value without reallocating one_page_buf. Later unaligned read_log_page() calls can read log->page_size bytes into that 4 KiB scratch buffer at nv- kernels-pr450-review/fs/ntfs3/fslog.c:1167. On a 64 KiB log page this becomes a 64 KiB write into a 4 KiB allocation. Please grow/reallocate one_page_buf after the on-disk page size is adopted, or allocate it large enough for the maximum possible final size.

I think this is a pre-existing bug in the log replay page-size adjustment path: one_page_buf is allocated before log_replay() may adopt the on-disk log page size, and the existing code does not resize it after that adjustment.

This patch changes the initial 64K-kernel replay page size from PAGE_SIZE to DefaultLogPageSize, so it can make that pre-existing issue reachable on 64K kernels when replaying a log whose on-disk page size is larger than 4K.

I think I'll need to send another fix to the mailing list...

[clsotog]

I got this from codex: Resize one_page_buf when log->page_size grows. The patch now starts with a 4 KiB page size at nv-kernels-pr450-review/fs/ntfs3/fslog.c:3789, and one_page_buf is allocated at that size at nv-kernels-pr450-review/fs/ntfs3/fslog.c:3795. For an existing dirty log whose restart header has sys_page_size/page_size larger than 4 KiB, nv-kernels-pr450-review/fs/ntfs3/fslog.c:3928 updates log->page_size to the larger on-disk value without reallocating one_page_buf. Later unaligned read_log_page() calls can read log->page_size bytes into that 4 KiB scratch buffer at nv- kernels-pr450-review/fs/ntfs3/fslog.c:1167. On a 64 KiB log page this becomes a 64 KiB write into a 4 KiB allocation. Please grow/reallocate one_page_buf after the on-disk page size is adopted, or allocate it large enough for the maximum possible final size.

I think this is a pre-existing bug in the log replay page-size adjustment path: one_page_buf is allocated before log_replay() may adopt the on-disk log page size, and the existing code does not resize it after that adjustment.

This patch changes the initial 64K-kernel replay page size from PAGE_SIZE to DefaultLogPageSize, so it can make that pre-existing issue reachable on 64K kernels when replaying a log whose on-disk page size is larger than 4K.

I think I'll need to send another fix to the mailing list...

I see no further issues from me then.
Acked-by: Carol L Soto <csoto@nvidia.com>

[nvmochs]

Merged, closing PR.

https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-nvidia/+git/resolute/commit/?h=main-next&id=16bc779d85f051fe1b11a1fe906c6154b2c6fbc9