r339436 gjb Oct. 19, 2018, 12:37 a.m.
- Bump MACHINE_TRIPLE, TARGET_TRIPLE, FBSD_MAJOR, FBSD_CC_VER,
  FREEBSD_CC_VERSION, OS_VERSION.
- Update comment in UPDATING regarding debugging options.
- Remove debug.witness.trace=0 from installation media.
- Bump __FreeBSD_version.

Approved by:	re (implicit)
Sponsored by:	The FreeBSD Foundation
ViewVC
r339432 kib Oct. 18, 2018, 8:49 p.m.
Apparently AMD machines cannot tolerate this. This was uncovered by
r339386, where cache flush started really flushing the requested range.

Introduce pmap_mapdev_pciecfg(), which simply does not flush cache
comparing with pmap_mapdev().  It assumes that the MCFG region was
never accessed through the cacheable mapping, which is most likely
true for machine to boot at all.

Note that i386 does not need the change, since the architecture
handles access per-page due to the KVA shortage, and page remapping
already does not flush the cache.

Reported and tested by:	mjg, Mike Tancsa <mike@sentex.net>
Reviewed by:	alc
Sponsored by:	The FreeBSD Foundation
Approved by:	re (gjb)
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D17612
ViewVC
r339431 bz Oct. 18, 2018, 8:20 p.m.
returns the section start and stop locations as well as a count if the
caller asks for them.
There was only one out-of-file consumer of count which did not actually
use it and hence was eliminated in r339407.
In r194784 parse_dpcpu(), and in r195699 parse_vnet() (a copy of the
former) started to use the link_elf_lookup_set() interface internally
also asking for the count.

count is computed as the difference of the void **stop - void **start
locations and as such, if the absoulte numbers
	(stop - start) % sizeof(void *) != 0
a round-down happens, e.g., **stop 0x1003 - **start 0x1000 => count 0.

To get the section size instead of "count is the number of pointer
elements in the section", the parse_*() functions do a
	count *= sizeof(void *).
They use the result to allocate memory and copy the section data
into the "master" and per-instance memory regions with a size of
count.

As a result of count possibly round-down this can miss the last
bytes of the section.  The good news is that we do not touch
out of bounds memory during these operations (we may at a later stage
if the last bytes would overflow the master sections).
Given relocation in elf_relocaddr() works based on the absolute
numbers of start and stop, this means that we can possibly try to
access relocated data which was never copied and hence we get
random garbage or at best zeroed memory.

Stop the two (last) consumers of count (the parse_*() functions)
from using count as well, and calculate the section size based on
the absolute numbers of stop and start and use the proper size for
the memory allocation and data copies.  This will make the symbols
in the last bytes of the pcpu or vnet sections be presented as
expected.

PR:			232289
Approved by:		re (gjb)
MFC after:		2 weeks
ViewVC
r339430 tuexen Oct. 18, 2018, 7:21 p.m.
code paths. Both are not consistent and the one on the syn cache code
does not conform to the relevant specifications (Page 69 of RFC 793
and Section 4.2 of RFC 5961).

This patch fixes this:
* The sequence numbers checks are fixed as specified on
  page Page 69 RFC 793.
* The sysctl variable net.inet.tcp.insecure_rst is now honoured
  and the behaviour as specified in Section 4.2 of RFC 5961.

Approved by:		re (gjb@)
Reviewed by:		bz@, glebius@, rrs@,
Differential Revision:	https://reviews.freebsd.org/D17595
Sponsored by:		Netflix, Inc.
ViewVC
r339428 gjb Oct. 18, 2018, 7:07 p.m.
Reported by:	rpokala
Approved by:	re (kib)
Sponsored by:	The FreeBSD Foundation
ViewVC
r339427 des Oct. 18, 2018, 6:33 p.m.
if a network connection is available.  This is not an issue when running
'service local_unbound setup' interactively, but can be on a diskless
system where local_unbound self-configures on every boot.  To address
this, add explicit dependencies on netwait and defaultroute.

Submitted by:	eugen
Approved by:	re (gjb)
ViewVC
r339424 des Oct. 18, 2018, 3:35 p.m.
Approved by:	re (kib)
ViewVC
r339423 br Oct. 18, 2018, 3:25 p.m.
(e.g. RocketChip, lowRISC and derivatives).

RISC-V page table entries support A (accessed) and D (dirty) bits. The
spec makes hardware support for these bits optional. Implementations that
do not manage these bits in hardware raise page faults for accesses to a
valid page without A set and writes to a writable page without D set.
Check for these types of faults when handling a page fault and fixup the
PTE without calling vm_fault if they occur.

Reviewed by:	jhb, markj
Approved by:	re (gjb)
Sponsored by:	DARPA, AFRL
Differential Revision:	https://reviews.freebsd.org/D17424
ViewVC
r339422 br Oct. 18, 2018, 3:17 p.m.
Reported by:	ian
Approved by:	re (gjb)
Sponsored by:	DARPA, AFRL
ViewVC
r339421 br Oct. 18, 2018, 3:08 p.m.
(e.g. RocketChip, lowRISC and derivatives).

RISC-V page table entries support A (accessed) and D (dirty) bits. The
spec makes hardware support for these bits optional. Implementations that
do not manage these bits in hardware raise page faults for accesses to a
valid page without A set and writes to a writable page without D set.
Check for these types of faults when handling a page fault and fixup the
PTE without calling vm_fault if they occur.

Reviewed by:	jhb, markj
Approved by:	re (gjb)
Sponsored by:	DARPA, AFRL
Differential Revision:	https://reviews.freebsd.org/D17424
ViewVC
r339420 jamie Oct. 18, 2018, 3:02 p.m.
Reported by:	maxim
Approved by:	re (gjb)
ViewVC
r339419 jtl Oct. 18, 2018, 2:20 p.m.
was really a "socket close" callback.

Update the socket destructor functionality to run when a socket is
destroyed (rather than when it is closed). The original submitter has
confirmed that this change satisfies the intended use case.

Suggested by:	rwatson
Submitted by:	Michio Honda <micchie at sfc.wide.ad.jp>
Tested by:	Michio Honda <micchie at sfc.wide.ad.jp>
Approved by:	re (kib)
Differential Revision:	https://reviews.freebsd.org/D17590
ViewVC
r339417 bz Oct. 18, 2018, 2:07 a.m.
in r339413, a current pkgbase update problem came up.  For users
testing pkgbase at the moment there is no (automatic) way to pick
up new base packages (yet).
As a result rather than also moving init(8) to its own package,
back out the part of the change in r339413 that moved rc* to its
own package and defer creating new packages until the
infrastructure is in place to handle these cases.
Both init and rc* are considered too problematic to be lost by
early adaptors at this stage.

Discussed with:		brd
Reviewed by:		brd
Approved by:		re (gjb)
ViewVC
r339416 bz Oct. 18, 2018, 12:51 a.m.
to the SRC list.  Sort the list while changing the line.

Reported by:		ci.f.o, make -j24 buildkernel
Approved by:		re (gjb)
ViewVC
r339414 bz Oct. 17, 2018, 4:54 p.m.
case in tunefs(8).

Reviewed by:		imp (2017 version of the same diff)
Approved by:		re (gjb)
Differential Revision:	https://reviews.freebsd.org/D10046
ViewVC