[LTP] [PATCH v4 1/2] pty04: Use guarded buffers for transmission

[Richard Palethorpe]

Hi,

Richard Palethorpe <rpalethorpe@suse.de> writes:

> Hello,
>
> Petr Vorel <pvorel@suse.cz> writes:
>
>> Hi Richard,
>>
>>> Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
>>> ---
>>
>> Reviewed-by: Petr Vorel <pvorel@suse.cz>
>>
>> BTW Every second run with this patch it blocks after pty04.c:214: PASS: Read netdev 1
>> and then:
>> tst_checkpoint.c:147: BROK: pty04.c:249: tst_checkpoint_wait(0, 10000): ETIMEDOUT (110)
>> tst_test.c:373: BROK: Reported by child (26650)
>> safe_macros.c:258: BROK: pty04.c:215: read(5,0x7efebc306001,8191) failed, returned -1: ENETDOWN (100)
>> pty04.c:139: PASS: Writing to PTY interrupted by hangup
>> tst_test.c:373: WARN: Reported by child (26648)
>>
>> Tested on 5.7.0-rc3 in Tumbleweed.
>> But it looks this is not caused by this change, but was here before, because the
>> same behavior I see when testing pty04 *without* this patch on various kernels
>> (5.3.7, 5.6.0-rc5) and some of the never SLES (4.12 based).
>>
>> Kind regards,
>> Petr
>
> This looks similar to the issue reported by Jan:
>
> https://github.com/linux-test-project/ltp/issues/674
>
> Is this the full output?
>
> Thinking aloud: the following (probably) happens when writing to the PTY
>
> write() -> PTY -> SLIP/SLCAN -> netdev -> read()
>
> Writing to the PTY causes the PTY to write to the line discipline. What
> I found was that when the line discipline receive buffer got full and the PTY
> send buffer got full. The write would go to sleep and never wake up
> because the line discipline drained the receive buffer, but doesn't
> signal it is ready for more data (with tty_unthrottle). So I used
> nonblocking writes which just retry writing.
>
> From Jan's errors it looks like it might just be reading that is failing
> in one case and that writing is also failing in the other until we
> cancel the read. I doubt this is anything to do with the netdev code
> because it is generic networking code AFAICT and should work correctly
> with blocking reads...

Probably the best thing todo for now is to remove the test before the
release as this requires some more investigation.


-- 
Thank you,
Richard.