r344115 avos Feb. 14, 2019, 9:21 a.m.
removal

Notified by:	ian
ViewVC
r344112 dim Feb. 13, 2019, 8:13 p.m.
[MC] Make symbol version errors non-fatal

  We stil don't have a source location, which is pretty lame, but at
  least we won't tell the user to file a clang bug report anymore.

  Fixes PR40712

This will make errors for symbols with @@ versions that are not defined
non-fatal.  For example:

  void f(void)
  {
    __asm__(".symver foo,bar@@baz");
  }

will now result in:

  error: versioned symbol bar@@baz must be defined

instead of clang crashing with a diagnostic report.

PR:		234671
Upstream PR:	https://bugs.llvm.org/show_bug.cgi?id=40712
MFC after:	3 days
ViewVC
r344109 luporl Feb. 13, 2019, 6:28 p.m.
silence the following warning when compiling libthr with clang 8
for powerpc64 architecture:

usr/src/lib/libthr/arch/powerpc/include/pthread_md.h:82:10: error:
cast from 'uint8_t *' (aka 'unsigned char *') to 'struct tcb *'
increases required alignment from 1 to 8 [-Werror,-Wcast-align]
82:  return ((struct tcb *)(_tp - TP_OFFSET));

Submitted by:	alfredo.junior_eldorado.org.br
Reviewed by:	git_bdragon.rtk0.net, emaste, kib, jhibbits, luporl
Differential Revision:	https://reviews.freebsd.org/D18807
ViewVC
r344108 markj Feb. 13, 2019, 5:50 p.m.
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
ViewVC
r344107 markj Feb. 13, 2019, 5:38 p.m.
Reviewed by:	kib
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D18875
ViewVC
r344106 markj Feb. 13, 2019, 5:19 p.m.
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.

Reviewed by:	kib (earlier version)
Discussed with:	jhb
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D18863
Differential Revision:	https://reviews.freebsd.org/D18864
Differential Revision:	https://reviews.freebsd.org/D18865
Differential Revision:	https://reviews.freebsd.org/D18866
Differential Revision:	https://reviews.freebsd.org/D18867
Differential Revision:	https://reviews.freebsd.org/D18868
ViewVC
r344103 ae Feb. 13, 2019, 3:46 p.m.
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().

PR:		235684
MFC after:	1 week
ViewVC
r344099 rrs Feb. 13, 2019, 2:57 p.m.
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
ViewVC
r344089 mm Feb. 13, 2019, 7:37 a.m.
archive_read_disk_posix.c: initialize delayed_errno

MFC after:	2 weeks
ViewVC
r344085 obrien Feb. 13, 2019, 4:52 a.m.
r344084 kevans Feb. 13, 2019, 4:19 a.m.
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.

MFC after:	1 week
ViewVC
r344083 jhibbits Feb. 13, 2019, 3:11 a.m.
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.

MFC after:	3 weeks
ViewVC
r344070 imp Feb. 13, 2019, 12:10 a.m.
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).
ViewVC
r344069 marius Feb. 12, 2019, 11:39 p.m.
device_if.h.
ViewVC
r344067 ngie Feb. 12, 2019, 11:35 p.m.
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.

Reviewed by:	kevans, jtl
Approved by:	jtl (mentor)
MFC after:	1 week
Differential Revision: https://reviews.freebsd.org/D19024
ViewVC