committer filter by committer.
@path/to/ filter by path in repository.
committer@path/to/ filter by committer AND path in repository.
abdef0123 filter by commit's SHA hash.
rNNN filter by SVN revision.
rNNN-rMMM filter by SVN revisions range (inclusive).
Multiple filters can be specified separated by spaces or comas in which case they'll be combined using OR operator.
|cb130596||kp||Sept. 23, 2021, 7:56 p.m.||pf: fix pagefault in pf_getstatus()
We can't copyout() while holding a lock, in case it triggers a page fault. Release the lock before copyout, which is safe because we've already copied all the data into the nvlist. PR: 258601 Reviewed by: mjg MFC after: 1 week Sponsored by: Modirum MDPay Differential Revision: https://reviews.freebsd.org/D32076cgit
|d5ad2f2a||kbowling||Sept. 23, 2021, 7:41 p.m.||e1000: fix K1 configuration
This patch is for the following updates to the K1 configurations: Tx idle period for entering K1 should be 128 ns. Minimum Tx idle period in K1 should be 256 ns. Signed-off-by: Wenzhuo Lu <email@example.com> PR: 258153 Reviewed by: erj Tested by: firstname.lastname@example.org Approved by: imp Obtained from: DPDK (6f934fa24dfd437c90ead96bc7598ee77a117ede) MFC after: 1 weekcgit
|f555b39e||kevans||Sept. 23, 2021, 7:13 p.m.||man: reset OPTIND before parsing args
From jilles: POSIX requires that a script set `OPTIND=1` before using different sets of parameters with `getopts`, or the results will be unspecified. The specific problem observed here is that we would execute `man -f` or `man -k` without cleaning up state from man_parse_args()' `getopts` loop. FreeBSD's /bin/sh seems to reset OPTIND to 1 after we hit the second getopts loop, rendering the following shift harmless; other /bin/sh implementations will leave it at what we came into the loop at (e.g., bash as /bin/sh), shifting off any keywords that we had. Input from: jilles Reviewed by: allanjude, bapt, imp Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D32063cgit
|ef50d5fb||mav||Sept. 23, 2021, 6:31 p.m.||x86: Add NUMA nodes into CPU topology.
Depending on hardware, NUMA nodes may match last level caches, or they may be above them (AMD Zen 2/3) or below (Intel Xeon w/ SNC). This information is provided by ACPI instead of CPUID, and it is provided for each CPU individually instead of mask widths, but this code should be able to properly handle all the above cases. This change should immediately allow idle stealing in sched_ule(4) to prefer load from NUMA-local CPUs to remote ones when the node does not match LLC. Later we may think of how to better handle it on sched_pickcpu() side. MFC after: 1 monthcgit
|1ca931a5||rrs||Sept. 23, 2021, 3:43 p.m.||tcp: Rack compressed ack path updates the recv window too easily
The compressed ack path of rack is not following proper procedures in updating the peers window. It should be checking the seq and ack values before updating and instead it is blindly updating the values. This could in theory get the wrong window in the connection for some length of time. Reviewed by: tuexen Sponsored by: Netflix Inc. Differential Revision: https://reviews.freebsd.org/D32082cgit
|fd69939e||rrs||Sept. 23, 2021, 2:54 p.m.||tcp: Two bugs in rack one of which can lead to a panic.
In extensive testing in NF we have found two issues inside the rack stack. 1) An incorrect offset is being generated by the fast send path when a fast send is initiated on the end of the socket buffer and before the fast send runs, the sb_compress macro adds data to the trailing socket. This fools the fast send code into thinking the sb offset changed and it miscalculates a "updated offset". It should only do that when the mbuf in question got smaller.. i.e. an ack was processed. This can lead to a panic deref'ing a NULL mbuf if that packet is ever retransmitted. At the best case it leads to invalid data being sent to the client which usually terminates the connection. The fix is to have the proper logic (that is in the rsm fast path) to make sure we only update the offset when the mbuf shrinks. 2) The other issue is more bothersome. The timestamp check in rack needs to use the msec timestamp when comparing the timestamp echo to now. It was using a microsecond timestamp which ends up giving error prone results but causes only small harm in trying to identify which send to use in RTT calculations if its a retransmit. Reviewed by: tuexen Sponsored by: Netflix Inc. Differential Revision: https://reviews.freebsd.org/D32062cgit
|dbc7ca59||emaste||Sept. 23, 2021, 1:51 p.m.||vt: bound buffer access in redraw optimization|
|414499b3||tuexen||Sept. 23, 2021, 12:16 p.m.||sctp: Cleanup stream schedulers.
No functional change intended. MFC after: 1 weekcgit
|0b92a7fe||wma||Sept. 23, 2021, 8:57 a.m.||LACP: Do not wait response for marker messages not sent
The error returned when a marker message can not be emitted on a port is not handled. This cause the lacp to block all emissions until the timeout of 3 seconds is reached. To fix this issue, I just clear the LACP_PORT_MARK flag when the packet could not be emitted. Differential revision: https://reviews.freebsd.org/D30467 Obtained from: Stormshieldcgit
|492bf4fd||wma||Sept. 23, 2021, 8:53 a.m.||veriexec: Fix veriexec -i's confusion between loaded and locked states|
|d2c23317||wma||Sept. 23, 2021, 8:43 a.m.||sh: Add -o verify to use O_VERIFY when sourcing scripts
Add -o verify to sh to make it use O_VERIFY when sourcing scripts and reading profiles. Useful in conjunction with mac_veriexec to help protect at least some parts of the boot sequence, e.g., /etc/rc*. Differential revision: https://reviews.freebsd.org/D30464 Reviewed by: jilles, sjg Obtained from: Stormshieldcgit
|90f6610b||hselasky||Sept. 23, 2021, 7:49 a.m.||UPDATING: Fix spelling.|
|5e79bba5||kevans||Sept. 23, 2021, 6:03 a.m.||kern: random: collect ~16x less from fast-entropy sources
Previously, we were collecting at a base rate of: 64 bits x 32 pools x 10 Hz = 2.5 kB/s This change drops it to closer to 64-ish bits per pool per second, to work a little better with entropy providers in virtualized environments without compromising the security goals of Fortuna. Reviewed by: #csprng (cem, delphij, markm) Differential Revision: https://reviews.freebsd.org/D32021cgit
|6895cade||kevans||Sept. 23, 2021, 6:03 a.m.||kern: random: drop read_rate and associated functionality
Refer to discussion in PR 230808 for a less incomplete discussion, but the gist of this change is that we currently collect orders of magnitude more entropy than we need. The excess comes from bytes being read out of /dev/*random. The default rate at which we collect entropy without the read_rate increase is already more than we need to recover from a compromise of an internal state. Reviewed by: #csprng (cem, delphij, markm) Differential Revision: https://reviews.freebsd.org/D32021cgit
|7bc13692||wma||Sept. 23, 2021, 5:15 a.m.||hwpmc: fix performance issues
Differential revision: https://reviews.freebsd.org/D32025 Avoid using atomics as it_wait is guarded by td_lock. Report threshold calculation is done only if at least one PMC hook is installed Fixes: * avoid unnecessary branching (if frame != null ...) by having PMC_HOOK_INSTALLED_ANY condition on the top of them, which should hint the core not to execute speculatively anything which us underneath; * access intr_hwpmc_waiting_report_threshold cacheline only if at least one hook is loaded;cgit