The resize test used bsdlabel(8), which is not available on all
architectures. Change it to use gpart(8) instead, which should be available
everywhere.
PR: 221763
Reported by: andrew
MFC after: 2 weeks
This change mostly reverts r293436, which introduced the bug due to a belief
that geli(8) would allocate md(4) devices by itself. However, that belief is
incorrect. Instead of using linear probing to find available md(4) numbers,
it's best to use the existing attach_md function.
Reviewed by: ngie
MFC after: 2 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D13666
Some of the ptrace tests need to wait for a child process to become a
zombie before preceding. The parent process polls the child process
via the kern.proc.pid sysctl to wait for it to become a zombie.
Previously the code polled until the sysctl failed with ESRCH. Now it
will poll until either the sysctl fails with ESRCH (for compatiblity
with older kernels) or returns a kinfo_proc structure with the ki_stat
field set to SZOMB.
Reported by: Jenkins
Tested by: markj
Discussed with: mjg
MFC after: 1 week
We can't kldunload in the test head as Kyua interprets any output from
them. This would lead to syntax errors and skipping the entire file.
Move the kld commands into the test case bodies.
Pointed out by: asomers@
Some IPSec in tunnel mode allowing to test multiple IPSec
configurations. These tests are reusing the jail/vnet scripts from pf
tests for generating complex network.
Submitted by: olivier@
Differential Revision: https://reviews.freebsd.org/D13017
Previously, symlinks in FreeBSD were artificially limited to PATH_MAX-2.
Add a short test case to verify the change.
Submitted by: Gaurav Gangalwar <ggangalwar AT isilon.com>
Reviewed by: kib
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12589
tests/sys/aio/aio_kqueue_test.c
Instead of using a hard-coded queue depth, use
vfs.aio.max_aio_queue_per_proc
tests/sys/aio/lio_kqueue_test.c
The old, small limit on lio_listio's operation count was lifted by
change 324941. Raise the operation count as high as possible without
exceeding the process's operation limit.
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
When multiple threads wish to report a tracing event to a debugger,
both threads call ptracestop() and one thread will win the race to be
the reporting thread (p->p_xthread). The debugger uses PT_LWPINFO
with the process ID to determine which thread / LWP is reporting an
event and the details of that event. This event is cleared as a side
effect of the subsequent ptrace event that resumed the process
(PT_CONTINUE, PT_STEP, etc.). However, ptrace() was clearing the
event identified by the LWP ID passed to the resume request even if
that wasn't the 'p_xthread'. This could result in clearing an event
that had not yet been observed by the debugger and leaving the
existing event for 'p_thread' pending so that it was reported a second
time.
Specifically, if the debugger stopped due to a software breakpoint in
one thread, but then switched to another thread that was used to
resume (e.g. if the user switched to a different thread and issued a
step), the resume request (PT_STEP) cleared a pending event (if any)
for the thread being stepped. However, the process immediately
stopped and the first thread reported it's breakpoint event a second
time. The debugger decremented the PC for "both" breakpoint events
which resulted in the PC now pointing into the middle of an
instruction (on x86) and a SIGILL fault when the process was resumed a
second time.
To fix, always clear the pending event for 'p_xthread' when resuming a
process. ptrace() still honors the requested LWP ID when enabling
single-stepping (PT_STEP) or setting a different PC (PT_CONTINUE).
Reported by: GDB testsuite (gdb.threads/continue-pending-status.exp)
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D12794
Test fragmentation handling (i.e. scrub fragment reassemble) code for
IPv6.
Two simple tests: Ping a host (jail) and test forwarding of fragmented
packets.
When cleaning up we must destroy the jails before we destroy the interfaces.
Otherwise we might try to destroy interfaces that belong to a jail, which won't
work and fail to completely clean up.
Pass/block packets in the forwarding path with pf.
Introduce the pft_set_rules() helper function, because we need to
remember to flush states between individual tests. If not we can get
packets passing despite rules blocking them because they match states
created in a previous test.
Extend pft_ping.py to be able to send IPv6 echo requests.
^/head@r323923 changed when MODIFIED is printed at exit. It's better to follow the
documented way of determining whether or not a filesystem is clean per fsck_ffs, i.e.,
ensure that the exit code is either 0 or 7.
The pass/fail determination is brittle prior to this commit, and ^/head@r323923 made
the issue apparent -- thus this needs to be fixed independent of ^/head@r323923.
PR: 222780
MFC after: 1 week
MFC with: r323923
Reported by: Jenkins
If VIMAGE is present we can start jails with their own pf instance. This
makes it fairly easy to run tests.
For example, this basic test verifies that drop/pass and icmp
classification works. It's a basic sanity test for pf, and hopefully an
example on how to write more pf tests.
The tests are skipped if VIMAGE is not enabled.
This work is inspired by the GSoC work of Panagiotes Mousikides.
Differential Revision: https://reviews.freebsd.org/D12580
Some x86 class CPUs have accelerated intrinsics for SHA1 and SHA256.
Provide this functionality on CPUs that support it.
This implements CRYPTO_SHA1, CRYPTO_SHA1_HMAC, and CRYPTO_SHA2_256_HMAC.
Correctness: The cryptotest.py suite in tests/sys/opencrypto has been
enhanced to verify SHA1 and SHA256 HMAC using standard NIST test vectors.
The test passes on this driver. Additionally, jhb's cryptocheck tool has
been used to compare various random inputs against OpenSSL. This test also
passes.
Rough performance averages on AMD Ryzen 1950X (4kB buffer):
aesni: SHA1: ~8300 Mb/s SHA256: ~8000 Mb/s
cryptosoft: ~1800 Mb/s SHA256: ~1800 Mb/s
So ~4.4-4.6x speedup depending on algorithm choice. This is consistent with
the results the Linux folks saw for 4kB buffers.
The driver borrows SHA update code from sys/crypto sha1 and sha256. The
intrinsic step function comes from Intel under a 3-clause BSDL.[0] The
intel_sha_extensions_sha<foo>_intrinsic.c files were renamed and lightly
modified (added const, resolved a warning or two; included the sha_sse
header to declare the functions).
[0]: https://software.intel.com/en-us/articles/intel-sha-extensions-implementations
Reviewed by: jhb
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12452
When crypto_newsession() is given a request for an unsupported capability,
raise a more specific error than EINVAL.
This allows cryptotest.py to skip some HMAC tests that a driver does not
support.
Reviewed by: jhb, rlibby
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12451
- Import print_function from __future__ and use print(..) instead of `print ..`.
- Use repr instead of backticks when the object needs to be dumped, unless
print(..) can do it lazily. Use str instead of backticks as appropriate
for simplification reasons.
This doesn't fully convert these modules over py3k. It just gets over some of
the trivial compatibility hurdles.
I accidentally introduced different whitespace style in r323878. I'm not
used to using tabs for indentation in Python scripts.
Whitespace only; no functional change.
Sponsored by: Dell EMC Isilon
Previously, this test was entirely a no-op as no vector in the NIST-KAT file
has a precisely 20-byte key.
Additionally, not every vector in the file is SHA1. The length field
determines the hash under test, and is now decoded correctly.
Finally, due to a limitation I didn't feel like fixing in cryptodev.py, MACs
are truncated to 16 bytes in this test.
With this change and the uncommitted D12437 (to allow key sizes other than
those used in IPSec), the SHA tests in cryptotest.py actually test something
and e.g. at least cryptosoft passes the test.
Sponsored by: Dell EMC Isilon
For some reason, we only skipped AES-XTS tests if a driver was not in the
aesmodules list. Skip other AES modes as well to prevent spurious failures
in non-AES drivers.
Sponsored by: Dell EMC Isilon
Non-tests/... changes:
- Add HAS_TESTS= to Makefiles with libraries and programs to enable iteration
and propagate the appropriate environment down to *.test.mk.
tests/... changes:
- Add appropriate support Makefile.inc's to set HAS_TESTS in a minimal manner,
since tests/... is a special subdirectory tree compared to the others.
MFC after: 2 months
MFC with: r322511
Reviewed by: arch (silence), testing (silence)
Differential Revision: D12014
Executable bits should be set at install time instead of in the repo.
Setting executable bits on files triggers false positives with Phabricator.
MFC after: 2 months
The layout of st_rdev has changed after this commit, and assumptions made
in the NetBSD tests are no longer valid. Change the hardcoded assumed
values to account for the fact that major/minor are now represented by
64 bits as opposed to the less precise legacy precision of 16 bits.
PR: 221048
Relnotes: st_rdev layout changed; warning about impact of r321920 to
downstream consumers
tests/... is a special snowflake directory and using HAS_TESTS would
result in a nasty layering violation between bsd.tests.mk and
bsd.prog.mk.
Add reachover Makefile.inc's which get the default value from
Makefile.inc0 (inspired by gnu/usr.bin/binutils/Makefile.inc0).
