Document that force_depend() supports only /etc/rc.d scripts
Currently, force_depend() from rc.subr(8) does not support depending on
scripts outside of /etc/rc.d (like /usr/local/etc/rc.d). The /etc/rc.d path
is hard-coded into force_depend().
MFC r363383: dtrace/fbt: fix return probe arguments on arm
arg0 should be an offset of the return point within the function, arg1
should be the return value. Previously the return probe had arguments as
if for the entry probe.
Tested on armv7.
andrew noted that the same problem seems to be present on arm64, mips,
and riscv.
I am not sure if I will get around to fixing those. So, platform users
or anyone looking to make a contribution please be aware of this
opportunity.
MFC r362530: teach ena driver about RSS kernel option
Networking is broken if the driver configures its (virtual) hardware to
use a hash algorithm (or a key) different from the one that the network
stack (software RSS) uses. This can be seen with connections initiated
from the host. The PCB will be placed into the hash table based on the
hash value calculated by the software. The hardware-calculated hash
value in reponse packets will be different, so the PCB won't be found.
Tested with a kernel compiled with 'options RSS' on an instance with ena
driver.
MFC r362294,r362647: hdac_intr_handler: keep working until global interrupt status clears
It is plausible that the hardware interrupts a host only when GIS goes
from zero to one. GIS is formed by OR-ing multiple hardware statuses,
so it's possible that a previously cleared status gets set again while
another status has not been cleared yet. Thus, there will be no new
interrupt as GIS always stayed set. If we don't re-examine GIS then we
can leave it set and never get another interrupt again.
Without this change I frequently saw a problem where snd_hda would stop
working. Setting dev.hdac.1.polling=1 would bring it back to life and
afterwards I could set polling back to zero. Sometimes the problem
started right after a boot, sometimes it happened after resuming from
S3, frequently it would occur when sound output and input are active
concurrently (such as during conferencing). I looked at HDAC_INTSTS
while the sound was not working and I saw that both HDAC_INTSTS_GIS and
HDAC_INTSTS_CIS were set, but there were no interrupts.
Brooks Davis [Wed, 29 Jul 2020 20:30:15 +0000 (20:30 +0000)]
MFC r363435:
Avoid reading one byte before the path buffer.
This happens when there's only one component (e.g. "/foo"). This
(mostly-harmless) bug has been present since June 1990 when it was
commited to mountd.c SCCS version 5.9.
Note: the bug is on the second changed line, the first line is changed
for visual consistency.
Don Lewis [Wed, 29 Jul 2020 04:36:45 +0000 (04:36 +0000)]
Make lex a bootstrap tool when cross-building on recent 13-CURRENT if
binutils/ld is going to be built. The latter is no longer true by default.
The import of flex 2.6.4 into -CURRENT changed the type of yy_n_chars
in the lex skeleton from yy_size_t to int, which breaks the build of
binutils/ld when using the host copy of lex.
ldlex.c:3216:3: error: incompatible pointer types passing 'int *' to parameter
of type 'yy_size_t *' (aka 'unsigned long *')
[-Werror,-Wincompatible-pointer-types]
...YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is a direct commit to stable/12 since binutils/ld has been removed
from -CURRENT, and it would require a different fix there since the
bootstrap tool version of lex would also cause breakage. This is similar
to the stable/11 change in r363653, but in stable/12 we only need to
build lex as a bootstrap tool if binutils/ld is going to be built.
MFC r355132: Support kernels larger than EFI_STAGING_SIZE in loader.efi
With a very large kernel or module the staging area may be too small to
hold it. When this is the case try to allocate more space before failing
in the efi copyin/copyout/readin functions.
Brooks Davis [Mon, 27 Jul 2020 23:18:14 +0000 (23:18 +0000)]
MFC r363439:
Correct a type-mismatch between xdr_long and the variable "bad".
Way back in r28911 (August 1997, CVS rev 1.22) we imported a NetBSD
information leak fix via OpenBSD. Unfortunatly we failed to track the
followup commit that fixed the type of the error code. Apply the change
from int to long now.
Revert r363492, r363491, r363430, r363429 and r362650.
The introduction of epoch in the network stack is incomplete in stable/12, and
there are simply too many limitations to make the bridge epoch code work there.
The final problem is capability configuration of the bridge member interfaces.
if_bridge needs to enable promiscuous mode, which for certain drivers (e1000
for example) can sleep. In stable/12 we may not sleep within epoch.
If the interfaces on which wpa_supplicant is to run are not known or do
not exist, wpa_supplicant can match an interface when it arrives. Each
matched interface is separated with -M argument and the -i argument now
allows for pattern matching.
As an example, the following command would start wpa_supplicant for a
specific wired interface called lan0, any interface starting with wlan
and lastly any other interface. Each match has its own configuration
file, and for the wired interface a specific driver has also been given.
sshd: Warn about missing ssh-keygen only when necessary
The sshd service is using ssh-keygen to generate missing SSH keys.
If ssh-keygen is missing, it prints the following message:
> /etc/rc.d/sshd: WARNING: /usr/bin/ssh-keygen does not exist.
It makes sense when the key is not generated yet and
cannot be created because ssh-keygen is missing.
The problem is that even if the key is present on the host,
the sshd service would still warn about missing ssh-keygen
(even though it does not need it).
It turns out that currently mandoc(1) is not handling Fl in Ss
correctly (maybe it never was). Let's just replace "Fl S \&Ss ..."
with "-S ...". After all, this subsection title is stylized anyway, so Fl
is not that helpful.
r363277:
Only use the use_inet6 variable when INET6 is a build option.
This is a prerequisite to upcoming argument processing cleanups which
will resolve consistency as was done with ippool previously.
PR: 247952
r363278:
fr_family (the protocol family) must be AF_INET or AF_INET6, as in
the kernel, not an arbitrary 4 or 6.
This only affected printing ipfilter stats and rules from a kernel
dump. (This is currently undocumented.)
PR: 247952
r363279:
Historically ipfstat listings and stats only listed IPv4 or IPv6 output.
ipfstat would list IPv4 outputs by default while -6 would produce IPv6
outputs. This commit combines the ipfstat -i and -o outputs into one
listing of IPv4 and IPv6 rules. The -4 option lists only IPv4 rules
(as the default before) while -6 continues to list only rules that affect
IPv6.
PR: 247952
Reported by: joeb1@a1poweruser.com
r363280:
ipfstat -t defaults to IPv4 output. Make consistent with ipfstat -i
and ipfstat -o where without an argument IPv4 and IPv6 states are
shown. Use -4 and -6 to limit the display to IPv4 or IPv6 respectively.
PR: 247952
r363281:
Make ipfstat -t header generic when IPv4 and IPv6 output are
displayed in the same display.
PR: 247952
r363282:
The output from usage() need not contain usage for -t when STATETOP
is not compiled in.
r342577 Make sh(1) collapse $HOME into "~" in PS1
r342576 Simplify the way we set the default sh(1) PS1
r342645 Add current working directory to the default sh prompt
r342812 Give sh(1) a proper default prompt instead of just "$".
r342881 Make sh(1) recognize the default $HOME
r343231 Don't mess with BLOCKSIZE in shell startup files
r343399 Make sh(1) support \u in PS1
amd64: revamp memcmp
amd64: speed up failing case for memcmp
amd64: sync up libc memcmp with the kernel version (r357208)
amd64: sync up libc memcmp with the kernel version (r357309)
cache: push sdt probes in cache_zap_locked to code doing the work
cache: bump numcache on entry, while here fix lnumcache type
cache: fix a brainfart in r347505
cache: assorted cleanups
cache: change the formula for calculating lock array sizes
cache: avoid excessive relocking on entry removal during lookup
cache: jump in negative success instead of positive
cache: count evictions of negatve entries
cache: tidy up handling of negative entries
cache: stop recalculating upper limit each time a new entry is added
cache: make negative list shrinking a little bit concurrent
cache: stop requeuing negative entries on the hot list
cache: decrease ncnegfactor to 5
cache: minor stat cleanup
cache: fix numcache accounting on entry
cache: stop reusing .. entries on enter
cache: convert numcachehv to counter(9) on 64-bit platforms
cache: counter_u64_add_protected -> counter_u64_add
cache: make numcachehv use counter(9) on all archs
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
10.0.1 final (aka llvmorg-10.0.1-0-gef32c611aa2).
MFC r359582 (by emaste):
lldb: use lua as the default script language
In the FreeBSD base system we do not have Python support in lldb, but
will have Lua support. Make Lua the default.
This needs to be made into a configure-time option; that is being
discussed upstream and will appear in a future lldb import. For now
carry this change as a tiny patch to our copy of lldb.
MFC r359599 (by emaste):
lldb: add rule to generate LLDBWrapLua.cpp
Building lldb's lua/python bindings requires swig, but we do not want to
include it in the FreeBSD base system (as a build tool) because it has
non-trivial dependencies. As a workaround, add a make rule to generate
LLDBWrapLua.cpp, and we will commit the generated file.
Requires the swig30 package.
Reviewed by: brooks
Discussed with: dim
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24265
MFC r359600 (by emaste):
lldb: commit generated LLDBWrapLua.cpp
MFC r359606 (by emaste):
lldb: build and enable lua script bindings
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24266
MFC r360697:
In r358396 I merged llvm upstream commit 2e24219d3, which fixed "error:
unsupported relocation on symbol" when assembling arm 'adr' pseudo
instructions. However, the upstream commit did not take big-endian arm
into account.
Applying the same changes to the big-endian handling is straightforward,
thanks to Andrew Turner and Peter Smith for the hint. This will also be
submitted upstream.
MFC r360702:
Merge commit 4ca2cad94 from llvm git (by Justin Hibbits):
[PowerPC] Add clang -msvr4-struct-return for 32-bit ELF
Summary:
Change the default ABI to be compatible with GCC. For 32-bit ELF
targets other than Linux, Clang now returns small structs in
registers r3/r4. This affects FreeBSD, NetBSD, OpenBSD. There is no
change for 32-bit Linux, where Clang continues to return all structs
in memory.
Add clang options -maix-struct-return (to return structs in memory)
and -msvr4-struct-return (to return structs in registers) to be
compatible with gcc. These options are only for PPC32; reject them on
PPC64 and other targets. The options are like -fpcc-struct-return and
-freg-struct-return for X86_32, and use similar code.
To actually return a struct in registers, coerce it to an integer of
the same size. LLVM may optimize the code to remove unnecessary
accesses to memory, and will return i32 in r3 or i64 in r3:r4.
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.0-97-g6f71678ecd2 (not quite 10.0.1 rc2, as more fixes are
still pending).
MFC r362587 (by cem):
Add WITH_CLANG_FORMAT option
clang-format is enabled conditional on either WITH_CLANG_EXTRAS or
WITH_CLANG_FORMAT. Some sources in libclang are build conditional on
either rule, and obviously the clang-format binary itself depends on the
rule.
Also add a few more llvm utilities under WITH_CLANG_EXTRAS:
* llvm-dwp, a utility for merging DWARF 5 Split DWARF .dwo files into
.dwp (DWARF package files)
* llvm-size, a size(1) replacement
* llvm-strings, a strings(1) replacement
MFC r362733:
Remove older llvm-ranlib.1 entry from ObsoleteFiles.inc, as it has
gotten its own manpage now, and should be no longer be removed by "make
delete-old".
MFC r362734:
Fix llvm-strings.1 not installing, this was a copy/paste error.
MFC r363401:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
10.0.1 final (aka llvmorg-10.0.1-0-gef32c611aa2).
There were no changes since rc2, except in the upstream regression
tests, which we do not ship.
In r362650 we merged r360345. This required manual changes due to the
differences in EPOCH macros between head and stable/12, and was done
imperfectly.
Alan Somers [Fri, 24 Jul 2020 18:19:25 +0000 (18:19 +0000)]
MFC r363014:
geli: enable direct dispatch
geli does all of its crypto operations in a separate thread pool, so
g_eli_start, g_eli_read_done, and g_eli_write_done don't actually do very
much work. Enabling direct dispatch eliminates the g_up/g_down bottlenecks,
doubling IOPs on my system. This change does not affect the thread pool.
Alan Somers [Fri, 24 Jul 2020 17:45:06 +0000 (17:45 +0000)]
MFC r362891:
Fix page fault in zfsctl_snapdir_getattr
Must acquire the z_teardown_lock before accessing the zfsvfs_t object. I
can't reproduce this panic on demand, but this looks like the correct
solution.
MFC: Merge sendmail 8.16.1 to HEAD: See contrib/sendmail/RELEASE_NOTES for
details
Includes build infrastructure & config updates required for changes
in 8.16.1
MFC r363244: ether_ifattach: set mtu before calling if_attach()
if_attach() -> if_attach_internal() will call if_attachdomain1(ifp) any time
an ethernet interface is setup *after*
SI_SUB_PROTO_IFATTACHDOMAIN/SI_ORDER_FIRST. This eventually leads to
nd6_ifattach() -> nd6_setmtu0() stashing off ifp->if_mtu in ndi->maxmtu
*before* ifp->if_mtu has been properly set in some scenarios, e.g., USB
ethernet adapter plugged in later on.
For interfaces that are created in early boot, we don't have this issue as
domains aren't constructed enough for them to attach and thus it gets
deferred to domainifattach at SI_SUB_PROTO_IFATTACHDOMAIN/SI_ORDER_SECOND
*after* the mtu has been set earlier in ether_ifattach().
Brooks Davis [Wed, 22 Jul 2020 21:06:32 +0000 (21:06 +0000)]
MFC r363228:
Don't imply that all action values can be OR'd.
This is neither POSIX compliant nor what the implementation does.
This could be allowed by changing the value of TCSAFLUSH from 2 to 3,
but that doesn't seem worthwhile after 25+ years.
bridge: Enter epoch for bridge_input()/bridge_output()
In stable/12 epoch is not as wide as it is in head. The network stack isn't yet
in epoch when bridge_input()/bridge_output() get called, so rather than assert
this we must enter it ourselves.
While it doesn't trigger INVARIANTS or WITNESS on head it does in stable/12.
There's also no reason for it, as we can easily report the out of memory error
to the caller (i.e. userspace). All of these can already fail.
Tom Jones [Wed, 22 Jul 2020 10:00:13 +0000 (10:00 +0000)]
MFC r363141:
Don't print VNET pointer when initializing dummynet
When dummynet initializes it prints a debug message with the current VNET
pointer unnecessarily revealing kernel memory layout. This appears to be left
over from when the first pieces of vimage support were added.
Tom Jones [Wed, 22 Jul 2020 06:47:38 +0000 (06:47 +0000)]
MFC r350749, r362275
r350749:
Rename IPPROTO 33 from SEP to DCCP
IPPROTO 33 is DCCP in the IANA Registry:
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
IPPROTO_SEP was added about 20 years ago in r33804. The entries were added
straight from RFC1700, without regard to whether they were used.
The reference in RFC1700 for SEP is '[JC120] <mystery contact>', this is an
indication that the protocol number was probably in use in a private network.
As RFC1700 is no longer the authoritative list of internet numbers and that
IANA assinged 33 to DCCP in RFC4340, change the header to the actual
authoritative source.
r362275:
Add header definition for RFC4340, Datagram Congestion Control Protocol
Add a header definition for DCCP as defined in RFC4340. This header definition
is required to perform validation when receiving and forwarding DCCP packets.
We do not currently support DCCP.
Tom Jones [Wed, 22 Jul 2020 06:45:24 +0000 (06:45 +0000)]
MFC r362541:
pkg: Provide a friendlier message when bootstrap fails due to address resolution
The current message when bootstapping pkg fails for any reason implies that pkg
is not available. We have the error code from fetch so if bootstrap failed due
to address resolution say so.