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". -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
