Newer firmware on POWER systems, including v2.10 of the Talos II and
Blackbird firmware can end up reserving more than 32 memory regions in
the device tree, which exceeded an assumption made by ofw_machdep.c's
excise_fdt_reserved(). Bump the maximum number of FDT reservations to
the next power of 2 in order to fix booting on newer firmware.
PR: 277097
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D44015
It is needed at least to ensure that undesirable code is not linked into
rtld from libsys/libc, and adding the map file option each time is not
productive.
Reviewed by: brooks, emaste
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D44136
A socket marked with PR_SOCKBUF has protocol specific socket buffers
and will take care of the in its pr_listen method. Right now we don't
have any sockets that can listen and are PR_SOCKBUF, but that will
change soon.
It's a thin wrapper on cap_getmode() implemented in libc, not a system
call so the symbol should have been exposed by libc/gen/Symbol.map
alongside the implementation.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D44110
Applies both to SOCK_STREAM and SOCK_SEQPACKET. Put the test in this file
as it is most advanced one.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D43854
This is undocumented feature of PF_UNIX/SOCK_STREAM and thus of
PF_UNIX/SOCK_SEQPACKET, too. Put the test into this file, since this file
is most advanced and has all primitives to write this test in minimum
number of lines.
Differential Revision: https://reviews.freebsd.org/D43853
Use the function in mk_pair_of_sockets(), and in four existing tests -
'listen_bound', 'connect', 'shutdown_send' and 'shutdown_send_sigpipe'.
While here make mk_pair_of_sockets() return pointer to sockaddr_un instead
of path. This also fixes bug of returning pointer to stack memory of
returning function. However, the only caller that cares about this return
is temporarily ifdefed out. No functional change intended.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D43852
These tests were not testing conformance to the specification, rather than
the limitation of our implementation. The specification doesn't say that
a SOCK_SEQPACKET shall ever return EMSGSIZE. It says:
The SOCK_SEQPACKET socket type is similar to the SOCK_STREAM type,
and is also connection-oriented. The only difference between these
types is that record boundaries are maintained using the
SOCK_SEQPACKET type. A record can be sent using one or more output
operations and received using one or more input operations, but a
single operation never transfers parts of more than one record.
Record boundaries are visible to the receiver via the MSG_EOR flag
in the received message flags returned by the recvmsg() function. It
is protocol-specific whether a maximum record size is imposed.
The EMSGSIZE is specified as 'message is too large to be sent all at once,
as the socket requires'. Indeed existing implementation that has
unix/seqpacket marked as PR_ATOMIC has such a limitation. But future
implementation won't have, thus remove the tests.
Reviewed by: tuexen, asomers
Differential Revision: https://reviews.freebsd.org/D43756
The PF_UNIX/SOCK_SEQPACKET was marked as PR_ATOMIC and that made
soreceive_generic() to treat it pretty much as a datagram socket.
However, POSIX says:
The SOCK_SEQPACKET socket type is similar to the SOCK_STREAM type,
and is also connection-oriented. The only difference between these
types is that record boundaries are maintained using the
SOCK_SEQPACKET type. A record can be sent using one or more output
operations and received using one or more input operations, but a
single operation never transfers parts of more than one record.
Record boundaries are visible to the receiver via the MSG_EOR flag
in the received message flags returned by the recvmsg() function. It
is protocol-specific whether a maximum record size is imposed.
What the test was doing is checking if MSG_TRUNC would report the space
required to return up the end of next mbuf record in the socket buffer.
Apparently the test assumed that this boundary is defined by the write(2)
size on the peer socket. This was true in test conditions, but I'm not
sure it would always be true - sbcompress() may merge mbufs. Anyway, the
mbuf boundaries are internal socket buffer implementation, they are not
SOCK_SEQPACKET records. The records need to be explicitly marked with
MSG_EOR by sender, and the test definitely wasn't doing that.
Reviewed by: tuexen, markj
Differential Revision: https://reviews.freebsd.org/D43707
Make the ldconfig program accept hints files in little-endian and
big-endian format on all architectures.
The default format is the native byte-order of the respective host.
This is expected to change when a version of the pkg command is
available that implements support for either byte-order in its
internal ldconfig function. (Already committed in the development
tree of the pkg utility, a release is expected at the end of Q1/2024).
This update adds the -B option to the ldconfig program. It enforces
the creation of a big-endian hints file on a little-endian host.
The main purpose to is support of tests with non-native byte-order
files on little-endian hosts. It will be removed when all supported
FreeBSD releases use little-endian hints files by default.
When little-endian hints files are generally used, support of
either byte-order in libexec/rtld can also be removed.
When support for big-endian hints files is no longer required,
the COND_SWAP macro in ldconfig and rtld shall be replaced by
le32toh(), which just return their argument on little-endian
architectures.
Approved by: kib
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D44093
While lorder is not required by our current toolchain (or any toolchain
we've used in the past decade or two), it still occasionally shows up
in build systems of third party software, including The Open Group's
UNIX conformance test suite, and the maintenance cost is negligible.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: imp, allanjude, emaste
Differential Revision: https://reviews.freebsd.org/D44135
* Properly parse (no) command-line options.
* Ensure that errors go to stderr and result in a non-zero exit.
* Drop the special-case code for a single argument, as it will produce
the wrong outcome if the file does not exist or is corrupted.
* Don't print anything until after we've collected all the data.
* Always create all temporary files before setting the trap. This
ensures that the trap can safely fire at any moment, regardless of any
previous definition of `T`.
* Use a temporary file rather than a pipe between `nm` and `sed` to
ensure proper termination if `nm` fails due to a missing or invalid
input.
* The check for self-referential entries was conditional on testing our
argument list against a regex looking for archives. This was a
needless and unreliable optimization; make the check unconditional.
* Document that lorder will not work properly if any of its inputs have
spaces in their name.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D44133
If the LPI Configuration Tabel has been pre-allocated by the boot
loader, then we have to remember PROPBASER and use it rather than
allocating memory for it ourselves. Linux provides us with a reserved
table that contains all the gicv3 allocations, so make sure what we read
from PROPBASER matches something in that table. Normally, bare metal
boot loaders leave the gic in a reset state. However, Linux brings it up
fully so it can do I/O to boot the next kernel via kexec. Since the
gicv3 PENDBASER can't be reset while running due to undefined behavior,
we must reuse what's there for both PENDBASER and PROPBASER.
With this commit, the workaround is complete. Details are at
https://lkml.iu.edu/hypermail/linux/kernel/1809.2/06246.html
and pointers in the thread.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D44038
When we're using the preallocated memory for gicv3, record each cpu's
PENDBASER where we'd normally allocate memory for it. Make sure that
memory is in the excluded list and map the PA to VA and store that, to
mimic what we do with the allocation case.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D44037
Define masks for these registers to find the PA of where these are
pointing.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D44096
Report some stats about PENDBASE when we're running under
bootverbose. We don't do this by default because experience has been
excess output in this routine hangs the system.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D44036
Only set the redistributor base if we're not reallocated. If we are
preallocated, leave it all alone.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D44035
If the gicv3 is already started, then don't allocate memory for the
pend_base tables.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D44034
Due to undefined behavior, it's impossible to re-program a gicv3 ITS
table once it's programmed once. Memory corruption happens otherwise.
Panic if we detect the LPI is already enabled.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D44033
The current code is written such that all the attach routines can do so
in parallel. However, newbus serializes children today, and is likely to
do so in the future. Only allocate memory for the first time. Add an
assertion that this memory is allocated for larger units.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D44032
The last example in the manpage md5(1) wants to demonstrate
GNU mode (md5sum), but uses BSD mode (md5) instead:
In GNU mode, the -c option does not compare against a hash string
passed as parameter. Instead, it expects a digest file,
as created under the name digest for /boot/loader.conf in
the example above.
PR: 276560
Reviewed by: mhorne
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D44098
The manpage of nvmecontrol(8) has the following SYNOPSIS:
nvmecontrol format [-f fmt] [-m mset] [-o pi] [-l pil] [-E]
[-C] <device-id | namespace-id>
The correct switch for the pi option is -p according
to sbin/nvmecontrol/format.c:
OPT("pi", 'p', arg_uint32, opt, pi, "Protective information")
So correct the SYNOPSIS section accordingly.
PR: 276554
Reviewed by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D44099
This will load/save the /var/run directories at boot/shutdown if
and only if /var/run/ is a tmpfs mount so it is a win for tmpfs
users and a no-op for everyone else.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D44097
Sponsored by: Beckhoff Automation GmbH & Co. KG
Enable the Synopsis UART driver. Other drivers will be added in the
future.
Reviewed by: jrtc27
Sponsored by: The FreeBSD Foundatino
Differential Revision: https://reviews.freebsd.org/D44105
The core of this driver is supported by multiple architectures. Move the
config entries to the MI conf/files.
This hardware is found on several available/emerging RISC-V SoCs, so we
will soon need it on this architecture.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44104
Move the core dwc(4) file entries to the MI conf/files.
Platform-specific versions e.g. rk_dwc are retained in their current
position. On arm64 this necessitates adding an additional 'device dwc'
option.
This hardware is found on several available/emerging RISC-V SoCs, so we
will soon need it on this architecture.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44103
It conflicts with the general "DEBUG" macro defined as an option in LINT
builds. Since this is actually unused, just rename it to GMAC_DEBUG.
Reviewed by: manu
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44102
Define SNL_DECLARE_FIELD_PARSER* macros to create a parser that has
no output attributes only input fields and use this to define the
snl_donemsg_parser.
This removes the need for the zero-length nla_p_donemsg[] variable.
Zero length arrays are not valid in ISO C.
Reviewed by: jrtc27, melifaro
Differential Revision: https://reviews.freebsd.org/D43918
This uses bus_generic_rman_alloc/release_resource to reduce some code
duplication. However, I've left the custom activate/deactivate
methods as-is.
Differential Revision: https://reviews.freebsd.org/D43939
For SYS_RES_MEMORY, use bus_generic_rman_* for
activate/deactivate_resource methods as well as custom
map/unmap_resource methods that request submappings of the sc_mem
resource allocated from the parent bus.
Differential Revision: https://reviews.freebsd.org/D43938
These functions are not safe as the rman implementation assumes that
all regions (including allocated resources) are sorted by address in
the internal linked-list.
Differential Revision: https://reviews.freebsd.org/D43936
Those mode pages are obsolete since SBC-2 specification almost 20
years ago. First I was trying to understand possible relations
between physical block and physical sector terms in different specs.
Then was thinking about possible relations to device CHS geometry
and compatibility issues. Finally I just decided that none of it
worth the efforts and should rest in piece.
PR: 276524
When we handle a packet via route-to (i.e. pf_route6()) we still need to
verify the MTU. However, we only run that check in the forwarding case.
Set the PFIL_FWD tag when running the pf_test6(PF_OUT) check from
pf_route6(). We are in fact forwarding, so should call the test function
as such. This will cause us to run the MTU check, and generate an ICMP6
packet-too-big error when required.
See also: 54c62e3e5d
See also: f1c0030bb0
See also: https://redmine.pfsense.org/issues/14290
Sponsored by: Rubicon Communications, LLC ("Netgate")
