John Baldwin [Sat, 12 Dec 2020 16:55:23 +0000 (16:55 +0000)]
MFC 366854: Re-enable receive flow control for TOE TLS sockets.
Flow control was disabled during initial TOE TLS development to
workaround a hang (and to match the Linux TOE TLS support for T6).
The rest of the TOE TLS code maintained credits as if flow control was
enabled which was inherited from before the workaround was added with
the exception that the receive window was allowed to go negative.
This negative receive window handling (rcv_over) was because I hadn't
realized the full implications of disabling flow control.
To clean this up, re-enable flow control on TOE TLS sockets. The
existing TPF_FORCE_CREDITS workaround is sufficient for the original
hang. Now that flow control is enabled, remove the rcv_over
workaround and instead assert that the receive window never goes
negative matching plain TCP TOE sockets.
Kristof Provost [Fri, 11 Dec 2020 15:39:22 +0000 (15:39 +0000)]
MFC r368020, r368025:
if: Protect V_ifnet in vnet_if_return()
When we terminate a vnet (i.e. jail) we move interfaces back to their home
vnet. We need to protect our access to the V_ifnet CK_LIST.
We could enter NET_EPOCH, but if_detach_internal() (called from if_vmove())
waits for net epoch callback completion. That's not possible from NET_EPOCH.
Instead, we take the IFNET_WLOCK, build a list of the interfaces that need to
move and, once we've released the lock, move them back to their home vnet.
We cannot hold the IFNET_WLOCK() during if_vmove(), because that results in a
LOR between ifnet_sx, in_multi_sx and iflib ctx lock.
Separate out moving the ifp into or out of V_ifnet, so we can hold the lock as
we do the list manipulation, but do not hold it as we if_vmove().
if: Fix non-VIMAGE build
if_link_ifnet() and if_unlink_ifnet() are needed even when VIMAGE is not
enabled.
Kristof Provost [Fri, 11 Dec 2020 14:11:41 +0000 (14:11 +0000)]
MFC r368015:
if: Remove ifnet_rwlock
It no longer serves any purpose, as evidenced by the fact that we never take it
without ifnet_sxlock.
This differs slightly from r368015 in that we keep the ifnet_rwlock instance
(but no longer take the lock) in case there are external users who still take
the lock.
John Baldwin [Thu, 10 Dec 2020 22:26:51 +0000 (22:26 +0000)]
MFC 366584: Don't invoke semunload() if seminit() fails during MOD_LOAD.
The module handler code invokes a MOD_UNLOAD event immediately if
MOD_LOAD fails. The result was that if seminit() failed, semunload()
was invoked twice. semunload() is not idempotent however and would
try to remove it's process_exit eventhandler twice resulting in a
panic.
John Baldwin [Thu, 10 Dec 2020 21:12:25 +0000 (21:12 +0000)]
MFC 366897: Use a template assembly file to generate the embedded MFS.
This uses the .incbin directive to pull in the MFS image contents.
Using assembly directly ensures that symbols can be defined with the
name and properties (such as .size) desired without having to rename
symbols, etc. via a second objcopy invocation. Since it is compiled
by the C compiler driver, it also avoids the need for all of the
EMBEDFS* make variables.
Fix bug in ifconfig preventing proper VLAN creation.
Detection of VLAN interface type must happen before detection of
interface type by prefix. Else the following sequence of commands will
try to create a LAGG interface instead of a VLAN interface, which
accidentially worked previously, because the data pointed to by the
ifr_data pointer was not parsed by the VLAN create ioctl(2). This is a
regression after r368229, because the VLAN creation now parses the
ifr_data field.
How to reproduce:
# ifconfig lagg0 create
# ifconfig lagg0.256 create
This is a direct commit, until r366917, stacked VLANs has been MFC'ed.
Alan Somers [Wed, 9 Dec 2020 20:06:37 +0000 (20:06 +0000)]
ZFS: fix spurious EBUSY after zfs receive to an existing dataset
If you do a "zfs send -p <src> | zfs receive -F <dst>" to an existing but
empty dataset, the receive will complete successfully but spuriously fail
with exit status 1 and the message "cannot mount 'pool/dataset': mountpoint
or dataset is busy".
The root cause is a merge error made in r344569 and MFCed in r345578, which
merged changes a10d50f999 and e63ac16d25 from ZoL. The merge:
* failed to flip a == to an != like the upstream change did, and
* Left out one chunk
Direct commit to stable/12 because head has moved on to OpenZFS.
Ed Maste [Wed, 9 Dec 2020 00:28:27 +0000 (00:28 +0000)]
MFC r368397: Add deprecation notice to mn(4)
Sync serial (T1/E1) interfaces are largely irrelevant today and phk
confirms this driver is unnecessary in review D23928.
This leaves ce(4) and cp(4) in the tree. They're likely not relevant
either, but glebius contacted the manufacturer and those devices are
still available for purchase. At glebius' suggestion leave them in
the tree as long as they do not impose a maintenace burden.
Rick Macklem [Tue, 8 Dec 2020 22:37:30 +0000 (22:37 +0000)]
MFC: r368268
Improve man page for AmazonEFS mounts.
PR#250770 was actually just a misunderstanding of what
NFS mount options are needed for AmazonEFS mounts.
This patch attempts to clarify the manpage to clarify this.
Yuri Pankov [Tue, 8 Dec 2020 07:47:29 +0000 (07:47 +0000)]
MFC r340354:
Use blank am_pm and t_fmt_ampm for de_AT and de_DE locales as apparently
they use 24-hour clock notation. The visible change is that w(1) now
uses 24-hour clock format as it checks for t_fmt_ampm presence.
PR: 231771
Submitted by: Christoph Schönweiler <public2016@hauptsignal.at>
Eugene Grosbein [Sun, 6 Dec 2020 16:22:26 +0000 (16:22 +0000)]
MFC r364027 by arichardson: Fix linker error in libuutil with recent LLVM
This also fixes nanobsd-style build (cross-compiling).
Original commit log:
Not marking the function as static can result in a linker error:
undefined reference to __assfail [--no-allow-shlib-undefined]
I noticed this error after updating our CHERI LLVM to the latest upstream
LLVM HEAD revision.
This change effectively reverts r329984 and marks dmu_buf_init_user as
static (which keeps the GCC build happy).
Gordon Bergling [Sun, 6 Dec 2020 07:55:12 +0000 (07:55 +0000)]
MFC r366662 (by imp), r367897
r366662: devmatch: First appeared in 12.0
Document that devmatch first appeared in FreeBSD 12.0. Also can't -> can not. But
it doesn't help the sentence much.
r367897: devmatch(8): Fix section ordering
- sections out of conventional order: Sh HISTORY
Gordon Bergling [Sun, 6 Dec 2020 07:50:15 +0000 (07:50 +0000)]
MFC r366572: Fix a few mandoc issues
- no blank before trailing delimiter
- whitespace at end of input line
- sections out of conventional order
- normalizing date format
- AUTHORS section without An macro
Unlike HEAD, stable/12 still uses the check for vfs_susp_clean != NULL
as indicator that fs supports suspension. Satisfy the requirement by
providing dummy msdosfs_susp_clean method implementation.
r367743:
_umtx_op: fix a compat32 bug in UMTX_OP_NWAKE_PRIVATE
Specifically, if we're waking up some value n > BATCH_SIZE, then the
copyin(9) is wrong on the second iteration due to upp being the wrong type.
upp is currently a uint32_t**, so upp + pos advances it by twice as many
elements as it should (host pointer size vs. compat32 pointer size).
Fix it by just making upp a uint32_t*; it's still technically a double
pointer, but the distinction doesn't matter all that much here since we're
just doing arithmetic on it.
Add a test case that demonstrates the problem, placed with the libthr tests
since one messing with _umtx_op should be running these tests. Running under
compat32, the new test case will hang as threads after the first 128 get
missed in the wake. it's not immediately clear how to hit it in practice,
since pthread_cond_broadcast() uses a smaller (sleepq batch?) size observed
to be around ~50 -- I did not spend much time digging into it.
The uintptr_t change makes no functional difference, but i've tossed it in
since it's more accurate (semantically).
Kyle Evans [Fri, 4 Dec 2020 02:28:45 +0000 (02:28 +0000)]
MFC r368009-r368010: kern: cpuset: minor improvements
r368009:
kern: cpuset: allow cpuset_create() to take an allocated *setp
Currently, it must always allocate a new set to be used for passing to
_cpuset_create, but it doesn't have to. This is purely kern_cpuset.c
internal and it's sparsely used, so just change it to use *setp if it's
not-NULL and modify the two consumers to pass in the address of a NULL
cpuset.
This paves the way for consumers that want the unr allocation without the
possibility of sleeping as long as they've done their due diligence to
ensure that the mask will properly apply atop the supplied parent
(i.e. avoiding the free_unr() in the last failure path).
r368010:
kern: cpuset: rename _cpuset_create() to cpuset_init()
cpuset_init() is better descriptor for what the function actually does. The
name was previously taken by a sysinit that setup cpuset_zero's mask
from all_cpus, it was removed in r331698 before stable/12 branched.
A comment referencing the removed sysinit has now also been removed, since
the setup previously done was moved into cpuset_thread0().
Kyle Evans [Fri, 4 Dec 2020 02:20:41 +0000 (02:20 +0000)]
MFC r368006: kern: never restart syscalls calling closefp(), e.g. close(2)
All paths leading into closefp() will either replace or remove the fd from
the filedesc table, and closefp() will call fo_close methods that can and do
currently sleep without regard for the possibility of an ERESTART. This can
be dangerous in multithreaded applications as another thread could have
opened another file in its place that is subsequently operated on upon
restart.
The following are seemingly the only ones that will pass back ERESTART
in-tree:
- sockets (SO_LINGER)
- fusefs
- nfsclient
Kyle Evans [Fri, 4 Dec 2020 02:19:45 +0000 (02:19 +0000)]
MFC r367944: cpuset_setproc: use the appropriate parent for new anon. sets
As far as I can tell, this has been the case since initially committed in
2008. cpuset_setproc is the executor of cpuset reassignment; note this
excerpt from the description:
* 1) Set is non-null. This reparents all anonymous sets to the provided
* set and replaces all non-anonymous td_cpusets with the provided set.
However, reviewing cpuset_setproc_setthread() for some jail related work
unearthed the error: if tdset was not anonymous, we were replacing it with
`set`. If it was anonymous, then we'd rebase it onto `set` (i.e. copy the
thread's mask over and AND it with `set`) but give the new anonymous set
the original tdset as the parent (i.e. the base of the set we're supposed to
be leaving behind).
The primary visible consequences were that:
1.) cpuset_getid() following such assignment returns the wrong result, the
setid that we left behind rather than the one we joined.
2.) When a process attached to the jail, the base set of any anonymous
threads was a set outside of the jail.
This was initially bundled in D27298, but it's a minor fix that's fairly
easy to verify the correctness of.
A test is included in D27307 ("badparent"), which demonstrates the issue
with, effectively:
osetid = cpuset_getid()
newsetid = cpuset()
cpuset_setaffinity(thread)
cpuset_setid(osetid)
cpuset_getid(thread) -> observe that it matches newsetid instead of osetid.
Kyle Evans [Fri, 4 Dec 2020 02:18:40 +0000 (02:18 +0000)]
MFC r368116: kern: cpuset: drop the lock to allocate domainsets
Restructure the loop a little bit to make it a little more clear how it
really operates: we never allocate any domains at the beginning of the first
iteration, and it will run until we've satisfied the amount we need or we
encounter an error.
The lock is now taken outside of the loop to make stuff inside the loop
easier to evaluate w.r.t. locking.
This fixes it to not try and allocate any domains for the freelist under the
spinlock, which would have happened before if we needed any new domains.
John Baldwin [Fri, 4 Dec 2020 01:09:51 +0000 (01:09 +0000)]
MFC 366844: Mark asymmetric cryptography via OCF deprecated for 14.0.
Only one MIPS-specific driver implements support for one of the
asymmetric operations. There are no in-kernel users besides
/dev/crypto. The only known user of the /dev/crypto interface was the
engine in OpenSSL releases before 1.1.0. 1.1.0 includes a rewritten
engine that does not use the asymmetric operations due to lack of
documentation.
Yuri Pankov [Wed, 2 Dec 2020 22:44:40 +0000 (22:44 +0000)]
MFC r353130:
Mark "private use area" characters as printable.
At least some of the characters in E000-F8FF range are used by Powerline
fonts, and having no attributes for these ranges in UnicodeData.txt
other than "Other, Private Use" it should be safe to mark all of them as
printable. Some actually were before r340491, so this fixes the
regression introduced there as well.
Dimitry Andric [Wed, 2 Dec 2020 21:44:41 +0000 (21:44 +0000)]
MFC r367809:
When elftoolchain's objcopy (or strip) is rewriting a file in-place,
make it create the temporary file in the same directory as the source
file by default, instead of always using $TMPDIR or /tmp. If creating
that file fails because the directory is not writable, also fallback to
$TMPDIR or /tmp.
This has also been submitted upstream as:
https://sourceforge.net/p/elftoolchain/tickets/597/
Dimitry Andric [Wed, 2 Dec 2020 21:39:54 +0000 (21:39 +0000)]
MFC r367304:
Add WITH_LLVM_CXXFILT option to install llvm-cxxfilt as c++filt
Since elftoolchain's cxxfilt is rather far behind on features, and we
ran into several bugs, add an option to use llvm-cxxfilt as an drop-in
replacement.
It supports the same options as elftoolchain cxxfilt, though it doesn't
have support for old ARM (C++ Annotated Reference Manual, not the CPU)
and GNU v2 manglings. But these are irrelevant in 2020.
Note: as we already compile the required libraries as part of libllvm,
this will not add any significant build time either.
Alan Somers [Tue, 1 Dec 2020 15:15:18 +0000 (15:15 +0000)]
Fix error merging r354116 from OpenZFS
When we merged 4c0883fb4af0d5565459099b98fcf90ecbfa1ca1 from OpenZFS (svn
r354116), there were some merge conflicts. One of those was resolved
incorrectly, causing "zfs receive" to fail to delete snapshots that a "zfs
send -R" stream has deleted.
This change corrects that merge conflict, and also reduces some harmless
diffs vis-a-vis OpenZFS that were also introduced by the same revision.
Direct commit to stable/12 because head has moved on to OpenZFS.
MFC r366933 and r366934:
Add support for IP over infiniband, IPoIB, to lagg(4). Currently only
the failover protocol is supported due to limitations in the IPoIB
architecture. Refer to the lagg(4) manual page for how to configure
and use this new feature. A new network interface type,
IFT_INFINIBANDLAG, has been added, similar to the existing
IFT_IEEE8023ADLAG .
ifconfig(8) has been updated to accept a new laggtype argument when
creating lagg(4) network interfaces. This new argument is used to
distinguish between ethernet and infiniband type of lagg(4) network
interface. The laggtype argument is optional and defaults to
ethernet. The lagg(4) command line syntax is backwards compatible.
MFC r366930, r366936, r366993 and r366994:
Factor out generic IP over infiniband, IPoIB, definitions and code
into net/if_infiniband.c and net/infiniband.h . No functional change
intended.
MFC r367719:
Make mlx5_cmd_exec_cb() a safe API in mlx5core.
APIs that have deferred callbacks should have some kind of cleanup
function that callers can use to fence the callbacks. Otherwise things
like module unloading can lead to dangling function pointers, or worse.
The IB MR code is the only place that calls this function and had a
really poor attempt at creating this fence. Provide a good version in
the core code as future patches will add more places that need this
fence.
Make completion event path mostly lockless using EPOCH(9).
Implement a mechanism using EPOCH(9) which allows us to make
the callback path for completion events mostly lockless.
Simplify draining callback events using epoch_wait().
While at it make sure all receive completion callbacks are
covered by the network EPOCH(9), because this is required
when calling if_input() and ether_input() after r357012.
MFC r367716:
Use mlx5core to create/destroy all Dynamically Connected Targets, DCTs.
To prevent a hardware memory leak when a DEVX DCT object is destroyed
without calling drain DCT before, (e.g. under cleanup flow), need to
manage its creation and destruction via mlx5 core.
MFC r367555:
Include GID type when deleting GIDs from HW table under RoCE in mlx4ib.
Refer to the Linux commit mentioned below for a more detailed description.
- Sort options alphabetically
- Add missing arguments (e.g., "list" to -a)
- Adjust the width of Bl
Clean up the synopsis section & fix mandoc warnings
The synopsis section had two very similar entries. The flags documented by
the first one were a strict subset of the second one. Let's just keep only
the second entry for simplicity.
Let's have two entries in the synopsis:
- chpass now lists options which can be used for non-NIS-specific
functionalities.
- ypchpass additionally lists the NIS-specific flags.
Technically, it is an artificial distinction, as chpass and ypchpass behave
identically. Nevertheless, it might help navigating the synopsis section.
Michael Tuexen [Mon, 30 Nov 2020 09:45:44 +0000 (09:45 +0000)]
MFC r367530:
RFC 7323 specifies that:
* TCP segments without timestamps should be dropped when support for
the timestamp option has been negotiated.
* TCP segments with timestamps should be processed normally if support
for the timestamp option has not been negotiated.
This patch enforces the above.
Manually resolved merge conflicts.
MFC 367891:
Fix an issue I introuced in r367530: tcp_twcheck() can be called
with to == NULL for SYN segments. So don't assume tp != NULL.
Thanks to jhb@ for reporting and suggesting a fix.
MFC r367946:
Fix two occurences of a typo in a comment introduced in r367530.
Thanks to lstewart@ for reporting them.
Michael Tuexen [Mon, 30 Nov 2020 09:21:01 +0000 (09:21 +0000)]
MFC r367464:
The ioctl() calls using FIONREAD, FIONWRITE, FIONSPACE, and SIOCATMARK
access the socket send or receive buffer. This is not possible for
listening sockets since r319722.
Because send()/recv() calls fail on listening sockets, fail also ioctl()
indicating EINVAL.
PR: 250366
Reported by: Yong-Hao Zou
Reviewed by: glebius, rscheff
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D26897