Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1195265 > unrolled thread

Re: May close() return any error code?

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: May close() return any error code? Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2015-07-29 16:50 +0200
    Re: May close() return any error code? Al Viro <viro@ZenIV.linux.org.uk> - 2015-08-02 16:10 +0200
      Re: May close() return any error code? Takashi Iwai <tiwai@suse.de> - 2015-08-04 12:30 +0200

#1195265 — Re: May close() return any error code?

HI Takashi,

On Wed, Jul 29, 2015 at 12:46:59PM +0200, Takashi Iwai wrote:
> Hi,
> 
> while debugging a problem of X and gdm with the old systemd-210, we
> encountered a sudden death of systemd-logind, and this turned out to
> be an unexpected errno from close().  The close() call for input
> devices returns ENODEV error.  The logind in systemd-210 treats this
> error code as fatal, triggers assert() and eventually kills itself.
> The details are found in an openSUSE bugzilla thread:
>   https://bugzilla.opensuse.org/show_bug.cgi?id=939571
> 
> 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

Hmm, if I checked the right version of the code close_nointr_nofail()
expects only 0 as the return code so even if we change the kernel to
use more conforming -EIO instead of -ENODEV systemd will still die...

The question is whether we really need to propagate return value from
f_op->flush() up to userspace in filp_close(). Why don't we ask Al?

Thanks.

-- 
Dmitry
--
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/

[toc] | [next] | [standalone]

#1198351

On Wed, Jul 29, 2015 at 07:45:11AM -0700, Dmitry Torokhov 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
> 
> Hmm, if I checked the right version of the code close_nointr_nofail()
> expects only 0 as the return code so even if we change the kernel to
> use more conforming -EIO instead of -ENODEV systemd will still die...
> 
> The question is whether we really need to propagate return value from
> f_op->flush() up to userspace in filp_close(). Why don't we ask Al?

That's the whole damn point of having ->flush().  And yes, we do need that -
things like NFS (not to mention tapes, etc.) do rely on that.

Whether it makes sense to do this kind of "do something that might have
a failure to report on each close()" for evdev is up to driver, obviously.
--
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/

[toc] | [prev] | [next] | [standalone]

#1199638

On Sun, 02 Aug 2015 16:07:06 +0200,
Al Viro wrote:
> 
> On Wed, Jul 29, 2015 at 07:45:11AM -0700, Dmitry Torokhov 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
> > 
> > Hmm, if I checked the right version of the code close_nointr_nofail()
> > expects only 0 as the return code so even if we change the kernel to
> > use more conforming -EIO instead of -ENODEV systemd will still die...
> > 
> > The question is whether we really need to propagate return value from
> > f_op->flush() up to userspace in filp_close(). Why don't we ask Al?
> 
> That's the whole damn point of having ->flush().  And yes, we do need that -
> things like NFS (not to mention tapes, etc.) do rely on that.
> 
> Whether it makes sense to do this kind of "do something that might have
> a failure to report on each close()" for evdev is up to driver, obviously.

So, the behavior of VFS layer is as designed.  Then I suppose the fix
should be rather in evdev.c.  Dmitry, could you paper over it?


thanks,

Takashi
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web