Linux Serial subsystem development
 help / color / mirror / Atom feed
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 --]

             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