r359731 brueffer April 8, 2020, 8 p.m.
Submitted by:	Gordon Bergling
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D23905
r359730 oshogbo April 8, 2020, 6:43 p.m.
We don't have a way to send a UDP package.

PR:		245314
Reported by:	dch
Discussed with:	emaste
r359729 imp April 8, 2020, 5:55 p.m.
Reviewed by: rrs@
r359727 hselasky April 8, 2020, 5:09 p.m.
in the LinuxKPI.

This allows synchronize RCU to be used inside a SRCU read section.
No functional change intended.

Bump the __FreeBSD_version to force recompilation of external kernel modules.

PR:		242272
MFC after:	1 week
Sponsored by:	Mellanox Technologies
r359726 hselasky April 8, 2020, 4:07 p.m.
- Make sure to use READ_ONCE() when deferring variables.
- Remove superfluous zero initializer.

MFC after:	1 week
Sponsored by:	Mellanox Technologies
r359724 hselasky April 8, 2020, 8:56 a.m.
MFC after:	1 week
Sponsored by:	Mellanox Technologies
r359723 hselasky April 8, 2020, 8:53 a.m.
Leftover from when DRBR was removed.

MFC after:	1 week
Sponsored by:	Mellanox Technologies
r359720 rmacklem April 8, 2020, 1:12 a.m.
Luoqi Chen reported a problem on freebsd-fs@ where a Linux NFSv4 client
was able to open and write to a file when the file's permissions were
not set to allow the owner write access.

Since NFS servers check file permissions on every write RPC, it is standard
practice to allow the owner of the file to do writes, regardless of
file permissions. This provides POSIX like behaviour, since POSIX only
checks permissions upon open(2).
The traditional way NFS clients handle this is to check access via the
Access operation/RPC and use that to determine if an open(2) on the
client is allowed.

It appears that, for NFSv4, the Linux client expects the NFSv4 Open (not a
POSIX open) operation to fail with NFSERR_ACCES if the file is not being
created and file permissions do not allow owner access, unlike NFSv3.
Since both the Linux and OpenSolaris NFSv4 servers seem to exhibit this
behaviour, this patch changes the FreeBSD NFSv4 server to do the same.
A sysctl called vfs.nfsd.v4openaccess can be set to 0 to return the
NFSv4 server to its previous behaviour.

Since both the Linux and FreeBSD NFSv4 clients seem to exhibit correct
behaviour with the access check for file owner in Open enabled, it is enabled
by default.

Reported by:	luoqi.chen@gmail.com
MFC after:	2 weeks
r359719 rgrimes April 7, 2020, 11:17 p.m.
smbios->bcdrev value.
Correct that by calculating bcdrev from the major/minor values.

Reported by:	bcran
Reviewed by:	bcran, jhb
Approved by:	jhb (maintainer)
r359718 imp April 7, 2020, 10:23 p.m.
including it. sparc64 was the last straggler here, but these weren't removed at
the time.
r359717 dab April 7, 2020, 8:26 p.m.
I recently made some bug fixes in nvmecontrol. It occurred to me that
since nvmecontrol lacks any kyua tests, I should convert the informal
testing I did into a more formal automated test. The test in this
change should be considered just a starting point; it is neither
complete nor thorough. While converting the test to ATF/kyua, I
discovered a small bug in nvmecontrol; the nvmecontrol devlist command
would always exit with an unsuccessful status. So I included the fix
for that, too, so that the test won't fail.

Reviewed by:	imp@
MFC after:	3 days
Sponsored by:	Dell EMC Isilon
Differential Revision:	https://reviews.freebsd.org/D24269
r359716 luporl April 7, 2020, 7:46 p.m.
Although PPC OFW loader already had a LOADER_MSDOS_SUPPORT option, a few lines
were missing in conf.c, in order to support FAT filesystems.

This is useful when running FreeBSD under QEMU, to be able to easily change the
kernel and modules when running on hosts without UFS read/write support.

Reviewed by:	jhibbits
Sponsored by:	Eldorado Research Institute (eldorado.org.br)
Differential Revision:	https://reviews.freebsd.org/D24328
r359705 bdrewery April 7, 2020, 5:07 p.m.
Sponsored by:	Dell EMC
MFC after:	2 weeks
r359704 afedorov April 7, 2020, 5:06 p.m.
The flag can be enabled using the new 'mtu' option:
bhyve -s X:Y:Z,virtio-net,[tapN|valeX:N],mtu=9000

Reported by:	vmaffione, jhb
Approved by:	vmaffione (mentor)
Differential Revision:	https://reviews.freebsd.org/D23971
r359702 kevans April 7, 2020, 5:04 p.m.
-fno-common will become the default in GCC10/LLVM11. Plenty of work has been
put in to make sure our world builds are no -fno-common clean, so let's slap
the build with this until it becomes the compiler default to ensure we don't

At this time, we will not be enforcing -fno-common on ports builds. I
suspect most ports will be or quickly become -fno-common clean as they're
naturally built against compilers that default to it, so this will hopefully
become a non-issue in due time. The exception to this, which is actually the
status quo, is that kmods built from ports will continue to build with

As of the time of writing, I intend to also make stable/12 -fno-common
clean. What's been done will be MFC'd to stable/11 if it's easily applicable
and/or not much work to massage it into being functional, but I anticipate
adding -fcommon to stable/11 builds to maintain its ability to be built with
newer compilers for the rest of its lifetime instead of putting in a third
branch's worth of effort.