WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/crypto/crypto.c?h=jd%2Fsimplify-queueing 2020-03-30T17:48:39Z 2020-03-30T17:48:39Z krw krw@openbsd.org 2020-03-30T17:48:39Z urn:sha1:cbf8475b9318827d4174f247f210e07ba24f7ac2 clearer what is being checked. Original suggestion from kettenis@. 2020-03-29T13:43:13Z krw krw@openbsd.org 2020-03-29T13:43:13Z urn:sha1:fbb739eb267b044ccd8998fbc4cb30373da24eb6 unregistering an invalid algorithm. CID 1453298 ok kettenis@ (with suggested improvements to come) 2017-11-30T16:31:12Z visa visa@openbsd.org 2017-11-30T16:31:12Z urn:sha1:2e84407f35579034f0ededa3b8f08f44afe6b9b0 is passed to the mutex implementation, and the queue actually runs without the kernel lock. Tested by dhill@ OK mikeb@, dhill@, kettenis@ 2017-02-07T17:25:45Z patrick patrick@openbsd.org 2017-02-07T17:25:45Z urn:sha1:e410e70d23f72ad4c503f395ca0443e81460573b by pre-allocating two cryptodesc objects and storing them in an array instead of a linked list. If more than two cryptodesc objects are required use mallocarray to fetch them. Adapt the drivers to the new API. This change results in one pool-get per ESP packet instead of three. It also simplifies softraid crypto where more cryptodesc objects are allocated than used. From, with and ok markus@, ok bluhm@ "looks sane" mpi@ 2016-09-19T18:09:40Z tedu tedu@openbsd.org 2016-09-19T18:09:40Z urn:sha1:4e5722bba036151ddcac34e049b1f58cdf184054 2016-09-15T02:00:16Z dlg dlg@openbsd.org 2016-09-15T02:00:16Z urn:sha1:1378bae268607a02c6648b2f5af62a452cd7f812 the ioff argument to pool_init() is unused and has been for many years, so this replaces it with an ipl argument. because the ipl will be set on init we no longer need pool_setipl. most of these changes have been done with coccinelle using the spatch below. cocci sucks at formatting code though, so i fixed that by hand. the manpage and subr_pool.c bits i did myself. ok tedu@ jmatthew@ @ipl@ expression pp; expression ipl; expression s, a, o, f, m, p; @@ -pool_init(pp, s, a, o, f, m, p); -pool_setipl(pp, ipl); +pool_init(pp, s, a, ipl, f, m, p); 2016-04-18T21:05:55Z kettenis kettenis@openbsd.org 2016-04-18T21:05:55Z urn:sha1:e2bfd84839ab78ed2e4a429dfa5f48d50f05fa40 CRYPTOCAP_F_MPSAFE flag that crypto implementations can set to indicate that their cc_process() implementation can safely run without holding the kernel lock. ok mikeb@ 2015-08-28T00:03:53Z deraadt deraadt@openbsd.org 2015-08-28T00:03:53Z urn:sha1:bae2bd509caafb58e32eb30678e33df546f85cbd 2015-02-09T03:15:41Z dlg dlg@openbsd.org 2015-02-09T03:15:41Z urn:sha1:79ea9c0869049943ab6cdc92992898acdc34b734 interrupt context to a taskq running in a thread. however, there is a concern that if we do that then we allow accidental use of sleeping APIs in this work, which will make it harder to move the work back to interrupts in the future. guenther and kettenis came up with the idea of marking a proc with CANTSLEEP which the sleep paths can check and panic on. this builds on that so you create taskqs that run with CANTSLEEP set except when they need to sleep for more tasks to run. the taskq_create api is changed to take a flags argument so users can specify CANTSLEEP. MPSAFE is also passed via this flags field now. this means archs that defined IPL_MPSAFE to 0 can now create mpsafe taskqs too. lots of discussion at s2k15 ok guenther@ miod@ mpi@ tedu@ pelikan@ 2015-01-27T03:17:35Z dlg dlg@openbsd.org 2015-01-27T03:17:35Z urn:sha1:e419548092f59c20a140404818050eb2ab331a19 when workqs were introduced, we provided a second argument so you could pass a thing and some context to work on it in. there were very few things that took advantage of the second argument, so when i introduced pools i suggested removing it. since tasks were meant to replace workqs, it was requested that we keep the second argument to make porting from workqs to tasks easier. now that workqs are gone, i had a look at the use of the second argument again and found only one good use of it (vdsp(4) on sparc64 if you're interested) and a tiny handful of questionable uses. the vast majority of tasks only used a single argument. i have since modified all tasks that used two args to only use one, so now we can remove the second argument. so this is a mechanical change. all tasks only passed NULL as their second argument, so we can just remove it. ok krw@