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.
|d765b211||andrew||Feb. 19, 2021, 3:31 p.m.||Remove __XSCALE__ checks from the arm code
XScale support was removed over 2 years ago, remove the last __XSCALE__ checks from the arm MD code. Sponsored by: Innovate UKcgit
|853fd7a2||rscheff||Feb. 19, 2021, 12:55 p.m.||Ensure cwnd doesn't shrink to zero with PRR|
|248a47a4||debdrup||Feb. 19, 2021, 12:42 p.m.||ports(7): Update instructions for package target
Packages default to ending up in a different location compared to the documentation, so catch up to the implementation by referring to the location where packages can usually be found if no environment variables have been set. While here, also update the mention of the file extension to match the txz format that packages use. PR: 253179, 224370 Reported by: rwatson, jeromer at fastmail dotnetcgit
|4c0bef07||kevans||Feb. 19, 2021, 4:36 a.m.||kern: net: remove TCP_LINGERTIME
TCP_LINGERTIME can be traced back to BSD 4.4 Lite and perhaps beyond, in exactly the same form that it appears here modulo slightly different context. It used to be the case that there was a single pr_usrreq method with requests dispatched to it; these exact two lines appeared in tcp_usrreq's PRU_ATTACH handling. The only purpose of this that I can find is to cause surprising behavior on accepted connections. Newly-created sockets will never hit these paths as one cannot set SO_LINGER prior to socket(2). If SO_LINGER is set on a listening socket and inherited, one would expect the timeout to be inherited rather than changed arbitrarily like this -- noting that SO_LINGER is nonsense on a listening socket beyond inheritance, since they cannot be 'connected' by definition. Neither Illumos nor Linux reset the timer like this based on testing and inspection of Illumos, and testing of Linux. Reviewed by: rscheff, tuexen Differential Revision: https://reviews.freebsd.org/D28265cgit
|812c9f48||mav||Feb. 19, 2021, 3:29 a.m.||Save context switch per I/O for iSCSI and IOCTL frontends.
Introduce new CTL core KPI ctl_run(), preprocessing I/Os in the caller context instead of scheduling another thread just for that. This call may sleep, that is not acceptable for some frontends like the original CAM/FC one, but iSCSI already has separate sleepable per-connection RX threads, and another thread scheduling is mostly just a waste of time. IOCTL frontend actually waits for the I/O completion in the caller thread, so the use of another thread for this has even less sense. With this change I can measure ~5% IOPS improvement on 4KB iSCSI I/Os to ZFS. MFC after: 1 monthcgit
|4621c4f2||emaste||Feb. 19, 2021, 1:45 a.m.||tests/sys/audit: force PIE off
df093aa9463b linked against libprivateauditd.a, but that is currently (and incorrectly) built as position-dependent. For now just force PIE off for this test to fix the WITH_PIE build. Sponsored by: The FreeBSD Foundationcgit
|80ab50e1||gjb||Feb. 18, 2021, 11:53 p.m.||pass UNAME_r to fix building 14.x ports on 13.x
MFC after: 1 week Sponsored by: Rubicon Communications, LLC ("Netgate")cgit
|e7adccf7||noreply||Feb. 18, 2021, 11:51 p.m.||FreeBSD: disable the use of hardware crypto offload drivers for now
First, the crypto request completion handler contains a bug in that it fails to reset fs_done correctly after the request is completed. This is only a problem for asynchronous drivers. Second, some hardware drivers have input constraints which ZFS does not satisfy. For instance, ccp(4) apparently requires the AAD length for AES-GCM to be a multiple of the cipher block size, and with qat(4) the AES-GCM AAD length may not be longer than 240 bytes. FreeBSD's generic crypto framework doesn't have a mechanism to automatically fall back to a software implementation if a hardware driver cannot process a request, and ZFS does not tolerate such errors. The plan is to implement such a fallback mechanism, but with FreeBSD 13.0 approaching we should simply disable the use hardware drivers for now. Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Reviewed-by: Alexander Motin <mav@FreeBSD.org> Signed-off-by: Mark Johnston <markj@FreeBSD.org> Closes #11612cgit
|bdde49b7||rpokala||Feb. 18, 2021, 11:08 p.m.||nvdimm(4): Export NVDIMM health flags via sysctl
The ACPI NFIT specification defines a set of "NVDIMM State Flags". These flags are already reported by `acpidump -t', but this change makes them available on a per-device basis, in a format that is more easily parsed. To simplify this, introduce acpi_nfit_get_memory_maps_by_dimm(), which locates the (ACPI_NFIT_MEMORY_MAP)s associated with a given (nfit_handle_t). Reviewed by: mav, cem Tested by: mav, rpokala (version for stable/12) MFC after: 3 days Sponsored by: Panasascgit
|2f48313a||rmacklem||Feb. 18, 2021, 10:38 p.m.||nfs-over-tls: add rc scripts for rpc.tlsclntd and rpc.tlsservd|
|b9cbc85d||rmacklem||Feb. 18, 2021, 10:15 p.m.||nfs-over-tls: add user space daemons rpc.tlsclntd and rpc.tlsservd
The kernel changes needed for nfs-over-tls have been committed to main. However, nfs-over-tls requires user space daemons to handle the TLS handshake and other non-application data TLS records. There is one daemon (rpc.tlsclntd) for the client side and one daemon (rpc.tlsservd) for the server side, although they share a fair amount of code found in rpc.tlscommon.c and rpc.tlscommon.h. They use a KTLS enabled OpenSSL to perform the actual work and, as such, are only built when MK_OPENSSL_KTLS is set. Communication with the kernel is done via upcall RPCs done on AF_LOCAL sockets and the custom system call rpctls_syscall. Reviewed by: gbe (man pages only), jhb (usr.sbin/Makefile only) Comments by: jhb MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D28430 Relnotes: yescgit
|778869fa||noreply||Feb. 18, 2021, 9:53 p.m.||Fix report_mount_progress never calling set_progress_header
That happens because of an off-by-one mistake. share_mount_one_cb() calls report_mount_progress(current=sm_done) after having incremented sm_done by one. Then report_mount_progress() increments the parameter again. It appears that that logic became obsolete after commit a10d50f999511, parallel zfs mount. On FreeBSD I observe that zfs mount -a -v prints, for example, (null): (201/248) That happens because set_progress_header() is never called. With this change the output becomes correct: Mounting ZFS filesystems: (209/248) Reviewed-by: Brian Behlendorf <firstname.lastname@example.org> Signed-off-by: Andriy Gapon <avg@FreeBSD.org> Closes #11607cgit
|c67a2909||mav||Feb. 18, 2021, 9:31 p.m.||Move XPT_IMMEDIATE_NOTIFY handling out of periph lock.
It is a rare, but still better to not have lock dependencies. MFC after: 1 monthcgit
|0ee0dbfb||dim||Feb. 18, 2021, 9:30 p.m.||Merge libcxxrt master 8049924686b8414d8e652cbd2a52c763b48e8456
Interesting fixes: b3c73ba libelftc_dem_gnu3: Sync with elftoolchain r3877 7b2335c Mostly fix __cxa_demangle after #3 Reported by: arichardson PR: 253226 MFC after: 3 dayscgit
|04d2d2d7||mhorne||Feb. 18, 2021, 9:17 p.m.||cgem: improve usage of busdma(9) KPI
BUS_DMA_NOCACHE should only be used when one needs to guarantee the created mapping has uncached memory attributes, usually as a result of buggy hardware. Normal use cases should pass BUS_DMA_COHERENT, to create an appropriate mapping based on the flags passed to bus_dma_tag_create(). This should have no functional change, since the DMA tags in this driver are created without the BUS_DMA_COHERENT flag. Reported by: mmel Reviewed by: mmel, Thomas Skibo <email@example.com> MFC after: 3 dayscgit