b21f19c9 imp July 11, 2021, 4:35 p.m. 
Remove deugging stuff, since it's arguably not needed in a minimal
setup. Also vlan, tuntap and gif since they can be loaded.

imp didn't include the part of the patch that removed xen guest support.
Xen guest is relatively small and has no way of being loaded.

Reviewed by:	imp
PR:		229564
MFC After:	3 days
cgit
36cfb5d5 imp July 11, 2021, 3:05 p.m. 
NanoBSD has helper script "fill_pkg.sh" which links all packages and
ther dependencies from "package dump" (like /usr/ports/packages/All) to
specified director. fill_pkg.sh has some limitations:

1) It needs ports tree, which should have exactly same versions as
   "package dump".
2) It requires full paths to needed ports, including "/usr/ports" part.
3) It has assumptions about Nano Package Dir (it assumes, that it
   specified rtelative to current directory).
4) It does not have any diagnostics (almost).

This PR enhances "fill_pkg.sh" script in several ways:

1) Nano package dir could be absolute path.
2) Script understands four ways to specify "root" ports/packages:
   (a) Absolute directory with port (old one)
   (b) Relative directory with port, relative to ${PORTSDIR} or /usr/ports
   (c) Absolute path to file with package (with .tbz suffix)
   (d) Name of package in dump dir, with or without .tbz suffix

   These ways can be mixed in one call. Dependencies for
   packages are obtained with 'pkg_info -r' call, and are searched for
   in same directory as "parent" package. Dependencies for ports are
   obtained in old way from port's Makefile.
3) Three levels of diagnostic (and -v option, could be repeated) are added.
4) All path variables are enclosed in quotes, to make script work with paths,
   containing spaces.

Note: imp merged in the changes to fill_pkg.sh since this has been a PR.

PR:			151695
Reviewed by:		imp@
MFC After:		3 days
Differential Revision:	https://reviews.freebsd.org/D31101
cgit
9c1c0209 imp July 11, 2021, 2:47 p.m. 
Large nextboot.conf files (over 80 bytes) are not read correctly by the
Forth loader, causing file parsing to abort, and nextboot configuration
fails to apply.

Simple repro:

nextboot -e foo=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
shutdown -r now

That will cause the bug to cause a parse failure but shouldn't otherwise
affect the boot.  Depending on your loader configuration, you may also
have to set beastie_disable and/or reduce the number of modules loaded
to see the error on a small console screen.  12.0 or CURRENT users will
also have to explicitly use the Forth loader instead of the Lua loader.
The error will look something like:

Warning: syntax error on file /boot/loader.conf.local
foo="xxxxxxxxxxxxxxnextboot_enable="YES"
                                    ^
/boot/support.4th has crude file I/O buffering, which uses a buffer
'read_buffer', defined to be 80 bytes by the 'read_buffer_size'
constant.  The loader first tastes nextboot.conf, reading and parsing
the first line in it for nextboot_enable="YES".  If this is true, then
it reopens the file and parses it like other loader .conf files.

Unfortunately, the file I/O buffering code does not fully reset the
buffer state in the reset_line_reading word.  If the last file was read
to the end, that doesn't matter; the file buffer is treated as empty
anyway.  But in the nextboot.conf case, the loader will not read to the
end of file if it is over 80 bytes, and the file buffer may be reused
when reading the next file.  When the file is reread, the corrupt text
may cause file parsing to abort on bad syntax (if the corrupt line has
<>2 quotes in it), the wrong variable to be set, no variable to be set
at all, or (if the splice happens to land at a line ending) something
approximating normal operation.

The bug is very old, dating back to at least 2000 if not before, and is
still present in 12.0 and CURRENT r345863 (though it is now hidden by
the Lua loader by default).

Suggested one-line attached.  This does change the behavior of the
reset_line_reading word, which is exported in the line-reading
dictionary (though the export is not documented in loader man pages).
But repo history shows it was probably exported for the PNP support
code, which was never included in the loader build, and was removed 5
months ago.

One thing that puzzles me: how has this bug gone unnoticed/unfixed for
nearly 2 decades?  I find it hard to believe that nobody's tried to do
something interesting with nextboot, like load a kernel and filesystem,
which is what I'm doing.

PR: 239315
Reviewed by: imp
cgit
5aa1e55b gbe July 11, 2021, 12:53 p.m. 
MFC after:	3 days
cgit
cf48d1f7 hselasky July 11, 2021, 11:57 a.m. 
will work under FreeBSD, if the value is too big.

MFC after:	1 week
Sponsored by:	NVIDIA Networking
cgit
958826be noreply July 11, 2021, 1 a.m. 
Callers of zfs_file_get and zfs_file_put can corrupt the reference
counts for the file structure resulting in a panic or a soft lockup.
When zfs send/recv runs, it will add a reference count to the
open file, and begin to send or recv the stream. If the file descriptor
is closed, then when dmu_recv_stream() or dmu_send() return we will
call zfs_file_put to remove the reference we placed on the file
structure. Unfortunately, because zfs_file_put() uses the file
descriptor to lookup the file structure, it may end up finding that
the file descriptor table no longer contains the file struct, thus
leaking the file structure. Or it might end up finding a file
descriptor for a different file and blindly updating its reference
counts. Other failure modes probably exists.

This change reworks the zfs_file_[get|put] interface to not rely
on the file descriptor but instead pass the zfs_file_t pointer around.

Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Mark Maybee <mark.maybee@delphix.com>
Reviewed-by: Ryan Moeller <ryan@iXsystems.com>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: George Wilson <gwilson@delphix.com>
External-issue: DLPX-76119
Closes #12299
cgit
05f56ac9 hselasky July 10, 2021, 7:59 p.m. 
This allows other threads to execute, typically during hardware waiting loops.
This also maches how the function works in Linux.

Reviewed by:	kib
MFC after:	1 week
Sponsored by:	NVIDIA Networking
cgit
f52783fc hselasky July 10, 2021, 7:31 p.m. 
MFC after:	1 week
Sponsored by:	NVIDIA Networking
cgit
d2b55828 theraven July 10, 2021, 7:26 p.m. 
This broke the i386 build.

This reverts commit 3a522ba1bc852c3d4660a4fa32e4a94999d09a47.
cgit
8fc2a3c4 hselasky July 10, 2021, 6:59 p.m. 
computing the same isochronous start frame number over and over again.

PR:		257082
MFC after:	1 week
Sponsored by:	NVIDIA Networking
cgit
3f505486 hselasky July 10, 2021, 5:57 p.m. 
This fixes a compilation error.

MFC after:	1 week
Sponsored by:	NVIDIA Networking
cgit
d038463b hselasky July 10, 2021, 5:57 p.m. 
as given by the XHCI hardware parameters to avoid scheduling isochronous
transfers too early.

MFC after:	1 week
Sponsored by:	NVIDIA Networking
cgit
e036ee6c hselasky July 10, 2021, 5:57 p.m. 
the number of completion event TRBs. This avoids wasting memory.

MFC after:	1 week
Sponsored by:	NVIDIA Networking
cgit
d8514fa6 imp July 10, 2021, 4:53 p.m. 
Retire LZMA_SUPPORT. It's unused since r332995.

Reviewed by:		delphij
PR:			244302
Sponsored by:		Netflix
Differential Revision:	https://reviews.freebsd.org/D31088
cgit
445b5554 imp July 10, 2021, 4:53 p.m. 
The description of the power command is missing. While the synopsis is
present, there's no explanation. Add one.

Reviewed by:		mav, chuck
PR:			237866
Sponsored by:		Netflix
Differential Revision:	https://reviews.freebsd.org/D31122
cgit