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: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Rich Felker <dalias at libc dot org>
- Cc: nd <nd at arm dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Mon, 2 Sep 2019 18:35:12 +0000
- Subject: Re: [PATCH 2/4] nptl: Handle EPIPE on tst-cancel2
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uW/4xjJAFXpwhrgVrjxwkOIo8bVtknrl33IjsRsRMJ8=; b=LP9dftQBBBOvw5XOOd14DjGuWG3fO/myejEWOqOOev7jdiMuG0+j6e6Bqk4bQ0aHXPC05N2wuWzqxF37VY4d1+O3KDpHVAoEwKn+kL9PDr9YuKPSyoQPLCY3x335y2cLfW4aAGpUcJ6QDgNGwx9SaGRb0DwjgxgK6HoE2HOhJRuFYN5mAFtJw1YnqysUL5VtTYuX3zUnkVw7OPknX5zv3E7hcBvxOv3kT5fzz/aD109EnRH9ycMmkADYlE1EwQQGc+//dFAZw1wVu9xDiBJ0/T/IZkqt2iSyM1xuR5uoDoQl0PSdjnxOzzR15LZSfUfGQAk8QRSRUmCscWkRSQ2weA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UFqRFqaeM0YWSoVq7zw03pkYgfg8blr0lZVIZdbkF+Eq8gH70hKS2gBcknpJY34I8iy4J8gmzZTqA6EME/5LgjVhnxF3LDwZEhiMxACzFs20NqPYF23+9/7qglqG0Hp2trZPQk5XAa0J9BAbvF7f6XbeEfQEtl1OP+PR66Hr1xo+FvFsgBepIFDoiuvYKxC36TYlL7fw2vs6fRtW95RsVO4+xOUl+Gkk5ujEBwjD0xpJBs5z9Cq1G0CCLjqVFX23ZMCufCchnQkKsGeaDh2BX9zSR7vcanpf+2tnMX3zbrHErojhnbe54M/X3HDQnFTz2oxwhtYmDm9PChNsERh17g==
- Original-authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- References: <20190815211843.22799-1-adhemerval.zanella@linaro.org> <20190815211843.22799-2-adhemerval.zanella@linaro.org> <87k1b8p23k.fsf@oldenburg2.str.redhat.com> <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>
On 02/09/2019 13:37, Florian Weimer wrote:
> * Rich Felker:
>> No. POSIX is very clear that cancellation is only permitted to be
>> acted on when the side effects are the same as EINTR, which can only
>> happen for read/write when no data has been transferred yet. If data
>> has already been transferred, the only option not ruled out by one or
>> more constraints is to return successfully with a short read or write;
>> pending cancellation will then be handled on a subsequent call to a
>> cancellation point. (If you're doing a retry loop until the total
>> length n is transferred, then in the next iteration of the loop.)
>
> This seems to be a backwards interpretation to me. I think POSIX wants
> to describe what can happen during cancellation, and not say that any
> cancellation point can be skipped if some side effect happens that
> cannot happen before EINTR.
>
>> Of course this case of non-conformance would be less severe than UAF
>> or resource leak errors in most cases, but it's still not good.
>
> Agreed. And I think not acting on the cancellation and returning
> success is also not conforming.
how is that non-conformance observable?
the user cannot know if the cancellation
request arrived in time or not if io
error (short write) can happen for other
reasons than the cancellation signal.