From: Dianne Skoll <dianne@skoll.ca>
To: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>
Subject: N_HDLC line discipline: Race condition
Date: Wed, 24 Apr 2024 17:31:14 -0400 [thread overview]
Message-ID: <20240424173114.035ddd7b@gato.skoll.ca> (raw)
[-- Attachment #1: Type: text/plain, Size: 2272 bytes --]
Hi,
I'm reposting here (originally emailed GregKH and Jiri Slaby directly
as they are listed as tty maintainers) as well as responding to a
reply from Greg.
Original mail:
Some people have been reporting bugs using synchronous PPP with the
rp-pppoe user-space program. See for example
https://github.com/dfskoll/rp-pppoe/issues/32
I've narrowed this down to the N_HDLC line discipline sometimes
concatenating two packets on the write side into a single read on the
other side. I have attached a proof-of-concept program illustrating
the problem.
If you run:
./test_n_hdlc
with no arguments, then the program makes two writes in quick succession
to the tty followed by a read. It generally only takes one or two tries
on my computer before I see both writes being combined in a single read.
On the other hand, if you run:
./test_n_hdlc foo
with a single argument, then the program sleeps for 0.1s between writes,
and I never see them being combined in a single read, even after 20 tries.
I'm running mainline kernel 6.8.7 on amd64; the processor model name
per cpuinfo is: AMD Ryzen Threadripper 3970X 32-Core Processor
Regards,
Dianne.
Greg's reply with my responses inline:
> What is wrong with that? Does the N_HDLC line discipline somewhere
> state that this is not possible to happen? Normal write combining
> happens for other tty ldiscs. Userspace should be able to handle
> this, unless again, the N_HDLC ldisc somehow says that this should
> never happen.
> Ok, I looked at the comments at the top of the the ldisc, and it says
> this should not happen, so something is odd, I agree.
Right. It's done that way so a PPP 'pty' helper always gets exactly one
frame when it reads from the tty file dscriptor.
> Did this change recently? Or has this always been the case? Meaning
> did something in the kernel change to cause this to break?
I haven't used this mode of PPP in over a decade, so I know it used to work,
but no longer does. I'm sorry I can't narrow down more precisely as to
when it stopped working.
> Also, please cc: the linux-serial list for tty issues, doing stuff in
> private is generally not a good idea.
OK, sorry about that... I misread the bug reporting instructions and
forgot to Cc the lists.
Regards,
Dianne.
[-- Attachment #2: test_n_hdlc.tar.gz --]
[-- Type: application/gzip, Size: 1085 bytes --]
next reply other threads:[~2024-04-24 21:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 21:31 Dianne Skoll [this message]
2024-04-25 18:01 ` N_HDLC line discipline: Race condition Dianne Skoll
2024-05-15 10:33 ` Jiri Slaby
2024-05-15 13:42 ` Dianne Skoll
2024-05-15 15:44 ` Dianne Skoll
2024-05-21 10:47 ` Jiri Slaby
2024-05-21 14:15 ` Dianne Skoll
2024-05-23 8:01 ` Jiri Slaby
2024-05-23 12:44 ` Dianne Skoll
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240424173114.035ddd7b@gato.skoll.ca \
--to=dianne@skoll.ca \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox