On Mon, Mar 18, 2024 at 11:01 AM Nam Cao <namcao@xxxxxxxxxxxxx> wrote:
> Nice! I assume I can add
> Reported-and-tested-by: Eva Kurchatova <nyandarknessgirl@xxxxxxxxx>
> to the patch?
>
Yes.
You can also add link to upstream RVVM repo if anyone is interested in
reproduction. This RVVM patch applied to 0.6 makes a keystroke storm:
(window_update() is called on each display redraw and has access to hid_kb)
diff --git a/src/devices/fb_window.c b/src/devices/fb_window.c
index f170e2d..17e2519 100644
--- a/src/devices/fb_window.c
+++ b/src/devices/fb_window.c
@@ -77,6 +77,11 @@ static const uint8_t rvvm_logo_pix[] = {
static void window_update(rvvm_mmio_dev_t* device)
{
+ fb_window_t* win = device->data;
+ for (size_t i=0; i<100000; ++i) {
+ hid_keyboard_press(win->keyboard, HID_KEY_LEFTCTRL);
+ hid_keyboard_release(win->keyboard, HID_KEY_LEFTCTRL);
+ }
fb_window_update((fb_window_t*)device->data);
}
> I am still confused why RT throttling doesn't unstuck the kernel in this
> case. I will consult some people and investigate more on this. But I think
> this patch is good on its own, so I will send a proper patch shortly.
>
> Best regards,
> Nam
RT throttling kicked in *very* rarely, in most cases where the unpatched
kernel was actually stuck RT throttling wasn't reported at all.
It didn't hang every time either, so it's possible that RT throttling
helped sometimes, but not enough to always recover from such a loop:
[incoming IRQ]->[IRQ claimed]->[no handling]->[IRQ completion (which
immediately triggers phase 1 again)]
Best regards,
Eva
