Summary

cd9660 is the only mainstream filesystem not wired into DragonFly's SEEK_DATA/SEEK_HOLE infrastructure: cd9660_ioctl intercepts every ioctl and returns ENOTTY except FIOGETLBA, so lseek(SEEK_DATA/SEEK_HOLE) on any cd9660 file returns EINVAL while ufs/ext2/hammer2 all dispatch to vn_bmap_seekhole. This gap is today the ONLY thing keeping cd9660_bmap's KKASSERT((loffset & (bsize-1))==0) (:76) unreachable: vn_bmap_seekhole_locked passes the raw user-supplied file offset to VOP_BMAP on its first loop iteration ('noff += bsize - noff % bsize' only aligns subsequent iterations), so wiring cd9660 up the way the other filesystems are wired would make 'lseek(fd, 1, SEEK_DATA)' - unprivileged, needing only read access to any file on a mounted ISO - panic every INVARIANTS/DEBUG kernel instantly. No impact as shipped (unreachability proven by enumeration of all seven VOP_BMAP caller classes + the ENOTTY catch-all). Latent trap + functional gap. Fix (either suffices): make cd9660_bmap tolerant (round loffset down instead of asserting - the mapping is a pure offset shift, so rounding is semantically correct); optionally wire FIOSEEK* through vn_bmap_seekhole for parity. [VERIFIED pass2: reproduced - lseek SEEK_DATA HOLE EINVAL on cd9660 vs ufs working; F40FIX wires FIOSEEKDATA HOLE through vn_bmap_seekhole, aligned and unaligned work no panic]