- Perform ifp mismatch checks (to determine if a send tag is allocated
for a different ifp than the one the packet is being output on), in
ip_output() and ip6_output(). This avoids sending packets with send
tags to ifnet drivers that don't support send tags.
Since we are now checking for ifp mismatches before invoking
if_output, we can now try to allocate a new tag before invoking
if_output sending the original packet on the new tag if allocation
succeeds.
To avoid code duplication for the fragment and unfragmented cases,
add ip_output_send() and ip6_output_send() as wrappers around
if_output and nd6_output_ifp, respectively. All of the logic for
setting send tags and dealing with send tag-related errors is done
in these wrapper functions.
For pseudo interfaces that wrap other network interfaces (vlan and
lagg), wrapper send tags are now allocated so that ip*_output see
the wrapper ifp as the ifp in the send tag. The if_transmit
routines rewrite the send tags after performing an ifp mismatch
check. If an ifp mismatch is detected, the transmit routines fail
with EAGAIN.
- To provide clearer life cycle management of send tags, especially
in the presence of vlan and lagg wrapper tags, add a reference count
to send tags managed via m_snd_tag_ref() and m_snd_tag_rele().
Provide a helper function (m_snd_tag_init()) for use by drivers
supporting send tags. m_snd_tag_init() takes care of the if_ref
on the ifp meaning that code alloating send tags via if_snd_tag_alloc
no longer has to manage that manually. Similarly, m_snd_tag_rele
drops the refcount on the ifp after invoking if_snd_tag_free when
the last reference to a send tag is dropped.
This also closes use after free races if there are pending packets in
driver tx rings after the socket is closed (e.g. from tcpdrop).
In order for m_free to work reliably, add a new CSUM_SND_TAG flag in
csum_flags to indicate 'snd_tag' is set (rather than 'rcvif').
Drivers now also check this flag instead of checking snd_tag against
NULL. This avoids false positive matches when a forwarded packet
has a non-NULL rcvif that was treated as a send tag.
- cxgbe was relying on snd_tag_free being called when the inp was
detached so that it could kick the firmware to flush any pending
work on the flow. This is because the driver doesn't require ACK
messages from the firmware for every request, but instead does a
kind of manual interrupt coalescing by only setting a flag to
request a completion on a subset of requests. If all of the
in-flight requests don't have the flag when the tag is detached from
the inp, the flow might never return the credits. The current
snd_tag_free command issues a flush command to force the credits to
return. However, the credit return is what also frees the mbufs,
and since those mbufs now hold references on the tag, this meant
that snd_tag_free would never be called.
To fix, explicitly drop the mbuf's reference on the snd tag when the
mbuf is queued in the firmware work queue. This means that once the
inp's reference on the tag goes away and all in-flight mbufs have
been queued to the firmware, tag's refcount will drop to zero and
snd_tag_free will kick in and send the flush request. Note that we
need to avoid doing this in the middle of ethofld_tx(), so the
driver grabs a temporary reference on the tag around that loop to
defer the free to the end of the function in case it sends the last
mbuf to the queue after the inp has dropped its reference on the
tag.
- mlx5 preallocates send tags and was using the ifp pointer even when
the send tag wasn't in use. Explicitly use the ifp from other data
structures instead.
- Sprinkle some assertions in various places to assert that received
packets don't have a send tag, and that other places that overwrite
rcvif (e.g. 802.11 transmit) don't clobber a send tag pointer.
Reviewed by: gallatin, hselasky, rgrimes, ae
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D20117
The point of r345008 was to reset the Command Reference Number (CRN)
in some situations where a device stayed in the topology, but had
changed somehow.
This can include moving from a switch connection to a direct
connection or vice versa, or a device that temporarily goes away
and comes back. (e.g. moving to a different switch port)
There were a couple of bugs in that change:
- We were reporting that a device had not changed whenever the
Establish Image Pair bit was not set. That is not quite correct.
Instead, if the Establish Image Pair bit stays the same (set or
not), the device hasn't changed in that way.
- We weren't setting PRLI Word0 in the port database when a new
device arrived, so comparisons with the old value for the
Establish Image Pair bit weren't really possible. So, make sure
PRLI Word0 is set in the port database for new devices.
- We were resetting the CRN whenever the Establish Image Pair bit
was set for a device, even when the device had stayed the same
and the value of the bit hadn't changed. Now, only reset the
CRN for devices that have changed, not devices that sayed the
same.
The result of all of this was that if we had a single FC device on
an FC port and it went away and came back, we would wind up
correctly resetting the CRN.
But, if we had multiple devices connected via a switch, and there
was any change in one or more of those devices, all of the devices
that stayed the same would also have their CRN values reset.
The result, from a user standpoint, is that the tape drives, etc.
would all start to time out commands and the initiator would send
aborts.
sys/dev/isp/isp.c:
In isp_pdb_add_update(), look at whether the Establish
Image Pair bit has changed as part of the check to
determine whether a device is still the same. This was
causing erroneous change notifications. Also, when
creating a new port database entry, initialize the
PRLI Word 0 values.
sys/dev/isp/isp_freebsd.c:
In isp_async(), in the changed/stayed case, instead of
looking at the Establish Image Pair bit to determine
whether to reset the CRN, look at the command value.
(Changed vs. Stayed.) Only reset the CRN for devices
that have changed.
Sponsored by: Spectra Logic
MFC after: 3 days
That made, for example, gpioc -l output quite hard to read and parse.
Also, fix formatting of a nearby statement with too long lines.
MFC after: 2 weeks
Pull the responsibility for zeroing events, which is general to any
conceivable implementation of a random device algorithm, out of the
algorithm-specific Fortuna code and into the callers. Most callers
indirect through random_fortuna_process_event(), so add the logic there.
Most callers already explicitly bzeroed the events they provided, so the
logic in Fortuna was mostly redundant.
Add one missing bzero in randomdev_accumulate(). Also, remove a redundant
bzero in the same function -- randomdev_hash_finish() is obliged to bzero
the hash state.
Reviewed by: delphij
Approved by: secteam(delphij)
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D20318
This takes the SPCR code currently in uart_cpu_arm64.c, moves it into
a new uart_cpu_acpi.c (with some associated refactoring), and uses it
from both arm64 and x86.
An SPCR serial port address AccessWidth field value of 0 ("reserved")
is now treated as 1 ("byte access") in order to work around a buggy
SPCR table on Amazon EC2 i3.metal instances.
Reviewed by: manu, Greg V
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D20357
Pnpinfo is bus-specific and requires the bus name. The FDTCOMPAT_PNP_INFO()
macro makes it easier to define new FDT-based pnpinfo for busses other than
simplebus.
Differential Revision: https://reviews.freebsd.org/D20382
Many i2c slave drivers are in modules that can be unloaded. If they detach
while IO is in progress the bus would be hung forever. Conversely,
lower-layer drivers (iicbus and the hardware driver) also live in modules
and other kinds of bad things happen if they get detached while IO is in
progress. Because device_busy() propagates up to parents, marking the slave
device busy while it owns the bus solves both kinds of problems that come
with detaching i2c devices while IO is in progress.
It should be safer to flush controller and disk caches on the shutdown.
And to gracefully shut down the controller as well.
It seems that the Linux driver has been doing that for a long time.
Discussed with: scottl
Reviewed by: imp, Sumit Saxena <sumit.saxena@broadcom.com>
(both earlier version)
MFC after: 3 weeks
Sponsored by: Panzura
Differential Revision: https://reviews.freebsd.org/D19817
hint.gpioled.%d.state determines the initial state of the LED when the
driver takes control over it:
0 - the LED is off
1 - the LED is on
-1 - the LED is kept as it was
While here, add a module version declaration.
MFC after: 2 weks
This is a curious small widget for which I might write a driver.
It is bridge between USB HID interface and I2C interface plus some
GPIO pins.
MFC after: 2 weeks
This fixes a regress introduced in r339754.
After that change the code required that there is a HPET device
in the ACPI namespace.
The problem has been noticed on an PC Engines apu2 system.
While here, fix a small formatting issue.
has been in the PR system for 5 months and then on reviews for another 5.
Nobody came with any cases where it fails, while many people cried for
it to be commited & merged.
PR: 209468
Submitted by: Prasad B M <prasad.munirathnam@microsemi.com>
Reported by: Steven Peterson <scp@mainstream.net>
Approved by: scottl
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D18408
Previously, if a system had multiple batteries, the remaining life
percentage was calculated as the average of each battery's percent
remaining. This results in rather incorrect values when you consider the
case of the Thinkpad X270 that has a small 3 cell internally battery, and
a hot-swappable 9 cell battery that is used first. Battery 0 is at 100%,
but battery 1 is at 10%, you do not infact have 55% of your capacity
remaining.
The new method calculates the percentage based on remaining capacity
out of total capacity, giving a much more accurate reading.
PR: 229818
Submitted by: Keegan Drake H.P. <kd-dev@pm.me>
MFC after: 2 weeks
Sponsored by: Klara Systems
Event: Waterloo Hackathon 2019
Similar to r348026, exhaustive search for uses of CTRn() and cross reference
ktr.h includes. Where it was obvious that an OS compat header of some kind
included ktr.h indirectly, .c files were left alone. Some of these files
clearly got ktr.h via header pollution in some scenarios, or tinderbox would
not be passing prior to this revision, but go ahead and explicitly include it
in files using it anyway.
Like r348026, these CUs did not show up in tinderbox as missing the include.
Reported by: peterj (arm64/mp_machdep.c)
X-MFC-With: r347984
Sponsored by: Dell EMC Isilon
Using the latest NVIDIA driver, upon resuming from suspend with X
running the display remained blank. Additionally OpenGL applications
that were running triggered a number of error messages from the NVIDIA
driver.
This occurred because the vt efifb back-end did not signal the X server
to release the display before suspending (or to re-acquire it after
resuming). The NVIDIA driver includes code for smoothly shutting down
and re-initializing the GPU, which was not getting called.
Since the NVIDIA driver doesn't currently support framebuffer devices
and vt is forced to fall back to the efifb back-end, add vd_suspend and
vd_resume members to connect the suspend/resume path. This ensures the
X server is properly able to re-initialize the display.
PR: 237050
Submitted by: Erik Kurzinger <ekurzinger@nvidia.com>
Reviewed by: markj
MFC after: 2 weeks
Event: Waterloo Hackathon 2019
This was enumerated with exhaustive search for sys/eventhandler.h includes,
cross-referenced against EVENTHANDLER_* usage with the comm(1) utility. Manual
checking was performed to avoid redundant includes in some drivers where a
common os_bsd.h (for example) included sys/eventhandler.h indirectly, but it is
possible some of these are redundant with driver-specific headers in ways I
didn't notice.
(These CUs did not show up as missing eventhandler.h in tinderbox.)
X-MFC-With: r347984
These are obviously missing from the .c files, but don't show up in any
tinderbox configuration (due to latent header pollution of some kind). It
seems some configurations don't have this pollution, and the includes are
obviously missing, so go ahead and add them.
Reported by: Peter Jeremy <peter AT rulingia.com>
X-MFC-With: r347984
all-ones then carving out blocks of zeroes where specified values go, init
it to all-zeroes, put in ones where values need to be masked, then use it
as value &= ~sc_led_modes_mask. In addition to being more idiomatic, this
means everything related to FDT data is initialized to zero along with the
rest of the softc, and that allows removing some #ifdef FDT sections and
wrapping the whole muge_set_leds() function in a single ifdef block.
This also deletes the early-out from muge_set_leds() when an eeprom exists.
Even if there is an eeprom with led config in it, the fdt data (if present)
should override that, because the user is in control of the fdt data.
OTP registers (because the user is in control of the fdt data). Remove the
early returns from the code that tries to find a good mac address, so that
the execution always flows through the routine to get an address from FDT
data last, when on FDT-enabled systems.
the device instance, and to get the MAC address for the device instance.
The ad-hoc code this replaces could find the wrong instance if multiple
devices were present.
Also use LED mode settings from the FDT to set the PHY.
From v3 of the patch submitted in the PR.
I moved the sc_led_modes and sc_led_modes_mask default setting outside
of the #ifdef FDT case.
PR: 237325
Submitted by: Ralf <iz-rpi03@hs-karlsruhe.de>
Reviewed by: ian
MFC after: 2 weeks
MFC with: r348001
Event: Waterloo Hackathon 2019
Differential Revision: https://reviews.freebsd.org/D20325
Also apply some style(9) and remove the message about EEPROM configuration
(if there's an EEPROM the hardware handles LED configuration itself).
PR: 237325
Reviewed by: ian
MFC after: 2 weeks
Submitted by: Ralf <iz-rpi03@hs-karlsruhe.de>
Summary:
PowerPC kernels are fully position independent, just like kernel modules.
The same fixups that are done for modules therefore need to be done to the
kernel, else symbol resolution in, e.g., DTrace, cannot resolve the kernel
symbols, so only addresses in the kernel are printed, while kernel module
symbols are printed.
Test Plan:
Run lockstat on powerpc64. Note symbols are resolved for kernel and
modules.
Reviewed By: markj
Differential Revision: https://reviews.freebsd.org/D20316
This allows replacing "sys/eventfilter.h" includes with "sys/_eventfilter.h"
in other header files (e.g., sys/{bus,conf,cpu}.h) and reduces header
pollution substantially.
EVENTHANDLER_DECLARE and EVENTHANDLER_LIST_DECLAREs were moved out of .c
files into appropriate headers (e.g., sys/proc.h, powernv/opal.h).
As a side effect of reduced header pollution, many .c files and headers no
longer contain needed definitions. The remainder of the patch addresses
adding appropriate includes to fix those files.
LOCK_DEBUG and LOCK_FILE_LINE_ARG are moved to sys/_lock.h, as required by
sys/mutex.h since r326106 (but silently protected by header pollution prior
to this change).
No functional change (intended). Of course, any out of tree modules that
relied on header pollution for sys/eventhandler.h, sys/lock.h, or
sys/mutex.h inclusion need to be fixed. __FreeBSD_version has been bumped.
FDT data is sometimes used to configure usb devices which are hardwired into
an embedded system. Because the devices are instantiated by the usb
enumeration process rather than by ofwbus iterating through the fdt data, it
is somewhat difficult for a usb driver to locate fdt data that belongs to
it. In the past, various ad-hoc methods have been used, which can lead to
errors such applying configuration that should apply only to a hardwired
device onto a similar device attached by the user at runtime. For example,
if the user adds an ethernet device that uses the same driver as the builtin
ethernet, both devices might end up with the same MAC address.
These changes add a new usb_fdt_get_node() helper function that a driver can
use to locate FDT data that belongs to a single unique instance of the
device. This function locates the proper FDT data using the mechanism
detailed in the standard "usb-device.txt" binding document [1].
There is also a new usb_fdt_get_mac_addr() function, used to retrieve the
mac address for a given device instance from the fdt data. It uses
usb_fdt_get_node() to locate the right node in the FDT data, and attempts to
obtain the mac-address or local-mac-address property (in that order, the
same as linux does it).
The existing if_smsc driver is modified to use the new functions, both as an
example and for testing the new functions. Rpi and rpi2 boards use this
driver and provide the mac address via the fdt data.
[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/usb-device.txt
Differential Revision: https://reviews.freebsd.org/D20262
We need to make the find_veriexec_file() function available publicly, so
rename it to mac_veriexec_metadata_find_file_info() and make it non-static.
Bump the version of the veriexec device interface so user space will know
the labelized version of fingerprint loading is available.
Approved by: sjg
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D20295
priv. This allows for MAC/veriexec to prevent apps that are not "trusted"
from using these commands.
Obtained from: Juniper Networks, Inc.
MFC after: 1 week
When activating a resource do not compare the resource id to the adress.
Treat IO region as MEMORY region too.
Submitted by: Tuan Phan <tphan@amperecomputing.com> (Original Version)
Sponsored by: Ampere Computing, LLC
Differential Revision: https://reviews.freebsd.org/D20214
We cannot know the bus end number before parsing the MCFG table
so don't set the bus_end before that. If the MCFG table doesn't
exist we will set the configuration base address based on the _CBA
value and set the bus_end to the maximal number allowed by PCI.
Sponsored by: Ampere Computing, LLC
Differential Revision: https://reviews.freebsd.org/D20213
