Extend the ino_t, dev_t, nlink_t types to 64-bit ints. Modify
struct dirent layout to add d_off, increase the size of d_fileno
to 64-bits, increase the size of d_namlen to 16-bits, and change
the required alignment. Increase struct statfs f_mntfromname[] and
f_mntonname[] array length MNAMELEN to 1024.
ABI breakage is mitigated by providing compatibility using versioned
symbols, ingenious use of the existing padding in structures, and
by employing other tricks. Unfortunately, not everything can be
fixed, especially outside the base system. For instance, third-party
APIs which pass struct stat around are broken in backward and
forward incompatible ways.
Kinfo sysctl MIBs ABI is changed in backward-compatible way, but
there is no general mechanism to handle other sysctl MIBS which
return structures where the layout has changed. It was considered
that the breakage is either in the management interfaces, where we
usually allow ABI slip, or is not important.
Struct xvnode changed layout, no compat shims are provided.
For struct xtty, dev_t tty device member was reduced to uint32_t.
It was decided that keeping ABI compat in this case is more useful
than reporting 64-bit dev_t, for the sake of pstat.
Update note: strictly follow the instructions in UPDATING. Build
and install the new kernel with COMPAT_FREEBSD11 option enabled,
then reboot, and only then install new world.
Credits: The 64-bit inode project, also known as ino64, started life
many years ago as a project by Gleb Kurtsou (gleb). Kirk McKusick
(mckusick) then picked up and updated the patch, and acted as a
flag-waver. Feedback, suggestions, and discussions were carried
by Ed Maste (emaste), John Baldwin (jhb), Jilles Tjoelker (jilles),
and Rick Macklem (rmacklem). Kris Moore (kris) performed an initial
ports investigation followed by an exp-run by Antoine Brodin (antoine).
Essential and all-embracing testing was done by Peter Holm (pho).
The heavy lifting of coordinating all these efforts and bringing the
project to completion were done by Konstantin Belousov (kib).
Sponsored by: The FreeBSD Foundation (emaste, kib)
Differential revision: https://reviews.freebsd.org/D10439
There are two possible ways how crypto callback are called: directly from
caller and deffered from crypto thread.
For inbound packets the direct call chain is the following:
IPSEC_INPUT() method -> ipsec_common_input() -> xform_input() ->
-> crypto_dispatch() -> crypto_invoke() -> crypto_done() ->
-> xform_input_cb() -> ipsec[46]_common_input_cb() -> netisr_queue().
The SA reference is held while crypto processing is not finished.
The error handling code wrongly expected that crypto callback always called
from the crypto thread context, and it did SA reference releasing in
xform_input_cb(). But when the crypto callback called directly, in case of
error (e.g. data authentification failed) the error handling in
ipsec_common_input() also did SA reference releasing.
To fix this, remove error handling from ipsec_common_input() and do it
in xform_input() before crypto_dispatch().
PR: 219356
MFC after: 10 days
- Start new sentences on new lines.
- Separate e.g. (more of an igor thing) with commas, and rewrite some examples
not to be enclosed in parentheses.
Reported by: igor, make manlint
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
- Sort .Xr entries in SEE ALSO section.
- Sort SEE ALSO and STANDARDS sections properly, in terms of the
entire document.
Reported by: make manlint
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
The (eventually) upcoming ath(4) changes will include being able to load
ath(4) devices on the AHB bus (ie the on-die wifi part of the SoC)
as modules.
In order for this to happen, a copy of the calibration data needs to be
copied away before the SPI driver runs or the memory map access hack
won't work.
Now, ideally (!) there'd be some driver that can come up after the MTD
pieces (eg, SPI, NAND, etc) and load into a firmware chunk the calibration
data.
(Or, really really nicely, would be an actual async firmware API that
would lead itself to having a driver schedule a file read - or a raw device
read - to get to the calibration data.)
Now, until all of the above is done - I'm going to perpetuate the layer
breaking atrocity here by simply doing the PCI bus fixup EEPROM/calibration
data hack here. This will work for any AR71xx (and later on, AR231x/AR531x)
device, as well as the handful of QCA MIPS + QCA9880v2 802.11ac boards with
NOR flash.
To use, this goes into the kernel config:
# Enable EEPROM hacks
options AR71XX_ATH_EEPROM
device ar71xx_caldata
device firmware
# This enables the ath_ahb driver (when I commit the change!) to
# pull data out of the firmware hack.
options ATH_EEPROM_FIRMWARE
In the hints file:
# ART calibration data mapping device
hint.ar71xx_caldata.0.at="nexus0"
hint.ar71xx_caldata.0.order=0
# Where the ART is - last 64k in the first 8MB of flash
hint.ar71xx_caldata.0.map.0.ath_fixup_addr=0x1fff0000
hint.ar71xx_caldata.0.map.0.ath_fixup_size=16384
# And now tell the ath(4) driver where to look!
hint.ath.0.eeprom_firmware="ar71xx_caldata.0.map.0.eeprom_firmware"
Tested:
* carambola2, AR933x SoC, using a set of ath and ath_hal modules to load
TODO:
* unify this bit of firmware loading code, as I will definitely need
to include both the PCI bus firmware version (for PCI ID fixups too!)
as well as AHB/on-chip calibration data.
* Commit the ath_ahb bus code
* Convert .. everything over. That'll take the majority of the time.
[ARM] Clear the constant pool cache on explicit .ltorg directives
Multiple ldr pseudoinstructions with the same constant value will
reuse the same constant pool entry. However, if the constant pool is
explicitly flushed with a .ltorg directive, we should not try to
reference constants in the previous pool any longer, since they may
be out of range.
This fixes assembling hand-written assembler source which repeatedly
loads the same constant value, across a binary size larger than the
pc-relative fixup range for ldr instructions (4096 bytes). Such
assembler source already uses explicit .ltorg instructions to emit
constant pools with regular intervals. However if we try to reuse
constants emitted in earlier pools, they end up out of range.
This makes the output of the testcase match what binutils gas does
(prior to this patch, it would fail to assemble).
Differential Revision: https://reviews.llvm.org/D32847
This should fix "out of range pc-relative fixup value" errors, when
compiling certain ARM inline assembly for www/webkit-gtk[23].
Reported by: mmel
MFC after: 3 days
The textproc/glimpse port expired over 3 years ago because there weren't any
more publicly available distfiles, and because it lacked a maintainer. Remove
the target as it's no longer executable on FreeBSD.
Differential Revision: D10764
MFC after: 1 month
Reviewed by: imp
Sponsored by: Dell EMC Isilon
if it is called on a TCP socket
* with an IPv6 address and the socket is bound to an
IPv4-mapped IPv6 address.
* with an IPv4-mapped IPv6 address and the socket is bound to an
IPv6 address.
Thanks to Jonathan T. Leighton for reporting this issue.
Reviewed by: bz gnn
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D9163
ENA is a networking interface designed to make good use of modern CPU
features and system architectures.
The ENA device exposes a lightweight management interface with a
minimal set of memory mapped registers and extendable command set
through an Admin Queue.
The driver supports a range of ENA devices, is link-speed independent
(i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc.), and has
a negotiated and extendable feature set.
Some ENA devices support SR-IOV. This driver is used for both the
SR-IOV Physical Function (PF) and Virtual Function (VF) devices.
ENA devices enable high speed and low overhead network traffic
processing by providing multiple Tx/Rx queue pairs (the maximum number
is advertised by the device via the Admin Queue), a dedicated MSI-X
interrupt vector per Tx/Rx queue pair, and CPU cacheline optimized
data placement.
The ENA driver supports industry standard TCP/IP offload features such
as checksum offload and TCP transmit segmentation offload (TSO).
Receive-side scaling (RSS) is supported for multi-core scaling.
The ENA driver and its corresponding devices implement health
monitoring mechanisms such as watchdog, enabling the device and driver
to recover in a manner transparent to the application, as well as
debug logs.
Some of the ENA devices support a working mode called Low-latency
Queue (LLQ), which saves several more microseconds. This feature will
be implemented for driver in future releases.
Submitted by: Michal Krawczyk <mk@semihalf.com>
Jakub Palider <jpa@semihalf.com>
Jan Medala <jan@semihalf.com>
Obtained from: Semihalf
Sponsored by: Amazon.com Inc.
Differential revision: https://reviews.freebsd.org/D10427
