This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/4] nptl: Handle EPIPE on tst-cancel2
- From: Rich Felker <dalias at libc dot org>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Tue, 3 Sep 2019 08:24:29 -0400
- Subject: Re: [PATCH 2/4] nptl: Handle EPIPE on tst-cancel2
- References: <508b3320-35a9-60f8-d507-5213e71f706d@linaro.org> <877e78nga9.fsf@oldenburg2.str.redhat.com> <363f8fb4-2628-827e-c309-4a58d1f18fba@linaro.org> <87imqrn9bv.fsf@oldenburg2.str.redhat.com> <d1f95ec8-5ec6-059a-f8e6-5822c0f2c9f8@linaro.org> <8736hsujys.fsf@oldenburg2.str.redhat.com> <20190830135103.GJ9017@brightrain.aerifal.cx> <87d0gix4aq.fsf@oldenburg2.str.redhat.com> <20190902232623.GU9017@brightrain.aerifal.cx> <c384bf67-599a-e326-0453-3bdf454690c5@linaro.org>
On Tue, Sep 03, 2019 at 09:15:58AM -0300, Adhemerval Zanella wrote:
>
>
> On 02/09/2019 20:26, Rich Felker wrote:
> > If the descriptor has been closed, you *can't* act on cancellation. On
> > Linux, SYS_close *never* returns to userspace without the fd having
> > been closed. It can return EINTR, indicating that the fd has been
> > closed but the underlying open file description (if this was the last
> > reference to it) has not, but this EINTR is not POSIX conforming with
> > the new changes to POSIX, and it was always inconsistent with the
> > semantics implied by EINTR ("no nontrivial side effects have happened
> > yet"). See https://sourceware.org/bugzilla/show_bug.cgi?id=14627
>
> So is it true even for newer version? I had the impression from the lwn
> article [1] that this is driver dependent and this behaviour will eventually
> be removed from kernel to not allow close to return EINTR.
>
> About BZ#14627, does it still make sense for *Linux* to map EINTR to
> EINPROGRESS?
>
> [1] https://lwn.net/Articles/576478/
The kernel folks are adamantly opposed to changing SYS_close to match
the POSIX requirement here, which is the right thing to do but for the
wrong reasons -- if it were changed, libc could not safely handle the
situation because it couldn't know what meaning the kernel was
assigning to EINTR.
Hopefully they will just stop returning EINTR entirely. That would not
break any of the behavior discussed above. Returning EINPROGRESS may
be a problem though because applications may not know to expect it and
may treat it as a hard error rather than a reasonable condition
(discussed in https://sourceware.org/bugzilla/show_bug.cgi?id=14627).
The ideal behavior is probably just returning 0.
Rich