Date: Sun, 10 Oct 2021 14:15:36 +1100 From: Peter Jeremy <peter@rulingia.com> To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Subject: Consistent panic with "zfs send --raw" Message-ID: <YWJa2CdoVbD9mXyT@server.rulingia.com>
next in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
I'm trying to replicate a filesystem with native encrytion enabled and
am getting a consistent NULL pointer dereference panic. I'm running
13-stable fdbbd118faab but the code is identical in HEAD.
Looking at the backtrace:
#16 <signal handler called>
#17 dmu_dump_write (dscp=dscp@entry=0xfffffe02501abc30, type=<optimized out>,
object=<optimized out>, offset=<optimized out>, offset@entry=0,
lsize=<optimized out>, lsize@entry=131072, psize=psize@entry=131072,
bp=0x0, data=0xfffffe02d94a6000)
at /usr/src/sys/contrib/openzfs/module/zfs/dmu_send.c:493
#18 0xffffffff80410a3c in do_dump (dscp=dscp@entry=0xfffffe02501abc30,
range=range@entry=0xfffff805fd82d900)
at /usr/src/sys/contrib/openzfs/module/zfs/dmu_send.c:1016
#19 0xffffffff8040ead3 in dmu_send_impl (dspp=<optimized out>,
dspp@entry=0xfffffe02501abdf0)
at /usr/src/sys/contrib/openzfs/module/zfs/dmu_send.c:2537
#20 0xffffffff8040d8fd in dmu_send_obj (pool=<optimized out>,
pool@entry=0xfffffe02d3b61000 "tank/compat@20210604bu", tosnap=10690,
fromsnap=11065, embedok=<optimized out>, embedok@entry=1,
large_block_ok=<optimized out>, large_block_ok@entry=2,
compressok=<optimized out>, compressok@entry=4, rawok=8, savedok=0,
outfd=1, off=0xfffffe02501ac070, dsop=0xfffffe02501ac058)
at /usr/src/sys/contrib/openzfs/module/zfs/dmu_send.c:2695
dmu_send.c:493 is "ASSERT(!BP_IS_EMBEDDED(bp));" which dereferences bp
with no checks for NULL, whereas dmu_send.c:1016 explicitly passes NULL
to dmu_dump_write() as bp. This is obviously a bug somewhere.
Looking at the comment at lines 1006-1008, it seems the code expects
that raw sends will always have large block sends enabled, avoiding the
problematic code block. And zfs-send(8) says that --raw implies
--large-block if the source is not encrypted. But even if I explicitly
specify --large-block then the code panics in the same way. (And
--large-block as on option doesn't actually make sense with --raw
because the send stream must match what's on local disk by definition).
At this point, I'm not sure what the correct fix is.
--
Peter Jeremy
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmFiWtBfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF
QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi
CzSQ0A/9FKtlwkAV1Icyobzwqs6t85aL+2zkoaOxHtCVhxIPrdDjc2T6h735C8Ur
Q/KSNrGEfLoeaGwsY6oSg/PKERxcagMVX/x+xg/jeprVz7ty+8eeFwCnOekmA+GM
8W6zlotdpkV8DhQxnoFJny0+D1wCsceU5e3WjOPPkeI54LWBTawm9CGYD2gH+ON7
LqHuhOUM89LDXNnv/DvpSPP4CAfkRzkjMmjtlp5Qsw4ry8Lxv/K9n4b2leiFJkML
acQwbM2bUEEdcTILKhJJrSGcBror1S21g1F58ediKboyWs2WdJkUJFbbH1H1cinj
x1hmNOFW6fO4b0YqNGEaUs88p/T4llm/iG78Uh2xuBzsHcqS+jPsORjaIMxqR+TC
D8QRvjWEoHnj1dPPqDZiv1y4hoE3LjxDlgg0S2HwKHstYtf2T7DttJdd1W1z0XvD
xswCLDt0J4eduOKzSfNgs9U6hF+GB1OqYCOxlTsZgieL8b1XSG8oawtoV5z3VujU
2yKVHmwfdzfhHI5WEjiJO8fMWy3PshuVVoiTE9tS61aa+BJQrRafrAJQfa0tMGIr
E+wB5qyg2pGgpSi+T+ZVcxQr6B55cCFdVanJZkiVmgXck5m3+MmjX5c5ehyUPCH8
Ono2bj0Ry8W7N95d39DCxzWLU2pvVjwLI8xfc291EIYkby0Wk9w=
=eIVH
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YWJa2CdoVbD9mXyT>