r368246 bz Dec. 1, 2020, 6:24 p.m.
Some USB WLAN devices have "on-board" storage showing up as umass
and making the root mount wait for a very long time.
The WLAN drivers know how to deal with that an issue an eject
command later when attaching themselves.
Introduce a quirk to not probe these devices as umass and avoid
hangs and confusion altogether.

Reviewed by:	hselasky, imp
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D27434
ViewVC
r368245 jhb Dec. 1, 2020, 6:22 p.m.
Reviewed by:	andrew
Obtained from:	CheriBSD
Sponsored by:	DARPA
Differential Revision:	https://reviews.freebsd.org/D27361
ViewVC
r368242 jhb Dec. 1, 2020, 6:08 p.m.
This catches up to the changes made to struct unwind_state in r364180.

Reviewed by:	mhorne
Obtained from:	CheriBSD
Sponsored by:	DARPA
Differential Revision:	https://reviews.freebsd.org/D27360
ViewVC
r368241 jhb Dec. 1, 2020, 5:17 p.m.
- Validate any stack addresses read from against td_kstack before
  reading.  If an unwind operation would attempt to read outside the
  bounds of td_kstack, abort the unwind instead.

- For stack_save_td(), don't use the PC and SP from the current
  thread, instead read the PC and SP from pcb_context[].

- For stack_save(), use the current PC and SP of the current thread,
  not the values from pcb_regs (the horribly named td_frame of the
  outermost trapframe).  The result was that stack_trace() never
  logged _any_ kernel frames but only the frame from the saved
  userspace registers on entry from the kernel.

- Inline the one use of stack_register_fetch().

- Add a VALID_PC() helper macro and simplify types to remove
  excessive casts in stack_capture().

- Fix stack_capture() to work on compilers written in this century.
  Don't treat function epilogues as function prologues by skipping
  additions to SP when searching for a function start.

- Add some comments to stack_capture() and fix some style bugs.

Reviewed by:	arichardson
Obtained from:	CheriBSD
Sponsored by:	DARPA
Differential Revision:	https://reviews.freebsd.org/D27358
ViewVC
r368240 jhb Dec. 1, 2020, 5:04 p.m.
This is useful for stack unwinders which need to avoid out-of-bounds
reads of a kernel stack which can trigger kernel faults.

Reviewed by:	kib, markj
Obtained from:	CheriBSD
Sponsored by:	DARPA
Differential Revision:	https://reviews.freebsd.org/D27356
ViewVC
r368239 kp Dec. 1, 2020, 4:44 p.m.
We've fixed the vnet/epair cleanup race, so it is now safe to re-enable these
tests.

MFC after:	2 weeks
Sponsored by:	Modirum MDPay
ViewVC
r368238 kp Dec. 1, 2020, 4:34 p.m.
Revert the mitigation code for the vnet/epair cleanup race (done in r365457).
r368237 introduced a more reliable fix.

MFC after:	2 weeks
Sponsored by:	Modirum MDPay
ViewVC
r368237 kp Dec. 1, 2020, 4:23 p.m.
When destroying a vnet and an epair (with one end in the vnet) we often
panicked. This was the result of the destruction of the epair, which destroys
both ends simultaneously, happening while vnet_if_return() was moving the
struct ifnet to its home vnet. This can result in a freed ifnet being re-added
to the home vnet V_ifnet list. That in turn panics the next time the ifnet is
used.

Prevent this race by ensuring that vnet_if_return() cannot run at the same time
as if_detach() or epair_clone_destroy().

PR:		238870, 234985, 244703, 250870
MFC after:	2 weeks
Sponsored by:	Modirum MDPay
Differential Revision:	https://reviews.freebsd.org/D27378
ViewVC
r368236 markj Dec. 1, 2020, 4:06 p.m.
A pair of bugs are believed to have caused the hangs described in the
commit log message for r364744:

1. uma_reclaim() could trigger reclamation of the reserve of boundary
   tags used to avoid deadlock.  This was fixed by r366840.
2. The loop in vmem_xalloc() would in some cases try to allocate more
   boundary tags than the expected upper bound of BT_MAXALLOC.  The
   reserve is sized based on the value BT_MAXMALLOC, so this behaviour
   could deplete the reserve without guaranteeing a successful
   allocation, resulting in a hang.  This was fixed by r366838.

PR:		248008
Tested by:	rmacklem
ViewVC
r368234 mm Dec. 1, 2020, 3:53 p.m.
Update libarchive to 3.5.0

Relevant vendor changes:
  Issue #1258: add archive_read_support_filter_by_code()
  PR #1347: mtree digest reader support
  Issue #1381: skip hardlinks pointing to itself on extraction
  PR #1387: fix writing of cpio archives with hardlinks without file type
  PR #1388: fix rdev field in cpio format for device nodes
  PR #1389: completed support for UTF-8 encoding conversion
  PR #1405: more formats in archive_read_support_format_by_code()
  PR #1408: fix uninitialized size in rar5_read_data
  PR #1409: system extended attribute support
  PR #1435: support for decompression of symbolic links in zipx archives
  Issue #1456: memory leak after unsuccessful archive_write_open_filename

MFC after:	1 week
ViewVC
r368204 mmel Dec. 1, 2020, 9:18 a.m.
Reported by:	lattera
ViewVC
r368203 mmel Dec. 1, 2020, 8:52 a.m.
Requested by:	ian, imp
MFC with:	r368167
ViewVC
r368200 mhorne Nov. 30, 2020, 10:16 p.m.
efivar_device_path_to_unix_path() returns standard error codes on
failure and zero on success. Checking for a return value less than zero
means that the actual failure cases won't be handled. This could
manifest as a segfault during the subsequent call to printf().

Reviewed by:	imp
MFC after:	3 days
Differential Revision:	https://reviews.freebsd.org/D27424
ViewVC
r368199 melifaro Nov. 30, 2020, 9:59 p.m.
Refactor sysctl_sysctl_next_ls():
* Move huge inner loop out of sysctl_sysctl_next_ls() into a separate
 non-recursive function, returning the next step to be taken.
* Update resulting node oid parts only on successful lookup
* Make sysctl_sysctl_next_ls() return boolean success/failure instead of errno,
 slightly simplifying logic

Reviewed by:	freqlabs
Differential Revision:	https://reviews.freebsd.org/D27029
ViewVC
r368198 melifaro Nov. 30, 2020, 9:42 p.m.
Suggested by:	rpokala
ViewVC