Certain configurations need to use a different path for pidfile.
Allow rc.conf to overwrite it.
Reviewed by: cy, 0mp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D36141
At least KVM in Proxmox seems not happy about it. Just to be safe
block it for all VMs, since it should just improve profile accuracy.
MFC after: 1 week
It is desirable to run kboot as the first program in some LinuxBoot
environments. This is the traditional "pid 1" or "init" program. When
running as pid 1. rovide a minimal environment based on what sysvinit,
u-root, initramfs-tools and other like projects do. We mount /dev, /sys,
/proc, make symlinks from /dev/fd to /dev/proc, and create /tmp, /run,
and /var. We also setup stdin/out/err to the console, set the tty
characteristics of same and block the appropriate signals.
This is indended as an environment that never does a fork/exec. If
that's required, the process groups, session leaders and all things
POSIX terminal handlers will need to be added.
Unlike the general purpose linux projects in this area, no attempt is
made to support very old kernels.
When not pid 1, we skip all of the above.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D36368
Give scripts the ability to determine if the currently running loader
has provided a command.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D36365
interp_has_builtin_cmd() will try to lookup the passed in command and
returns true if it was found, false otherwise.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D36364
Factor out interp_lookup_cmd to search for a command from
interp_builtin_cmd. This simplifies the latter and can be used to expand
lua to ask if a command exists.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D36363
Failure to map RSDP, XSLT and checksum failures are events that can't
happen unless something has gone wrong. As such, they should be reported
always, and not in bootverbose. This has been this way since it was
originally brought in to parse APIC tables.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D36406
Add missing pmap_unmapbios() calls for when we return 0. Otherwise we
can leave the table mapped when it is of no use.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D36405
arm64 requires ACPI RSDP Revision 2.0 since it requires 64-bit physical
addresses. It is an error worth reporting if we have a RSDP pointer, but
it points to the wrong version.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D36404
Document how EFI consoles work, at least on x86. There's a number of
weird quirks and limitations that are generally known, but not
documented until now. Include information on how EFI decides what the
defualt console is, how to set it and how to cope with common
situations. Note limitations and mismatch between ACPI (which uses UID
to identify a device) and our console code (which uses a raw address)
and explain why we can't translate between them in the loader.
Sponsored by: Netflix
Reviewed by: manu, kevans, rpokala, pauamma
Differential Revision: https://reviews.freebsd.org/D36286
Commit 603677334a added a sentence with a file path
in it. However, it did not use .Pa since it would leave
a space after it, where ('s) was supposed to go.
This patch rewords the sentence so that .Pa can
be used.
This is a content change.
Suggested by: mkarels
Introduce a local change. It seems ieee80211_get_tid() does not deal
with non-dataqos packets unlike net80211's ieee80211_gettid().
Gernally all calls in Linux drivers to ieee80211_get_tid() seem to
be proceeded by an ieee80211_is_data_qos() check.
Moving the ieee80211_get_tid() has no difference in the result, but
(a) saves us the call if we do not need it due to an earlier return,
and (b) allows us to put an assert into the LinuxKPI ieee80211_get_tid()
implementation to avoid accidentally returning random frame header data
in case of a missing earlier ieee80211_is_data_qos() check in (future/
other) drivers.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
The AccECN handshake and TCP header flags are supported,
no support yet for the AccECN option. This minimalistic
implementation is sufficient to support DCTCP while
dramatically cutting the number of ACKs, and provide ECN
response from the receiver to the CC modules.
Reviewed By: #transport, #manpages, rrs, pauamma
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D21011
While a receiver should continue sending SACK blocks for the
duration of a SACK loss recovery, if for some reason the
TCP options no longer contain these SACK blocks, but we
already started maintaining the Scoreboard, keep on handling
incoming ACKs (without SACK) as belonging to the SACK recovery.
Reported by: thj
Reviewed by: tuexen, #transport
MFC after: 2 weeks
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D36046
The mpidr register is 64 bit on arm64 and 32 bit on arm. Fix this by
extending the arm64 definition to include the top 32 bits.
To preserve KBI when MFCing split the value into two 32 bit values.
This will be cleaned up later only on main.
Reviewed by: bz
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36346
Here go cons of using inpcb for divert:
- divert(4) uses only 16 bits (local port) out of struct inpcb,
which is 424 bytes today.
- The inpcb KPI isn't able to provide hashing for divert(4),
thus it uses global inpcb list for lookups.
- divert(4) uses INET-specific part of the KPI, making INET
a requirement for IPDIVERT.
Maintain our own very simple hash lookup database instead. It
has mutex protection for write and epoch protection for lookups.
Since now so->so_pcb no longer points to struct inpcb, don't
initialize protosw methods to methods that belong to PF_INET.
Also, drop support for setting options on a divert socket. My
review of software in base and ports confirms that this has no
use and unlikely worked before.
Differential revision: https://reviews.freebsd.org/D36382
Instead of incrementing pretty random counters in the IP statistics,
create divert socket statistics structure. Export via netstat(1).
Differential revision: https://reviews.freebsd.org/D36381
Since 4.4BSD the protosw was used to implement socket types created
by socket(2) syscall and at the same to demultiplex incoming IPv4
datagrams (later copied to IPv6). This story ended with 78b1fc05b2.
These entries (e.g. IPPROTO_ICMP) in inetsw that were added to catch
packets in ip_input(), they would also be returned by pffindproto()
if user says socket(AF_INET, SOCK_RAW, IPPROTO_ICMP). Thus, for raw
sockets to work correctly, all the entries were pointing at raw_usrreq
differentiating only in the value of pr_protocol.
With 78b1fc05b2 all these entries are no longer needed, as ip_protox
is independent of protosw. Any socket syscall requesting SOCK_RAW type
would end up with rip_protosw. And this protosw has its pr_protocol
set to 0, allowing to mark socket with any protocol.
For IPv6 raw socket the change required two small fixes:
o Validate user provided protocol value
o Always use protocol number stored in inp in rip6_attach, instead
of protosw value, which is now always 0.
Differential revision: https://reviews.freebsd.org/D36380
The divert(4) is not a protocol of IPv4. It is a socket to
intercept packets from ipfw(4) to userland and re-inject them
back. It can divert and re-inject IPv4 and IPv6 packets today,
but potentially it is not limited to these two protocols. The
IPPROTO_DIVERT does not belong to known IP protocols, it
doesn't even fit into u_char. I guess, the implementation of
divert(4) was done the way it is done basically because it was
easier to do it this way, back when protocols for sockets were
intertwined with IP protocols and domains were statically
compiled in.
Moving divert(4) out of inetsw accomplished two important things:
1) IPDIVERT is getting much closer to be not dependent on INET.
This will be finalized in following changes.
2) Now divert socket no longer aliases with raw IPv4 socket.
Domain/proto selection code won't need a hack for SOCK_RAW and
multiple entries in inetsw implementing different flavors of
raw socket can merge into one without requirement of raw IPv4
being the last member of dom_protosw.
Differential revision: https://reviews.freebsd.org/D36379
Recent problems related to NFSv4 mounts has been traced
to multiple NFSv4 clients using the same /etc/hostid
(or kern.hostuuid, if you prefer).
This patch adds a sentence to the man page noting that
clients must have unique /etc/hostid's.
This is a content change.
Reviewed by: gbe (manpages)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D36392
To avoid issues starting any USB transfers before the open
function is complete.
Differential Revision: https://reviews.freebsd.org/D36391
MFC after: 1 week
Sponsored by: NVIDIA Networking
Some controllers like the XHCI(4) loose track of the data toggle value when
USB receive transfers are cancelled at close. This in turn can lead to to
data loss after the next open.
To avoid data loss, make sure both the receive and transmit data toggles
get reset, before trying to read or write any data.
Differential Revision: https://reviews.freebsd.org/D36391
Submitted by: Dave Baukus <daveb@spectralogic.com>
MFC after: 1 week
Sponsored by: NVIDIA Networking
domain_init() called at SI_SUB_PROTO_DOMAIN/SI_ORDER_SECOND is always
called right after domain_add(), that had been called at SI_ORDER_FIRST.
Note that protocols aren't initialized yet at this point, since they are
usually scheduled to initialize at SI_ORDER_THIRD.
After this merge it becomes clear that DOMF_SUPPORTED / DOMF_INITED
can be garbage collected as they are set & checked in the same function.
For initialization of the domain system itself it is now clear that
domaininit() can be garbage collected and static initializer is enough.
o Statically initialize max_linkhdr to default value without relying
on domain(9) code doing that.
o Statically initialize max_protohdr to a sane value, without relying
on TCP being always compiled in.
o Retire max_datalen. Set, but not used.
o Don't make the domain(9) system responsible in validating these
values and updating max_hdr. Instead provide KPI max_linkhdr_grow()
and max_protohdr_grow().
o Call max_linkhdr_grow() from IEEE802.11 and max_protohdr_grow() from
TCP. Those are the only protocols today that may want to grow.
Reviewed by: tuexen
Differential revision: https://reviews.freebsd.org/D36376
- Ignore I/O requests with insufficiently sized input or output
buffers (those not containing compete request headers).
- Ignore control requests with improperly sized buffers.
- While here, explicitly zero the output header of an I/O request to
avoid leaking malloc garbage from the host if the header is not
fully populated.
PR: 264521
Reported by: Robert Morris <rtm@lcs.mit.edu>
Reviewed by: mav, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36271
Use a consistent prefix ("virtio-scsi: ") similar to the e1000 device
model.
Reviewed by: mav, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36270
When preparing to transmit pending packets, ensure that the head (TDH)
and tail (TDT) indices are in bounds. Note that validating values
when they are written is not sufficient along as the transmit length
(TDLEN) could be changed turning a value that was valid when written
into an out of bounds value.
While here, add further restrictions to the head register (TDH). The
manual states that writing to this value while transmit is enabled can
cause unexpected behavior and that it should only be written after a
reset. As such, ignore attempts to write while transmit is active,
and also ignore writes of non-zero values. Later e1000 chipsets have
this register as read-only.
Also ignore any attempts to transmit packets if the transmit ring's
size is zero.
PR: 264567
Reported by: Robert Morris <rtm@lcs.mit.edu>
Reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36269
