Skip to content
  • Kirk McKusick's avatar
    Two bug fixes to UFS/FFS superblock integrity checks when reading a superblock. · bc218d89
    Kirk McKusick authored
    Two bugs have been reported with the UFS/FFS superblock integrity
    checks that were added in commit 076002f2.
    
    The code checked that fs_sblockactualloc was properly set to the
    location of the superblock. The fs_sblockactualloc field was an
    addition to the superblock in commit dffce215 on Jan 26 2018
    and used a field that was zero in filesystems created before it
    was added. The integrity check had to be expanded to accept the
    fs_sblockactualloc field being zero so as not to reject filesystems
    created before Jan 26 2018.
    
    The integrity check set an upper bound on the value of fs_maxcontig
    based on the maximum transfer size supported by the kernel. It
    required that fs->fs_maxcontig <= maxphys / fs->fs_bsize. The kernel
    variable maxphys defines the maximum transfer size permitted by the
    controllers and/or buffering. The fs_maxcontig parameter controls the
    maximum number of blocks that the filesystem will read or write in
    a single transfer. It is calculated when the filesystem is created
    as maxphys / fs_bsize. The bug appeared in the loader because it
    uses a maxphys of 128K even when running on a system that supports
    larger values. If the filesystem was built on a system that supports
    a larger maxphys (1M is typical) it will have configured fs_maxcontig
    for that larger system so would fail the test when run with the smaller
    maxphys used by the loader. So we bound the upper allowable limit
    for fs_maxconfig to be able to at least work with a 1M maxphys on the
    smallest block size filesystem: 1M / 4096 == 256. We then use the
    limit for fs_maxcontig as fs_maxcontig <= MAX(256, maxphys / fs_bsize).
    There is no harm in allowing the mounting of filesystems that make larger
    than maxphys I/O requests because those (mostly 32-bit machines) can
    (very slowly) handle I/O requests that exceed maxphys.
    
    Thanks to everyone who helped sort out the problems and the fixes.
    
    Reported by:  Cy Schubert, David Wolfskill
    Diagnosis by: Mark Johnston, John Baldwin
    Reviewed by:  Warner Losh
    Tested by:    Cy Schubert, David Wolfskill
    MFC after:    1 month (with 076002f2)
    Differential Revision: https://reviews.freebsd.org/D35219
    bc218d89