race condition using kernel_threads in hvcs.c

Ryan Arnold rsa at us.ibm.com
Fri May 28 09:52:26 EST 2004


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hvcs.c
Type: text/x-c
Size: 35123 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20040527/da29b4f7/attachment.bin>


More information about the Linuxppc-dev mailing list