Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965145AbWAIAfi (ORCPT ); Sun, 8 Jan 2006 19:35:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965364AbWAIAfi (ORCPT ); Sun, 8 Jan 2006 19:35:38 -0500 Received: from x35.xmailserver.org ([69.30.125.51]:63156 "EHLO x35.xmailserver.org") by vger.kernel.org with ESMTP id S965145AbWAIAfi (ORCPT ); Sun, 8 Jan 2006 19:35:38 -0500 X-AuthUser: davidel@xmailserver.org Date: Sun, 8 Jan 2006 16:35:33 -0800 (PST) From: Davide Libenzi X-X-Sender: davide@localhost.localdomain To: "David S. Miller" cc: Linux Kernel Mailing List Subject: Re: [PATCH/RFC] POLLHUP tinkering ... In-Reply-To: <20060108.162017.97708180.davem@davemloft.net> Message-ID: References: <20060108.160802.103497642.davem@davemloft.net> <20060108.162017.97708180.davem@davemloft.net> X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1472 Lines: 51 On Sun, 8 Jan 2006, David S. Miller wrote: > From: Davide Libenzi > Date: Sun, 8 Jan 2006 16:11:10 -0800 (PST) > >> On Sun, 8 Jan 2006, David S. Miller wrote: >> >>> The extra last read is always necessary, it's an error synchronization >>> barrier. Did you know that? >>> >>> If a partial read or write hits an error, the successful amount of >>> bytes read or written before the error occurred is returned. Then any >>> subsequent read or write will report the error immediately. >> >> Sorry for the missing info, but I was clearly talking about O_NONBLOCK >> here. > > What I said still applies to O_NONBLOCK. I thought you said in _not_ necessary, sorry. The extra read() for error discovery is just bogus, w/out proper Linux poll reporting. The epoll interface will have wait queue heads dropped inside the monitored devices wait queue, so I assume that an error condition would trigger a wakeup -> epoll event. If this is not true (but I'm pretty much sure it is), look at the extra read() for error reporting: 1) Good read_loop(); --> Error happen on device if (read() == ERROR) gotcha(); 2) read_loop(); if (read() == ERROR) whoops(); --> Error happen on device - Davide - 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/