From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262058AbVBPQGZ (ORCPT ); Wed, 16 Feb 2005 11:06:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262061AbVBPQGY (ORCPT ); Wed, 16 Feb 2005 11:06:24 -0500 Received: from fire.osdl.org ([65.172.181.4]:56249 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S262058AbVBPQGK (ORCPT ); Wed, 16 Feb 2005 11:06:10 -0500 Date: Wed, 16 Feb 2005 08:06:00 -0800 (PST) From: Linus Torvalds To: "Theodore Ts'o" cc: Roman Zippel , Andreas Schwab , linux-kernel@vger.kernel.org Subject: Re: Pty is losing bytes In-Reply-To: <20050216144203.GB7767@thunk.org> Message-ID: References: <20050216144203.GB7767@thunk.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 16 Feb 2005, Theodore Ts'o wrote: > > The comment above the test explains why that test is there in > n_tty_receive_room. If that test isn't there, and we are doing input > canonicalization, when the buffer gets full Yes, yes, but did you see my suggested version that I had just below that explained what I thought the real fix was? Th eproblem with checking for the "canon but no canon data" is that it's a special case that IS ONLY VALID WHEN THE BUFFER IS FULL! Until that happens, it means that the code returns the wrong value, and then can (obviously, as seen by the bug) drop bytes even when it shouldn't. That's why my suggested work-around moved things around, to only return the "we'll take anything" thing if the buffer really was full. Linus