fork.2: note that all methods to pre-resolve symbols have consequences
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D56362
tools/build/Makefile: Always add md4.h to SYSINCS
Since libmd was added to the bootstrap, building main on stable/14
fails because of an incompatibility in its old md4.h. Fix this by
always including md4.h in the bootstrap headers, instead of only
doing so when building on a non-FreeBSD host.
Fixes: 50de0bf50512 ("flua: Always build as a bootstrap tool")
Reported by: olce
Reviewed by: olce, kevans
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D56327
(cherry picked from commit 0dd9c4abf0e56b9d4f6f7204a68b1475f2bbf1fc)
flua: Always build as a bootstrap tool
We want to use flua from the source tree (not the host) during package
build, firstly to protect us from breaking changes in lua or libucl,
and secondly to allow (in future) cross-building of packages from
Linux or macOS.
Since we don't know if the user will be building packages during the
bootstrap phase, and because flua is fairly small and generally useful,
build it as a bootstrap tool unconditionally.
MFC after: 2 weeks
Reviewed by: kevans, emaste
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D56270
(cherry picked from commit 50de0bf50512aa98d18f21ac1347941396596944)
lockf.1: Organize and provide error numbers
Add error numbers to the exit codes so that readers can decode them
without having to use a separate utility. Organize exits by error code.
Mark up the error constants with the error constant macro, even though
this is really not very helpful because people will search for the error
code, the macro is explicitly for the constants and not the codes.
While where, align and alphabetize the options list as well, fix
misaligned padding in an example, and a one-sentance-per-line error.
MFC after: 3 days
Reported by: Antranig Vartanian <antranigv at freebsd.am>
Differential Revision: https://reviews.freebsd.org/D48470
(cherry picked from commit dd201e407e48ba59bdfa1f71d41acfdac1a9c562)
raw ip: move hash table manipulation to inpcb layer
The SOCK_RAW socket is a multiple receiver socket by its definition. An
incoming packet may be copied to multiple sockets. Thus, incoming packet
handling is expensive. Systems with many thousands of raw sockets usually
have them connect(2)-ed to different destinations. This allows for some
improvement of the input handling, which was introduced by 9ed324c9a588
back in 2008. This optimization was made specifically for L2TP/PPTP VPN
concentrators based on ports/net/mpd5.
This change generalizes the idea of 9ed324c9a588, so that it potentially
can be used with IPv6 raw sockets. This also eliminates last use of the
pcbinfo hash lock outside of in_pcb.c.
While here make a speculative design decision: put into the hash table
sockets that did only connect(2). Previously, we were indexing only
sockets that were protocol bound, did bind(2) and did connect(2). My
speculation is that only the remote IP provides some real entropy into the
hash and local address and proto are expected to be the same for majority
[4 lines not shown]
inpcb: move local address assignment out of in_pcbdisconnect()
The logic of clearing local address at the protocol level makes sense. It
is feature of UDP, not of any protocol, that local address is cleared on
disconnect. This code can be tracked down to pre-FreeBSD times.
For example, for TCP we want a disconnected socket to return previously
used local address with getsockname(2). The TCP has successfully evaded
that by not calling in_pcbdisconnect() and calling in_pcbdetach() in the
very old code and in_pcbdrop() later. After D55661 TCP again has this
potential bug masked. Better make it right than rely on such
unintentional evasions.
The raw IP sockets don't use in_pcbdisconnect(), but they are going to in
the near future. If in_pcbdisconnect() clears local address for them,
that would be a larger bug than just getsockname(). A raw socket may be
bound with bind(2) and then connect(2)ed, and then disconnected, e.g.
connect(INADDR_ANY). And when we run raw IP socket through
in_pcbdisconnect() we don't want to lose local address.
[6 lines not shown]
inpcb: retire INP_DROPPED and in_pcbdrop()
The inpcb flag INP_DROPPED served two purposes.
It was used by TCP and subsystems running on top of TCP as a flag that
marks a connection that is now in TCPS_CLOSED, but was in some other state
before (not a new-born connection). Create a new TCP flag TF_DISCONNECTED
for this purpose.
The in_pcbdrop() was a TCP's version of in_pcbdisconnect() that also sets
INP_DROPPED. Use in_pcbdisconnect() instead.
Second purpose of INP_DROPPED was a negative lookup mask in
inp_smr_lock(), as SMR-protected lookup may see inpcbs that had been
removed from the hash. We already have had INP_INHASHLIST that marks
inpcb that is in hash. Convert it into INP_UNCONNECTED with the opposite
meaning. This allows to combine it with INP_FREED for the negative lookup
mask.
[7 lines not shown]
netinet6: remove INP_DROPPED checks from setsockopt(2)
The INP_DROPPED is going to become an internal flag for inpcb. As of now
it means a TCP pcb that is in TCPS_CLOSED. There is nothing wrong with
calling setsockopt(2) on such socket, although has no practical use.
This deletes a piece of code from 56713d16a06c5 / D16201. There is no
description of the panic fixed, but I will speculate that the panic was
about in6p->in6p_outputopts being NULL as the inpcb already went through
in_pcbfree_deferred(). This also can be related to compressed TIME-WAIT,
that is also gone now.
With current locking this shouldn't be possible. An inpcb goes through
in_pcbfree() only with pr_detach method, which is called from sofree(),
and the latter is called on losing the very last socket reference. So, at
the point when in_pcbfree() is called, the socket has lost its file
descriptor reference and there can not be any running setsockopt() on it.
Leave the call to ip6_pcbopt() still embraced with INP_WLOCK(), since we
[9 lines not shown]
inpcb: make in_pcbdisconnect() acquire the hash lock internally
Should be no functional change.
Reviewed by: pouria, markj
Differential Revision: https://reviews.freebsd.org/D55968
inpcb: retire the inpcb global list
The iteration over all pcbs is possible without the global list. The
newborn inpcbs are put on a global list of unconnected inpcbs, then after
connect(2) or bind(2) they move to respective hash slot list.
This adds a bit of complexity to inp_next(), but the storage scheme is
actually simplified.
One potential problem before this change was that a couple of pcbs fall
into the same hash slot and are linked A->B there, but they also sit next
to each other in the global list, linked as B->A. This can deadlock of
course. The problem was never observed in the wild, but I was able to
instrument it with lots of effort: just few pcbs in the system, hash size
reduced down to 2 and a lot of repetitive calls into two kinds of
iterators.
However the main motivation is not the above problem, but make a step
towards splitting the big hash lock into per-slot locks.
[2 lines not shown]
inpcb: retire the inpcbinfo list lock
With the SMR locking of inpcbs the use of this lock reduced down to the
global list and generation number. It was used only on an inpcb creation
and destruction. Use the inpcbinfo hash lock for this purpose.
Reviewed by: pouria, rrs, markj
Differential Revision: https://reviews.freebsd.org/D55966
inpcb: apply smr_advance(9)/smr_wait(9) trick only to reusable sockets
The protocols marked with PR_CONNREQUIRED can never go through pr_connect
after being disconnected. This is a tiny improvement of fdb987bebddf0.
While here push clearing of the addresses under the same condition.
Although this clearing originates from pre-FreeBSD times, it actually
makes sense only for protocols that can reconnect.
Reviewed by: pouria, markj
Differential Revision: https://reviews.freebsd.org/D55661
wsp(4): Make evdev interface operational if sysmouse one is not opened
Before this change evdev interface sent only copy of data sent through
the sysmouse interface. It worked as /dev/wsp0 device node was
automatcaly opened by devd(8) with starting of moused(8).
Starting with 15.0 moused(8) does not open sysmouse interface by default
thus making wsp(4) device dysfunctional.
Fix it with adding extra checks of interfaces state.
MFC after: 1 week
wsp(4): Do not handle pressure on non-ForceTouch devices
They always report it value as zero breaking pressure-driven drivers
like moused(8) and xf86-input-synaptics.
MFC after: 1 week
bcm5974(4): Do not handle pressure on non-ForceTouch devices
They always report it value as zero breaking pressure-driven drivers
like moused(8) and xf86-input-synaptics.
MFC after: 1 week
bcm5974(4): Fix pre-2015 Apple touchpad support
These devices appeared to stop sending reports via mouse USB interface
after switching to RAW mode. Fix it with changing Usage of Top Level
Collection to one found in HID report descriptor of proper interface.
MFC after: 1 week
hid: Change Usage Page names to match documentation
According to "HID Usage Tables FOR Universal Serial Bus (USB)"
Usage Page ID range 0x93-0xF1CF is "Reserved" and Usage Page ID range
0xFF00-0xFFFF is "Vendor-defined".
MFC after: 1 week
