The staleness reported in an error cause is in us, not ms.
Enforce limits on the life time via sysct; and socket options
consistently. Update the description of the sysctl variable to
use the right unit. Also do some minor cleanups.
This also fixes an interger overflow issue if the peer can
modify the cookie. This was reported by Felix Weinrank by fuzz testing
the userland stack and in
https://oss-fuzz.com/testcase-detail/4800394024452096
MFC after: 3 days
Hiding this feature behind RB_VERBOSE is gratuitous. The tunable is enough
to limit its use to only those who explicitly request it.
Suggested by: kevans
We convert a string like "W32:vendor/device" into "I:vendor;I:device",
where the output is longer than the input, but only allocate space equal
to the length of the input, leading to a buffer overflow.
Instead use open_memstream so we get a safe dynamically-grown buffer.
Found by: CHERI
Reviewed by: imp, jhb (mentor)
Approved by: imp, jhb (mentor)
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D26637
This simplifies the code while allowing for concurrent negative eviction
down the road.
Cache misses increased slightly due to higher rate of evictions allowed by
the change.
The current algorithm remains too aggressive.
It is reported to fix kernel panics when early unsolicited responses
delivered to the CODEC device not having driver attached yet.
PR: 250248
Reported by: Rajeev Pillai <rajeev_v_pillai@yahoo.com>
Reviewed by: avg
MFC after: 2 weeks
At some poing over the last week, the bootx64.efi file has grown
past the 800KB threshold, resulting in being unable to copy it to
the EFI/BOOT directory.
# stat -f %z efiboot.znWo7m
819200
# stat -f %z stand-test.PIEugN/EFI/BOOT/bootx64.efi
842752
The comment in the script that creates the ISOs suggests that 800KB
is the maximum allowed for the boot code, however I was able to
boot an ISO with a 1024KB boot partition. Additionally, I verified
against an ISO from OtherOS, where the boot EFI partition is 2.4MB.
Sponsored by: Rubicon Communications, LLC (netgate.com)
Only assign the address from the iovec to bio_data if it is a kernel
address. This was the single place where bio_data stored (however
briefly) a userspace pointer.
Reviewed by: imp, markj
Obtained from: CheriBSD
MFC after: 1 week
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D26783
Our gcc-6.4 flags require non-empty function declarations.
Fix this to match the rest of the codebase.
Tested:
* compiled on gcc-6.4 for amd64
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D26795
This fixes a "suggested parens" compile warning-into-error
that shows up on gcc-6.4.
Reviewed by: ngie
Differential Revision: https://reviews.freebsd.org/D26789
VMware now has arm64 support; move these to MI files in advance of
building them on arm64.
PR: 250308
Reported by: Vincent Milum Jr
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
motherboard temperatures. In particular, the U4 northbridge die is very
hard to cool or heat effectively with fans and is not responsive to load.
It generally sits around 64C, where it seems happy, so (like Linux) just
declare that to be its target temperature.
This makes the PowerMac G5 much less loud, with no change in the
temperatures of any system components.
MFC after: 2 weeks
Offensive) the Linux Steam client likes to occasionally scan the game
process memory, presumably as part anti-cheat measures. Turns out
the client also expects each inode entry to be followed by a space
character, otherwise the parsing code crashes.
PR: 248216
Submitted by: Alex S <iwtcex@gmail.com>
MFC after: 2 weeks
The try lock loop in HN_LOCK put the thread spinning on cpu if the lock
is not available. It is possible to cause deadlock if the thread holding
the lock is sleeping. Relinquish the cpu to work around this problem even
it doesn't completely solve the issue. The priority inversion could cause
the livelock no matter how less likely it could happen. A more complete
solution may be needed in the future.
Reported by: Microsoft, Netapp
MFC after: 2 weeks
Sponsored by: Microsoft
It is possible that the vmbus pcib channel is revoked during attach path.
The attach path could be waiting for response from host and this response will never
arrive since the channel has already been revoked from host point of view. Check
this situation during wait complete and return failed if this happens.
Reported by: Netapp
MFC after: 2 weeks
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D26486
Some vnodes come with a hack which inherits the fplookup flag despite having vops
which don't provide the routine.
Reported by: YAMAMOTO Shigeru <shigeru@os-hackers.jp>
Ampere Altra in a dual socket configuration has 12 ITSes for the
12 PCIe root complexes. The NIRQ interrupts are statically split
between each child of the gic bus, so here we increase that
value. 16k is enough for
(#cpus * #its * max_pcie_bifurcation) LPIs + (#SPIs and #PPIs)
Reviewed by: jhb
Approved by: scottl (implicit)
MFC after: 1 week
Sponsored by: Ampere Computing
Differential Revision: https://reviews.freebsd.org/D26766
RIght now PCB_KERNFPU is used both as indication that kernel prepared
hardware FPU context to use and that the thread is fpu-kern
thread. This also breaks fpu_kern_enter(FPU_KERN_NOCTX), since
fpu_kern_leave() then clears PCB_KERNFPU.
Introduce new flag PCB_KERNFPU_THR which indicates that the thread is
fpu-kern. Do not clear PCB_KERNFPU if fpu-kern thread leaves noctx
fpu region.
Reported and tested by: jhb (amd64)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D25511
From Linux sources and several datasheets I looked at, it seems that
the workaround is only needed on families 0xf and 0x10. For instance,
Ryzens do not implement the accessed MSR at all, it is documented as
reserved. Also, hypervisors should not allow guest to put CPU into
idle state, so activate workaround only when on bare hardware.
While there, style the code:
move MSR defines to specialreg.h
move identification to initcpu.c
Reported by: whu
Reviewed by: avg
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D26470
Move dump_avail[] extern declaration and inlines into a new header
vm/vm_dumpset.h. This fixes default gcc build for mips.
Reviewed by: alc, scottph
Tested by: kevans (previous version)
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D26741
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
