[PATCH] tty: n_tty: convert the full VTIME interval to jiffies

[PATCH] tty: n_tty: convert the full VTIME interval to jiffies

[Hungyu Lin]

VTIME specifies a timeout in tenths of a second, but n_tty_read() divides
HZ by 10 before multiplying by VTIME. For supported HZ values that are
not divisible by 10, this truncates each decisecond and shortens the
requested interval. For example, HZ=128 and VTIME=40 produce 480 ticks
instead of 512 ticks for four seconds.

Convert the full interval to milliseconds before calling
msecs_to_jiffies(), for both the read and inter-byte timeouts. This
preserves zero VTIME and avoids accumulating the initial division's
rounding loss.

Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
---
 drivers/tty/n_tty.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index e6a0f5b40d0a..e485cf36dfa1 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -2219,9 +2219,9 @@ static ssize_t n_tty_read(struct tty_struct *tty, struct file *file, u8 *kbuf,
 	if (!ldata->icanon) {
 		minimum = MIN_CHAR(tty);
 		if (minimum) {
-			time = (HZ / 10) * TIME_CHAR(tty);
+			time = msecs_to_jiffies(100 * TIME_CHAR(tty));
 		} else {
-			timeout = (HZ / 10) * TIME_CHAR(tty);
+			timeout = msecs_to_jiffies(100 * TIME_CHAR(tty));
 			minimum = 1;
 		}
 	}
-- 
2.43.0

Re: [PATCH] tty: n_tty: convert the full VTIME interval to jiffies

[Greg KH]

On Thu, Oct 29, 2026 at 12:20:52AM +0000, Hungyu Lin wrote:
> VTIME specifies a timeout in tenths of a second, but n_tty_read() divides
> HZ by 10 before multiplying by VTIME. For supported HZ values that are
> not divisible by 10, this truncates each decisecond and shortens the
> requested interval. For example, HZ=128 and VTIME=40 produce 480 ticks
> instead of 512 ticks for four seconds.

What real system uses HZ=128 ?

In other words, is this a real issue at all?

thanks,

greg k-h

Re: [PATCH] tty: n_tty: convert the full VTIME interval to jiffies

[Hungyu Lin]

> What real system uses HZ=128 ?
>
> In other words, is this a real issue at all?

AT91RM9200, for example. arch/arm/Kconfig fixes HZ to 128 when
CONFIG_SOC_AT91RM9200 is enabled.

OpenWrt also uses HZ=128 for its at91/sam9x target; see
target/linux/at91/sam9x/config-6.18. It publishes images for
SAM9X60-EK and AT91SAM9G20-EK, among other boards.

Thanks,
Hungyu

Re: [PATCH] tty: n_tty: convert the full VTIME interval to jiffies

[Greg KH]

On Wed, Oct 28, 2026 at 11:38:28PM -0700, Hungyu Lin wrote:
> > What real system uses HZ=128 ?
> >
> > In other words, is this a real issue at all?
> 
> AT91RM9200, for example. arch/arm/Kconfig fixes HZ to 128 when
> CONFIG_SOC_AT91RM9200 is enabled.
> 
> OpenWrt also uses HZ=128 for its at91/sam9x target; see
> target/linux/at91/sam9x/config-6.18. It publishes images for
> SAM9X60-EK and AT91SAM9G20-EK, among other boards.

Ok, and has it ever reported problems with this rounding error?  This is
very old code, changing it needs to be done only if an issue is actually
noticed as it might be relied on, right?

thanks,

greg k-h

Re: [PATCH] tty: n_tty: convert the full VTIME interval to jiffies

[Hungyu Lin]

> Ok, and has it ever reported problems with this rounding error?  This is
> very old code, changing it needs to be done only if an issue is actually
> noticed as it might be relied on, right?

I don't have a report from users of those systems. I found this by
inspection and reproduced the early timeout using PTYs under QEMU.

For comparison, FreeBSD's original VMIN/VTIME code keeps the timeout
in microseconds and rounds the remaining interval up when
converting to ticks:
https://github.com/freebsd/freebsd-src/commit/d32198f15b39a0f6dc29229ba4925d67d136956e

I understand that this doesn't rule out applications depending on the
existing Linux timing. Would you consider the conversion correction
worthwhile on that basis?

Thanks,
Hungyu

Re: [PATCH] tty: n_tty: convert the full VTIME interval to jiffies

[Greg KH]

On Thu, Oct 29, 2026 at 12:52:59AM -0700, Hungyu Lin wrote:
> > Ok, and has it ever reported problems with this rounding error?  This is
> > very old code, changing it needs to be done only if an issue is actually
> > noticed as it might be relied on, right?
> 
> I don't have a report from users of those systems. I found this by
> inspection and reproduced the early timeout using PTYs under QEMU.
> 
> For comparison, FreeBSD's original VMIN/VTIME code keeps the timeout
> in microseconds and rounds the remaining interval up when
> converting to ticks:
> https://github.com/freebsd/freebsd-src/commit/d32198f15b39a0f6dc29229ba4925d67d136956e
> 
> I understand that this doesn't rule out applications depending on the
> existing Linux timing. Would you consider the conversion correction
> worthwhile on that basis?

Unless you can prove that this is causing a problem, I would suggest
leaving this as-is please.  Modifying user-visable behaviour is very
tricky.

thanks,

greg k-h

Re: [PATCH] tty: n_tty: convert the full VTIME interval to jiffies

[Hungyu Lin]

> Unless you can prove that this is causing a problem, I would suggest
> leaving this as-is please.  Modifying user-visable behaviour is very
> tricky.

Understood. I'll leave this as-is.

Thanks,
Hungyu