Re: [PATCH] tty: Fix race condition if flushing tty flip buffers

From: Greg Kroah-Hartman
Date: Mon Apr 08 2013 - 14:48:14 EST


On Wed, Mar 20, 2013 at 01:20:43PM -0400, Peter Hurley wrote:
> As Ilya Zykov identified in his patch 'PROBLEM: Race condition in
> tty buffer's function flush_to_ldisc()', a race condition exists
> which allows a parallel flush_to_ldisc() to flush and free the tty
> flip buffers while those buffers are in-use. For example,
>
> CPU 0 | CPU 1 | CPU 2
> | flush_to_ldisc() |
> | grab spin lock |
> tty_buffer_flush() | | flush_to_ldisc()
> wait for spin lock | | wait for spin lock
> | if (!test_and_set_bit(TTYP_FLUSHING)) |
> | while (next flip buffer) |
> | ... |
> | drop spin lock |
> grab spin lock | |
> if (test_bit(TTYP_FLUSHING)) | |
> set_bit(TTYP_FLUSHPENDING) | receive_buf() |
> drop spin lock | |
> | | grab spin lock
> | | if (!test_and_set_bit(TTYP_FLUSHING))
> | | if (test_bit(TTYP_FLUSHPENDING))
> | | __tty_buffer_flush()
>
> CPU 2 has just flushed and freed all tty flip buffers while CPU 1 is
> transferring data from the head flip buffer.
>
> The original patch was rejected under the assumption that parallel
> flush_to_ldisc() was not possible. Because of necessary changes to
> the workqueue api, work items can execute in parallel on SMP.
>
> This patch differs slightly from the original patch by testing for
> a pending flush _after_ each receive_buf(), since TTYP_FLUSHPENDING
> can only be set while the lock is dropped around receive_buf().
>
> Reported-by: Ilya Zykov <linux@xxxxxxx>
> Signed-off-by: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
> ---
> drivers/tty/tty_buffer.c | 22 ++++++++++------------
> 1 file changed, 10 insertions(+), 12 deletions(-)

What tree is this against? Does it need your other larger set of ldisc
patches, or can it be applied without it?

confused,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/