linux-kernel - Re: [PATCH] fix n_tty/pty input/output buffer full and other misc char handling

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]

Message-ID: <48FF807B.2020002@skyrush.com>
Date:	Wed, 22 Oct 2008 13:35:23 -0600
From:	Joe Peterson <joe@...rush.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] fix n_tty/pty input/output buffer full and other misc
 char handling

Alan Cox wrote:
>> that ^C, ^Q, etc. can have effect) in non-canonical mode?  This would
>> allow prevention of the gridlocks that still can be invoked when using
>> stty -icanon in, say, an xterm.  For now, I took the conservative route
>> in this patch, but let me know if a more permissive approach is better.
> 
> I suspect having thought about this a bit more that the proper logic is
> in fact
> 
> 	if (special case a)
> 	if (special case b)
> 	if (....)
> 
> 	/* An ordinary character for the queue */
> 	if (queue_full) { ....}
> 
> and we should process everything that may have a special effect (flow
> control, delete line, etc) before worrying about having room to store the
> character whatever the tty ldisc state

Yeah, I had thought about this a little before too.  The tricky part is
knowing that such a character exists and is waiting when we have already
stopped accepting characters.  In the current way things work, a ^C, for
example, will not make it into the line discipline until the stuff that
came before has been processed (which is now wedged waiting for space to
free up), so it's hard to check in the ldisc for it.  I'm guessing that
is why the orignal logic in set_room was designed to lets stuff flow in
in that case when we're looking for an erase char...

Now, in the case of a ^C or ^Q (e.g.), if we knew one was back in the
queue waiting to get to the ldisc, we could put it through out of
sequence, but for an erase (e.g.), it needs to wait for what real chars
come before it (i.e. it cannot jump to the front)...

I'll think more on this, too - let me know if I am not hearing what you
are saying exactly.

				-Joe

--
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/