many sockets in TIME_WAIT state at the end of the test.
PR: 249885
Reviewed by: markj
Approved by: markj
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D26549
If a FUSE server returns FOPEN_DIRECT_IO in response to FUSE_OPEN, that
instructs the kernel to bypass the page cache for that file. This feature
is also known by libfuse's name: "direct_io".
However, when accessing a file via mmap, there is no possible way to bypass
the cache completely. This change fixes a deadlock that would happen when
an mmap'd write tried to invalidate a portion of the cache, wrongly assuming
that a write couldn't possibly come from cache if direct_io were set.
Arguably, we could instead disable mmap for files with FOPEN_DIRECT_IO set.
But allowing it is less likely to cause user complaints, and is more in
keeping with the spirit of open(2), where O_DIRECT instructs the kernel to
"reduce", not "eliminate" cache effects.
PR: 247276
Reported by: trapexit@spawn.link
Reviewed by: cem
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D26485
memfd_create is implemented on top of posixshm, so this is a logically
correct place for them to be. Moreover, this reduces the number of places to
look to run tests when working in this part of the tree.
Discussed with: kib (to some extent, a while ago)
The current default is provided in various Makefile.inc in some top-level
directories and covers a good portion of the tree, but doesn't cover parts
of the build a little deeper (e.g. libcasper).
Provide a default in src.sys.mk and set WARNS to it in bsd.sys.mk if that
variable is defined. This lets us relatively cleanly provide a default WARNS
no matter where you're building in the src tree without breaking things
outside of the tree.
Crunchgen has been updated as a bootstrap tool to work on this change
because it needs r365605 at a minimum to succeed. The cleanup necessary to
successfully walk over this change on WITHOUT_CLEAN builds has been added.
There is a supplemental project to this to list all of the warnings that are
encountered when the environment has WARNS=6 NO_WERROR=yes:
https://warns.kevans.dev -- this project will hopefully eventually go away
in favor of CI doing a much better job than it.
Reviewed by: emaste, brooks, ngie (all earlier version)
Reviewed by: emaste, arichardson (depend-cleanup.sh change)
Differential Revision: https://reviews.freebsd.org/D26455
Use MACHINE_CPUARCH with arm64 (aarch64) when we build code that could run
on any 64-bit Arm instruction set. This will simplify checks in downstream
consumers targeting prototype instruction sets.
The only place we check for MACHINE_ARCH == aarch64 is when building the
device tree blobs. As these are targeting current generation ISAs.
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D26370
Main part is that kern_copyin on amd64 after LA57 should query the top
of UVA for correct operations. In fact it should started doing that
after the workaround for AMD bug with IRET in the last user page was
fixed by reducing UVA by a page.
Also since we started calculating top of UVA, fix MIPS according to
the comment.
Reported by: lwhsu
PR: 248933
Reviewed by: alc, markj
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D26312
Messing with gnop devices under a zpool fails in this test, causing
the pool to be suspended and eventually the system to deadlock.
Skip the test for now until the issue is resolved.
PR: tests/248910
Discussed with: lwhsu
Sponsored by: iXsystems, Inc.
The primary benefit is maintaining a completely shared
code base with the community allowing FreeBSD to receive
new features sooner and with less effort.
I would advise against doing 'zpool upgrade'
or creating indispensable pools using new
features until this change has had a month+
to soak.
Work on merging FreeBSD support in to what was
at the time "ZFS on Linux" began in August 2018.
I first publicly proposed transitioning FreeBSD
to (new) OpenZFS on December 18th, 2018. FreeBSD
support in OpenZFS was finally completed in December
2019. A CFT for downstreaming OpenZFS support in
to FreeBSD was first issued on July 8th. All issues
that were reported have been addressed or, for
a couple of less critical matters there are
pull requests in progress with OpenZFS. iXsystems
has tested and dogfooded extensively internally.
The TrueNAS 12 release is based on OpenZFS with
some additional features that have not yet made
it upstream.
Improvements include:
project quotas, encrypted datasets,
allocation classes, vectorized raidz,
vectorized checksums, various command line
improvements, zstd compression.
Thanks to those who have helped along the way:
Ryan Moeller, Allan Jude, Zack Welch, and many
others.
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D25872
RTF_HOST indicates whether route is a host route
(netmask is empty or /{32,128}).
Check that if netmask is empty and host route is not specified, kernel
returns an error.
Differential Revision: https://reviews.freebsd.org/D26155
Thanks to r364064, the name cache now returns a hit where previously it
would miss. Adjust the expectations accordingly.
PR: 248583
Reported by: lwhsu
MFC with: r364064
This fixes possible link errors, similar to:
ld: error: undefined symbol: iface_setup_addr
>>> referenced by test_rtsock_l3.c:111 (tests/sys/net/routing/test_rtsock_l3.c:111)
>>> test_rtsock_l3.o:(presetup_ipv4)
>>> referenced by test_rtsock_l3.c:79 (tests/sys/net/routing/test_rtsock_l3.c:79)
>>> test_rtsock_l3.o:(presetup_ipv6)
>>> referenced by test_rtsock_l3.c:512 (tests/sys/net/routing/test_rtsock_l3.c:512)
>>> test_rtsock_l3.o:(atfu_rtm_change_v4_gw_success_body)
>>> referenced 10 more times
In C (not C++), 'naked' inline is almost always a mistake. Either use
static inline (this is appropriate for most cases), or extern inline.
MFC after: 3 days
This avoids injecting errors into the test system's mirrors.
gnop seems like a good solution here but it injects errors at the wrong
place vs where these tests expect and does not support a 'max global count'
like the failpoints do with 'n*' syntax.
Reviewed by: cem, vangyzen
Sponsored by: Dell EMC Isilon
Prior to this change a `SF_IMMUTABLE` chflagsat(2)'ed file (`path`) was left
behind, which sabotaged kyua(1) from being able to clean up the work directory,
This resulted in unnecessary work for folks having to clean up the work
directory on non-disposable systems, which defaults to `/tmp`. Use `UF_OFFLINE`
instead of `SF_IMMUTABLE`, in part because setting `SF_IMMUTABLE` isn't relevant
to the test and `SF_IMMUTABLE` cannot be cleared at all securelevels, as pointed
out by @asomers.
Additional work is required to catch cases like this upfront in the future to
avoid tester headache. See PR # 247765 for more details/followup.
Suggested by: asomers
Reviewed By: asomers, #tests
MFC after: 1 week
PR: 247761
Sponsored by: DellEMC
Differential Revision: https://reviews.freebsd.org/D25561
memfd_create fds will no longer require an ftruncate(2) to set the size;
they'll grow (to the extent that it's possible) upon write(2)-like syscalls.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D25502
geli does all of its crypto operations in a separate thread pool, so
g_eli_start, g_eli_read_done, and g_eli_write_done don't actually do very
much work. Enabling direct dispatch eliminates the g_up/g_down bottlenecks,
doubling IOPs on my system. This change does not affect the thread pool.
Reviewed by: markj
MFC after: 2 weeks
Sponsored by: Axcient
Differential Revision: https://reviews.freebsd.org/D25587
This test should no longer provoke large amounts of traffic, which can
overwhelm single-core systems, preventing them from making progress in the
tests.
The test can now be re-enabled.
PR: 246448
Enable STP before bringing the bridges up. This avoids a switching loop,
which has a tendency to drown out progress in userspace processes,
especially on single-core systems.
Only check that we have indeed shut down one of the looped interfaces
PR: 246448
Reviewed by: melifaro
Differential Revision: https://reviews.freebsd.org/D25084
Fix the netinet/netinet6 divert tests falsely reporting 'ipdivert module is
not loaded' when the divert module is built into the kernel
Sponsored by: Axiado
Differential Revision: https://reviews.freebsd.org/D25026
This patch fixes two issues relating to FUSE_ACCESS when the
default_permissions mount option is disabled:
* VOP_ACCESS() calls with VADMIN set should never be sent to a fuse server
in the form of FUSE_ACCESS operations. The FUSE protocol has no equivalent
of VADMIN, so we must evaluate such things kernel-side, regardless of the
default_permissions setting.
* The FUSE protocol only requires FUSE_ACCESS to be sent for two purposes:
for the access(2) syscall and to check directory permissions for
searchability during lookup. FreeBSD sends it much more frequently, due to
differences between our VFS and Linux's, for which FUSE was designed. But
this patch does eliminate several cases not required by the FUSE protocol:
* for any FUSE_*XATTR operation
* when creating a new file
* when deleting a file
* when setting timestamps, such as by utimensat(2).
* Additionally, when default_permissions is disabled, this patch removes one
FUSE_GETATTR operation when deleting a file.
PR: 245689
Reported by: MooseFS FreeBSD Team <freebsd@moosefs.pro>
Reviewed by: cem
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D24777
When a FUSE operation other than LOOKUP returns ENOENT, the kernel will
reclaim that vnode, resuling in a FUSE_FORGET being sent a short while
later. Many of the ENOENT tests weren't expecting those FUSE_FORGET
operations. They usually passed by luck since FUSE_FORGET is often delayed.
This commit adds appropriate expectations.
MFC after: 2 weeks
common_init_tbl is only used within this single CU, so it should be marked
static.
WARNS=6 also complained about the var defined by
`ATF_TC_WITH_CLEANUP(getastats);` being unused, which turns out to be
because it's not been hooked up in ATF_TP_ADD_TCS. kp@ did not immediately
recall any reason for this, and the case passes on my local system, so hook
it up.
Note that I've not yet set WARNS= 6 here. Investigation is underway to see
if we can feasibly default WARNS to 6 for src builds to catch directories
too deep to inherit a WARNS from the top-level subdirectories' Makefile.inc.
Those particular WARNS settings will be subsequently removed as they become
redundant with a more-global default.
MFC after: 1 week
