Kernel Panic when under load, [SPTM] VIOLATION_ILLEGAL_PERMS

[Twister915]

Hi!

I was getting this kernel panic:

panic(cpu 12 caller 0xfffffe0055c64010): [SPTM] VIOLATION_ILLEGAL_PERMS: sptm_map_page(sptm.c:500) - page_fte(0xfffffdc00a4b4820), page_fte->type(0xe), new_perms(0x3), new_pte(0x46001292f154603), vaddr(0xfffffe85584d0000)

...

Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space
Panicked task 0xfffffe2315fcdcd0: 0 pages, 1534 threads: pid 0: kernel_task
Panicked thread: 0xfffffe28e1a7c4b8, backtrace: 0xfffffe6ef1b4ad10, tid: 2336
          lr: 0xfffffe00553417e0  fp: 0xfffffe6ef1b4adb0
          lr: 0xfffffe00554c2d7c  fp: 0xfffffe6ef1b4ae20
          lr: 0xfffffe00554c0e44  fp: 0xfffffe6ef1b4aee0
          ...
      Kernel Extensions in backtrace:
         com.apple.sptm(25.5)[7D2A90AA-5610-3400-B003-590DDDFDCD0C]@0xfffffe0030c0c000->0xfffffe0030c67fff
         org.openzfsonosx.zfs(2.3.1)[06D2D3A1-C9F7-3653-BAF1-F281AB0EF1F0]@0xfffffe00580b4f40->0xfffffe00582ef4ef
            dependency: com.apple.iokit.IOStorageFamily(2.1)[AA8C81ED-995B-3A0A-8879-A3B1BC904718]@0xfffffe00547552c0->0xfffffe00547749bf


last started kext at 1473784025: com.apple.filesystems.smbfs    6.0.1 (addr 0xfffffe005187dd30, size 113379)
loaded kexts: (skipped, see boot kernelcache)

** Stackshot Succeeded ** Bytes Traced 739948 (Uncompressed 1921872) **

I removed some stuff from here that I thought would not be relevant, but you can find it here.

Anyhow, I pointed my agent at it, and here's what I got (I will try to open a PR tomorrow, the diff it proposed is a few lines)

AI text below (gpt5.5, xhigh, June 14th) ⬇️

Environment

• Hardware: Mac Studio Mac15,14
• Chip: Apple M3 Ultra, 28 cores (20 performance / 8 efficiency)
• Memory: 256 GB
• Architecture: arm64 / Apple Silicon
• macOS: 26.5.1 build 25F80
• Darwin kernel: 25.5.0
• Kernel build: xnu-12377.121.6~2/RELEASE_ARM64_T6031
• System firmware: 18000.120.36
• OS loader: 18000.120.36
• OpenZFS userspace: zfs-2.3.1-1
• OpenZFS kmod: zfs-kmod-2.3.1-1
• ZFS sysctl: zfs.kext_version: 2.3.1-1
• Loaded kext: org.openzfsonosx.zfs (2.3.1)
• Loaded kext UUID: 06D2D3A1-C9F7-3653-BAF1-F281AB0EF1F0
• ZFS tools path: /usr/local/zfs/bin/zpool, /usr/local/zfs/bin/zfs
• Panic component: com.apple.sptm(25.5) with [SPTM] VIOLATION_ILLEGAL_PERMS

Workload correlation

This happened twice under heavy metadata churn:

• Spotlight indexing on the ZFS volume: mds / mdworker
• MinIO object storage workload on the pool
• scrub was also active/recent
• after disabling Spotlight indexing and stopping MinIO/scrub, panics stopped

Suspected cause

The macOS vnode/UBC code still has paths that call ubc_upl_map() or request writable UPL mappings where read-only mappings should be enough. On Apple Silicon, SPTM appears to reject a writable kernel mapping of a file-backed/protected/non-default page frame.

Most suspicious paths:

• update_pages() in module/os/macos/zfs/zfs_vnops_os.c
• mappedread() in module/os/macos/zfs/zfs_vnops_os.c
• zfs_vnop_pagein() in module/os/macos/zfs/zfs_vnops_osx.c
• legacy zfs_pageout() in module/os/macos/zfs/zfs_vnops_osx.c

zfs_vnop_pageoutv2() already has a partial SPTM-related ubc_upl_map_range(... VM_PROT_READ ...) workaround, but the other paths still look unsafe.

Proposed direction

For macOS 12+ / Apple Silicon:

• use ubc_upl_map_range() with explicit protections
• use VM_PROT_READ for pageout/mapped-read paths
• use VM_PROT_READ | VM_PROT_WRITE only where ZFS actually fills pages
• avoid UPL_FILE_IO in update_pages() when ZFS intends to CPU-write into UPL pages; use UPL_WILL_MODIFY