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 Content-Length: 1018 Lines: 25 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/