r344066 ngie Feb. 12, 2019, 11:33 p.m.
This issue was noticed when running `make manlint` as part of MFCing r342597 to
$ 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
r344065 mm Feb. 12, 2019, 11:24 p.m.
Sync libarchive with vendor.

Relevant vendor changes:
  PR #1085: Fix a null pointer dereference bug in zip writer
  PR #1110: ZIP reader added support for XZ, LZMA, PPMD8 and BZIP2
  PR #1116: Add support for 64-bit ar format
  PR #1120: Fix a 7zip crash [1] and a ISO9660 infinite loop [2]
  PR #1125: RAR5 reader - fix an invalid read and a memory leak
  PR #1131: POSIX reader - do not fail when tree_current_lstat() fails
            due to ENOENT [3]
  PR #1134: Delete unnecessary null pointer checks before calls of free()
  OSS-Fuzz 10843: Force intermediate to uint64_t to make UBSAN happy.
  OSS-Fuzz 11011: Avoid buffer overflow in rar5 reader

PR:		233006 [3]
Security:	CVE-2019-1000019 [1], CVE-2019-1000020 [2]
MFC after:	2 weeks
r344064 marius Feb. 12, 2019, 10:33 p.m.
r344062 marius Feb. 12, 2019, 9:23 p.m.
So far, intr_{g,s}etaffinity(9) take a single int for identifying
a device interrupt. This approach doesn't work on all architectures
supported, as a single int isn't sufficient to globally specify a
device interrupt. In particular, with multiple interrupt controllers
in one system as found on e. g. arm and arm64 machines, an interrupt
number as returned by rman_get_start(9) may be only unique relative
to the bus and, thus, interrupt controller, a certain device hangs
off from.
In turn, this makes taskqgroup_attach{,_cpu}(9) and - internal to
the gtaskqueue implementation - taskqgroup_attach_deferred{,_cpu}()
not work across architectures. Yet in turn, iflib(4) as gtaskqueue
consumer so far doesn't fit architectures where interrupt numbers
aren't globally unique.
However, at least for intr_setaffinity(..., CPU_WHICH_IRQ, ...) as
employed by the gtaskqueue implementation to bind an interrupt to a
particular CPU, using bus_bind_intr(9) instead is equivalent from
a functional point of view, with bus_bind_intr(9) taking the device
and interrupt resource arguments required for uniquely specifying a
device interrupt.
Thus, change the gtaskqueue implementation to employ bus_bind_intr(9)
instead and intr_{g,s}etaffinity(9) to take the device and interrupt
resource arguments required respectively. This change also moves
struct grouptask from <sys/_task.h> to <sys/gtaskqueue.h> and wraps
struct gtask along with the gtask_fn_t typedef into #ifdef _KERNEL
as userland likes to include <sys/_task.h> or indirectly drags it
in - for better or worse also with _KERNEL defined -, which with
device_t and struct resource dependencies otherwise is no longer
as easily possible now.
The userland inclusion problem probably can be improved a bit by
introducing a _WANT_TASK (as well as a _WANT_MOUNT) akin to the
existing _WANT_PRISON etc., which is orthogonal to this change,
though, and likely needs an exp-run.

While at it:
- Change the gt_cpu member in the grouptask structure to be of type
  int as used elswhere for specifying CPUs (an int16_t may be too
  narrow sooner or later),
- move the gtaskqueue_enqueue_fn typedef from <sys/gtaskqueue.h> to
  the gtaskqueue implementation as it's only used and needed there,
- change the GTASK_INIT macro to use "gtask" rather than "task" as
  argument given that it actually operates on a struct gtask rather
  than a struct task, and
- let subr_gtaskqueue.c consistently use __func__ to print functions

Reported by:	mmel
Reviewed by:	mmel
Differential Revision:	https://reviews.freebsd.org/D19139
r344061 kp Feb. 12, 2019, 9:22 p.m.
Gratuitous ARP packets are sent from a timer, which means we don't have a vnet
context set. As a result we panic trying to send the packet.

Set the vnet context based on the interface associated with the interface

To reproduce:
  sysctl net.link.ether.inet.garp_rexmit_count=2
  ifconfig vtnet1 up

PR:		235699
Reviewed by:	vangyzen@
MFC after:	1 week
r344060 marius Feb. 12, 2019, 9:08 p.m.
o Correct the obvious bugs in the netmap(4) parts:
  - No longer check for the existence of DMA maps as bus_dma(9)
    is used unconditionally in iflib(4) since r341095.
  - Supply the correct DMA tag and map pairs to bus_dma(9)
    functions (see also the commit message of r343753).
  - In iflib_netmap_timer_adjust(), add synchronization of the
    TX descriptors before calling the ift_txd_credits_update
    method as the latter evaluates the TX descriptors possibly
    updated by the MAC.
  - In _task_fn_tx(), wrap the netmap(4)-specific bits in
    #ifdef DEV_NETMAP just as done in _task_fn_admin() and
    _task_fn_rx() respectively.
o In iflib_fast_intr_rxtx(), synchronize the TX rather than
  the RX descriptors before calling the ift_txd_credits_update
  method (see also above).
o There's no need to synchronize an RX buffer that is going to
  be recycled in iflib_rxd_pkt_get(), yet; it's sufficient to
  do that as late as passing RX buffers to the MAC via the
  ift_rxd_refill method. Hence, combine that synchronization
  with the synchronization of new buffers into a common spot
  in _iflib_fl_refill().
o There's no need to synchronize the RX descriptors of a free
  list in preparation of the MAC updating their statuses with
  every invocation of rxd_frag_to_sd(); it's enough to do this
  once before handing control over to the MAC, i. e. before
  calling ift_rxd_flush method in _iflib_fl_refill(), which
  already performs the necessary synchronization.
o Given that the ift_rxd_available method evaluates the RX
  descriptors which possibly have been altered by the MAC,
  synchronize as appropriate beforehand. Most notably this
  is now done in iflib_rxd_avail(), which in turn means that
  we don't need to issue the same synchronization yet again
  before calling the ift_rxd_pkt_get method in iflib_rxeof().
o In iflib_txd_db_check(), synchronize the TX descriptors
  before handing them over to the MAC for transmission via
  the ift_txd_flush method.
o In iflib_encap(), move the TX buffer synchronization after
  the invocation of the ift_txd_encap() method. If the MAC
  driver fails to encapsulate the packet and we retry with
  a defragmented mbuf chain or finally fail, the cycles for
  TX buffer synchronization have been wasted. Synchronizing
  afterwards matches what non-iflib(4) drivers typically do
  and is sufficient as the MAC will not actually start with
  the transmission before - in this case - the ift_txd_flush
  method is called.
  Moreover, for the latter reason the synchronization of the
  TX descriptors in iflib_encap() can go as it's enough to
  synchronize them before passing control over to the MAC by
  issuing the ift_txd_flush() method (see above).
o In iflib_txq_can_drain(), only synchronize TX descriptors
  if the ift_txd_credits_update method accessing these is
  actually called.

Differential Revision:	https://reviews.freebsd.org/D19081
r344059 phk Feb. 12, 2019, 9:06 p.m.
r344057 imp Feb. 12, 2019, 7:05 p.m.
Approved by:	core@
r344056 dim Feb. 12, 2019, 6:32 p.m.
[ARM] Make PerformSHLSimplify add nodes to the DAG worklist correctly.

  Intentionally excluding nodes from the DAGCombine worklist is likely
  to lead to weird optimizations and infinite loops, so it's generally
  a bad idea.

  To avoid the infinite loops, fix DAGCombine to use the
  isDesirableToCommuteWithShift target hook before performing the
  transforms in question, and implement the target hook in the ARM
  backend disable the transforms in question.

  Fixes https://bugs.llvm.org/show_bug.cgi?id=38530 . (I don't have a
  reduced testcase for that bug. But we should have sufficient test
  coverage for PerformSHLSimplify given that we're not playing weird
  tricks with the worklist. I can try to bugpoint it if necessary,

  Differential Revision: https://reviews.llvm.org/D50667

This should fix a possible hang when compiling sys/dev/nxge/if_nxge.c
(which exists now only in the stable/11 branch) for arm.
r344050 trasz Feb. 12, 2019, 1:01 p.m.
Reported by:	0mp
MFC after:	2 weeks
Sponsored by:	DARPA, AFRL
r344049 luporl Feb. 12, 2019, 11:29 a.m.
At moea64_sync_icache(), when the 'va' argument has page size
alignment, round_page() will return the same value as 'va'.
This would cause 'len' to be 0 and thus an infinite loop.

With this change, 'lim' will always point to the next page boundary.

This issue occurred especially during debugging sessions, when a breakpoint
was placed on an exact page-aligned offset, for instance.

Reviewed by:	jhibbits
Differential Revision:	https://reviews.freebsd.org/D19149
r344048 tuexen Feb. 12, 2019, 10:17 a.m.

This issue was found by running syzkaller on OpenBSD.
Greg Steuck made me aware that the problem might also exist on FreeBSD.

Reported by:		Greg Steuck
MFC after:		1 month
Differential Revision:	https://reviews.freebsd.org/D18834
r344045 lwhsu Feb. 12, 2019, 8:16 a.m.
Approved by:	markj (mentor)
Sponsored by:	The FreeBSD Foundation
r344043 bwidawsk Feb. 12, 2019, 5:15 a.m.
The project is here:

I created a port (which now needs updating):

If only we could use terminfo :(

MFC after:      5 days
Approved by:    bapt
Differential Revision:	https://reviews.freebsd.org/D19060
r344042 pfg Feb. 12, 2019, 4:33 a.m.
As a followup to r343673, unsign some variables related to allocation
since the hashsize cannot be negative. This gives a bit more space to
handle bigger allocations and avoid some implicit casting.

While here also unsign uh_hashmask, it makes little sense to keep that

MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D19148