race condition using kernel_threads in hvcs.c
From: Ryan Arnold <hidden>
Date: 2004-05-27 23:52:26
Ben, I've modeled hvcs's usage of kernel_threads for scheduling I/O on your recent changes to hvc_console.c as reflected in the Ameslab tree. The scheduling of hvcs performs admirably under most circumstance but I'm experiencing a timing window race condition under heavy I/O. The scenario is that hvcs_write() [which is invoked via the tty layer's write thread] is, at times, unable to write to the vty-server device due to a full hypervisor buffer. When this happens the driver buffers a character, flags the hvcs_struct.todo_flag |= HVCS_TRY_WRITE and then hvcs_kicks() the kernel thread (which awakens it). The hvcs_write() function returns a partial write notification to the tty write thread, who then sleeps. The kernel thread is supposed to wake up if it is sleeping, and continue attempting to send the character to all hvcs_struct instances whose todo_flags have I/O requested, particularly until it succeeds at sending the buffered character to the hypervisor, at which point it wakes the tty write thread [at least I _think_ it does]. Under heavy I/O it appears that what happens is that somehow the kernel thread doesn't recognize that I/O has been requested for one of the hvcs_struct instances and control drops to the schedule() call even though the thread has supposedly been kicked. Unfortunately adding printk's to the hvcs_try_write() function seems to eliminate the race condition even though it makes the output jerky. I have no idea what is happening and I seem to have tried everything. I'm also aware that I need a way to terminate the kernel_thread when the driver is removed. I just neglected to implement it. Ryan S. Arnold IBM Linux Technology Center