Re: Large pastes into readline enabled programs causes breakage from v2.6.31 onwards

[Stas Sergeev <stsp@list.ru>]

04.12.2013 03:53, Peter Hurley пишет:
> On 12/03/2013 02:18 PM, Stas Sergeev wrote:
>> 03.12.2013 21:00, Peter Hurley пишет:
>>> Any unit test is specifically designed to break the code under test.
>>> This unit test does in fact break a possible input: note specifically
>>> that the writer is not changing the termios so has no control over
>>> the timing of when the input is received.
>>>
>>> Also note that the test is a simulation; the patch will break any
>>> input stream under the following conditions:
>>> 1. The writer writes an EOF-terminated buffer
>>> 2. All the input is received _except_ the EOF; this is strictly
>>>    timing-related and not controllable.
>>> 3. The reader changes the termios from non-canon -> canon.
>>>
>>> At that point the damage is done; the read_flags will indicate
>>> 2 EOFs and the 2nd EOF will be interpreted as end-of-file because
>>> it will appear to begin on a new line.
>> How is this different from the unpatched kernel?
>> In the unpatched kernel, if you happen on reader side
>> to enable icanon while n_tty received all but VEOF (is this possible 
>> at all?),
>> then the buffer will be flushed, and the remaining VEOF
>> will get you a nice EOF.
>> So, in the unpatched kernel you get EOF because the buffer
>> gets wiped.
>
> ???
>
> Testcase output from 3.12 w/o patch:
OK, sorry, after a year of rot of my patch in bugzilla, I've
completely forgot the pre-conditions, which is that the
buffer is not discarded, just not pushed.

> Consider the total brute-force approach; a shadow read_flags that
> distinguishes a real EOF receive from the fake EOF push initiated
> by the patch.
What is to do with them?
Remove all "fake" EOFs on receiving the real one?
But that will depend on whether the reader happened to
read everything before the real one arrived.
I think that changing termios on reader side while another
process is writing, is full of surprises. For example, even in
your test-case (without the patch) the writer could expect
that the reader would receive the VEOF char in raw mode.
But the reader switced icanon and the VEOF char is not being read.
And I am sure there are other oddities to suspect, so why
the unexpected EOF is any worse?

> That would work, but I'm looking for a solution more
> space-efficient and simpler than a duplicate 256-byte buffer 
I think "fake" EOFs do not need the entire bitmap.
It is only important to remember the position where icanon was
enabled the last time I suppose, even if it was switched many
times.