Messages in this thread | | | From | Sergei Organov <> | Subject | Re: [PATCH] Airprime driver improvements to allow full speed EvDO transfers | Date | Thu, 13 Jul 2006 18:17:10 +0400 |
| |
Alan Cox <alan@lxorguk.ukuu.org.uk> writes: > Ar Llu, 2006-07-10 am 19:54 +0400, ysgrifennodd Sergei Organov: >> Wow! The code you've quoted seems to be correct! But where did you get >> it from? The version of flush_to_ldisc() from drivers/char/tty_io.c from >> 2.17.4 got last Friday from kernel.org does this: > >> From HEAD so it should make 2.6.18. Paul fixed this one.
I've tested my driver with 2.6.18-rc1 and can confirm Paul changes finally fixed this particular problem. However, this fix unveiled different problem with the current tty buffering code.
The memory amount that could be used by tty buffers is uncontrolled. I've arranged a test[1] that demonstrates that tty buffers do indeed grow to the entire size of available memory at some conditions resulting in kernel starting to kill random processes until the testing process is killed.
This problem may occur with any tty driver that doesn't stop to insert data into the tty buffers in throttled state. And yes, there are such drivers in the tree. Before Paul's changes, the tty just dropped bytes that aren't accepted by ldisc, so this problem had no chances to arise.
I think that either the amount of memory used by tty buffers should be limited by a tty variable with a suitable default, or tty buffering should be changed not to accept data from drivers in throttled state. Alternatively, tty may rely on drivers not to insert data in the throttled state, but then it's better to be written in big red letters in the description of tty buffer interface routines. Though in the 2 latter cases drivers that insert too much data without pushing to ldisc may cause similar problem. Anyway, you definitely know better what to do about it.
[1] I have a USB device streaming data on its bulk endpoint. The device is handled by improved airprime driver (usb-to-tty converter) that could be found in Greg's patches. The driver attached the device to /dev/ttyUSB0. The testing application just opened /dev/ttyUSB0 and went to sleep, i.e., it just didn't read from the resulting fd. At these conditions the slab memory reported in /proc/meminfo grew linearly in time until in a few minutes kernel started to kill processes. The testing process wasn't the first one the kernel killed. It killed X server and some other applications until eventually it killed the testing process at which point things returned to normal operation.
-- Sergei. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |