These tests should be skipped if /etc/rc.d/auditd is missing, which could be
the case if world was built with WITHOUT_AUDIT set. Also, one test case
requires /etc/rc.d/accounting.
Alan Somers [Thu, 14 Feb 2019 20:26:59 +0000 (20:26 +0000)]
MFC r341390, r341392, r341667
r341390:
Remove some dead code from the geli tests
This is detritus in the Makefile, leftover from 327662.
r341392:
Unbreak geli/gmirror testcases if their geom classes cannot be loaded
The problem with the logic prior to this commit was twofold:
1. The wrong set of idioms (TAP-compatible) were being applied to the ATF
testcases when run, resulting in confusing ATF failure results on setup.
2. The cleanup subroutines were broken when the geom classes could not be
loaded as they exited with 0 unexpectedly.
This commit changes the test code to source the class-specific configuration
(conf.sh) once globally, instead of sourcing it per testcase and per cleanup
subroutine, and to call the ATF-specific setup subroutine(s) inline in
the testcases.
The refactoring done is effectively a no-op for the TAP testcases, modulo
any refactoring done to create common code between the ATF and TAP
testcases.
This unbreaks the geli testcases converted to ATF in r327662 and r327683,
and the gmirror testcases added in r327780, respectively, when the geom
class could not be loaded.
tests/sys/geom/class/mirror/...
While here, ignore errors when turning debug failpoint sysctl off, which
could occur if the gmirror class was not loaded.
r341667:
geom tests: Fix cleanup of ATF tests since r341392
r341392 changed common test cleanup routines in a way that allowed them to
be used by TAP tests as well as ATF tests. However, a late change made
during code review resulted in cleanup being broken for ATF tests, which
source geom_subr.sh separately during the body and cleanup phases of the
test. The result was that md(4) devices wouldn't get cleaned up.
Alan Somers [Thu, 14 Feb 2019 20:24:33 +0000 (20:24 +0000)]
MFC r341598:
stat(2): clarify which syscalls modify file timestamps
The list of syscalls that modify st_atim, st_mtim, and st_ctim was quite out
of date and probably not accurate to begin with. Update it, and make it
clear that the list is open-ended.
Alan Somers [Thu, 14 Feb 2019 18:01:06 +0000 (18:01 +0000)]
MFC r340988:
vfs_aio.c: rename "physio" symbols to "bio".
aio has two paths: an asynchronous "physio" path and a synchronous path.
Confusingly, physio(9) isn't actually used by the "physio" path, and never
has been. In fact, it may even be called by the synchronous path! Rename
the "physio" path to the "bio" path to reflect what it actually does:
directly compose BIOs and send them to character devices.
Ben Widawsky [Wed, 13 Feb 2019 19:00:06 +0000 (19:00 +0000)]
MFC r339577:
acpi: Add an interface to obtain DSM information
The Device Specific Method (_DSM) is on optional object that defines
device specific controls. This will be useful for our power management
controller in upcoming patches. More information can be found in ACPI
spec 6.2 section 9.1.1
Marius Strobl [Wed, 13 Feb 2019 16:02:52 +0000 (16:02 +0000)]
MFC: r343372
ixl(4): Fix handling data passed with ioctl from NVM update tool
From Krzysztof:
Ensure that the entire data buffer passed from the NVM update tool is copied in
to kernel space and copied back out to user space using copyin() and copyout().
PR: 234104
Submitted by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Reported by: Finn <ixbug@riseup.net>
Differential Revision: https://reviews.freebsd.org/D18817
Marius Strobl [Wed, 13 Feb 2019 15:27:17 +0000 (15:27 +0000)]
MFC: r343622
ix(4),ixv(4): Fix TSO offloads when TXCSUM is disabled
This patch and commit message are based on r340256 created by Jacob Keller:
The iflib stack does not disable TSO automatically when TXCSUM is
disabled, instead assuming that the driver will correctly handle TSOs
even when CSUM_IP is not set.
This results in iflib calling ixgbe_isc_txd_encap with packets which have
CSUM_IP_TSO, but do not have CSUM_IP or CSUM_IP_TCP set. Because of
this, ixgbe_tx_ctx_setup will not setup the IPv4 checksum offloading.
This results in bad TSO packets being sent if a user disables TXCSUM
without disabling TSO.
Fix this by updating the ixgbe_tx_ctx_setup function to check both
CSUM_IP and CSUM_IP_TSO when deciding whether to enable checksums.
Once this is corrected, another issue for TSO packets is revealed. The
driver sets IFLIB_NEED_ZERO_CSUM in order to enable a work around that
causes the ip->sum field to be zero'd. This is necessary for ix
hardware to correctly perform TSOs.
However, if TXCSUM is disabled, then the work around is not enabled, as
CSUM_IP will not be set when the iflib stack checks to see if it should
clear the sum field.
Fix this by adding IFLIB_TSO_INIT_IP to the iflib flags for the ix and
ixv interface files.
Once both of these changes are made, the ix and ixv drivers should
correctly offload TSO packets when TSO offload is enabled, regardless
of whether TXCSUM is enabled or disabled.
Marius Strobl [Wed, 13 Feb 2019 15:19:31 +0000 (15:19 +0000)]
MFC: r343621
ix(4): Run {mod,msf,mbx,fdir,phy}_task in if_update_admin_status
From Piotr:
This patch introduces adapter->task_requests register responsible for
recording requests for mod_task, msf_task, mbx_task, fdir_task and
phy_task calls. Instead of enqueueing these tasks with
GROUPTASK_ENQUEUE, handlers will be called directly from
ixgbe_if_update_admin_status() while holding ctx lock.
SIOCGIFXMEDIA ioctl() call reads adapter->media list. The list is
deleted and rewritten in ixgbe_handle_msf() task without holding ctx
lock. This change is needed to maintain data coherency when sharing
adapter info via ioctl() calls.
Patch co-authored by Krzysztof Galazka <krzysztof.galazka@intel.com>.
Marius Strobl [Wed, 13 Feb 2019 14:39:16 +0000 (14:39 +0000)]
MFC: r343934
- Remove the redundant device disabled hint handling; ever since
r241119 that's performed globally by device_attach(9).
- As for the EM-class of devices, em(4) supports multiple queues
and MSI-X respectively only with 82574 devices. However, since
the conversion to iflib(4), em(4) relies on the interrupt type
fallback mechanism, i. e. MSI-X -> MSI -> INTx, of iflib(4) to
figure out the interrupt type to use for the EM-class (as well
as the IGB-class) of MACs. Moreover, despite the datasheet for
82583V not mentioning any support of MSI-X, there actually are
82583V devices out there that report a varying number of MSI-X
messages as supported. The interrupt type fallback of iflib(4)
is causing two failure modes depending on the actual number of
MSI-X messages supported for such instances of 82583V:
1) With only one MSI-X message supported, none is left for the
RX/TX queues as that one message gets assigned to the admin
interrupt. Worse, later on - which will be addressed with a
separate fix - iflib(4) interprets that one messages as MSI
or INTx to be set up, but fails to actually do so as it has
previously called pci_alloc_msix(9). [1, 2]
2) With more message supported, their distribution is okay but
then em_if_msix_intr_assign() doesn't work for 82583V, with
the interface being left in a non-working state, too. [3]
Thus, let em_if_attach_pre() indicate to iflib(4) to try MSI-X
with 82574 only, and at most MSI for the remainder of EM-class
devices.
While at it, remove "try_second_bar" as it's polarity inverted
and not actually needed.
- Remove code from em_if_timer() that effectively is a NOP since
the conversion to iflib(4) ("trigger" is no longer read).
While at it, let the comment for em_if_timer() reflect reality
after said conversion.
- Implement an ifdi_watchdog_reset method which only updates the
em(4) "watchdog_events" counter but doesn't perform any reset,
so that the em(4) "watchdog_timeouts" SYSCTL (iflib(4) doesn't
provide a counterpart) reflects reality and these timeouts add
to IFCOUNTER_OERRORS again after the iflib(4) conversion.
- Remove the "mbuf_defrag_fail" and "tx_dma_fail" SYSCTLS; since
the iflib(4) conversion, associated counters are disconnected,
but iflib(4) provides "mbuf_defrag_failed" and "tx_map_failed"
respectively as equivalents.
- Move the description preceding lem_smartspeed() to the correct
spot before em_reset() and bring back appropriate comments for
{igb,em}_initialize_rss_mapping() and lem_smartspeed() lost in
the iflib(4) conversion.
- Adapt some other function descriptions and INIT_DEBUGOUT() use
to match reality after the iflib(4) conversion.
- Put the debugging message of em_enable_vectors_82574() (missed
in r343578) under bootverbose, too.
Marius Strobl [Wed, 13 Feb 2019 14:36:24 +0000 (14:36 +0000)]
MFC: r343369
intel iflib drivers: correct initialization of tx_cidx_processed
From Jake:
In r341156 ("Fix first-packet completion", 2018-11-28) a hack to work
around a delta calculation determining how many descriptors were used
was added to ixl_isc_tx_credits_update_dwb.
The same fix was also applied to the em and igb drivers in r340310, and
to ix in r341156.
The hack checked the case where prev and cur were equal, and then added
one. This works, because by the time we do the delta check, we already
know there is at least one packet available, so the delta should be at
least one.
However, it's not a complete fix, and as indicated by the comment is
really a hack to work around the real bug.
The real problem is that the first time that we transmit a packet,
tx_cidx_processed will be set to point to the start of the ring.
Ultimately, the credits_update function expects it to point to the
*last* descriptor that was processed. Since we haven't yet processed any
descriptors, pointing it to 0 results in this incorrect calculation.
Fix the initialization code to have it point to the end of the ring
instead. One way to think about this, is that we are setting the value
to be one prior to the first available descriptor.
Doing so, corrects the delta calculation in all cases. The original fix
only works if the first packet has exactly one descriptor. Otherwise, we
will report 1 less than the correct value.
As part of this fix, also update the MPASS assertions to match the real
expectations. First, ensure that prev is not equal to cur, since this
should never happen. Second, remove the assertion about prev==0 || delta
!= 0. It looks like that originated from when the em driver was
converted to iflib. It seems like it was supposed to ensure that delta
was non-zero. However, because we originally returned 0 delta for the
first calculation, the "prev == 0" was tacked on.
Instead, replace this with a check that delta is greater than zero,
after the correction necessary when the ring pointers wrap around.
This new solution should fix the same bug as r341156 did, but in a more
robust way.
Lars Engels [Wed, 13 Feb 2019 14:32:14 +0000 (14:32 +0000)]
MFC r342945, r342947, r343020
Add `bluetooth-config` script to simplify setting up bluetooth connections to
devices like mice, keyboards, bt-audio, ...
This script currently allows scanning for nearby devices, adds one to
/etc/bluetooth/hosts, adds an entry to hcsecd's conf and if it is a HID, add an
entry to bthidd's configs, as well.
Marius Strobl [Wed, 13 Feb 2019 14:27:59 +0000 (14:27 +0000)]
MFC: r343203
ixgbe: this statement may fall through warnings with gcc
The recent gcc versions (7 and 8 at least) can check for switch case
statements for fall through (implicit-fallthrough). When fall through
is intentional, the default method for warning suppression is to place
comment /* FALLTHROUGH */ exactly before next case statement.
netmap: fix lock order reversal related to kqueue usage
When using poll(), select() or kevent() on netmap file descriptors,
netmap executes the equivalent of NIOCTXSYNC and NIOCRXSYNC commands,
before collecting the events that are ready. In other words, the
poll/kevent callback has side effects. This is done to avoid the
overhead of two system call per iteration (e.g., poll() + ioctl(NIOC*XSYNC)).
When the kqueue subsystem invokes the kqueue(9) f_event callback
(netmap_knrw), it holds the lock of the struct knlist object associated
to the netmap port (the lock is provided at initialization, by calling
knlist_init_mtx).
However, netmap_knrw() may need to wake up another netmap port (or even
the same one), which means that it may need to call knote().
Since knote() needs the lock of the struct knlist object associated to
the to-be-wake-up netmap port, it is possible to have a lock order reversal
problem (AB/BA deadlock).
This change prevents the deadlock by executing the knote() call in a
per-selinfo taskqueue, where it is possible to hold a mutex.
Alexander Motin [Wed, 13 Feb 2019 00:39:03 +0000 (00:39 +0000)]
MFC r343586: Remove BIO_ORDERED flag from BIO_FLUSH sent by ZFS.
In all cases where ZFS sends BIO_FLUSH, it first waits for all related
writes to complete, so its BIO_FLUSH does not care about strict ordering.
Removal of one makes life much easier at least for NVMe driver, which
hardware has no concept of request ordering, relying completely on software.
Alexander Motin [Wed, 13 Feb 2019 00:37:16 +0000 (00:37 +0000)]
MFC r343582,r343588:Relax BIO_FLUSH ordering in da(4), respecting BIO_ORDERED.
r212160 tightened this from always using MSG_SIMPLE_Q_TAG to always
MSG_ORDERED_Q_TAG. Since it also marked all BIO_FLUSH requests with
BIO_ORDERED, this commit changes nothing immediately, but it returns
BIO_FLUSH callers ability to actually specify ordering they really
need, alike to other request types.
Alexander Motin [Wed, 13 Feb 2019 00:33:01 +0000 (00:33 +0000)]
MFC r343585: Only sort requests of types that have concept of offset.
Other types, such as BIO_FLUSH or BIO_ZONE, or especially new/unknown ones,
may imply some degree of ordering even if strict ordering is not requested
explicitly.
MFC r342946: Remove accessing remote node and domain objects
while processing cam actions.
Issue:
ocs_fc(4) driver panics. It's induced by setting the port_state
sysctl to offline, then online, then offline, then online, and so
forth and so on in rapid succession.
Reason:
While we set the port_state to online fc discovery will start and OS
is enumerating the target discs by calling ocs_action(), then set the
port state to "offline" which deletes domain/sport/nodes.
In ocs_action()->XPT_GET_TRAN_SETTINGS we are accessing the remote
node which can be invalid to get the wwpn, wwnn and port.
Fix:
Removed accessing of remote node and domain in some ocs_action() cases.
Populated the required values from ocs_fcport.
This removes the dependency of node and domain structures while
processing XPT_PATH_INQ and XPT_GET_TRAN_SETTINGS.
We will invalidate the target entries after the device lost
timeout(30 seconds).
Changelist:
- Replace ND, D and RD macros with nm_prdis, nm_prinf, nm_prerr
and nm_prlim, to avoid possible naming conflicts.
- Add netmap_krings_mode_commit() helper function and use that
to reduce code duplication.
- Refactor pipes control code to export some functions that
can be reused by the veth driver (on Linux) and epair(4).
- Add check to reject API requests with version less than 11.
- Small code refactoring for the null adapter.
Enji Cooper [Tue, 12 Feb 2019 03:12:19 +0000 (03:12 +0000)]
MFC r342904:
route(8): clarify -prefixlen description
Try to reword -prefixlen section to more clearly and accurately describe how
the -prefixlen modifier works.
While here, fix a word that igor considered a typo: aggregatable addresses is a
valid technical term per RFC-2374, however, it was superseded by the term
"aggregator" in RFC-3587.
Alexander Motin [Tue, 12 Feb 2019 00:53:14 +0000 (00:53 +0000)]
MFC r343562, r343563: Reimplement BIO_ORDERED handling in nvd(4).
This fixes BIO_ORDERED semantics while also improving performance by:
- sleeping also before BIO_ORDERED bio, as defined, not only after;
- not queueing BIO_ORDERED bio to taskqueue if no other bios running;
- waking up sleeping taskqueue explicitly rather then rely on polling.
On Samsung SSD 970 PRO this shows sync write latency, measured with
`diskinfo -wS`, reduction from ~2ms to ~1.1ms by not sleeping without
reason till next HZ tick.
On the same device ZFS pool with 8 ZVOLs synchronously writing 4KB blocks
shows ~950 IOPS instead of ~750 IOPS before. I suspect ZFS does not need
BIO_ORDERED on BIO_FLUSH at all, but that will be next question.
Patrick Kelsey [Mon, 11 Feb 2019 23:35:34 +0000 (23:35 +0000)]
MFC r343535:
Speed up non-status operations applied to a single interface
When performing a non-status operation on a single interface, it is
not necessary for ifconfig to build a list of all addresses in the
system, sort them, then iterate through them looking for the entry for
the single interface of interest. Doing so becomes increasingly
expensive as the number of interfaces in the system grows (e.g., in a
system with 1000+ vlan(4) interfaces).
Patrick Kelsey [Mon, 11 Feb 2019 23:33:16 +0000 (23:33 +0000)]
MFC r343534:
Don't re-evaluate ALTQ kernel configuration due to events on non-ALTQ interfaces
Re-evaluating the ALTQ kernel configuration can be expensive,
particularly when there are a large number (hundreds or thousands) of
queues, and is wholly unnecessary in response to events on interfaces
that do not support ALTQ as such interfaces cannot be part of an ALTQ
configuration.
Patrick Kelsey [Mon, 11 Feb 2019 23:30:30 +0000 (23:30 +0000)]
MFC r343995:
Reduce the time it takes the kernel to install a new PF config containing a large number of queues
In general, the time savings come from separating the active and
inactive queues lists into separate interface and non-interface queue
lists, and changing the rule and queue tag management from list-based
to hash-bashed.
In HFSC, a linear scan of the class table during each queue destroy
was also eliminated.
There are now two new tunables to control the hash size used for each
tag set (default for each is 128):
MFC r343301:
Add missing dependency to vmxnet3 Makefile and clean it up a bit otherwise.
MFC r343688:
Fix interrupt index configuration when using MSI interrupts.
When in MSI mode, the device was only being configured with one
interrupt index, but it needs two - one for the actual interrupt and
one to park the tx queue at.
Also clarified comments relating to interrupt index assignment.
Patrick Kelsey [Mon, 11 Feb 2019 23:13:38 +0000 (23:13 +0000)]
MFC r343287:
Reduce pf.conf parsing cost for configs that define N queues from O(N^2) to O(N)
The number of syscalls made during parsing of any config that
defines tables is also reduced, and incorrect warnings that HFSC
parent queue bandwidths were smaller than the sum of their child
bandwidths have been fixed.
MFC r344025:
Fix the fix added in r343287 for spurious HFSC bandwidth check errors
The logic added in r343287 to avoid false-positive
sum-of-child-bandwidth check errors for HFSC queues has a bug in it
that causes the upperlimit service curve of an HFSC queue to be pulled
down to its parent's linkshare service curve if it happens to be above
it.
Upon further inspection/reflection, this generic
sum-of-child-bandwidths check does not need to be fixed for HFSC - it
needs to be skipped. For HFSC, the equivalent check is to ensure the
sum of child linkshare service curves are at or below the parent's
linkshare service curve, and this check is already being performed by
eval_pfqueue_hfsc().
This commit reverts the affected parts of r343287 and adds new logic
to skip the generic sum-of-child-bandwidths check for HFSC.
Kristof Provost [Mon, 11 Feb 2019 19:08:01 +0000 (19:08 +0000)]
MFC r343520:
pfctl: Point users to net.pf.request_maxcount if large requests are rejected
The kernel will reject very large tables to avoid resource exhaustion
attacks. Some users run into this limit with legitimate table
configurations.
The error message in this case was not very clear:
pf.conf:1: cannot define table nets: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded
If a table definition fails we now check the request_maxcount sysctl,
and if we've tried to create more than that point the user at
net.pf.request_maxcount:
pf.conf:1: cannot define table nets: too many elements.
Consider increasing net.pf.request_maxcount.
pfctl: Syntax error in config file: pf rules not loaded
MFC r343921:
Add an example to pw.8 about how to add an existing user to a group.
Instead of using pw to modify group membership, users often edit
/etc/group by hand, which is discouraged. Provide an example of
adding a user to the wheel group, which is a common use case.
I'm using a different user here as in the previous example as that
deleted the user (although the examples don't necessarily have to
be followed in order).
MFC r339877-r339879,r343564-r343566,r343580,r343754:
Untangle jemalloc and mutexes initialization.
The merge includes required warnings cleanup by arichardson, both to
avoid conflicts and to make rtld_malloc.c compilable with the libthr
WARNS settings.
Alexander Motin [Mon, 11 Feb 2019 14:48:45 +0000 (14:48 +0000)]
MFC r343728: Check element type before setting LEDs.
With r319610, sesutil started twiddling the bits of every SES device.
Not everything is a disk slot, there are also fan controllers, temperature
sensors, even power supplies, among other things controlled by SES.
Add a type check to make sure we are only operating on device slot and array
device slot elements. Other type elements will be skipped, but it would be
simple to add additional cases for controlling the ident LEDs of other
element types (which are not necessarily the same bits).
Rather than doing raw bit manipulation of an unstructured byte array using
unnamed numeric constants, leverage existing code abstractions.
Submitted by: Ryan Moeller <ryan@freqlabs.com>
Sponsored by: iXsystems, Inc.
MFC r343815:
iwn(4): plug initialization path vs interrupt handler races
There are few places in interrupt handler where the driver
lock is dropped; ensure that device is still running before
processing remaining ring entries.
Mariusz Zaborski [Sun, 10 Feb 2019 22:33:41 +0000 (22:33 +0000)]
MFC r343471:
libcasper: do not run registered exit functions
Casper library should not use exit(3) function because before setting it up
applications may register it. Casper doesn't depend on any registered exit
function, so it safe to change this.
For 11n / 11ac we are still using non-11n rates for management and
multicast traffic by default; check 'MCS rate' bit to determine how
to print them correctly.
Stefan Eßer [Sat, 9 Feb 2019 14:21:29 +0000 (14:21 +0000)]
MFC r343479: Fix potential buffer overflow and undefined behavior.
The buffer allocated in read_chat() could be 1 element too short, if the
chatstr parameter passed in is 1 or 3 charachters long (e.g. "a" or "a b").
The allocation of the pointer array does not account for the terminating
NULL pointer in that case.
Overlapping source and destination strings are undefined in strcpy().
Instead of moving a string to the left by one character just increment the
char pointer before it is assigned to the results array.
Stefan Eßer [Sat, 9 Feb 2019 14:07:04 +0000 (14:07 +0000)]
MFC r343303: Silence a CI warning regarding the use of strcpy().
While this is a false positive (a sufficiently large buffer has been
allocated in the line above), the use of strdup() simplifies and clarifies
the code.
This fixes 'Assertion failed: ((VT.getVectorNumElements() +
N2C->getZExtValue() <= N1.getValueType().getVectorNumElements()) &&
"Extract subvector overflow!"), function getNode' when building the
multimedia/aom port (with AVX2 enabled).
Marius Strobl [Sat, 9 Feb 2019 11:51:59 +0000 (11:51 +0000)]
MFC: r343753
o As illustrated by e. g. figure 7-14 of the Intel 82599 10 GbE
controller datasheet revision 3.3, in the context of Ethernet
MACs the control data describing the packet buffers typically
are named "descriptors". Each of these descriptors references
one buffer, multiple of which a packet can be composed of.
By contrast, in comments, messages and the names of structure
members, iflib(4) refers to DMA resources employed for RX and
TX buffers (rather than control data) as "desc(riptors)".
This odd naming convention of iflib(4) made reviewing r343085
and identifying wrong and missing bus_dmamap_sync(9) calls in
particular way harder than it already is. This convention may
also explain why the netmap(4) part of iflib(4) pairs the DMA
tags for control data with DMA maps of buffers and vice versa
in calls to bus_dma(9) functions.
Therefore, change iflib(4) to refer to buf(fers) when buffers
and not the usual understanding of descriptors is meant. This
change does not include corrections to the DMA resources used
in the netmap(4) parts. However, it revises error messages to
state which kind of allocation/creation failed. Specifically,
the "Unable to allocate tx_buffer (map) memory" copy & pasted
inappropriately on several occasions was replaced with proper
messages.
o Enhance some other error messages to indicate which half - RX
or TX - they apply to instead of using identical text in both
cases and generally canonicalize them.
o Correct the descriptions of iflib_{r,t}xsd_alloc() to reflect
reality; current code doesn't use {r,t}x_buffer structures.
o In iflib_queues_alloc():
- Remove redundant BUS_DMA_NOWAIT of iflib_dma_alloc() calls,
- change the M_WAITOK from malloc(9) calls into M_NOWAIT. The
return values are already checked, deferred DMA allocations
not being an option at this point, BUS_DMA_NOWAIT has to be
used anyway and prior malloc(9) calls in this function also
specify M_NOWAIT.
MFC r342908:
Reduce the size of struct ip_fw_args from 240 to 128 bytes on amd64.
And refactor the code to avoid unneeded initialization to reduce overhead
of per-packet processing.
ipfw(4) can be invoked by pfil(9) framework for each packet several times.
Each call uses on-stack variable of type struct ip_fw_args to keep the
state of ipfw(4) processing. Currently this variable has 240 bytes size
on amd64. Each time ipfw(4) does bzero() on it, and then it initializes
some fields.
glebius@ has reported that they at Netflix discovered, that initialization
of this variable produces significant overhead on packet processing.
After patching I managed to increase performance of packet processing on
simple routing with ipfw(4) firewalling to about 11% from 9.8Mpps up to
11Mpps (Xeon E5-2660 v4@ + Mellanox 100G card).
Introduced new field flags, it is used to keep track of what fields was
initialized. Some fields were moved into the anonymous union, to reduce
the size. They all are mutually exclusive. dummypar field was unused, and
therefore it is removed. The hopstore6 field type was changed from
sockaddr_in6 to a bit smaller struct ip_fw_nh6. And now the size of struct
ip_fw_args is 128 bytes.
ipfw_chk() was modified to properly handle ip_fw_args.flags instead of
rely on checking for NULL pointers.
MFC r343551:
Fix the bug introduced in r342908, that causes problems with dynamic
handling for protocols without ports numbers.
Since port numbers were uninitialized for protocols like ICMP/ICMPv6,
ipfw_chk() used some non-zero values to create dynamic states, and due
this it failed to match replies with created states.
Alexander Motin [Sat, 9 Feb 2019 02:09:29 +0000 (02:09 +0000)]
MFC r343673: Fix integer math overflow in UMA hash_alloc().
512GB of ZFS ABD ARC means abd_chunk zone of 128M 4KB items. To manage
them UMA tries to allocate 2GB hash table, which size does not fit into
the int variable, causing later allocation failure, which makes ARC shrink
back below the 512GB, not letting it to use more RAM. With this change I
easily reached >700GB ARC size on 768GB RAM machine.
Add SYNC_KLOOP_MODE option, and add support for direct mode, where application
executes the TXSYNC and RXSYNC in the context of the ioeventfd wake up callback.
Marius Strobl [Thu, 7 Feb 2019 10:30:11 +0000 (10:30 +0000)]
MFC: r343578 (partial)
- Stop iflib(4) from leaking MSI messages on detachment by calling
bus_teardown_intr(9) before pci_release_msi(9).
- Ensure that iflib(4) and associated drivers pass correct RIDs to
bus_release_resource(9) by obtaining the RIDs via rman_get_rid(9)
on the corresponding resources instead of using the RIDs initially
passed to bus_alloc_resource_any(9) as the latter function may
change those RIDs. Solely em(4) for the ioport resource (but not
others) and bnxt(4) were using the correct RIDs by caching the ones
returned by bus_alloc_resource_any(9).
- Change the logic of iflib_msix_init() around to only map the MSI-X
BAR if MSI-X is actually supported, i. e. pci_msix_count(9) returns
> 0. Otherwise the "Unable to map MSIX table " message triggers for
devices that simply don't support MSI-X and the user may think that
something is wrong while in fact everything works as expected.
- Put some (mostly redundant) debug messages emitted by iflib(4)
and em(4) during attachment under bootverbose. The non-verbose
output of em(4) seen during attachment now is close to the one
prior to the conversion to iflib(4).
- Replace various variants of spelling "MSI-X" (several in messages)
with "MSI-X" as used in the PCI specifications.
- Remove some trailing whitespace from messages emitted by iflib(4)
and change them to consistently start with uppercase.
- Remove some obsolete comments about releasing interrupts from
drivers and correct a few others.
Reviewed by: erj, Jacob Keller, shurd
Differential Revision: https://reviews.freebsd.org/D18980
Dimitry Andric [Thu, 7 Feb 2019 06:55:26 +0000 (06:55 +0000)]
MFC r343748:
Use NLDT to get number of LDTs on i386
Compiling a GENERIC kernel for i386 with clang 8.0 results in the
following warning:
/usr/src/sys/i386/i386/sys_machdep.c:542:40: error: 'sizeof ((ldt))' will return the size of the pointer, not the array itself [-Werror,-Wsizeof-pointer-div]
nldt = pldt != NULL ? pldt->ldt_len : nitems(ldt);
^~~~~~~~~~~
/usr/src/sys/sys/param.h:299:32: note: expanded from macro 'nitems'
#define nitems(x) (sizeof((x)) / sizeof((x)[0]))
~~~~~~~~~~~ ^
Indeed, 'ldt' is declared as 'union descriptor *', so nitems() is not
the right way to determine the number of LDTs. Instead, the NLDT define
from sys/x86/include/segments.h should be used.
netmap: improvements to the netmap kloop (CSB mode)
Changelist:
- Add the proper memory barriers in the kloop ring processing
functions.
- Fix memory barriers usage in the user helpers (nm_sync_kloop_appl_write,
nm_sync_kloop_appl_read).
- Fix nm_kr_txempty() helper to look at rhead rather than rcur. This
is important since the kloop can read a value of rcur which is ahead
of the value of rhead (see explanation in nm_sync_kloop_appl_write)
- Remove obsolete ptnetmap_guest_write_kring_csb() and
ptnet_guest_read_kring_csb(), and update if_ptnet(4) to use those.
- Prepare in advance the arguments for netmap_sync_kloop_[tr]x_ring(),
to make the kloop faster.
- Provide kernel and user implementation for nm_ldld_barrier() and
nm_ldst_barrier()
netmap: fix knote() argument to match the mutex state
The nm_os_selwakeup function needs to call knote() to wake up kqueue(9)
users. However, this function can be called from different code paths,
with different lock requirements.
This patch fixes the knote() call argument to match the relavant lock state.
Also, comments have been updated to reflect current code.
MFC r343697:
net80211(4): fix rate check when 'roaming' ifconfig(8) option is set to 'auto'
Do not try to clear 'basic rate' bit from roamRate; it cannot be here and,
actually, this operation clears 'MCS rate' bit instead, breaking comparison
for 11n / 11ac modes.
projects / FreeBSD / FreeBSD.git / log