6bcba8da manu March 23, 2021, 3:37 p.m.
Reported by:	  andrew
63f34402 manu March 23, 2021, 2:24 p.m.
Do for arm64 what was done for armv7 in e63faa9ba832b6
b93a796b markj March 23, 2021, 2:04 p.m.
PR:		254419
Reviewed by:	gallatin, kp
Tested by:	Igor A. Valkov <viaprog@gmail.com>
MFC after:	3 days
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D29378
1240fba4 manu March 23, 2021, 2:02 p.m.
6be33864 manu March 23, 2021, 2 p.m.
c2f16c59 nwhitehorn March 23, 2021, 1:29 p.m.
Because the ESP mount point (/boot/efi) is in mtree, tar will attempt to
extract a directory at that point post-mount when the system is installed.
Normally, this is fine, since tar can happily set whatever properties it
wants. For FAT32 file systems, however, like the ESP, tar will attempt to
set mtime on the root directory, which FAT does not support, and tar will
interpret this as a fatal error, breaking the install (see
https://github.com/libarchive/libarchive/issues/1516). This issue would
also break scripted installs on bare-metal POWER8, POWER9, and PS3
systems, as well as some ARM systems.

This patch solves the problem in two ways:
- If stdout is a TTY, use the distextract stage instead of tar, as in
  interactive installs. distextract solves this problem internally and
  provides a nicer UI to boot, but requires a TTY.
- If stdout is not a TTY, use tar but, as a stopgap for 13.0, exclude
  boot/efi from tarball extraction and then add it by hand. This is a
  hack, and better solutions (as in the libarchive ticket above) will
  obsolete it, but it solves the most common case, leaving only
  unattended TTY-less installs on a few tier-2 platforms broken.

In addition, fix a bug with fstab generation uncovered once the tar issue
is fixed that umount(8) can depend on the ordering of lines in fstab in a
way that mount(8) does not. The partition editor now writes out fstab in
mount order, making sure umount (run at the end of scripted, but not
interactive, installs) succeeds.

PR:		254395
Reviewed by:	gjb, imp
MFC after:	3 days
Differential Revision:	https://reviews.freebsd.org/D29380
3c6b5956 avg March 23, 2021, 10:45 a.m.
MFC after:	1 week
4489124c royger March 23, 2021, 10:07 a.m.
Only attempt to fetch the configuration data and connect the shared
ring once the frontend has switched to the 'Connected' state. This
seems to be inline with what Linux netback does, and is required to
make newer versions of NetBSD netfront work, since NetBSD only
publishes the required configuration before switching to the Connected

MFC after:	1 week
Sponsored by:	Citrix Systems R&D
be97fc8d khng March 23, 2021, 8:12 a.m.
Bump offset with MOD_INC instead in amdvi_dump_cmds.

Reviewed by:	jhb
Approved by:	philip (mentor)
MFC after:	3 days
Differential Revision:	https://reviews.freebsd.org/D28862
62ffcaab tsoome March 23, 2021, 7:31 a.m.
Small visual nit, make menu title more clean

MFC after: 3 days
3ead6023 markj March 23, 2021, 2:21 a.m.
Make it easy to define interceptors for new sanitizer runtimes, rather
than assuming KCSAN.  Lay a bit of groundwork for KASAN and KMSAN.

When a sanitizer is compiled in, atomic(9) and bus_space(9) definitions
in atomic_san.h are used by default instead of the inline
implementations in the platform's atomic.h.  These definitions are
implemented in the sanitizer runtime, which includes
machine/{atomic,bus}.h with SAN_RUNTIME defined to pull in the actual

No functional change intended.

MFC after:	1 month
Sponsored by:	The FreeBSD Foundation
fb581531 rwatson March 22, 2021, 11:57 p.m.
MFC after:	3 days
Reviewed:	andrew
Differential Revision:	https://reviews.freebsd.org/D29369
599fb1d1 rwatson March 22, 2021, 11:49 p.m.
In both cases, too few frames were trimmed, leading to exception handling
or DTrace internals being exposed in stack traces exposed by D's stack()

MFC after:	3 days
Reviewed by:	emaste, andrew
9f88bee1 nwhitehorn March 22, 2021, 11:41 p.m.
c8923d19 nwhitehorn March 22, 2021, 7:58 p.m.