From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14873 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] aio: aio_read() may not return error for invalid argument Date: Sun, 27 Oct 2019 11:17:26 -0400 Message-ID: <20191027151726.GZ16318@brightrain.aerifal.cx> References: <20191027054537.166030-1-zhangtianci1@huawei.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="238636"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14889-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 27 16:17:41 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iOkIX-000zxi-7r for gllmg-musl@m.gmane.org; Sun, 27 Oct 2019 16:17:41 +0100 Original-Received: (qmail 13952 invoked by uid 550); 27 Oct 2019 15:17:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 13931 invoked from network); 27 Oct 2019 15:17:38 -0000 Content-Disposition: inline In-Reply-To: <20191027054537.166030-1-zhangtianci1@huawei.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14873 Archived-At: On Sun, Oct 27, 2019 at 01:45:37PM +0800, Zhang Tianci wrote: > For aio_read(0, buf, 0, -1) will return success. > > Because STDIN is unseekable, so aio_read() will call read(0, buf, 0), > but read(0, buf, 0) will not return error. > > So we should check that whether aio_offset is valid or not when the > file is unseekable. > > Signed-off-by: Zhang Tianci I don't follow what you claim is the bug here. The error condition for EINVAL is specified as: "EINVAL The file offset value implied by aiocbp->aio_offset would be invalid." But for operations on unseekable files, no offset is implied by aio_offset; it's not used. At the moment I'm actually not finding the exact part of the standard text relevant to this case. The text I was working from when I wrote this code appears to be for write operations only: "If O_APPEND is not set for the file descriptor aio_fildes and if aio_fildes is associated with a device that is capable of seeking, then the requested operation takes place at the absolute position in the file as given by aio_offset, as if lseek() were called immediately prior to the operation with an offset argument equal to aio_offset and a whence argument equal to SEEK_SET. If O_APPEND is set for the file descriptor, or if aio_fildes is associated with a device that is incapable of seeking, write operations append to the file in the same order as the calls were made, with the following exception..." (XSH 2.8.2) and: "If O_APPEND is not set for the file descriptor aio_fildes, then the requested operation shall take place at the absolute position in the file as given by aio_offset, as if lseek() were called immediately prior to the operation with an offset equal to aio_offset and a whence equal to SEEK_SET. If O_APPEND is set for the file descriptor, or if aio_fildes is associated with a device that is incapable of seeking, write operations append to the file in the same order as the calls were made, except under circumstances described in Asynchronous I/O." (aio_write DESCRIPTION). Indeed, aio_read seems horribly underspecified. No mention is made of what happens if the file is not seekable or even if it is seekable but the seek fails. It just says "as if lseek() were called immediately prior to the operation with an offset equal to aio_offset and a whence equal to SEEK_SET", and of course lseek can fail. I think it's plausible that your interpretation that it should check and fail with EINVAL on negative offset is plausible here, but I think it's also plausible that -1 is used as a dummy value for offset with unseekable streams, which would be useful to catch erroneous use with a seekable stream, when the aio_read calls would not behave as intended unless the caller tracked a running position and passed the right offsets. We should probably refer this to the Austin Group for an interpretation. Rich