This target is far too noisy to be at all useful. Save the output ala
make universe in _. files. Also report where to find errors.
Sponsored by: Netflix
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.
The goal of this project is to integrate the relevant scripts from the
FreeBSD-CI project (https://github.com/freebsd/freebsd-ci) into the src
repository. This allows developers to run the test suite similar to how
it is executed on ci.freebsd.org, and eventually, have it directly used
by our CI system. This effort is also part of the workflow improvement
project, aiming to incorporate pre-merge testing.
Current Features:
* Does smoke tests using either bhyve(amd64 only) or qemu(Non x86_64 or
when defined USE_QEMU=1). Currently defined CITYPE=smoke. Once we have
added full tests we can also utilize something like CITYPE=full
* Most of the resources are dynamically allocated based on available
resources in the host
* If CPU supports POPCNT or vmm can be loaded then bhyve is used for
amd64 otherwise automatically installs and uses qemu@nox11
* When required third party applications or packages for booting non-x86
images are automatically installed
Current Limitation:
* Does not support full tests like the one in our Jenkins
* At this moment this is also not suitable to be used in our Jenkins
platform as the jobs are divided in multiple smaller tasks and
artifacts are moved here and there which are not exactly the scenario
for individual developers.
Future Works:
* Add full tests like the one in ci.freebsd.org
* Add different tests or options to disable some tests
* Add test profiles full
* Possibly add test through Cloud Providers like AWS/GCP/Azure or Cirrus
or Github Actions
* Update documentation
Test Plan:
cd /usr/src/tests/ci
make ci
make TARGET=amd64 TARGET_ARCH=amd64 ci
make TARGET=amd64 TARGET_ARCH=amd64 USE_QEMU=1 ci
make TARGET=arm64 TARGET_ARCH=aarch64 ci
make TARGET=powerpc TARGET_ARCH=powerpc64 ci
make TARGET=powerpc TARGET_ARCH=powerpc64le ci
make TARGET=riscv TARGET_ARCH=riscv64 ci
Reviewed by: lwhsu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43786
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
Ensure that we pick the correct dummynet pipe (i.e. forward vs. reverse
direction) when applying route-to.
We mark the processing as outbound so that dummynet will re-inject in
the correct phase of processing after it's done with the packet, but
that will cause us to pick the wrong pipe number. Reverse them so that
the incorrect decision ends up picking the correct pipe.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D44366
In some setups we end up with multiple states created for a single
packet, which in turn can mean we run the packet through dummynet
multiple times. That's not expected or intended. Mark each packet when
it goes through dummynet, and do not pass packet through dummynet if
they're marked as having already passed through.
See also: https://redmine.pfsense.org/issues/14854
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D44365
All callers do it right. Don't be overprotective against a stupid
caller and thus don't look like a code that leaks a resource.
Reported by: Coverity Scan
CID: 1539210
The checksum code assumed that struct ustar_header filled an entire
block and calculcated the checksum based on the size of the structure.
The header is in fact only 500 bytes long while the checksum covers
the entire block (“logical record” in POSIX terms). Add padding and
an assertion, and clean up the checksum code.
MFC after: 3 days
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44226
* Reject hard or soft links with an empty target path. Currently, a
debugging kernel will hit an assertion in tarfs_lookup_path() while
a non-debugging kernel will happily create a link to the mount root.
* Use a temporary variable to store the result of the link target path,
and copy it to tnp->other only once we have found it to be valid.
Otherwise we error out after creating a reference to the target but
before incrementing the target's reference count, which results in a
use-after-free situation in the cleanup code.
* Correctly return ENOENT from tarfs_lookup_path() if the requested
path was not found and create_dirs is false. Luckily, existing
callers did not rely solely on the return value.
MFC after: 3 days
PR: 277360
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: sjg
Differential Revision: https://reviews.freebsd.org/D44161
On reply-to we don't know what interface to bind to when we create
the state. Create any reply-to state as floating, but bind to the
appropriate interface once we're handling the reply.
See also: https://redmine.pfsense.org/issues/15220
Sponsored by: Rubicon Communications, LLC ("Netgate")
Applies both to SOCK_STREAM and SOCK_SEQPACKET. Put the test in this file
as it is most advanced one.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D43854
This is undocumented feature of PF_UNIX/SOCK_STREAM and thus of
PF_UNIX/SOCK_SEQPACKET, too. Put the test into this file, since this file
is most advanced and has all primitives to write this test in minimum
number of lines.
Differential Revision: https://reviews.freebsd.org/D43853
Use the function in mk_pair_of_sockets(), and in four existing tests -
'listen_bound', 'connect', 'shutdown_send' and 'shutdown_send_sigpipe'.
While here make mk_pair_of_sockets() return pointer to sockaddr_un instead
of path. This also fixes bug of returning pointer to stack memory of
returning function. However, the only caller that cares about this return
is temporarily ifdefed out. No functional change intended.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D43852
These tests were not testing conformance to the specification, rather than
the limitation of our implementation. The specification doesn't say that
a SOCK_SEQPACKET shall ever return EMSGSIZE. It says:
The SOCK_SEQPACKET socket type is similar to the SOCK_STREAM type,
and is also connection-oriented. The only difference between these
types is that record boundaries are maintained using the
SOCK_SEQPACKET type. A record can be sent using one or more output
operations and received using one or more input operations, but a
single operation never transfers parts of more than one record.
Record boundaries are visible to the receiver via the MSG_EOR flag
in the received message flags returned by the recvmsg() function. It
is protocol-specific whether a maximum record size is imposed.
The EMSGSIZE is specified as 'message is too large to be sent all at once,
as the socket requires'. Indeed existing implementation that has
unix/seqpacket marked as PR_ATOMIC has such a limitation. But future
implementation won't have, thus remove the tests.
Reviewed by: tuexen, asomers
Differential Revision: https://reviews.freebsd.org/D43756
The PF_UNIX/SOCK_SEQPACKET was marked as PR_ATOMIC and that made
soreceive_generic() to treat it pretty much as a datagram socket.
However, POSIX says:
The SOCK_SEQPACKET socket type is similar to the SOCK_STREAM type,
and is also connection-oriented. The only difference between these
types is that record boundaries are maintained using the
SOCK_SEQPACKET type. A record can be sent using one or more output
operations and received using one or more input operations, but a
single operation never transfers parts of more than one record.
Record boundaries are visible to the receiver via the MSG_EOR flag
in the received message flags returned by the recvmsg() function. It
is protocol-specific whether a maximum record size is imposed.
What the test was doing is checking if MSG_TRUNC would report the space
required to return up the end of next mbuf record in the socket buffer.
Apparently the test assumed that this boundary is defined by the write(2)
size on the peer socket. This was true in test conditions, but I'm not
sure it would always be true - sbcompress() may merge mbufs. Anyway, the
mbuf boundaries are internal socket buffer implementation, they are not
SOCK_SEQPACKET records. The records need to be explicitly marked with
MSG_EOR by sender, and the test definitely wasn't doing that.
Reviewed by: tuexen, markj
Differential Revision: https://reviews.freebsd.org/D43707