illumos gate

Anyone looking at this?

By taking advantage of Channel Programs, this bug is becoming more frequent.

Here's a core dump from my latest encounter:

ftp://ftp.nrg.wustl.edu/pub/zfs/core_zfs_recv.gz

It appears OpenZFS recently fixed this in commit 7a6c12fd6a756af5a2f664c0a6a292d22fbb2487:

Don't assert on nvlists larger than SPA_MAXBLOCKSIZE
Originally we asserted that all reads are less than SPA_MAXBLOCKSIZE
However, nvlists are not ZFS records, and are not limited to
SPA_MAXBLOCKSIZE.

Add a new environment variable, ZFS_SENDRECV_MAX_NVLIST, to allow the
user to specify the maximum size of the nvlist that can be sent or
received.
Default value: 4 * SPA_MAXBLOCKSIZE (64 MB)

Modify libzfs send routines to return a useful error if the send stream
will generate an nvlist that is beyond the maximum size.

Modify libzfs recv routines to add an explicit error message if the
nvlist is too large, rather than abort()ing.

Move the change the assert() to only trigger on data records

Reviewed-by: Paul Dagnelie <pcd@delphix.com>
Reviewed-by: Kjeld Schouten <kjeld@schouten-lebbing.nl>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Allan Jude <allan@klarasystems.com>
Closes #9616

Looking at the change, it should be fairly straightforward to port this over.

A followup change should also be included:

commit 908d43d0a9f736af62c0f4b179950bb1262dfd7d
Author: Allan Jude <allanjude@freebsd.org>
Date:   Fri Sep 18 13:23:29 2020 -0400

    libzfs: Don't leak buf if nvlist is too large

    Resolves FreeBSD Coverity defect:
    CID 1432398:  Resource leaks  (RESOURCE_LEAK)

    libzfs: don't leak hdl if there is an error reading env var

    Resolves FreeBSD Coverity defect:
    CID 1432395:  Resource leaks  (RESOURCE_LEAK)

    Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
    Signed-off-by: Allan Jude <allanjude@freebsd.org>
    Closes #10882

I tested this by running the zfs test suite. The only failures were tests with known failure.

Additionally, I was able to recreate the assertion failure using the steps documented in the ticket. When booted on a BE with the change applied, the zfs recv command no longer fails, but succeeds:

root@pi:~# zpool create testpool c3t0d0
root@pi:~# zfs create testpool/foo
root@pi:~# for f in $(seq 1 160); do zfs create testpool/foo/$f; done
root@pi:~# for f in $(seq 1 1000); do zfs snapshot -r testpool/foo@abcdefghijklmnopqrstuvwxyz${f}; done
root@pi:~# zfs send -Ri abcdefghijklmnopqrstuvwxyz999 testpool/foo@abcdefghijklmnopqrstuvwxyz1000 > /ws/foo.zfs
root@pi:~# zfs recv -n testpool/foo < /ws/foo.zfs
Assertion failed: ilen <= SPA_MAXBLOCKSIZE, file ../common/libzfs_sendrecv.c, line 2201, function recv_read
Abort (core dumped)

On a BE w/ the change:

root@pi:/ws# zfs recv -n testpool/foo < foo.zfs
root@pi:/ws# echo $?
0