Weirdly, I needed to sprinkle more parens here to get gcc-as in 6.4
to correctly generate things.
Without them, I'd get an unknown variable reference to SKEIN_ASM_UNROLL1024.
This at least links now, but I haven't run any test cases against it.
It may be worthwhile doing it in case gcc-as demands we liberally sprinkle
more brackets around variables in .if statements.
Thanks to ed for the suggestion of just sprinkling more brackets to
see if that helped.
Reviewed by: emaste
The new C test takes 25 seconds on QEMU-RISC-V, wheras the shell version
takes 332 seconds.
Even with the latest optimizations to atf-sh this test still takes a few
seconds to startup in QEMU. Re-writing it in C reduces the runtime for a
single test from about 2-3 seconds to less than .5 seconds. Since there
are ~80 tests, this adds up to about 3-4 minutes.
This may not seem like a big speedup, but before the recent optimizations
to avoid atf_get_srcdir, each test took almost 100 seconds on QEMU RISC-V
instead of 3. This also significantly reduces the time it takes to list
the available test cases, which speeds up running the tests via kyua:
```
root@qemu-riscv64-alex:~ # /usr/bin/time kyua test -k /usr/tests/sbin/pfctl/Kyuafile pfctl_test_old
...
158/158 passed (0 failed)
332.08 real 42.58 user 286.17 sys
root@qemu-riscv64-alex:~ # /usr/bin/time kyua test -k /usr/tests/sbin/pfctl/Kyuafile pfctl_test
158/158 passed (0 failed)
24.96 real 9.75 user 14.26 sys
root@qemu-riscv64-alex:/usr/tests/sbin/pfctl # /usr/bin/time ./pfctl_test pf1001
pfctl_test: WARNING: Running test cases outside of kyua(1) is unsupported
pfctl_test: WARNING: No isolation nor timeout control is being applied; you may get unexpected failures; see atf-test-case(4)
Running pfctl -o none -nvf /usr/tests/sbin/pfctl/./files/pf1001.in
---
binat on em0 inet6 from fc00::/64 to any -> fc00:0:0:1::/64
binat on em0 inet6 from any to fc00:0:0:1::/64 -> fc00::/64
---
passed
0.17 real 0.06 user 0.08 sys
root@qemu-riscv64-alex:/usr/tests/sbin/pfctl # /usr/bin/time ./pfctl_test_old pf1001
pfctl_test_old: WARNING: Running test cases outside of kyua(1) is unsupported
pfctl_test_old: WARNING: No isolation nor timeout control is being applied; you may get unexpected failures; see atf-test-case(4)
Id Refs Name
141 1 pf
Executing command [ pfctl -o none -nvf - ]
passed
1.73 real 0.25 user 1.41 sys
root@qemu-riscv64-alex:/usr/tests/sbin/pfctl # /usr/bin/time ./pfctl_test_old -l > /dev/null
24.36 real 2.26 user 21.86 sys
root@qemu-riscv64-alex:/usr/tests/sbin/pfctl # /usr/bin/time ./pfctl_test -l > /dev/null
0.04 real 0.02 user 0.01 sys
```
The speedups are even more noticeable on CHERI-RISC-V (since QEMU runs
slower when emulating CHERI instructions):
```
root@qemu-cheri-alex:/usr/tests/sbin/pfctl # /usr/bin/time ./pfctl_test_new -l > /dev/null
0.51 real 0.49 user 0.00 sys
root@qemu-cheri-alex:/usr/tests/sbin/pfctl # /usr/bin/time ./pfctl_test -l > /dev/null
34.20 real 32.69 user 0.16 sys
root@qemu-cheri-alex:/usr/tests/sbin/pfctl # /usr/bin/time ./pfctl_test pf1001
pfctl_test: WARNING: Running test cases outside of kyua(1) is unsupported
pfctl_test: WARNING: No isolation nor timeout control is being applied; you may get unexpected failures; see atf-test-case(4)
Id Refs Name
147 1 pf
Executing command [ pfctl -o none -nvf - ]
passed
5.74 real 5.41 user 0.03 sys
root@qemu-cheri-alex:/usr/tests/sbin/pfctl # /usr/bin/time ./pfctl_test_new pf1001
pfctl_test_new: WARNING: Running test cases outside of kyua(1) is unsupported
pfctl_test_new: WARNING: No isolation nor timeout control is being applied; you may get unexpected failures; see atf-test-case(4)
Running pfctl -o none -nvf /usr/tests/sbin/pfctl/./files/pf1001.in
---
binat on em0 inet6 from fc00::/64 to any -> fc00:0:0:1::/64
binat on em0 inet6 from any to fc00:0:0:1::/64 -> fc00::/64
---
passed
0.68 real 0.66 user 0.00 sys
root@qemu-cheri-alex:/usr/tests/sbin/pfctl #
```
Reviewed By: kp
Differential Revision: https://reviews.freebsd.org/D26779
This field was not in specs when the driver was written, but now there
are SSDs with the reported latency of 10s, where hardcoded value of 5s
seems to be not enough sometimes, causing shutdown timeout messages.
MFC after: 1 week
Sponsored by: iXsystems, Inc.
These already use the load variant that simulates userspace access.
Remove the macros that enable normal loads and stores from userspace
as they are unneeded.
Sponsored by: Innovate UK
For some reason I don't want to really understand, the following
happens with gnu as.
/home/adrian/git/freebsd/src/sys/crypto/skein/amd64/skein_block_asm.S: Assembler messages:
/home/adrian/git/freebsd/src/sys/crypto/skein/amd64/skein_block_asm.S:466: Error: found '(', expected: ')'
/home/adrian/git/freebsd/src/sys/crypto/skein/amd64/skein_block_asm.S:466: Error: junk at end of line, first unrecognized character is `('
/home/adrian/git/freebsd/src/sys/crypto/skein/amd64/skein_block_asm.S:795: Error: found '(', expected: ')'
/home/adrian/git/freebsd/src/sys/crypto/skein/amd64/skein_block_asm.S:795: Error: junk at end of line, first unrecognized character is `('
/home/adrian/git/freebsd/src/sys/crypto/skein/amd64/skein_block_asm.S:885: Error: non-constant expression in ".if" statement
/home/adrian/git/freebsd/src/sys/crypto/skein/amd64/skein_block_asm.S:885: Error: non-constant expression in ".if" statement
/home/adrian/git/freebsd/src/sys/crypto/skein/amd64/skein_block_asm.S:885: Error: non-constant expression in ".if" statement
/home/adrian/git/freebsd/src/sys/crypto/skein/amd64/skein_block_asm.S:885: Error: non-constant expression in ".if" statement
/home/adrian/git/freebsd/src/sys/crypto/skein/amd64/skein_block_asm.S:885: Error: non-constant expression in ".if" statement
/home/adrian/git/freebsd/src/sys/crypto/skein/amd64/skein_block_asm.S:885: Error: non-constant expression in ".if" statement
After an exhaustive search and experimentation at 11pm, I discovered that
putting them in parentheses fixes the compilation.
Ed pointed out that I could likely fix this in a bunch of other
locations but I'd rather leave these alone until other options
are enabled.
Tested:
* gcc-6, amd64
Reviewed by: emaste
In some environments is difficult to access bootp/dhcp
configuration as "standard user". Add a command that allows to set
or display the URI of the network server used as "net:" device.
Currently only tftp and nfs protocols are supported.
Typical usage pattern is:
netserver tftp://192.168.168.1/path_to_obj_dir/arm.armv7/sys/GENERIC/
boot net:kernel
Reviewed by: imp, kevans
MFC after: 4 weeks
Differential Revision: https://reviews.freebsd.org/D26736
Compiling it with LLVM 10 triggers https://bugs.llvm.org/show_bug.cgi?id=44351
While LLVM 11 is the default compiler, I regularly build with
CROSS_TOOLCHAIN=llvm10 or use system packages for clang on Linux/macOS and
those have not been updated to 11 yet.
According to git blame the trymmap() function was added in 1996 to skip
mmap() calls for NFS file systems. However, nowadays mmap() should be
perfectly safe even on NFS. Importantly, onl ufs and cd9660 file systems
were whitelisted so we don't use mmap() on ZFS. It also prevents the use
of mmap() when bootstrapping from macOS/Linux since on those systems the
trymmap() function was always returning zero due to the missing MFSNAMELEN
define.
This change keeps the trymmap() function but changes it to check whether
using mmap() can reduce the number of system calls that are required.
Using mmap() only reduces the number of system calls if we need multiple read()
syscalls, i.e. if the file size is > MAXBSIZE. However, mmap() is more expensive
than read() so this sets the threshold at 4 fewer syscalls. Additionally, for
larger file size mmap() can significantly increase the number of page faults,
so avoid it in that case.
It's unclear whether using mmap() is ever faster than a read with an appropriate
buffer size, but this change at least removes two unnecessary system calls
for every file that is installed.
Reviewed By: markj
Differential Revision: https://reviews.freebsd.org/D26041
It is lightweight way to check if an IPv4 address exists.
Submitted by: Roy Marples
Reviewed by: gnn, melifaro
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D26636
This with the previous patch I committed makes traceroute6/traceroute
compile fine when libcasper isn't enabled.
This complains strongly with unused variables and such when compiled
with gcc-6 on mips32.
Tested:
* compiled/run on mips32 hardware (AR9344)
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D26773
When compiling without casper these API calls result in unused variable warnings.
Using #defines was lovely in the past but unfortunately it triggers warnings
which can cascade into errors.
Instead, just inline with some fallthrough functions and keep things happy.
Tested:
* gcc-6 targeting mips32, with casper disabled
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D26762
Call M_SETFIB() to make sure the IPoIB packet is directed to the correct
interface-specific FIB.
This was sufficient to allow general-purpose routing using the default FIB,
and a separate FIB for routing between IPoIB on ib0 and IPoEthernet on mce0.
Reviewed by: hselasky
Obtained from: Anmol Kumar <anmolk at panasas dot com>
MFC after: 1 week
Sponsored by: Panasas
Differential Revision: https://reviews.freebsd.org/D25239
The 32-bit counter eventually wraps to 0 which is a sentinel for invalid
id.
Make it 64-bit on LP64 platforms and 0-check otherwise.
Note: Linux counterpart uses id stored per queue instead of a global.
I did not check going that way is feasible with the goal being the
minimal fix doing the job.
Reported by: YAMAMOTO Shigeru <shigeru@os-hackers.jp>
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D26759
[clang][Sema] Fix PR47676: Handle dependent AltiVec C-style cast
Fix premature decision in the presence of type-dependent expression
operands on whether AltiVec vector initializations from single
expressions are "splat" operations.
Verify that the instantiation is able to determine the correct cast
semantics for both the scalar type and the vector type case.
Note that, because the change only affects the single-expression case
(and the target type is an AltiVec-style vector type), the
replacement of a parenthesized list with a parenthesized expression
does not change the semantics of the program in a program-observable
manner.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D88526
This should fix 'Assertion failed: (isScalarType()), function
getScalarTypeKind, file /usr/src/contrib/llvm-project/clang/lib/AST
/Type.cpp, line 2146', when building the graphics/opencv-core port for
powerpc64le.
Requested by: pkubaj
MFC after: 4 weeks
X-MFC-With: r364284
When SIOCAIFADDR ioctl configures an IPv4 address that is already exist,
it removes old ifaddr. When this IPv4 address is only one configured on
the interface, this also leads to leaving from AllHosts multicast group.
Then an address is added again, but due to the bug, this doesn't lead
to joining to AllHosts multicast group.
Submitted by: yannis.planus_alstomgroup.com
Reviewed by: gnn
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D26757
NAT64LSN requires the presence of upper level protocol header
in a IPv4 datagram to find corresponding state to make translation.
Now it will be handled automatically by nat64lsn instance.
Reviewed by: melifaro
Obtained from: Yandex LLC
MFC after: 1 week
Sponsored by: Yandex LLC
Differential Revision: https://reviews.freebsd.org/D26758
On the target side TLB shootdown IPI handler, prevent the compiler
from performing a forward store optimization which may mask a
subsequent update to the scoreboard by the initiator.
Reported by: Max Laier, Anton Rang
Discussed with: kib
Sponsored by: Dell EMC Isilon
This is a simplistic approach which encrypts each TLS record in two
separate passes: one to generate the MAC and a second to encrypt.
This supports TLS 1.0 connections with implicit IVs as well as TLS
1.1+ with explicit IVs.
Reviewed by: gallatin
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D26730
Remove quotes around size in the LUN section and change the suffix to 'GB'. The
UCL format does recognize 'G' on its own, which uses a base 10 multiplier where
'GB' uses a 2 power multiplier.
Document the difference between valid suffixes when using ctl.conf(5) in the
general syntax form or in UCL format.
Reviewed by: kevans, mav
Approved by: kevans (mentor)
Differential Revision: https://reviews.freebsd.org/D26716
Due to a weakness in the TLS 1.0 protocol, OpenSSL will periodically
send empty TLS records ("empty fragments"). These TLS records have no
payload (and thus a page count of zero). m_uiotombuf_nomap() was
returning NULL instead of an empty mbuf, and a few places needed to be
updated to treat an empty TLS record as having a page count of "1" as
0 means "no work to do" (e.g. nothing to encrypt, or nothing to mark
ready via sbready()).
Reviewed by: gallatin
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D26729
arm64 has a similar wrapper. This permits defining <machine/fpu.h> as
the standard header for fpu_kern_*.
Reviewed by: kib
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D26753
Use designated initializers to document positions in the arrays rather
than requiring counting. Use nitems() rather than rolling it by hand to
count elements.
Also, passify a Clang 12 warning about suspcious string concatenation
within an array initializer by adding parentheses.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D26592
On startup the arm64 efi loaders need to know PC-relative addresses.
Previously we used the adr instruction to find this address, however this
instruction is limited to +/- 1MiB.
Switch to adrp to find the 4k page the address is within and an add to
set the bottom 12 bits. This lets us address +/- 4GiB which should be
large enough for now.
Reported by: imp
MFC after: 2 weeks
Sponsored by: Innovate UK
This also fixes a bug in the existing list_add_rcu() where the
prev->prev pointer was updated to the new element instead of
next->prev. Currently this function is not widely used.
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking
Even if a kif doesn't have an ifp or if_group pointer we still can't delete it
if it's referenced by a rule. In other words: we must check rulerefs as well.
While we're here also teach pfi_kif_unref() not to remove kifs with flags.
Reported-by: syzbot+b31d1d7e12c5d4d42f28@syzkaller.appspotmail.com
MFC after: 2 weeks
When trapping on a wrote access to a buffer the kernel has mapped as write
only we should only pass the VM_PROT_WRITE flag. Previously the call to
vm_fault_trap as the VM_PROT_READ flag was unexpected.
Reported by: manu
Sponsored by: Innovate UK
Until clang 11 that was equivalent to -O2, but clang changed it to -O1 so
generated MIPS code will now be unnecessarily slow. It also removes a weird
special case from sys.mk.
This is similar to the D26471 change for debug kernels and should not change
anything since everything was previously building MIPS code at -O2 until the
clang 11 update.
Reviewed By: trasz
Differential Revision: https://reviews.freebsd.org/D26749
To prevent issues with odd shell characters appearing in, a surprising
shell feature is used. Document it and a workaround for it.
Differential Revision: https://reviews.freebsd.org/D26723
The OpenZFS code that uses the BMI instructions is broken. Forcibly
disable them to prevent their use. When enabled, the build breaks.
This fixes the build when compiled for a core with BMI instructions.
This is the same fix committed in r364777, for the same issue.
Submitted by: Jung-uk Kim
Add support to the _STANDALONE environment enough bits of the kernel
that we can compile it. We still have a small zstd_shim.c since there
were 3 items that were a bit hard to nail down and may be cleaned up
in the future. These go hand in hand with a number of commits to
sys/sys in the past weeks, should this need be MFCd.
Discussed with: mmacy (in review and on IRC/Slack)
Reviewed by: freqlabs (on openzfs repo)
Differential Revision: https://reviews.freebsd.org/D26218
Both s_len and s_size are ssize_t, so their differece is also more
properly a ssize_t not a size_t. Also, assert that len is <= size when
we enter. This should always be the case. Ensure that we have that one
byte that we write to the end of the buffer before we do so, though
the error should already be set on the buffer if not, and the only
times we supply 'partial' buffers they should be plenty large.
Reviewed by: cem, jhb (prior version, I did cem's suggestion)
Differential Revsion: https://reviews.freebsd.org/D26752
