svn commit: r320156 - in head: cddl/contrib/opensolaris/cmd/zdb cddl/contrib/opensolaris/cmd/ztest cddl/contrib/opensolaris/lib/libzfs/common sys/cddl/contrib/opensolaris/common/zfs sys/cddl/contri...

[Andriy Gapon]

On 20/06/2017 23:29, Ken Merry wrote:
> I don’t know for sure that this commit is the cause, but it (and r320153) are the only ZFS commits between a version of head from June 14th that boots off a ZFS mirror, and one that panics.
> 
> Here’s the stack trace:
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 22; 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 9; apic id = 09
> fault virtual address   = 0x0
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x20:0xffffffff81e47f21
> stack pointer           = 0x28:0xfffffe08b37f8810
> frame pointer           = 0x28:0xfffffe08b37f8860
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 0 (zio_free_issue_0_3)
> [ thread pid 0 tid 100478 ]
> Stopped at      0xffffffff81e47f21 = zio_vdev_io_start+0x1f1:   testb   $0x1,(%rax)
> db> bt
> Tracing pid 0 tid 100478 td 0xfffff80193156000
> zio_vdev_io_start() at 0xffffffff81e47f21 = zio_vdev_io_start+0x1f1/frame 0xfffffe08b37f8860
> zio_execute() at 0xffffffff81e4312c = zio_execute+0x36c/frame 0xfffffe08b37f88b0
> zio_nowait() at 0xffffffff81e422b8 = zio_nowait+0xb8/frame 0xfffffe08b37f88e0
> vdev_mirror_io_start() at 0xffffffff81e224fc = vdev_mirror_io_start+0x38c/frame 0xfffffe08b37f8930
> zio_vdev_io_start() at 0xffffffff81e48030 = zio_vdev_io_start+0x300/frame 0xfffffe08b37f8990
> zio_execute() at 0xffffffff81e4312c = zio_execute+0x36c/frame 0xfffffe08b37f89e0
> taskqueue_run_locked() at 0xffffffff809a9d6d = taskqueue_run_locked+0x13d/frame 0xfffffe08b37f8a40
> taskqueue_thread_loop() at 0xffffffff809aab28 = taskqueue_thread_loop+0x88/frame 0xfffffe08b37f8a70
> fork_exit() at 0xffffffff8091e3e4 = fork_exit+0x84/frame 0xfffffe08b37f8ab0
> fork_trampoline() at 0xffffffff80d930fe = fork_trampoline+0xe/frame 0xfffffe08b37f8ab0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> db> 
> 
> (kgdb) list *(zio_vdev_io_start+0x1f1)
> 0xd9f21 is in zio_vdev_io_start (/usr/home/kenm/perforce4/kenm/FreeBSD-test/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:350).
> 345
> 346             /*
> 347              * Ensure that anyone expecting this zio to contain a linear ABD isn't
> 348              * going to get a nasty surprise when they try to access the data.
> 349              */
> 350             IMPLY(abd_is_linear(zio->io_abd), abd_is_linear(data));
> 351
> 352             zt->zt_orig_abd = zio->io_abd;
> 353             zt->zt_orig_size = zio->io_size;
> 354             zt->zt_bufsize = bufsize;
> 
> I’ll try rebooting and see if the problem goes away.  If not, I’ll roll back the ABD change and see if the problem goes away.

Judging from the thread that panic-ed the problem may have to do with our TRIM
support.  Unfortunately,  I didn't have a chance to test the change on a system
with working TRIM and, so, I missed it.
I will look into this further, but it's almost obvious that the problem is
caused by zio->io_abd being NULL for a zio of type ZIO_TYPE_FREE.

-- 
Andriy Gapon