Re: Panic in getblkx() booting from disc1.iso in Qemu VM

On Thu, Dec 20, 2018 at 10:33:20AM -0700, Rebecca Cran wrote:
> I know booting from the cd/dvd iso worked fairly recently, but today booting a 
> new build of -CURRENT in a Qemu VM resulted in a panic:
> 
> FreeBSD 13.0-CURRENT 19a6ceb89db(HEAD) GENERIC amd64
> FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 
> 7.0.1)
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(efifb): resolution 800x600
> CPU: QEMU Virtual CPU version 2.5+ (2994.86-MHz K8-class CPU)
>   Origin="AuthenticAMD"  Id=0x663  Family=0x6  Model=0x6  Stepping=3
>   Features=0x783fbfd<FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2>
>   Features2=0x80002001<SSE3,CX16,HV>
>   AMD Features=0x20100800<SYSCALL,NX,LM>
>   AMD Features2=0x5<LAHF,SVM>
>   SVM: NAsids=16
> Hypervisor: Origin = "TCGTCGTCGTCG"
> real memory  = 8589934592 (8192 MB)
> avail memory = 8227643392 (7846 MB)
> 
> ...
> 
> WARNING: WITNESS option enabled, expect reduced performance.
> Trying to mount root from cd9660:/dev/iso9660/13_0_CURRENT_AMD64_DVD [ro]...
> panic: bsize == 0, check bo->bo_bsize
> cpuid = 0
> time = 2
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0041189270
> vpanic() at vpanic+0x1b4/frame 0xfffffe00411892d0
> panic() at panic+0x43/frame 0xfffffe0041189330
> getblkx() at getblkx+0x807/frame 0xfffffe00411893f0
> breadn_flags() at breadn_flags+0x3d/frame 0xfffffe0041189460
> cd9660_blkatoff() at cd9660_blkatoff+0x53/frame 0xfffffe00411894d0
> cd9660_vget_internal() at cd9660_vget_internal+0x26b/frame 0xfffffe0041189550
> vfs_domount() at vfs_domount+0x7d3/frame 0xfffffe0041189770
> vfs_donmount() at vfs_donmount+0x7b9/frame 0xfffffe0041189810
> kernel_mount() at kernel_mount+0x58/frame 0xfffffe0041189860
> parse_mount() at parse_mount+0x469/frame 0xfffffe00411899a0
> vfs_mountroot() at vfs_mountroot+0x67f/frame 0xfffffe0041189b10
> start_init() at start_init+0x28/frame 0xfffffe0041189bb0
> fork_exit() at fork_exit+0x84/frame 0xfffffe0041189bf0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0041189bf0

Peter reported the same problem with ext2.  I believe this is a
regression from r342135, which moved a VFS_ROOT call before VFS_STATFS.
For most filesystems, VFS_STATFS is the place where mp->mnt_stat is
initialized, so the problem arises because mnt_stat.f_iosize is still
0 when the root vnode is initialized.  UFS initializes mnt_stat.f_iosize
in its VFS_MOUNT implementation, so it is immune to this problem.