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.
|a0cbcbb7||jhb||Oct. 6, 2021, 9:08 p.m.||cryptodev: Allow some CIOCCRYPT operations with an empty payload.
If an operation would generate a MAC output (e.g. for digest operation or for an AEAD or EtA operation), then an empty payload buffer is valid. Only reject requests with an empty buffer for "plain" cipher sessions. Some of the AES-CCM NIST KAT vectors use an empty payload. While here, don't advance crp_payload_start for requests that use an empty payload with an inline IV. (*) Reported by: firstname.lastname@example.org (*) Reviewed by: markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32109cgit
|70dbebea||jhb||Oct. 6, 2021, 9:08 p.m.||cryptodev: Permit CIOCCRYPT for AEAD ciphers.|
|16676123||jhb||Oct. 6, 2021, 9:08 p.m.||cryptodev: Permit explicit IV/nonce and MAC/tag lengths.
Add 'ivlen' and 'maclen' fields to the structure used for CIOGSESSION2 to specify the explicit IV/nonce and MAC/tag lengths for crypto sessions. If these fields are zero, the default lengths are used. This permits selecting an alternate nonce length for AEAD ciphers such as AES-CCM which support multiple nonce leengths. It also supports truncated MACs as input to AEAD or ETA requests. Reviewed by: markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32107cgit
|5ae5ed5b||jhb||Oct. 6, 2021, 9:08 p.m.||cryptosoft, ccr: Use crp_iv directly for AES-CCM and AES-GCM.|
|1833d604||jhb||Oct. 6, 2021, 9:08 p.m.||crypto: Permit variable-sized IVs for ciphers with a reinit hook.
Add a 'len' argument to the reinit hook in 'struct enc_xform' to permit support for AEAD ciphers such as AES-CCM and Chacha20-Poly1305 which support different nonce lengths. Reviewed by: markj Sponsored by: Chelsio Communications, The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32105cgit
|cb128893||jhb||Oct. 6, 2021, 9:08 p.m.||ccp, ccr: Simplify drivers to assume an AES-GCM IV length of 12.|
|b4e0a27c||jhb||Oct. 6, 2021, 9:08 p.m.||cryptodev: Use 'csp' in the handlers for requests.
- Retire cse->mode and use csp->csp_mode instead. - Use csp->csp_cipher_algorithm instead of the ivsize when checking for the fixup for the IV length for AES-XTS. Reviewed by: markj Sponsored by: Chelsio Communications, The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32103cgit
|28ccd780||kbowling||Oct. 6, 2021, 9:03 p.m.||e1000: Function prototype cleanup|
|e7f8f3b9||0mp||Oct. 6, 2021, 8:51 p.m.||login.conf.5: Mark passwordtime as implemented
login.conf.5 listed passwordtime in RESERVED CAPABILITIES, which is a section for capabilities not implemented in the base system. However, passwordtime has been implemented in the base for several years now. PR: 246099 Reported by: avg Reviewed by: 0mp MFC after: 3 dayscgit
|f44a4487||asomers||Oct. 6, 2021, 8:28 p.m.||fusefs: fix intermittency in the dev_fuse_poll test
The DevFusePoll::access/select test would occasionally segfault. The cause was a file descriptor that was shared between two threads. The first thread would kill the second and close the file descriptor. But it was possible that the second would read the file descriptor before it shut down. That did not cause problems for kqueue, poll, or blocking operation, but it triggered segfaults in select's macros. MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D32142cgit
|880b670c||markj||Oct. 6, 2021, 8:09 p.m.||malloc: Unmark KASAN redzones if the full allocation size was requested
Consumers that want the full allocation size will typically access the full buffer, so mark the entire allocation as valid to avoid useless KASAN reports. Sponsored by: The FreeBSD Foundationcgit
|032a5bd5||asomers||Oct. 6, 2021, 8:07 p.m.||fusefs: Fix a bug during VOP_STRATEGY when the server changes file size
If the FUSE server tells the kernel that a file's size has changed, then the kernel must invalidate any portion of that file in cache. But the kernel can't do that during VOP_STRATEGY, because the file's buffers are already locked. Instead, proceed with the write. PR: 256937 Reported by: Agata <email@example.com> Tested by: Agata <firstname.lastname@example.org> MFC after: 2 weeks Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D32332cgit
|7430017b||asomers||Oct. 6, 2021, 8:07 p.m.||fusefs: fix a recurse-on-non-recursive lockmgr panic
fuse_vnop_bmap needs to know the file's size in order to calculate the optimum amount of readahead. If the file's size is unknown, it must ask the FUSE server. But if the file's data was previously cached and the server reports that its size has shrunk, fusefs must invalidate the cached data. That's not possible during VOP_BMAP because the buffer object is already locked. Fix the panic by not querying the FUSE server for the file's size during VOP_BMAP if we don't need it. That's also a a slight performance optimization. PR: 256937 Reported by: Agata <email@example.com> Tested by: Agata <firstname.lastname@example.org> MFC after: 2 weekscgit
|5d94aaac||asomers||Oct. 6, 2021, 8:07 p.m.||fusefs: quiet some cache-related warnings
If the FUSE server does something that would make our cache incoherent, we should print a warning to the user. However, we previously warned in some situations when we shouldn't, such as if the file's size changed on the server _after_ our own attribute cache had expired. This change suppresses the warning in cases like that. It also moves the warning logic to a single place within the code. PR: 256936 Reported by: Agata <email@example.com> Tested by: Agata <firstname.lastname@example.org>, jSML4ThWwBID69YC@protonmail.com MFC after: 2 weekscgit
|a76de177||markj||Oct. 6, 2021, 6:49 p.m.||linuxkpi: Handle a NULL cache pointer in kmem_cache_destroy()|