linux-kernel - Re: TTY loosing bytes ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 6 Oct 2009 16:27:53 +0300
From:	Felipe Balbi <felipe.balbi@...ia.com>
To:	ext Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	"Balbi Felipe (Nokia-D/Helsinki)" <felipe.balbi@...ia.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"dbrownell@...rs.sourceforge.net" <dbrownell@...rs.sourceforge.net>
Subject: Re: TTY loosing bytes ?

On Tue, Oct 06, 2009 at 03:11:15PM +0200, ext Alan Cox wrote:
> > With the patch above I still get this messages but it still goes through
> > since not receive_buf is returning the amount of bytes actually
> > received. Then flush_to_ldisc() will retry those bytes on the next
> > iteration. Maybe this is not the desired patch though ?
> > 
> > Thanks a lot for the comments Alan.
> 
> First guess try the following
> 
> n_tty: For some I/O patterns n_tty will lose bytes
> 
> From: Alan Cox <alan@...ux.intel.com>
> 
> Fix the obvious disagreement between the receive path and the receive room
> logic.
> 
> Signed-off-by: Alan Cox <alan@...ux.intel.com>
> ---
> 
>  drivers/char/n_tty.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> 
> diff --git a/drivers/char/n_tty.c b/drivers/char/n_tty.c
> index 2e50f4d..27b28ca 100644
> --- a/drivers/char/n_tty.c
> +++ b/drivers/char/n_tty.c
> @@ -95,6 +95,9 @@ static void n_tty_set_room(struct tty_struct *tty)
>  	/* tty->read_cnt is not read locked ? */
>  	int	left = N_TTY_BUF_SIZE - tty->read_cnt - 1;
>  
> +	if (tty->real_raw)
> +	        left = min(left, N_TTY_BUF_SIZE - tty->read_head - 1);
> +
>  	/*
>  	 * If we are doing input canonicalization, and there are no
>  	 * pending newlines, let characters through without limit, so

unfortunately it didn't work. Although now I don't the debugging prints
complaining we've lost bytes, the transfer does get stuck in lot earlier
stage.

Maybe this is one fix but there's still other problem with that code ?

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/