On 01.04.24 21:10, Wedson Almeida Filho wrote:
On Sun, 31 Mar 2024 at 07:27, Benno Lossin benno.lossin@proton.me wrote:
On 31.03.24 03:00, Wedson Almeida Filho wrote:
On Wed, 27 Mar 2024 at 13:04, Benno Lossin benno.lossin@proton.me wrote:
fn __init() -> core::ffi::c_int {{match <{type_} as kernel::Module>::init(&THIS_MODULE) {{Ok(m) => {{
/// # Safety////// This function must/// - only be called once,/// - be called after `__init`,/// - not be called concurrently with `__init`.The second item is incomplete: it must be called after `__init` *succeeds*.
Indeed.
With that added (which is a different precondition), I think the third item can be dropped because if you have to wait to see whether `__init` succeeded or failed before you can call `__exit`, then certainly you cannot call it concurrently with `__init`.
I would love to drop that requirement, but I am not sure we can. With that requirement, I wanted to ensure that no data race on `__MOD` can happen. If you need to verify that `__init` succeeded, one might think that it is not possible to call `__exit` such that a data race occurs, but I think it could theoretically be done if the concrete `Module` implementation never failed.
I see. If you're concerned about compiler reordering, then we need compiler barriers.
Do you have any suggestion for what I could add to the "be called after `__init` was called and returned `0`" requirement to make a data race impossible?
If you're concerned with reordering from the processor as well, then we need cpu barriers. You'd have to say that the cpu/thread executing `__init` must have a release barrier after `__init` completes, and the thread/cpu doing `__exit` must have an acquire barrier before starting `__exit`.
But I'm not sure we need to go that far. Mostly because C is going to guarantee that ordering for us, so I'd say we can just omit this or perhaps say "This function must only be called from the exit module implementation".
Yeah, though I do not exactly know where or what the "exit module implementation" is. If you are happy with v2, then I think we can go with that. This piece of code is also not really something people will need to read.