From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: May close() return any error code? Date: Sun, 2 Aug 2015 14:57:23 +0100 Message-ID: <20150802135723.GC17109@ZenIV.linux.org.uk> References: <20150802074220.GF3720@amd> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:51110 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751375AbbHBN53 (ORCPT ); Sun, 2 Aug 2015 09:57:29 -0400 Content-Disposition: inline In-Reply-To: <20150802074220.GF3720@amd> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Pavel Machek Cc: Takashi Iwai , Dmitry Torokhov , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, "Dr. Werner Fink" On Sun, Aug 02, 2015 at 09:42:20AM +0200, Pavel Machek wrote: > > This seems coming from evdev_flush(). As there is no fd leak, it's= no > > big problem per se. But, now the question is whether returning suc= h > > an error code is correct behavior at all. At least, it doesn't see= m > > defined in POSIX: > > > http://pubs.opengroup.org/onlinepubs/009695399/functions/close.html >=20 > Returning an error from close() would imply that file descriptor is > not closed.... seems like bad idea. Just fix the kernel not to do it. The only thing implied here is failure to RTF{M,S}. To quote close(2): NOTES Not checking the return value of close() is a common but never= theless serious programming error. It is quite possible that errors on= a pre=E2=80=90 vious write(2) operation are first reported at the final close()= =2E Not checking the return value when closing the file may lead to sile= nt loss of data. This can especially be observed with NFS and with disk= quota. Note that the return value should only be used for diagnosti= cs. In particular close() should not be retried after an EINTR since th= is may cause a reused descriptor from another thread to be closed. That's Linux one. FreeBSD one says In case of any error except EBADF, the supplied file descriptor is= deal- located and therefore is no longer valid. and that matches behaviour of historical BSD variants as well. POSIX i= s being its usual charming self and says "if a kernel shipped by $VALUED_MEMBER= does this and that cretinous thing, far be it from us to call it broken". -- To unsubscribe from this list: send the line "unsubscribe linux-input" = in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751578AbbHBN5a (ORCPT ); Sun, 2 Aug 2015 09:57:30 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:51110 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751375AbbHBN53 (ORCPT ); Sun, 2 Aug 2015 09:57:29 -0400 Date: Sun, 2 Aug 2015 14:57:23 +0100 From: Al Viro To: Pavel Machek Cc: Takashi Iwai , Dmitry Torokhov , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, "Dr. Werner Fink" Subject: Re: May close() return any error code? Message-ID: <20150802135723.GC17109@ZenIV.linux.org.uk> References: <20150802074220.GF3720@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150802074220.GF3720@amd> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Aug 02, 2015 at 09:42:20AM +0200, Pavel Machek wrote: > > This seems coming from evdev_flush(). As there is no fd leak, it's no > > big problem per se. But, now the question is whether returning such > > an error code is correct behavior at all. At least, it doesn't seem > > defined in POSIX: > > > http://pubs.opengroup.org/onlinepubs/009695399/functions/close.html > > Returning an error from close() would imply that file descriptor is > not closed.... seems like bad idea. Just fix the kernel not to do it. The only thing implied here is failure to RTF{M,S}. To quote close(2): NOTES Not checking the return value of close() is a common but nevertheless serious programming error. It is quite possible that errors on a pre‐ vious write(2) operation are first reported at the final close(). Not checking the return value when closing the file may lead to silent loss of data. This can especially be observed with NFS and with disk quota. Note that the return value should only be used for diagnostics. In particular close() should not be retried after an EINTR since this may cause a reused descriptor from another thread to be closed. That's Linux one. FreeBSD one says In case of any error except EBADF, the supplied file descriptor is deal- located and therefore is no longer valid. and that matches behaviour of historical BSD variants as well. POSIX is being its usual charming self and says "if a kernel shipped by $VALUED_MEMBER does this and that cretinous thing, far be it from us to call it broken".