glebius [Mon, 18 Feb 2019 21:27:13 +0000 (21:27 +0000)]
With r343051 UMA switched from atomic counts to counter(9) and now kernel
reports snap counts of how much a zone alloced and how much it freed. It
may happen that snap values doesn't match, e.g alloced - freed < 0.
Workaround that in memstat library.
dim [Mon, 18 Feb 2019 19:07:15 +0000 (19:07 +0000)]
Add one additional file to libllvmminimal, since in some cases (e.g.
upgrading from stable/10 to stable/11) symbols from it are needed to
link llvm-tblgen and clang-tblgen.
ian [Mon, 18 Feb 2019 17:12:30 +0000 (17:12 +0000)]
Allow the u-boot loaderdev env var to be formatted in the "usual" loader(8)
way: device<unit>[s|p]<slice><partition>. E.g., disk0s2a or disk3p12.
The code first tries to parse the variable in this format using the
standard disk_parsedev(). If that fails, it falls back to parsing the
legacy format that has been supported by ubldr for years.
In addition to 'disk', all the valid uboot device names can also be used:
mmc, sata, usb, ide, scsi. The 'disk' device serves as an alias for all
those types and will match the Nth storage-type device found (where N is
the unit number).
vmaffione [Mon, 18 Feb 2019 14:21:41 +0000 (14:21 +0000)]
netmap: don't schedule kqueue notify task when kqueue is not used
This change adds a counter (kqueue_users) to keep track of how many
kqueue users are referencing a given struct nm_selinfo.
In this way, nm_os_selwakeup() can schedule the kevent notification
task only when kqueue is actually being used.
This is important to avoid wasting CPU in the common case where
kqueue is not used.
ian [Mon, 18 Feb 2019 04:44:52 +0000 (04:44 +0000)]
Make uboot_devdesc properly alias disk_devdesc, so that parsing the u-boot
loaderdev variable works correctly.
The uboot_devdesc struct is variously cast back and forth between
uboot_devdesc and disk_devdesc as pointers are handed off through various
opaque interfaces. uboot_devdesc attempted to mimic the layout of
disk_devdesc by having a devdesc struct, followed by a union of some
device-specific stuff that included a struct that contains the same fields
as a disk_devdesc. However, one of those fields inside the struct is 64-bit
which causes the entire union to be 64-bit aligned -- 32 bits of padding
is added between the struct devdesc and the union, so the whole mess ends
up NOT properly mimicking a disk_devdesc after all. (In disk_devdesc there
is also 32 bits of padding, but it shows up immediately before the d_offset
field, rather than before the whole collection of d_* fields.)
This fixes the problem by using an anonymous union to overlay the devdesc
field uboot network devices need with the disk_devdesc that uboot storage
devices need. This is a different solution than the one contributed with
the PR (so if anything goes wrong, the blame goes to me), but 95% of the
credit for this fix goes to Pawel Worach and Manuel Stuhn who analyzed the
problem and proposed a fix.
emaste [Mon, 18 Feb 2019 03:49:16 +0000 (03:49 +0000)]
kdump: expand comment on reasons for CAPFAIL_LOOKUP
Comment for CAPFAIL_LOOKUP refered only to paths containing ".." but
it is returned for other restricted VFS lookup cases, such as absolute
paths or openat(AT_FDCWD, ...).
kevans [Mon, 18 Feb 2019 02:59:47 +0000 (02:59 +0000)]
lualoader: only clear the screen before first password prompt
This was previously an unconditional screen clear, regardless of whether or
not we would be prompting for any passwords. This is pointless, given that
the screen clear is only there to put our screen into a consistent state
before we draw the prompts and do cursor manipulation.
This is also the only screen clear besides that to draw the menu. One can
now see early pre-loader and loader output with the menu disabled, which may
be useful for diagnostics.
ian [Sun, 17 Feb 2019 23:32:09 +0000 (23:32 +0000)]
Restore loader(8)'s ability for lsdev to show partitions within a bsd slice.
I'm pretty sure this used to work at one time, perhaps long ago. It has
been failing recently because if you call disk_open() with dev->d_partition
set to -1 when d_slice refers to a bsd slice, it assumes you want it to
open the first partition within that slice. When you then pass that open
dev instance to ptable_open(), it tries to read the start of the 'a'
partition and decides there is no recognizable partition type there.
This restores the old functionality by resetting d_offset to the start
of the raw slice after disk_open() returns. For good measure, d_partition
is also set back to -1, although that doesn't currently affect anything.
I would have preferred to make disk_open() avoid such rude assumptions and
if you ask for partition -1 you get the raw slice. But the commit history
shows that someone already did that once (r239058), and had to revert it
(r239232), so I didn't even try to go down that road.
oshogbo [Sun, 17 Feb 2019 18:26:27 +0000 (18:26 +0000)]
libnv: fix double free
In r343986 we introduced a double free. The structure was already
freed fixed in the r302966. This problem was introduced
because the GitHub version was out of sync with the FreeBSD one.
Submitted by: Mindaugas Rasiukevicius <rmind@netbsd.org>
MFC with: r343986
pkelsey [Sun, 17 Feb 2019 03:52:44 +0000 (03:52 +0000)]
Remove whole-disk vdev support from zfsboot
This is consistent with the removal of whole-disk vdev support from
libsa/zfs/zfs.c in r342151, and is part way to having the LBAs read
during probe be fully constrained by partition tables when present.
pkelsey [Sun, 17 Feb 2019 03:35:15 +0000 (03:35 +0000)]
Fix memory corruption bug introduced in r325310
The bug occurred when a bounce buffer was used and the requested read
size was greater than the size of the bounce buffer. This commit also
rewrites the read logic so that it is easier to systematically verify
all alignment and size cases.
ganbold [Sun, 17 Feb 2019 01:16:27 +0000 (01:16 +0000)]
Add sysctl for setting battery charging current.
The charging current can be set using steps
from 0: 200mA to 13: 2800mA (200mA/step).
While there, fix battery charging current related
sensor descriptions.
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D19212
kevans [Sat, 16 Feb 2019 23:57:38 +0000 (23:57 +0000)]
mdmfs(8): use -o reserve with malloc-backed md(4)
Mentioned in mdconfig(8), malloc-backed md(4) can be unstable unless
required memory is allocated up front with -o reserve. Furthermore, panics
have been observed with md used in fstab on 12.0-RELEASE. Choose the stable
route and pass -o reserve.
avos [Sat, 16 Feb 2019 16:01:23 +0000 (16:01 +0000)]
Refresh OptionalObsoleteFiles.inc for MK_PMC:
- Add missing /usr/sbin/pmc, pmcformat.h, libpmcstat.h and pmc.haswellxeon.3
to the list.
- Correct man page section for pmcstudy.8.
- Include recently added libipt and libopencsd for corresponding TARGET_ARCH
sef [Sat, 16 Feb 2019 00:15:54 +0000 (00:15 +0000)]
Add support for a virtual hostname to nfsd
Specifically, this allows (via "-V vhostname") telling nfsd what principal
to use, instead of the hostname. This is used at iXsystems for fail-over in
HA systems.
Reviewed by: macklem
Sponsored by: iXsystems Inc.
Differential Revision: https://reviews.freebsd.org/D19191
glebius [Fri, 15 Feb 2019 23:36:22 +0000 (23:36 +0000)]
For 32-bit machines rollback the default number of vnode pager pbufs
back to the lever before r343030. For 64-bit machines reduce it slightly,
too. Together with r343030 I bumped the limit up to the value we use at
Netflix to serve 100 Gbit/s of sendfile traffic, and it probably isn't a
good default.
Provide a loader tunable to change vnode pager pbufs count. Document it.
cem [Fri, 15 Feb 2019 22:55:13 +0000 (22:55 +0000)]
FUSE: Refresh cached file size when it changes (lookup)
The cached fvdat->filesize is indepedent of the (mostly unused)
cached_attrs, and we failed to update it when a cached (but perhaps
inactive) vnode was found during VOP_LOOKUP to have a different size than
cached.
As noted in the code comment, this can occur in distributed filesystems or
with other kinds of irregular file behavior (anything is possible in FUSE).
We do something similar in fuse_vnop_getattr already.
PR: 230258 (as reported in description; other issues explored in
comments are not all resolved)
Reported by: MooseFS FreeBSD Team <freebsd AT moosefs.com>
Submitted by: Jakub Kruszona-Zawadzki <acid AT moosefs.com> (earlier version)
cem [Fri, 15 Feb 2019 22:52:49 +0000 (22:52 +0000)]
FUSE: The FUSE design expects writethrough caching
At least prior to 7.23 (which adds FUSE_WRITEBACK_CACHE), the FUSE protocol
specifies only clean data to be cached.
Prior to this change, we implement and default to writeback caching. This
is ok enough for local only filesystems without hardlinks, but violates the
general design contract with FUSE and breaks distributed filesystems or
concurrent access to hardlinks of the same inode.
In this change, add cache mode as an extension of cache enable/disable. The
new modes are UC (was: cache disabled), WT (default), and WB (was: cache
enabled).
For now, WT caching is implemented as write-around, which meets the goal of
only caching clean data. WT can be better than WA for workloads that
frequently read data that was recently written, but WA is trivial to
implement. Note that this has no effect on O_WRONLY-opened files, which
were already coerced to write-around.
cem [Fri, 15 Feb 2019 22:51:09 +0000 (22:51 +0000)]
FUSE: Only "dirty" cached file size when data is dirty
Most users of fuse_vnode_setsize() set the cached fvdat->filesize and update
the buf cache bounds as a result of either a read from the underlying FUSE
filesystem, or as part of a write-through type operation (like truncate =>
VOP_SETATTR). In these cases, do not set the FN_SIZECHANGE flag, which
indicates that an inode's data is dirty (in particular, that the local buf
cache and fvdat->filesize have dirty extended data).
cem [Fri, 15 Feb 2019 22:50:31 +0000 (22:50 +0000)]
FUSE: Respect userspace FS "do-not-cache" of path components
The FUSE protocol demands that kernel implementations cache user filesystem
path components (lookup/cnp data) for a maximum period of time in the range
of [0, ULONG_MAX] seconds. In practice, typical requests are for 0, 1, or
10 seconds; or "a long time" to represent indefinite caching.
Historically, FreeBSD FUSE has ignored this client directive entirely. This
works fine for local-only filesystems, but causes consistency issues with
multi-writer network filesystems.
For now, respect 0 second cache TTLs and do not cache such metadata.
Non-zero metadata caching TTLs in the range [0.000000001, ULONG_MAX] seconds
are still cached indefinitely, because it is unclear how a userspace
filesystem could do anything sensible with those semantics even if
implemented.
Pass fuse_entry_out to fuse_vnode_get when available and only cache lookup
if the user filesystem did not set a zero second TTL.
cem [Fri, 15 Feb 2019 22:49:15 +0000 (22:49 +0000)]
FUSE: Respect userspace FS "do-not-cache" of file attributes
The FUSE protocol demands that kernel implementations cache user filesystem
file attributes (vattr data) for a maximum period of time in the range of
[0, ULONG_MAX] seconds. In practice, typical requests are for 0, 1, or 10
seconds; or "a long time" to represent indefinite caching.
Historically, FreeBSD FUSE has ignored this client directive entirely. This
works fine for local-only filesystems, but causes consistency issues with
multi-writer network filesystems.
For now, respect 0 second cache TTLs and do not cache such metadata.
Non-zero metadata caching TTLs in the range [0.000000001, ULONG_MAX] seconds
are still cached indefinitely, because it is unclear how a userspace
filesystem could do anything sensible with those semantics even if
implemented.
In the future, as an optimization, we should implement notify_inval_entry,
etc, which provide userspace filesystems a way of evicting the kernel cache.
One potentially bogus access to invalid cached attribute data was left in
fuse_io_strategy. It is restricted behind the undocumented and non-default
"vfs.fuse.fix_broken_io" sysctl or "brokenio" mount option; maybe these are
deadcode and can be eliminated?
Some minor APIs changed to facilitate this:
1. Attribute cache validity is tracked in FUSE inodes ("fuse_vnode_data").
2. cache_attrs() respects the provided TTL and only caches in the FUSE
inode if TTL > 0. It also grows an "out" argument, which, if non-NULL,
stores the translated fuse_attr (even if not suitable for caching).
3. FUSE VTOVA(vp) returns NULL if the vnode's cache is invalid, to help
avoid programming mistakes.
4. A VOP_LINK check for potential nlink overflow prior to invoking the FUSE
link op was weakened (only performed when we have a valid attr cache). The
check is racy in a multi-writer network filesystem anyway -- classic TOCTOU.
We have to trust any userspace filesystem that rejects local caching to
account for it correctly.
emaste [Fri, 15 Feb 2019 22:22:38 +0000 (22:22 +0000)]
Add WITH_PIE knob to build Position Independent Executables
Building binaries as PIE allows the executable itself to be loaded at a
random address when ASLR is enabled (not just its shared libraries).
With this change PIE objects have a .pieo extension and INTERNALLIB
libraries libXXX_pie.a.
MK_PIE is disabled for some kerberos5 tools, Clang, and Subversion, as
they explicitly reference .a libraries in their Makefiles. These can
be addressed on an individual basis later. MK_PIE is also disabled for
rtld-elf because it is already position-independent using bespoke
Makefile rules.
Currently only dynamically linked binaries will be built as PIE.
Discussed with: dim
Reviewed by: kib
MFC after: 1 month
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18423
kevans [Fri, 15 Feb 2019 18:28:51 +0000 (18:28 +0000)]
stand: dev_net: correct net_open's interpretation of params
net_open previously casted the first vararg to a char * and this was
half-OK: at first, it is passed to netif_open, which would cast it back to
the struct devdesc * that it really is and use it properly. It is then
strdup()d and used as the netdev_name, which is objectively wrong.
Correct it so that the first vararg is properly casted to a struct devdesc *
and the netdev_name gets set properly to make it more clear at a glance that
it's not doing something horribly wrong.
rgrimes [Fri, 15 Feb 2019 16:48:15 +0000 (16:48 +0000)]
In r340044 an attempt to quiet coverity warning cid 1357336
was incorrectly implemented leading to a possible double free.
It is possible for both the conditional free,
and the unconditional free added in r340044 to be done,
fix that by initializing uopt to NULL,
removing the conditional free,
and only using the unconditional free at the end.
Reported by: Patrick Mooney (patrick.mooney@joyent.com)
Reviewed by: jhb (maintainer), Patrick Mooney (joyent/illumos)
Approved by: bde (mentor)
CID: 1357336
MFC after: 3 days
MFC with: 340044
Differential Revision: https://reviews.freebsd.org/D19202
rgrimes [Fri, 15 Feb 2019 16:20:21 +0000 (16:20 +0000)]
In r340042 an attempt to quiet coverity warning cid 1305412 was overdone.
nopt is the only allocated space,
xopt and cp are aliases into that allocated space.
Remove the 2 unneeded free's
Reported by: Patrick Mooney (@pmooney_pfmooney.com)
Reviewed by: jhb (maintainer), Patrick Mooney (joyent/illumos)
Approved by: bde (mentor)
CID: 1305412
MFC after: 3 days
MFC with: 340042
Differential Revision: https://reviews.freebsd.org/D19200
sef [Fri, 15 Feb 2019 03:53:03 +0000 (03:53 +0000)]
Add AES-CCM encryption, and plumb into OCF.
This commit essentially has three parts:
* Add the AES-CCM encryption hooks. This is in and of itself fairly small,
as there is only a small difference between CCM and the other ICM-based
algorithms.
* Hook the code into the OpenCrypto framework. This is the bulk of the
changes, as the algorithm type has to be checked for, and the differences
between it and GCM dealt with.
* Update the cryptocheck tool to be aware of it. This is invaluable for
confirming that the code works.
This is a software-only implementation, meaning that the performance is very
low.
Sponsored by: iXsystems Inc.
Differential Revision: https://reviews.freebsd.org/D19090
bde [Thu, 14 Feb 2019 19:07:08 +0000 (19:07 +0000)]
Finish the fix for overflow in calcru1().
The previous fix was unnecessarily very slow up to 105 hours where the
simple formula used previously worked, and unnecessarily slow by a factor
of about 5/3 up to 388 days, and didn't work above 388 days. 388 days is
not a long time, since it is a reasonable uptime, and for processes the
times being calculated are aggregated over all threads, so with N CPUs
running the same thread a runtime of 388 days is reachable after only
388 / N physical days.
The PRs document overflow at 388 days, but don't try to fix it.
Use the simple formula up to 76 hours. Then use a complicated general
method that reduces to the simple formula up to a bit less than 105
hours, then reduces to the previous method without its extra work up
to almost 388 days, then does more complicated reductions, usually
many bits at a time so that this is not slow. This works up to half
of maximum representable time (292271 years), with accumulated rounding
errors of at most 32 usec.
amd64 can do all this with no avoidable rounding errors in an inline
asm with 2 instructions, but this is too special to use. __uint128_t
can do the same with 100's of instructions on 64-bit arches. Long
doubles with at least 64 bits of precision are the easiest method to
use on i386 userland, but are hard to use in the kernel.
erj [Thu, 14 Feb 2019 18:02:37 +0000 (18:02 +0000)]
ixl: Fix panic caused by bug exposed by r344062
Don't use a struct if_irq for IFLIB_INTR_IOV type interrupts since that results
in get_core_offset() being called on them, and get_core_offset() doesn't
handle IFLIB_INTR_IOV type interrupts, which results in an assert() being triggered
in iflib_irq_set_affinity().
kib [Thu, 14 Feb 2019 15:45:53 +0000 (15:45 +0000)]
Make anon clustering more compatible.
Make the clustering enabling knob more fine-grained by providing a
setting where the allocation with hint is not clustered. This is aimed
to be somewhat more compatible with e.g. go 1.4 which expects that
hinted mmap without MAP_FIXED does not change the allocation address.
Now the vm.cluster_anon can be set to 1 to only cluster when no hints,
and to 2 to always cluster. Default value is 1.
Requested by: peter
Reviewed by: emaste, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
Differential revision: https://reviews.freebsd.org/D19194
luporl [Thu, 14 Feb 2019 15:15:32 +0000 (15:15 +0000)]
[PPC64] Fix mismatch between thread flags and MSR
When sigreturn() restored a thread's context, SRR1 was being restored
to its previous value, but pcb_flags was not being touched.
This could cause a mismatch between the thread's MSR and its pcb_flags.
For instance, when the thread used the FPU for the first time inside
the signal handler, sigreturn() would clear SRR1, but not pcb_flags.
Then, the thread would return with the FPU bit cleared in MSR and,
the next time it tried to use the FPU, it would fail on a KASSERT
that checked if the FPU was disabled.
This change clears the FPU bit in both pcb_flags and frame->srr1,
as the code that restores the context expects to use the FPU trap
to re-enable it.
kib [Thu, 14 Feb 2019 13:53:11 +0000 (13:53 +0000)]
Provide userspace versions of do_cpuid() and cpuid_count() on i386.
Some older compilers, when generating PIC code, cannot handle inline
asm that clobbers %ebx (because %ebx is used as the GOT offset
register). Userspace versions avoid clobbering %ebx by saving it to
stack before executing the CPUID instruction.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
markj [Wed, 13 Feb 2019 17:50:01 +0000 (17:50 +0000)]
Implement per-CPU pmap activation tracking for RISC-V.
This reduces the overhead of TLB invalidations by ensuring that we
only interrupt CPUs which are using the given pmap. Tracking is
performed in pmap_activate(), which gets called during context switches:
from cpu_throw(), if a thread is exiting or an AP is starting, or
cpu_switch() for a regular context switch.
For now, pmap_sync_icache() still must interrupt all CPUs.
Reviewed by: kib (earlier version), jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18874
markj [Wed, 13 Feb 2019 17:19:37 +0000 (17:19 +0000)]
Implement transparent 2MB superpage promotion for RISC-V.
This includes support for pmap_enter(..., psind=1) as described in the
commit log message for r321378.
The changes are largely modelled after amd64. arm64 has more stringent
requirements around superpage creation to avoid the possibility of TLB
conflict aborts, and these requirements do not apply to RISC-V, which
like amd64 permits simultaneous caching of 4KB and 2MB translations for
a given page. RISC-V's PTE format includes only two software bits, and
as these are already consumed we do not have an analogue for amd64's
PG_PROMOTED. Instead, pmap_remove_l2() always invalidates the entire
2MB address range.
pmap_ts_referenced() is modified to clear PTE_A, now that we support
both hardware- and software-managed reference and dirty bits. Also
fix pmap_fault_fixup() so that it does not set PTE_A or PTE_D on kernel
mappings.
ae [Wed, 13 Feb 2019 15:46:05 +0000 (15:46 +0000)]
In r335015 PCB destroing was made deferred using epoch_call().
But ipsec_delete_pcbpolicy() uses some VNET-virtualized variables,
and thus it needs VNET context, that is missing during gtaskqueue
executing. Use inp_vnet context to set curvnet in in_pcbfree_deferred().
rrs [Wed, 13 Feb 2019 14:57:59 +0000 (14:57 +0000)]
This commit adds the missing release mechanism for the
ratelimiting code. The two modules (lagg and vlan) did have
allocation routines, and even though they are indirect (and
vector down to the underlying interfaces) they both need to
have a free routine (that also vectors down to the actual interface).
Sponsored by: Netflix Inc.
Differential Revision: https://reviews.freebsd.org/D19032
kevans [Wed, 13 Feb 2019 04:19:08 +0000 (04:19 +0000)]
libbe(3): Fix be_destroy behavior w.r.t. deep BE snapshots and -o
be_destroy is documented to recursively destroy a boot environment. In the
case of snapshots, one would take this to mean that these are also
recursively destroyed. However, this was previously not the case.
be_destroy would descend into the be_destroy callback and attempt to
zfs_iter_children on the top-level snapshot, which is bogus.
Our alternative approach is to take note of the snapshot name and iterate
through all of fs children of the BE to try destruction in the children.
The -o option is also fixed to work properly with deep BEs. If the BE was
created with `bectl create -e otherDeepBE newDeepBE`, for instance, then a
recursive snapshot of otherDeepBE would have been taken for construction of
newDeepBE but a subsequent destroy with BE_DESTROY_ORIGIN set would only
clean up the snapshot at the root of otherDeepBE: ${BEROOT}/otherDeepBE@...
The most recent iteration instead pretends not to know how these things
work, verifies that the origin is another BE and then passes that back
through be_destroy to DTRT when snapshots and deep BEs may be in play.
jhibbits [Wed, 13 Feb 2019 03:11:12 +0000 (03:11 +0000)]
powerpc/booke: Use the 'tlbilx' instruction on newer cores
Newer cores have the 'tlbilx' instruction, which doesn't broadcast over
CoreNet. This is significantly faster than walking the TLB to invalidate
the PID mappings. tlbilx with the arguments given takes 131 clock cycles to
complete, as opposed to 512 iterations through the loop plus tlbre/tlbwe at
each iteration.
ngie [Wed, 13 Feb 2019 02:16:52 +0000 (02:16 +0000)]
Import GoogleTest 1.8.1 into the vendor tree under `^/google/googletest/dist`
GoogleTest is a widely used opensource C++ test framework, licensed under a
BSD 3-clause license. It fits best in the realm of doing functional/whitebox
testing, similar to ATF's C++ library. However, it has additional functionality
such as per-testcase setup fixtures, class level setup and teardown fixtures,
and a lot more functional/syntactic goodness.
In addition to large corporations adopting GoogleTest as their defacto C++ test
library (Facebook, Google, etc), many opensource projects have adopted
GoogleTest, e.g., the Capsicum project, Chrome, etc.
The goal for importing this is to enable testing with zfsd and integrate
googletest into kyua.
This is the final version that will support a pre-C++-11 compiler. As such, this
test framework will not be available to gcc 4.2.1, similar to ATF's C++ library.
A subsequent set of commits will:
1. Tag ^/google/googletest/dist as ^/google/googletest/1.8.1 using `svn cp ^/google/googletest/dist ^/google/googletest/1.8.1`.
2. Import this code into ^/head and integrate it into the build for all applicable
platforms and C++ compile toolchains.
The import was done via the following command pipeline on OSX:
```
curl -L https://github.com/google/googletest/archive/release-1.8.1.tar.gz | tar --strip-components=1 -xvzf - -C dist/
```
imp [Wed, 13 Feb 2019 00:10:12 +0000 (00:10 +0000)]
Fix panic message.
The panic message lead people to believe some userland CAM request had
caused a problem when in reallity it was for a kernel request (eg the
USER bit was cleared). Reword message. Also, improve a couple of
comments to reflect that the periph shouldn't be completely torn down
before we get here (so the path and sim pointers should be valid, but
aren't and the code is designed to be robust enough in the face of
that to give a specific panic message).
ngie [Tue, 12 Feb 2019 23:35:46 +0000 (23:35 +0000)]
Fix up concurrent test zpool setup and teardown
Set up zpools with a more unique name, stash the zpool name away in a file pointed
to by `$ZPOOL_NAME_FILE` (which is relative to a per-testcase generated temporary
directory), then remove the file based on `$ZPOOL_NAME_FILE` in the cleanup
routines.
This is a more concurrency-safe solution and will allow the testcases to be safely
executed in parallel.
ngie [Tue, 12 Feb 2019 23:33:16 +0000 (23:33 +0000)]
Add rc.resume(8) alias for rc(8) to fix the manpage cross references
This issue was noticed when running `make manlint` as part of MFCing r342597 to
^/stable/11:
```
$ make -C share/man/man8 rc.8lint
mandoc -Tascii -Tlint rc.8
mandoc: rc.8:548:6: STYLE: referenced manual not found: Xr rc.resume 8
$
```
This is a followup commit to r339818.
Reviewed by: eugen
Approved by: jtl (mentor)
MFC after: 1 week
MFC to: ^/stable/12
Differential Revision: https://reviews.freebsd.org/D19158