From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] aio: aio_read() may not return error for invalid argument
Date: Sun, 27 Oct 2019 11:17:26 -0400 [thread overview]
Message-ID: <20191027151726.GZ16318@brightrain.aerifal.cx> (raw)
In-Reply-To: <20191027054537.166030-1-zhangtianci1@huawei.com>
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 <zhangtianci1@huawei.com>
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
prev parent reply other threads:[~2019-10-27 15:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-27 5:45 Zhang Tianci
2019-10-27 15:17 ` Rich Felker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191027151726.GZ16318@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).