freebsd-src/tests
Kristof Provost c12013f5bb pf: fix udp_mapping cleanup
If we fail to obtain a new source port (pf_get_sport()) while we've
created a udp_mapping (for 'endpoint independent nat') we must free the
udp_mapping in pf_get_sport(). Otherwise the calling function will call
pf_udp_mapping_release(). This will then attempt to remove the udp_mapping from
a list it's not in, and crash.

Actually free the udp_mapping in all failure cases. While here sprinkle in a few
more assertions to ensure we don't forget leak udp_mappings and add a test case
to provoke this problem.

Reviewed by:	thj
MFC after:	1 week
See also:	https://redmine.pfsense.org/issues/16517
Sponsored by:	Rubicon Communications, LLC ("Netgate")
Differential Revision:	https://reviews.freebsd.org/D53737
2025-11-17 16:48:04 +01:00
..
atf_python tcp: Initial ktest for HPTS 2025-10-13 21:47:31 +02:00
ci release: Create /firstboot in common VM image creation code 2025-09-11 13:05:31 +00:00
etc Remove residual blank line at start of Makefile 2024-07-15 16:43:39 -06:00
examples Remove residual blank line at start of Makefile 2024-07-15 16:43:39 -06:00
freebsd_test_suite Remove $FreeBSD$: two-line .h pattern 2023-08-16 11:54:16 -06:00
include tests: Test endian.h, byteswap.h, sys/endian.h and both endian.h and byteswap.h together 2024-10-15 17:14:42 -06:00
oclo */*: remove recallocarray() compat shims following import into libc 2025-10-03 19:47:52 +02:00
sys pf: fix udp_mapping cleanup 2025-11-17 16:48:04 +01:00
__init__.py testing: Add basic atf support to pytest. 2022-06-25 19:25:15 +00:00
conftest.py Testing: add framework for the kernel unit tests. 2023-04-14 15:47:55 +00:00
Kyuafile Remove $FreeBSD$: one-line lua tag 2023-08-16 11:55:34 -06:00
Makefile tests: Adapt oclo tests to FreeBSD 2025-07-06 23:09:10 +00:00
Makefile.depend Remove $FreeBSD$: one-line sh pattern 2023-08-16 11:55:03 -06:00
Makefile.inc0 Remove residual blank line at start of Makefile 2024-07-15 16:43:39 -06:00
README Remove $FreeBSD$: one-line bare tag 2023-08-16 11:55:20 -06:00

src/tests: The FreeBSD test suite
=================================

Usage of the FreeBSD test suite:
(1)  Run the tests:
       kyua test -k /usr/tests/Kyuafile
(2)  See the test results:
       kyua report

For further information on using the test suite, read tests(7):
       man tests

Description of FreeBSD test suite
=================================
The build of the test suite is organized in the following manner:

* The build of all test artifacts is protected by the MK_TESTS knob.
  The user can disable these with the WITHOUT_TESTS setting in
  src.conf(5).

* The goal for /usr/tests/ (the installed test programs) is to follow
  the same hierarchy as /usr/src/ wherever possible, which in turn drives
  several of the design decisions described below.  This simplifies the
  discoverability of tests.  We want a mapping such as:

    /usr/src/bin/cp/      -> /usr/tests/bin/cp/
    /usr/src/lib/libc/    -> /usr/tests/lib/libc/
    /usr/src/usr.bin/cut/ -> /usr/tests/usr.bin/cut/
    ... and many more ...

* Test programs for specific utilities and libraries are located next
  to the source code of such programs.  For example, the tests for the
  src/lib/libcrypt/ library live in src/lib/libcrypt/tests/.  The tests/
  subdirectory is optional and should, in general, be avoided.

* The src/tests/ hierarchy (this directory) provides generic test
  infrastructure and glue code to join all test programs together into
  a single test suite definition.

* The src/tests/ hierarchy also includes cross-functional test programs:
  i.e. test programs that cover more than a single utility or library
  and thus don't fit anywhere else in the tree.  Consider this to follow
  the same rationale as src/share/man/: this directory contains generic
  manual pages while the manual pages that are specific to individual
  tools or libraries live next to the source code.

In order to keep the src/tests/ hierarchy decoupled from the actual test
programs being installed --which is a worthy goal because it simplifies
the addition of new test programs and simplifies the maintenance of the
tree-- the top-level Kyuafile does not know which subdirectories may
exist upfront.  Instead, such Kyuafile automatically detects, at
run-time, which */Kyuafile files exist and uses those directly.

Similarly, every directory in src/ that wants to install a Kyuafile to
just recurse into other subdirectories reuses this Kyuafile with
auto-discovery features.  As an example, take a look at src/lib/tests/
whose sole purpose is to install a Kyuafile into /usr/tests/lib/.
The goal in this specific case is for /usr/tests/lib/ to be generated
entirely from src/lib/.

--