Reviewed by: Serapheim Dimitropoulos <>
Reviewed by: George Wilson <>

While expanding stored pools, we ran into a panic using an old pool.

Steps to reproduce:

jkennedy-origin% sudo zpool create -o version=2 test c2t1d0
jkennedy-origin% sudo cp /etc/passwd /test/foo
jkennedy-origin% sudo zpool attach test c2t1d0 c2t2d0

We'll get this panic:

ffffff000fc0e5e0 unix:real_mode_stop_cpu_stage2_end+b27c ()
ffffff000fc0e6f0 unix:trap+dc8 ()
ffffff000fc0e700 unix:cmntrap+e6 ()
ffffff000fc0e860 zfs:dsl_scan_visitds+1ff ()
ffffff000fc0ea20 zfs:dsl_scan_visit+fe ()
ffffff000fc0ea80 zfs:dsl_scan_sync+1b3 ()
ffffff000fc0eb60 zfs:spa_sync+435 ()
ffffff000fc0ec20 zfs:txg_sync_thread+23f ()
ffffff000fc0ec30 unix:thread_start+8 ()

The problem is a bad trap accessing a NULL pointer. We're looking for the 
dp_origin_snap of a dsl_pool_t,
but version 2 didn't have that.  The system will go into a reboot loop at this 
point, and the dump won't
be accessible except by removing the cache file from within the recovery 

This impacts any sort of scrub or resilver on version <11 pools, e.g.:

zpool create -o version=10 test c2t1d0
zpool scrub test

Upstream bug: DLPX-56971
You can view, comment on, or merge this pull request online at:

-- Commit Summary --

  * 9443 panic when scrub a v10 pool

-- File Changes --

    M usr/src/uts/common/fs/zfs/dsl_scan.c (5)

-- Patch Links --

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:

openzfs: openzfs-developer
Delivery options:

Reply via email to