Open Lyude opened 2 months ago
An orthogonal thing that makes sense is to make the Backend::lock
function take the Context
type. Then the SpinlockIrq
would be able to use IrqDisabled<'a>
as the GuardState
(it would also need a lifetime). And both lock
and unlock
would have proof that IRQs are disabled.
There is a slight problem with this idea: Guard::do_unlocked
. It uses Backend::relock
, which just calls Backend::lock
, but it obviously doesn't have access to Context
. So we need to find a way around that.
This also shows that do_unlocked
probably shouldn't be used with SpinlockIrq
, since the supplied closure isn't allowed to eg sleep (like how Condvar
currently does), since IRQs are still disabled.
This is a follow-up of !998 now that we have a better idea of what a design for enabling and disabling IRQs will look like. Currently, the most recent version of the patch series we have for interrupt management is here:
https://lkml.org/lkml/2024/8/1/1454
During the last re-spin of this series though, it was pointed out that there was a situation which I entirely missed.
with_irqs_disabled()
works great for simple situations where you just want to turn IRQs off for the duration of a callback, and then turn them back on afterwards. However, there's more complicated scenarios that can occur in the kernel. One such example that Benno provided:After quite a long discussion in https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/Spinlocks.20with.20IRQs.3F we were able to come up with a pretty decent idea for a solution to this that still allows the more simple
with_irqs_disabled
in its current form to remain safe code.Basically: once we start wanting to handle more complicated scenarios, we would:
OwnedIrqDisabled
type which can hand outIrqDisabled<'a>
tokenswith_irqs_disabled
towith_irqs_disabled_always
with_irqs_disabled
function that would provide access to anOwnedIrqDisabled
. This would come with a rather complicated safety contract.The safety contract would basically be something like this (I've just copied the summary I typed up already. Note, the examples are not complete!):
Currently this isn't part of the main series for the
irq
module, as I don't think we really have any users that need this quite yet.