Messages in this thread | | | Date | Tue, 03 Dec 2013 13:01:01 +0400 | From | Stas Sergeev <> | Subject | Re: Large pastes into readline enabled programs causes breakage from v2.6.31 onwards |
| |
03.12.2013 04:18, Peter Hurley пишет: > Unfortunately, this patch breaks EOF push handling. > > Normally, when an EOF is found not at the line start, the output > is made available to a canonical reader (without the EOF) -- this is > commonly referred to as EOF push. An EOF at the beginning of a line > forces the read to return 0 bytes read, which the caller interprets > as an end-of-file and discontinues reading. > > Since this patch simulates an EOF push, an actual EOF push that > follows will appear to be an EOF at the beginning of a line and > cause read to return 0, thus indicating premature end-of-file. > > I've attached a simulation testcase that shows the unexpected EOF. > > I think this general approach is still the way forward with this bug > but I need to ponder how the simulated EOF push state can properly be > distinguished from the other eol conditions in canon_copy_from_read_buf() > so line_start is not reset to the read_tail. Hi Peter, why do you think this is even a problem? If you enable icanon and the first thing you did was to send VEOF, then you need an EOF. If you want to be backward-compatible, you'll likely need to go that route, because currently it works exactly that way, except that the read buffer is lost. Other than preserving the read buffer, my patch was not supposed to change anything. I already have a program (written, tested, went to customer, used in production, oops sorry:) that switches to icanon and sends VEOF to simulate EOF. If you change this, then the behaviour will depend on whether the reader happened to read the data while still in RAW mode or already in icanon mode, which will create an unfixable race.
I think the only reliable and consistent fix would be to add ioctls for EOF and EOL pushes. Then people will not even need to switch back-n-forth like crazy. But as things are now, I think my patch is conservative and safe. Do you think it can break something real, other than the test-case? I think your test-case was made with the particular patch in mind, but it is not compatible with the current kernel, so it can't be "broken". -- 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/
| |