On 20.01.2026 00:23, Stefano Stabellini wrote: > On Mon, 19 Jan 2026, Jan Beulich wrote: >> On 14.01.2026 01:39, Stefano Stabellini wrote: >>> @@ -815,6 +831,11 @@ long do_console_io( >>> if ( count > INT_MAX ) >>> break; >>> >>> + d = console_get_domain(); >>> + console_put_domain(d); >>> + if ( d != current->domain ) >>> + return 0; >> >> This isn't atomic (as in: in a suitably locked region) with ... >> >>> @@ -830,7 +851,10 @@ long do_console_io( >>> break; >>> } >>> rc += len; >>> - serial_rx_cons += len; >>> + nrspin_lock_irq(&console_lock); >>> + if ( serial_rx_cons != serial_rx_prod ) >>> + serial_rx_cons += len; >>> + nrspin_unlock_irq(&console_lock); >>> } >>> break; >> >> ... this. If the focus domain changes after the check in the earlier hunk, >> I think you need to also return with no input here. Or you need to acquire >> the lock earlier (and then similarly in console_switch_input()), albeit >> that would then mean holding it across a copy-to-guest. Which technically >> is perhaps not a problem, but it leaves an uneasy feeling. > > I thought about it when writing this patch and I had the same feeling as > you. However, especially considering the other feedback, I don't see > another viable solution.
Taking just the logic here, an option might be to re-check the focus domain once holding the lock, and discard the most recent chunk of input from what would go back to the caller if the focus changed. But that would come with its own new complexities. Jan
