> @@ -179,8 +180,8 @@ const fn deactivating_bit(old: u64, new: u64, shift:
> usize) -> bool {
> fn timer_handler(timer_cell: &BqlRefCell<HPETTimer>) {
> let mut t = timer_cell.borrow_mut();
> // SFAETY: state field is valid after timer initialization.
> - let regs = &mut unsafe { t.state.as_mut() }.regs.borrow_mut();
> - t.callback(regs)
> + let mut regs = unsafe { t.state.as_ref() }.regs.lock().unwrap();
> + t.callback(&mut regs)
> }
callback()
-> arm_timer(): access timer N register
-> update_irq(): modify global register (int_status or "isr" in C code)
So timer handler needs to lock Mutex. But this may cause deadlock:
timer_hanlder -> lock BQL -> try to lock Mutex
MMIO access -> lock Mutex -> try to lock BQL
C HPET doesn't have such deadlock issue since it doesn't lock Mutex in
timer handler.
I think it seems necessay to lock Mutex in timer handler since there's
no guarantee to avoid data race...
Thanks,
Zhao
