Background:
If a user does pathconf(_, _PC_MIN_HOLE_SIZE) on a fusefs file system,
the kernel must actually issue a FUSE_LSEEK operation in order to
determine whether the server supports it. We cache that result, so we
only have to send FUSE_LSEEK the first time that _PC_MIN_HOLE_SIZE is
requested on any given mountpoint.
Problem 1:
Unlike fpathconf, pathconf operates on files that may not be open. But
FUSE_LSEEK requires the file to be open. As described in PR 278135,
FUSE_LSEEK cannot be sent for unopened files, causing _PC_MIN_HOLE_size
to wrongly report EINVAL. We never noticed that before because the
fusefs test suite only uses fpathconf, not pathconf. Fix this bug by
opening the file if necessary.
Problem 2:
On a completely sparse file, with no data blocks at all, FUSE_LSEEK with
SEEK_DATA would fail to ENXIO. That's correct behavior, but
fuse_vnop_pathconf wrongly interpreted that as "FUSE_LSEEK not
supported". Fix the interpretation.
PR: 278135
MFC after: 1 week
Sponsored by: Axcient
Differential Revision: https://reviews.freebsd.org/D44618
Ensure that we correctly transfer byte counts if the value exceeds what can be
stored in a single 32-bit counter.
Sponsored by: Rubicon Communications, LLC ("Netgate")
A number of tests create a bridge, but did not check if if_bridge.ko is loaded.
We usually get away with that, because `ifconfig bridge create` autoloads the
module, but if we run the tests in a jail (e.g. because of kyua's upcoming
execenv.jail.params feature) we can't load the module and these tests can fail.
Check if the module is loaded, skip the test if it is not.
Reviewed by: markj
MFC after: 1 week
Event: Kitchener-Waterloo Hackathon 202406
Differential Revision: https://reviews.freebsd.org/D45487
Give them more time to hit the expected loss numbers.
We see occasional failures during CI runs. This makes that less likely.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
If we fail to change the vlan id we have to undo the removal (and vlan id
change) in the error path. Otherwise we'll have removed the vlan object from the
hash table, and have the wrong vlan id as well. Subsequent modification attempts
will then try to remove an entry which doesn't exist, and panic.
Undo the vlan id modification if the insertion in the hash table fails, and
re-insert it under the original vlan id.
PR: 279195
Reviewed by: zlei
MFC atfer: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D45285
When the if_vlan(4) interface has not been fully configured, i.e., a
bare interface without a physical interface associated with it,
retrieving the current settings of it and unconditionally overwriting
`params` will result in losing vlandev settings in `params`. That will
lead to failing to associate the if_vlan(4) interface with the requested
physical interface and the false report 'both vlan and vlandev must be
specified'.
Fix that by checking if the vlan interface has been fully configured.
The basic VLAN test is slightly modified to cover this case.
PR: 279181
Reviewed by: kp
Tested by: Mike Tancsa <mike@sentex.net>
Fixes: b82b8055ad ifconfig: fix vlan/vlanproto reconfiguration
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D45283
The functions g_eli_init_uma and g_eli_fini_uma are used to trace
the number of devices in GELI. There is an issue where the g_eli_create
function may fail before g_eli_init_uma is called, however
g_eli_fini_uma is still executed in the fail path. This can
incorrectly decrease the device count to zero, potentially leading to
the UMA pool being freed. Accessing the device after the pool has been
freed causes a system panic.
This commit resolves the issue by ensuring devices count is increassed
eariler.
PR: 278828
Reported by: Andre Albsmeier <mail@fbsd2.e4m.org>
Reviewed by: asomers
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D45225
User misconfiguration may lead to routing loops where we try to send the tunnel
packet into the tunnel. This eventually leads to stack overflows and panics.
Avoid this using if_tunnel_check_nesting(), which will drop the packet if we're
looping or we hit three layers of nested tunnels.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Modern GCC complains when casting pointers to integers of a different
size (even a larger one). Switch from uint64_t to uintptr_t which will
always be the right size for a stack address instead of maybe being too
big.
Reviewed by: dchagin, emaste
Differential Revision: https://reviews.freebsd.org/D45087
I wasn't able to reproduce a crash in several runs. Might be that
48698ead6f or earlier changes have closed the races. In case crashes
with just enabled tests are registered, I will either work on them or
disable tests again.
Based on the old submission from asomers@. With modern state of locking
in lagg(4), the patch got much simplier. Enable the test that was
waiting for this change.
PR: 226144
Reviewed by: asomers
Differential Revision: https://reviews.freebsd.org/D44605
The tests try to read kern.maxphys sysctl into int value, while
unsigned long is required. Not sure when this was broken, seems like
since cd85379104.
Reviewed by: asomers
Differential Revision: https://reviews.freebsd.org/D45053
Although there are already multiple tests in the tests collection
that utilize sendfile(2) support over unix/stream socket, they all
don't exercise the asynchronous part of the operation. This test
framework, however, uses a trick to toggle true async operation and
guarantee that pr_ready method of unix/stream is also tested.
Reviewed by: chs
Differential Revision: https://reviews.freebsd.org/D45055
It creates a pair of connected TCP sockets for later testing. No
functional change.
Reviewed by: chs
Differential Revision: https://reviews.freebsd.org/D45054
The fact that an accept filter needs to be cleared first before setting to
a different one isn't properly documented. The requirement that the
socket needs already be listening, although trivial, isn't documented
either. At least return a more meaningful error than EINVAL for an
existing filter. Cover this with a test case.
Put this simple test into an existing file. We don't have a designated
file for all unix/stream tests. There is extensive unix_seqpacket_test,
but (at least right now) unix/seqpacket is not a superset of unix/stream,
but a different implementation. We have one file that does one test for
unix/stream - unix_socketpair_test. So rename it to unix_stream and start
collecting all unix/stream tests in it.
Verify that a capability violation is recorded when shm_open(2) is called
with a non-anonymous path.
Approved by: markj (mentor)
Reviewed by: markj
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44733
In both cases the kernel returns EPIPE and delivers SIGPIPE, unless
blocked or disabled. The test isn't specific to SOCK_SEQPACKET, it is the
same for SOCK_STREAM. Put the test into this file, since it has all
primitives to write this test tersely.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D44146
Allocate a big chunk of randomly initialized memory. Send it to the peer
in random sized chunks, throwing MSG_EOR at randomly initialized offsets.
Receive into random sized chunks setting MSG_WAITALL randomly. Check that
MSG_EORs where they should be, check that MSG_WAITALL is abode, but
overriden by MSG_EOR. And finally memcmp() what we receive.
Reviewed by: asomers, tuexen
Differential Revision: https://reviews.freebsd.org/D43775
Introduce regression tests for ktrace(2) that target capability
violations.
These test cases ensure that ktrace(2) records these violations:
- CAPFAIL_NOTCAPABLE
- CAPFAIL_INCREASE
- CAPFAIL_SYSCALL
- CAPFAIL_SIGNAL
- CAPFAIL_PROTO
- CAPFAIL_SOCKADDR
- CAPFAIL_NAMEI
- CAPFAIL_CPUSET
A portion of these test cases create processes that do NOT enter
capability mode, but raise violations. This is intended behavior.
Users may run `ktrace -t p` on non-Capsicumized programs to detect
violations that would occur if the process were in capability mode.
Reviewed by: markj
Approved by: markj (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D40682
Previously, we would error out if we encountered a global extended
header, because we don't know what it means. This doesn't really
matter though, and traditionally, tar implementations have either
ignored them or treated them as plain files, so just ignore them.
This allows tarfs to mount tar files created by `git archive`.
MFC after: 3 days
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D44600
If we redirect a packet to localhost and it gets dummynet'd it may be
re-injected later (e.g. when delayed) which means it will be passed
through ip_input() again. ip_input() will then reject the packet because
it's directed to the loopback address, but did not arrive on a loopback
interface.
Fix this by having pf set the rcvif to V_iflo if we redirect to
loopback.
See also: https://redmine.pfsense.org/issues/15363
Sponsored by: Rubicon Communications, LLC ("Netgate")
The ng_ksocket(4) functionality is very fragile as it interfaces with
kernel socket code in unusual way. It definitely needs a test suite.
Start one with a test that tests UDP over IPv4.
Start a file that would collect tests for I/O functionality of a UDP
socket, targeted on how a socket interacts with userland rather than with
wire side of the protocol.
First version tests that MSG_TRUNC and MSG_PEEK are working correctly.
Any netgraph operation requires root priveleges. Some tests in the
directory already mark themselves with 'atf_tc_set_md_var(conf,
"require.user", "root");' which creates a lot of pasted code. Some tests
don't mark self. For this particular directory a blanket metadata setting
in the Makefile is acceptable, imho.
There's a report of MTU issues over IPv6 DCO tunnels.
Extend the 4in6 test to send a series of pings with different sizes, as
well as transfer a large file.
No issues were found, but we may as well extend the test case.
PR: 276838
While here also add a basic test case for it.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D44368
