From: Al Viro <viro@zeniv.linux.org.uk>
To: Jann Horn <jannh@google.com>
Cc: Jens Axboe <axboe@kernel.dk>, Stefan Roesch <shr@fb.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
io-uring <io-uring@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Pavel Begunkov <asml.silence@gmail.com>
Subject: Re: [PATCH v7 0/3] io_uring: add getdents64 support
Date: Mon, 3 Jan 2022 21:12:44 +0000 [thread overview]
Message-ID: <YdNmzESyEHeN2Gcv@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <CAG48ez1O9VxSuWuLXBjke23YxUA8EhMP+6RCHo5PNQBf3B0pDQ@mail.gmail.com>
On Mon, Jan 03, 2022 at 08:03:51AM +0100, Jann Horn wrote:
> io_prep_rw() grabs file->f_pos; then later, io_read() calls
> io_iter_do_read() (which will fail with -EINVAL), and then the error
> path goes through kiocb_done(), which writes the position back to
> req->file->f_pos. So I think the following race might work:
Why does it touch ->f_pos on failure, anyway? It's a bug, plain and
simple; note that read(2) and write(2) are explicitly requested to
leave IO position alone if they return an error. See e.g.
fs/read_write.c:ksys_read() -
ret = vfs_read(f.file, buf, count, ppos);
if (ret >= 0 && ppos)
f.file->f_pos = pos;
fdput_pos(f);
Position update happens only on success (and only for non-stream
files, at that).
No matter how special io-uring is (it's not covered by POSIX, for
obvious reasons), this is simply wrong, directories or no directories.
next prev parent reply other threads:[~2022-01-03 21:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-21 16:40 [PATCH v7 0/3] io_uring: add getdents64 support Stefan Roesch
2021-12-21 16:40 ` [PATCH v7 1/3] fs: add offset parameter to iterate_dir function Stefan Roesch
2021-12-21 16:40 ` [PATCH v7 2/3] fs: split off vfs_getdents function of getdents64 syscall Stefan Roesch
2021-12-21 16:40 ` [PATCH v7 3/3] io_uring: add support for getdents64 Stefan Roesch
2021-12-21 17:15 ` [PATCH v7 0/3] io_uring: add getdents64 support Linus Torvalds
2021-12-31 23:15 ` Al Viro
2022-01-01 19:59 ` Al Viro
2022-01-03 7:03 ` Jann Horn
2022-01-03 15:00 ` Jens Axboe
2022-01-03 18:55 ` Linus Torvalds
2022-01-03 21:12 ` Al Viro [this message]
2021-12-21 19:17 ` Jens Axboe
2021-12-31 23:14 ` Al Viro
2023-04-16 22:06 ` Dominique Martinet
-- strict thread matches above, loose matches on Subject: below --
2021-12-22 21:07 Stefan Roesch
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=YdNmzESyEHeN2Gcv@zeniv-ca.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=jannh@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=shr@fb.com \
--cc=torvalds@linux-foundation.org \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.