From: Al Viro <viro@zeniv.linux.org.uk>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3b] eventfd: convert to f_op->read_iter()
Date: Fri, 1 May 2020 20:00:18 +0100 [thread overview]
Message-ID: <20200501190018.GN23230@ZenIV.linux.org.uk> (raw)
In-Reply-To: <97a28bdb-284a-c215-c04d-288bcef66376@kernel.dk>
On Fri, May 01, 2020 at 11:54:01AM -0600, Jens Axboe wrote:
> @@ -427,8 +424,17 @@ static int do_eventfd(unsigned int count, int flags)
>
> fd = anon_inode_getfd("[eventfd]", &eventfd_fops, ctx,
> O_RDWR | (flags & EFD_SHARED_FCNTL_FLAGS));
> - if (fd < 0)
> + if (fd < 0) {
> eventfd_free_ctx(ctx);
> + } else {
> + struct file *file;
> +
> + file = fget(fd);
> + if (file) {
> + file->f_mode |= FMODE_NOWAIT;
> + fput(file);
> + }
No. The one and only thing you can do to return value of anon_inode_getfd() is to
return the fscker to userland. You *CAN* *NOT* assume that descriptor table is
still pointing to whatever you've just created.
As soon as it's in descriptor table, it's out of your hands. And frankly, if you
are playing with descriptors, you should be very well aware of that.
Descriptor tables are fundamentally shared objects; they *can* be accessed and
modified by other threads, right behind your back.
*IF* you are going to play with ->f_mode, you must use get_unused_fd_flags(),
anon_inode_getfile(), modify ->f_mode of the result and use fd_install() to
put it into descriptor table. With put_unused_fd() as cleanup in case
of allocation failure.
next prev parent reply other threads:[~2020-05-01 19:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-01 17:54 [PATCH v3b] eventfd: convert to f_op->read_iter() Jens Axboe
2020-05-01 19:00 ` Al Viro [this message]
2020-05-01 19:08 ` Jens Axboe
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=20200501190018.GN23230@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=axboe@kernel.dk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 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).