| 7a4d1d1d | 18-Jan-2024 |
Aaron LI <aly@aaronly.me> |
if_wg: fix access to noise_local->l_has_identity and l_private
These members are protected by the identity lock, so rlock it in
noise_remote_alloc() and then assert that we have it held to some exte
if_wg: fix access to noise_local->l_has_identity and l_private
These members are protected by the identity lock, so rlock it in
noise_remote_alloc() and then assert that we have it held to some extent
in noise_precompute_ss().
PR: 276392
show more ...
|
| b08ee10c | 21-Jun-2023 |
Kyle Evans <kevans@FreeBSD.org> |
wg: fix a number of issues with module load failure handling
If MOD_LOAD fails, then MOD_UNLOAD will be called to unwind module
state, but wg_module_init() will have already deinitialized everything
wg: fix a number of issues with module load failure handling
If MOD_LOAD fails, then MOD_UNLOAD will be called to unwind module
state, but wg_module_init() will have already deinitialized everything
it needs to in a manner that renders it unsafe to call MOD_UNLOAD
after (e.g., freed zone not reset to NULL, wg_osd_jail_slot not reset
to 0). Let's simply stop trying to handle freeing everything in
wg_module_init() to simplify it; let the subsequent MOD_UNLOAD deal with
it, and let's make that robust against partially-constructed state.
jhb@ notes that MOD_UNLOAD being called if MOD_LOAD fails is kind of an
anomaly that doesn't match other paradigms in the kernel; e.g., if
device_attach() fails, we don't invoke device_detach(). It's likely
that a future commit will revert this and instead stop calling
MOD_UNLOAD if MOD_LOAD fails, expecting modules to clean up after
themselves in MOD_LOAD upon failure. Some other modules already do this
and may see similar problems to the wg module (see: carp). The proper
fix is decidedly a bit too invasive to do this close to 14 branching,
and it requires auditing all kmods (base + ports) for potential leaks.
PR: 272089
Reviewed by: emaste
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D40708
show more ...
|
| 854d0662 | 28-Oct-2022 |
John Baldwin <jhb@FreeBSD.org> |
wg: Trim compat shims for versions older than current stable/13.
Reviewed by: kevans, markj, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36913 |
| c640d1af | 28-Oct-2022 |
John Baldwin <jhb@FreeBSD.org> |
wg: Retire now unused support.h.
Reviewed by: kevans, markj, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36912 |
| e32e1a16 | 28-Oct-2022 |
John Baldwin <jhb@FreeBSD.org> |
wg: Use atomic(9) instead of concurrency-kit atomics.
Kernel sanitizers only support atomic(9) operations.
Reviewed by: kevans, markj, emaste
Reported by: markj
Sponsored by: The FreeBSD Foundation
wg: Use atomic(9) instead of concurrency-kit atomics.
Kernel sanitizers only support atomic(9) operations.
Reviewed by: kevans, markj, emaste
Reported by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36910
show more ...
|