committer filter by committer.
@path/to/ filter by path in repository.
committer@path/to/ filter by committer AND path in repository.
NNN or rNNN filter by revision.
NNN-MMM or rNNN-rMMM filter by revisions range (inclusive).
Multiple filters can be specified separated by spaces or comas in which case they'll be combined using OR operator.
|r368246||bz||Dec. 1, 2020, 6:24 p.m.||USB umass: add quirk to not probe
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/D27434ViewVC
|r368245||jhb||Dec. 1, 2020, 6:22 p.m.||Use uintptr_t instead of uint64_t for pointers in stack frames.|
|r368242||jhb||Dec. 1, 2020, 6:08 p.m.||Use uintptr_t for pointers in stack frames.|
|r368241||jhb||Dec. 1, 2020, 5:17 p.m.||Make stack_save*() more robust on MIPS.
- 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/D27358ViewVC
|r368240||jhb||Dec. 1, 2020, 5:04 p.m.||Add a kstack_contains() helper function.|
|r368239||kp||Dec. 1, 2020, 4:44 p.m.||pf tests: Re-enable panicing tests
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 MDPayViewVC
|r368238||kp||Dec. 1, 2020, 4:34 p.m.||net: Revert vnet/epair cleanup race mitigation
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 MDPayViewVC
|r368237||kp||Dec. 1, 2020, 4:23 p.m.||if: Fix panic when destroying vnet and epair simultaneously
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/D27378ViewVC
|r368236||markj||Dec. 1, 2020, 4:06 p.m.||vmem: Revert r364744
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: rmacklemViewVC
|r368234||mm||Dec. 1, 2020, 3:53 p.m.||MFV r368207:
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 weekViewVC
|r368204||mmel||Dec. 1, 2020, 9:18 a.m.||Remove duplicated SV_ASLR from the elf flags.
Reported by: latteraViewVC
|r368203||mmel||Dec. 1, 2020, 8:52 a.m.||Always use the __unused attribute even for potentially unused parameters.
Requested by: ian, imp MFC with: r368167ViewVC
|r368200||mhorne||Nov. 30, 2020, 10:16 p.m.||efibootmgr: fix an incorrect error handling check
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/D27424ViewVC
|r368199||melifaro||Nov. 30, 2020, 9:59 p.m.||Move inner loop logic out of sysctl_sysctl_next_ls().
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/D27029ViewVC
|r368198||melifaro||Nov. 30, 2020, 9:42 p.m.||Renumber NHR_* flags after NHR_IFAIF removal in r368127.
Suggested by: rpokalaViewVC