tuexen [Thu, 16 May 2019 09:13:41 +0000 (09:13 +0000)]
MFC r344872:
After removing an entry from the stream scheduler list, set the pointers
to NULL, since we are checking for it in case the element gets inserted
again.
tuexen [Thu, 16 May 2019 09:12:13 +0000 (09:12 +0000)]
MFC r344742:
Allocate an assocition id and register the stcb with holding the lock.
This avoids a race where stcbs can be found, which are not completely
initialized.
tuexen [Thu, 16 May 2019 08:22:50 +0000 (08:22 +0000)]
MFC r339040:
After allocating chunks set the fields in a consistent way.
This removes two assignments for the flags field being done
twice and adds one, which was missing.
Thanks to Felix Weinrank for reporting the issue he found
by using fuzz testing of the userland stack.
tuexen [Thu, 16 May 2019 08:17:32 +0000 (08:17 +0000)]
MFC r339024:
Fix the handling of ancillary data for SCTP socket. Implement
sctp_process_cmsgs_for_init() and sctp_findassociation_cmsgs()
similar to sctp_find_cmsg() to improve consistency and avoid
the signed/unsigned issues in sctp_process_cmsgs_for_init()
and sctp_findassociation_cmsgs().
Thanks to andrew@ for reporting the problem he found using
syzcaller.
tuexen [Thu, 16 May 2019 08:15:54 +0000 (08:15 +0000)]
MFC r339022:
Increment the corresponding UDP stats counter (udps_opackets) when
sending UDP encapsulated SCTP packets.
This is consistent with the behaviour that when such packets are received,
the corresponding UDP stats counter (udps_ipackets) is incremented.
Thanks to Peter Lei for making me aware of this inconsistency.
gonzo [Thu, 16 May 2019 00:53:54 +0000 (00:53 +0000)]
MFC r345550:
Change default value of kern.bootfile to reflect reality
In most cases kernel.bootfile is populated from the information
provided by loader(8). There are certain scenarios when loader
is not available, for instance when kernel is loaded by u-boot
or some other BootROM directly. In this case the default value
"/kernel" points to invalid location and breaks some functinality,
like using installkernel on self-hosted system or dtrace's CTF
lookup. This can be fixed by setting the value manually but the
default that reflects correct location is better than default that
points to invalid one.
Current default was set around FreeBSD 1, when "/kernel" was the
actual path. Transition to /boot/kernel/kernel happened circa FreeBSD 3.
ian [Wed, 15 May 2019 17:58:08 +0000 (17:58 +0000)]
MFC r347422:
Allow dcons(4) to be unloaded when loaded as a module.
When the module is unloaded, the tty devices are destroyed. That requires
implementing the tsw_free callback to avoid a panic. This driver requires
no particular cleanup to be done from the callback, but the module itself
must remain in memory until the deferred tsw_free callbacks are invoked.
These changes implement that by incrementing a reference count variable in
the detach routine, and decrementing it in the tsw_free callback. The
MOD_UNLOAD event handler doesn't return until the count drops to zero.
ngie [Wed, 15 May 2019 07:51:30 +0000 (07:51 +0000)]
MFC r320009,r347075:
r320009 (by sbruno):
Quiesce clang warning while building lpc.
usr.sbin/lpr/lpc/lpc.c
Warning
passing 'char *[20]' to parameter of type 'const char **' discards
qualifiers in nested pointer types
[-Wincompatible-pointer-types-discards-qualifiers]
Fix:
Explicitly cast the variable "margv" to const char ** only for it's
use as a parameter to suppress the error
r347075:
Fix `clang -Wcast-qual` issues
Remove unnecessary `char*` casting for arguments passed to `cget*(3)`, and
deconst `_PATH_PRINTCAP` before passing it to `cget*` via the `printcapdb`
variable.
This unblocks ^/projects/runtime-coverage-v2 from building cleanly on
universe13a.freebsd.org. I suspect the issue was introduced through some
changes to `bsd.*.mk` inclusion on the branch, which I will continue to
investigate/isolate.
mav [Wed, 15 May 2019 01:40:40 +0000 (01:40 +0000)]
MFC r347240: Fix dataset name comparison in zfs_compare().
The code never returned match comparing two datasets (not snapshots).
As result, uu_avl_find(), called from zfs_callback(), never succeeded,
allowing to add same dataset into the list multiple times, for example:
# zfs get name pers pers pers@z pers@z
NAME PROPERTY VALUE SOURCE
pers name pers -
pers name pers -
pers@z name pers@z -
With the patch:
# zfs get name pers pers pers@z pers@z
NAME PROPERTY VALUE SOURCE
pers name pers -
pers@z name pers@z -
ganbold [Tue, 14 May 2019 03:05:06 +0000 (03:05 +0000)]
MFC r346028:
Fix URE_WDT6_SET_MODE value in the register definition.
Both linux and u-boot sources for RTL8152 driver has this value.
RTL8152 USB ethernet is used in NanoPI R1 board as second ethernet.
This fixes RTL8152 USB ethernet not detected problem after
reboot.
MFC r347241 (partial): Initial mechanism for mapping ifname <-> kld
if_tun/if_tap mappings have been removed and the vmnet mapping has been
updated to the if_tap module.
MFC r347392: ifconfig(8): Partial revert of r347241
r347241 introduced an ifname <-> kld mapping table, mostly so tun/tap/vmnet
can autoload the correct module on use. It also inadvertently made bogus
some previously valid uses of sizeof().
Revert back to ifkind on the stack for simplicity sake. This reduces the
diff from the previous version of ifmaybeload for easiser auditing.
MFC r347429: ifconfig(8): Add kld mappings for ipsec/enc
Additionally, providing mappings makes the comparison for already loaded
modules a little more strict. This should have been done at initial
introduction, but there was no real reason- however, it proves necessary for
enc which has a standard enc -> if_enc mapping but there also exists an
'enc' module that's actually CAM. The mapping lets us unambiguously
determine the correct module.
ae [Mon, 13 May 2019 08:27:52 +0000 (08:27 +0000)]
MFC r346885:
Handle HAVE_PROTO flag and print "proto" keyword for O_IP4 and O_IP6
opcodes when it is needed.
This should fix the problem, when printed by `ipfw show` rule can not
be added due to missing "proto" keyword.
dim [Sat, 11 May 2019 09:56:59 +0000 (09:56 +0000)]
MFC r347243:
Pull in r360099 from upstream llvm trunk (by Eli Friedman):
[ARM] Glue register copies to tail calls.
This generally follows what other targets do. I don't completely
understand why the special case for tail calls existed in the first
place; even when the code was committed in r105413, call lowering
didn't work in the way described in the comments.
Stack protector lowering breaks if the register copies are not glued
to a tail call: we have to insert the stack protector check before
the tail call, and we choose the location based on the assumption
that all physical register dependencies of a tail call are adjacent
to the tail call. (See FindSplitPointForStackProtector.) This is sort
of fragile, but I don't see any reason to break that assumption.
I'm guessing nobody has seen this before just because it's hard to
convince the scheduler to actually schedule the code in a way that
breaks; even without the glue, the only computation that could
actually be scheduled after the register copies is the computation of
the call address, and the scheduler usually prefers to schedule that
before the copies anyway.
This should fix several instances of "Bad machine code: Using an
undefined physical register", when compiling ports such as
multimedia/vlc, audio/alsa-lib and devel/avro-c for armv6, with
-fstack-protector-strong.
jhb [Fri, 10 May 2019 16:32:44 +0000 (16:32 +0000)]
MFC 338957:
Handle a guest executing a vm instruction by trapping and raising an
undefined instruction exception. Previously we would exit the guest,
however an unprivileged user could execute these.
erj [Fri, 10 May 2019 00:46:43 +0000 (00:46 +0000)]
ix(4): Move {mod,msf,mbx,fdir,phy,link}_task to lock protected handler
This patch introduces adapter->task_requests register responsible for recording
requests for mod_task, msf_task, mbx_task, fdir_task, phy_task and link_task
calls. Instead of enqueueing each of these tasks with GROUPTASK_ENQUEUE, new
task is created and all handlers are called from one task while holding
adapter->core_mtx lock.
SIOCGIFXMEDIA ioctl() call reads adapter->media list. The list is deleted and
rewritten in ixgbe_handle_msf() task without holding adapter->core_mtx lock.
This change is needed to maintain data coherency when sharing adapter info via
ioctl() calls.
Since handlers for abovementioned tasks will no longer act as task handlers,
but as regular functions, 'pending' parameter is removed from them.
This patch also removes ixgbe_update_link_status() call from
ixgbe_handle_link() handler. From now on, link status will be updated by
calling ixgbe_update_link_status() periodically from ixgbe_local_timer(). This
fixes problem with link flapping during changing interface state to UP.
Parameter keep_traffic is added to ixgbe_disable_intr(). This enables
ixgbe_handle_admin_task() to not disable and queue interrupts. Accordingly,
skip_traffic parameter is added to ixgbe_enable_intr() to let
ixgbe_handle_admin_task() skip enabling queues while enabling interrupts.
This patch is a port of r343621. r343621 can't be merged from current since
stable/11 contains ixgbe driver without iflib support.
Patch co-authored by Krzysztof Galazka <krzysztof.galazka@intel.com>.
jhb [Thu, 9 May 2019 22:31:47 +0000 (22:31 +0000)]
MFC 333639:
vmmdev: return EFAULT when trying to read beyond VM system memory max address
Currently, when using dd(1) to take a VM memory image, the capture never ends,
reading zeroes when it's beyond VM system memory max address.
Return EFAULT when trying to read beyond VM system memory max address.
jhb [Thu, 9 May 2019 20:30:35 +0000 (20:30 +0000)]
MFC 333235:
Allow arbitrary numbers of columns for VNC server screen resolution.
The prior code only allowed multiples of 32 for the
numbers of columns. Remove this restriction to allow
a forthcoming UEFI firmware update to allow arbitrary
x,y resolutions.
(the code for handling rows already supported non mult-32 values)
ngie [Thu, 9 May 2019 17:02:40 +0000 (17:02 +0000)]
MFC r346578:
Build libclang_rt/profile on all clang-supported architectures
There's no reason why a special case needs to be added specifically for amd64,
arm, and i386, as the code is written in machine architecture agnostic C/C++.
This will make it possible for all supporting clang architectures to produce
runtime coverage with `--coverage`.
r346602:
tun(4): Defer clearing TUN_OPEN until much later
tun destruction will not continue until TUN_OPEN is cleared. There are brief
moments in tunclose where the mutex is dropped and we've already cleared
TUN_OPEN, so tun_destroy would be able to proceed while we're in the middle
of cleaning up the tun still. tun_destroy should be blocked until these
parts (address/route purges, mostly) are complete.
r346670:
tun/tap: close race between destroy/ioctl handler
It seems that there should be a better way to handle this, but this seems to
be the more common approach and it should likely get replaced in all of the
places it happens... Basically, thread 1 is in the process of destroying the
tun/tap while thread 2 is executing one of the ioctls that requires the
tun/tap mutex and the mutex is destroyed before the ioctl handler can
acquire it.
This is only one of the races described/found in PR 233955.
r346671:
tun(4): Don't allow open of open or dying devices
Previously, a pid check was used to prevent open of the tun(4); this works,
but may not make the most sense as we don't prevent the owner process from
opening the tun device multiple times.
The potential race described near tun_pid should not be an issue: if a
tun(4) is to be handed off, its fd has to have been sent via control message
or some other mechanism that duplicates the fd to the receiving process so
that it may set the pid. Otherwise, the pid gets cleared when the original
process closes it and you have no effective handoff mechanism.
Close up another potential issue with handing a tun(4) off by not clobbering
state if the closer isn't the controller anymore. If we want some state to
be cleared, we should do that a little more surgically.
Additionally, nothing prevents a dying tun(4) from being "reopened" in the
middle of tun_destroy as soon as the mutex is unlocked, quickly leading to a
bad time. Return EBUSY if we're marked for destruction, as well, and the
consumer will need to deal with it. The associated character device will be
destroyed in short order.
r347183:
geom: fix initialization order
There's a race between the initialization of devsoftc.mtx (by devinit)
and the creation of the geom worker thread g_run_events, which calls
devctl_queue_data_f. Both of those are initialized at SI_SUB_DRIVERS
and SI_ORDER_FIRST, which means the geom worked thread can be created
before the mutex has been initialized, leading to the panic below:
wpanic: mtx_lock() of spin mutex (null) @ /usr/home/osstest/build.135317.build-amd64-freebsd/freebsd/sys/kern/subr_bus.c:620
cpuid = 3
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe003b968710
vpanic() at vpanic+0x19d/frame 0xfffffe003b968760
panic() at panic+0x43/frame 0xfffffe003b9687c0
__mtx_lock_flags() at __mtx_lock_flags+0x145/frame 0xfffffe003b968810
devctl_queue_data_f() at devctl_queue_data_f+0x6a/frame 0xfffffe003b968840
g_dev_taste() at g_dev_taste+0x463/frame 0xfffffe003b968a00
g_load_class() at g_load_class+0x1bc/frame 0xfffffe003b968a30
g_run_events() at g_run_events+0x197/frame 0xfffffe003b968a70
fork_exit() at fork_exit+0x84/frame 0xfffffe003b968ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe003b968ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 13 tid 100029 ]
Stopped at kdb_enter+0x3b: movq $0,kdb_why
Fix this by initializing geom at SI_ORDER_SECOND instead of
SI_ORDER_FIRST.
jhb [Wed, 8 May 2019 23:24:47 +0000 (23:24 +0000)]
MFC 333174: Use PCI power-mgmt to reset a device if FLR fails.
A large number of devices don't support PCIe FLR, in particular
graphics adapters. Use PCI power management to perform the
reset if FLR fails or isn't available, by cycling the device
through the D3 state.
This has been tested by a number of users with Nvidia and AMD GPUs.
mav [Wed, 8 May 2019 15:24:05 +0000 (15:24 +0000)]
MFC r346898: ip multicast debug: fix strings vs defines
Turning on multicast debug made multicast failure worse
because the strings and #define values no longer matched
up. Fix them, and make sure they stay matched-up.
mav [Wed, 8 May 2019 15:17:45 +0000 (15:17 +0000)]
MFC r346491: Polish SCSI sense data validity checks.
According to specs and common sense, all sense data reported in descriptor
format should be valid. But practice shows different, some devices return
descriptors with invalid data, resulting in error messages looking worse.
Decouple block/stream commands sense data and information field printing.
Looking on present specs, there are much more cases when those fields are
not related, and incomplete old code was not printing valid sense data and
leaving empty lines for invalid.
erj [Mon, 6 May 2019 21:31:02 +0000 (21:31 +0000)]
MFC r345312: iflib: mark isc_driver_version as constant
(Additional comment by erj: This also adds a new sysctl_add_oid macro,
SYSCTL_ADD_CONST_STRING, for displaying const strings. This commit also
includes an edit to the sysctl.9 man page for it.)
erj [Mon, 6 May 2019 21:21:15 +0000 (21:21 +0000)]
MFC r345303, 345658, and partially MFC r345305
These are:
r345303: prevent possible infinite loop in iflib_encap
r345305: expose the Rx mbuf buffer size to drivers
r345658: return ENETDOWN when the network device is down
r345305 is only partially MFC'd with no mergeinfo because it includes
changes to iflib-using drivers, and none of the drivers it changes use
iflib in stable/11. This commit just makes the function it adds available
for use with iflib-using kernel modules.
erj [Mon, 6 May 2019 18:50:08 +0000 (18:50 +0000)]
MFC r332389, r3342331, r334343, and partially r339338
This commit backports some new features from iflib in 12 back to stable/11:
r332389 - Split out flag manipulation from general context manipulation in iflib
r334231 - Add IFLIB_ADMIN_ALWAYS_RUN flag
r334343 - hold context lock across detach
r339338 - (Other updates to iflib that were included in this revision)
This commit doesn't include mergeinfo for r339338 since this only includes part
of it. I'm reminded of advice given to keep MFC-ability in mind when committing
large changes in the future.
rmacklem [Mon, 6 May 2019 03:13:22 +0000 (03:13 +0000)]
MFC: r346856
Add #ifdef INET6 around declaration of nbuf.
It was reported that without #ifdef INET6 around the declaration of "nbuf",
a build would report an unused variable. For some reason, I didn't see that
warning when I did a build, but it seems reasonable to add these #ifdef INET6's.
r347027:
libbe(3): Properly mount BEs with mountpoint=none
Instead of pretending to successfully mount them while not actually
mounting anything, we'll now actually mount them *and* claim we mounted them
successfully.
Reported by: ler
r347028:
libbe: set mountpoint=none in be_import
If we're going to set a mountpoint at all, mountpoint=none makes more sense
than mountpoint=/.
tuexen [Sun, 5 May 2019 20:08:01 +0000 (20:08 +0000)]
MFC r337708:
Use the stcb instead of the asoc in state macros.
This is not a functional change. Just a preparation for upcoming
dtrace state change provider support.
tuexen [Sun, 5 May 2019 19:20:27 +0000 (19:20 +0000)]
MFC r336937:
Send consistent SEG.WIN when using timewait codepath for TCP.
When sending TCP segments from the timewait code path, a stored
value of the last sent window is used. Use the same code for
computing this in the timewait code path as in the main code
path used in tcp_output() to avoid inconsistencies.
MFC r344148:
Fix a byte ordering issue for the advertised receiver window in ACK
segments sent in TIMEWAIT state, which I introduced in r336937.
tuexen [Sun, 5 May 2019 12:32:47 +0000 (12:32 +0000)]
MFC r336551:
Add missing dtrace probes for received UDP packets.
Fire UDP receive probes when a packet is received and there is no
endpoint consuming it. Fire the probe also if the TTL of the
received packet is smaller than the minimum required by the endpoint.
Clarify also in the man page, when the probe fires.
tuexen [Sun, 5 May 2019 12:11:58 +0000 (12:11 +0000)]
MFC r335194:
When retransmitting TCP SYN-ACK segments with the TCP timestamp option
enabled use an updated timestamp instead of reusing the one used in
the initial TCP SYN-ACK segment.
This patch ensures that an updated timestamp is used when sending the
SYN-ACK from the syncache code. It was already done if the
SYN-ACK was retransmitted from the generic code.
This makes the behaviour consistent and also conformant with
the TCP specification.
Reviewed by: jtl@, Jason Eggleston
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D15634