Introduce a mechanism to replace a file linked in the epoll interface with a new
file.
eventpoll_replace() finds all instances of the file to be replaced and replaces
them with the new file and the interested events.
Signed-off-by: aloktiagi <[email protected]>
---
Changes in v7:
- address review comments on incorrect use of spin_lock.
- cleanup comments and simplify them.
Changes in v6:
- incorporate latest changes that get rid of the global epmutex lock.
Changes in v5:
- address review comments and move the call to replace old file in each
subsystem (epoll, io_uring, etc.) outside the fdtable helpers like
replace_fd().
Changes in v4:
- address review comment to remove the redundant eventpoll_replace() function.
- removed an extra empty line introduced in include/linux/file.h
Changes in v3:
- address review comment and iterate over the file table while holding the
spin_lock(&files->file_lock).
- address review comment and call filp_close() outside the
spin_lock(&files->file_lock).
---
fs/eventpoll.c | 75 +++++++++++++++++++++++++++++++++++++++
include/linux/eventpoll.h | 2 ++
2 files changed, 77 insertions(+)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 980483455cc0..60c14b549918 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -973,6 +973,81 @@ void eventpoll_release_file(struct file *file)
spin_unlock(&file->f_lock);
}
+static int ep_insert(struct eventpoll *ep, const struct epoll_event *event,
+ struct file *tfile, int fd, int full_check);
+
+/*
+ * Replace a linked file in the epoll interface with a new file
+ */
+int eventpoll_replace_file(struct file *toreplace, struct file *file, int tfd)
+{
+ struct file *to_remove = toreplace;
+ struct epoll_event event;
+ struct hlist_node *next;
+ struct eventpoll *ep;
+ struct epitem *epi;
+ int error = 0;
+ bool dispose;
+ int fd;
+
+ if (!file_can_poll(file))
+ return 0;
+
+ spin_lock(&toreplace->f_lock);
+ hlist_for_each_entry_safe(epi, next, toreplace->f_ep, fllink) {
+ fd = epi->ffd.fd;
+ event = epi->event;
+ if (fd != tfd) {
+ spin_unlock(&toreplace->f_lock);
+ goto install;
+ }
+ ep = epi->ep;
+ ep_get(ep);
+ spin_unlock(&toreplace->f_lock);
+
+ mutex_lock(&ep->mtx);
+ error = ep_insert(ep, &event, file, fd, 1);
+ mutex_unlock(&ep->mtx);
+ if (error != 0)
+ goto error;
+ WARN_ON_ONCE(ep_refcount_dec_and_test(ep));
+install:
+ spin_lock(&toreplace->f_lock);
+ }
+ spin_unlock(&toreplace->f_lock);
+error:
+ /*
+ * In case of an error remove all instances of the new file in the epoll
+ * interface. If no error, remove all instances of the original file.
+ */
+ if (error != 0)
+ to_remove = file;
+
+remove:
+ spin_lock(&to_remove->f_lock);
+ if (to_remove->f_ep && to_remove->f_ep->first) {
+ epi = hlist_entry(to_remove->f_ep->first, struct epitem, fllink);
+ fd = epi->ffd.fd;
+ if (fd != tfd) {
+ spin_unlock(&to_remove->f_lock);
+ goto remove;
+ }
+ epi->dying = true;
+ spin_unlock(&to_remove->f_lock);
+
+ ep = epi->ep;
+ mutex_lock(&ep->mtx);
+ dispose = __ep_remove(ep, epi, true);
+ mutex_unlock(&ep->mtx);
+
+ if (dispose)
+ ep_free(ep);
+ goto remove;
+ }
+ spin_unlock(&to_remove->f_lock);
+ return error;
+}
+
static int ep_alloc(struct eventpoll **pep)
{
int error;
diff --git a/include/linux/eventpoll.h b/include/linux/eventpoll.h
index 3337745d81bd..f8d52c45a37a 100644
--- a/include/linux/eventpoll.h
+++ b/include/linux/eventpoll.h
@@ -25,6 +25,8 @@ struct file *get_epoll_tfile_raw_ptr(struct file *file, int tfd, unsigned long t
/* Used to release the epoll bits inside the "struct file" */
void eventpoll_release_file(struct file *file);
+int eventpoll_replace_file(struct file *toreplace, struct file *file, int tfd);
+
/*
* This is called from inside fs/file_table.c:__fput() to unlink files
* from the eventpoll interface. We need to have this facility to cleanup
--
2.34.1
On Wed, May 24, 2023 at 06:39:32AM +0000, aloktiagi wrote:
> Introduce a mechanism to replace a file linked in the epoll interface with a new
> file.
>
> eventpoll_replace() finds all instances of the file to be replaced and replaces
> them with the new file and the interested events.h
I've spent a bit more time on this and I have a few more
questions/thoughts.
* What if the seccomp notifier replaces a pollable file with a
non-pollable file? Right now you check that the file is pollable and
if it isn't you're not updating the file references in the epoll
instance for the file descriptor you updated. Why these semantics and
not e.g., removing all instances of that file referring to the updated
fd?
* What if the seccomp notifier replaces the file of a file descriptor
with an epoll file descriptor? If the fd and original file are present
in an epoll instance does that mean you add the epoll file into all
epoll instances? That also means you create nested epoll instances
which are supported but are subject to various limitations. What's the
plan?
* What if you have two threads in the same threadgroup that each have a
seccomp listener profile attached to them. Both have the same fd open.
Now both replace the same fd concurrently. Both threads concurrently
update references in the epoll instances now since the spinlock and
mutex are acquired and reacquired again. Afaict, you can end up with
some instances of the fd temporarily generating events for file1 and
other instances generating events for file2 while the replace is in
progress. Thus generating spurious events and userspace might be
acting on a file descriptor that doesn't yet refer to the new file?
That's possibly dangerous.
Maybe I'm mistaken but if so I'd like to hear the details why that
can't happen.
Thinking about it what if the same file is registered via multiple fds
at the same time? Can't you end up in a scenario where you have the
same fd referring to different files in one or multiple epoll
instance?
I mean, you can get into that situation via dup2() where you change
the file descriptor to refer to a different file but the fd might
still be registered in the epoll instance referring to the old file
provided there's another fd open holding the old file alive.
The difference though is that userspace must've been dumb enough to
actually do that whereas now this can just happen behind their back
misleading them.
Honestly, the kernel can't give you any atomicity in replacing these
references and if so it would require new possibly invasive locking
that would very likely not be acceptable upstream just for the sake of
this feature. I still have a very hard time seeing any of this
happening.
* I haven't looked at the codepath that tries to restore the old file on
failure. That might introduce even more weirdness.
On Wed, May 24, 2023 at 07:26:24PM +0200, Christian Brauner wrote:
> On Wed, May 24, 2023 at 06:39:32AM +0000, aloktiagi wrote:
> > Introduce a mechanism to replace a file linked in the epoll interface with a new
> > file.
> >
> > eventpoll_replace() finds all instances of the file to be replaced and replaces
> > them with the new file and the interested events.h
>
> I've spent a bit more time on this and I have a few more
> questions/thoughts.
>
> * What if the seccomp notifier replaces a pollable file with a
> non-pollable file? Right now you check that the file is pollable and
> if it isn't you're not updating the file references in the epoll
> instance for the file descriptor you updated. Why these semantics and
> not e.g., removing all instances of that file referring to the updated
> fd?
>
good question. the current implementation relies on __fput() calling
eventpoll_release() to ultimately release the file. eventpoll_replace_file()
only removes the file if it can successfully install the new file in epoll.
> * What if the seccomp notifier replaces the file of a file descriptor
> with an epoll file descriptor? If the fd and original file are present
> in an epoll instance does that mean you add the epoll file into all
> epoll instances? That also means you create nested epoll instances
> which are supported but are subject to various limitations. What's the
> plan?
>
My plan was to allow these cases since there is support for nested epoll
instances. But thinking more on this, since seccomp subsystem is the only
caller of eventpoll_replace_file(), I am not sure whether there is a valid
use case where seccomp is used to intercept a system call that uses an
epoll fd as a parameter. Maybe its ok to not do the replacement for such
cases. Thoughts?
> * What if you have two threads in the same threadgroup that each have a
> seccomp listener profile attached to them. Both have the same fd open.
>
> Now both replace the same fd concurrently. Both threads concurrently
> update references in the epoll instances now since the spinlock and
> mutex are acquired and reacquired again. Afaict, you can end up with
> some instances of the fd temporarily generating events for file1 and
> other instances generating events for file2 while the replace is in
> progress. Thus generating spurious events and userspace might be
> acting on a file descriptor that doesn't yet refer to the new file?
> That's possibly dangerous.
>
> Maybe I'm mistaken but if so I'd like to hear the details why that
> can't happen.
>
Considering file1 is the original file and file2 is the new file. First
the eventpoll_replace_file() is called before receive_fd_replace(), so
the file1 is still active and file2 would not receive any events. Within
receive_fd_replace() the install phase first installs file2 alongside file1
without removing file1. So during this phase the userspace can continue to
receive events on file1. In the remove phase within eventpoll_replace_file()
the epi for file1 is set to dying and replaced with file2. At this point the
fd should see no new events, since receive_fd_replace() is yet to be called.
> Thinking about it what if the same file is registered via multiple fds
> at the same time? Can't you end up in a scenario where you have the
> same fd referring to different files in one or multiple epoll
> instance?
>
> I mean, you can get into that situation via dup2() where you change
> the file descriptor to refer to a different file but the fd might
> still be registered in the epoll instance referring to the old file
> provided there's another fd open holding the old file alive.
>
The current implementation scopes the replacement to the fd being replaced
in the call to receive_fd_replace() since thats what the userspace intends
to do. In case there are multiple fds pointing to the same file, and
receive_fd_replace() replaces only one of them, we would end up updating
the file for only one of the fds. The other fd will see the same result as
seen today without this patch, where the replaced file doesn't exist in
epoll since it got cleared due to __fput().
> The difference though is that userspace must've been dumb enough to
> actually do that whereas now this can just happen behind their back
> misleading them.
>
Since this is mainly serving the seccomp add fd usecase today, do you think
its something that can be documented as a limitation? I am not aware of the
interesting ways users are using seccomp add fd to think of all the possible
scenarios, so I am open to suggestions.
> Honestly, the kernel can't give you any atomicity in replacing these
> references and if so it would require new possibly invasive locking
> that would very likely not be acceptable upstream just for the sake of
> this feature. I still have a very hard time seeing any of this
> happening.
>
> * I haven't looked at the codepath that tries to restore the old file on
> failure. That might introduce even more weirdness.