Files
linux/include/linux
Christian Brauner 011703a9ac file: add FD_{ADD,PREPARE}()
I've been playing with this to allow for moderately flexible usage of
the get_unused_fd_flags() + create file + fd_install() pattern that's
used quite extensively.

How callers allocate files is really heterogenous so it's not really
convenient to fold them into a single class. It's possibe to split them
into subclasses like for anon inodes. I think that's not necessarily
nice as well.

My take is to add two primites:
(1) FD_ADD() the simple cases a file is installed:

    fd = FD_ADD(O_CLOEXEC, open_file(some, args)));
    if (fd >= 0)
            kvm_get_kvm(vcpu->kvm);
    return fd;

(2) FD_PREPARE() that captures all the cases where access to fd or file
    or additional work before publishing the fd is needed:

    FD_PREPARE(fdf, open_flag, file_open_handle(&path, open_flag));
    if (fdf.err)
            return fdf.err;

    if (copy_to_user(/* something something */))
            return -EFAULT;

    return fd_publish(fdf);

I've converted all of the easy cases over to it and it gets rid of an
aweful lot of convoluted cleanup logic.

It's centered around struct fd_prepare. FD_PREPARE() encapsulates all of
allocation and cleanup logic and must be followed by a call to
fd_publish() which associates the fd with the file and installs it into
the callers fdtable. If fd_publish() isn't called both are deallocated.

It mandates a specific order namely that first we allocate the fd and
then instantiate the file. But that shouldn't be a problem nearly
everyone I've converted uses this exact pattern anyway.

There's a bunch of additional cases where it would be easy to convert
them to this pattern. For example, the whole sync file stuff in dma
currently retains the containing structure of the file instead of the
file itself even though it's only used to allocate files. Changing that
would make it fall into the FD_PREPARE() pattern easily. I've not done
that work yet.

There's room for extending this in a way that wed'd have subclasses for
some particularly often use patterns but as I said I'm not even sure
that's worth it.

Link: https://patch.msgid.link/20251123-work-fd-prepare-v4-1-b6efa1706cfd@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-11-28 12:42:23 +01:00
..
2025-09-24 17:09:47 +02:00
2025-06-15 21:19:08 +05:30
2025-09-05 15:06:03 +02:00
2025-07-21 18:18:51 +01:00
2025-07-31 11:28:03 -04:00
2025-09-10 05:23:45 -06:00
2025-09-24 02:48:05 -07:00
2025-11-28 12:42:23 +01:00
2025-08-14 10:37:33 -07:00
2025-09-23 11:13:22 +02:00
2025-11-28 12:42:23 +01:00
2025-08-21 13:58:07 +02:00
2025-07-16 14:28:21 +02:00
2025-09-13 17:32:44 -07:00
2025-08-29 13:39:53 -07:00
2025-08-02 12:06:10 -07:00
2025-09-18 10:17:09 +02:00
2025-09-23 11:13:22 +02:00
2025-06-11 11:57:14 -07:00
2025-07-02 17:18:01 +01:00
2025-07-17 06:01:16 -06:00
2025-09-13 16:54:50 -07:00
2025-07-09 22:41:56 -07:00
2025-09-17 15:58:29 -04:00
2025-06-17 18:18:46 -07:00
2025-07-14 15:20:02 -07:00
2025-09-23 13:28:20 -04:00
2025-07-08 19:11:57 -04:00
2025-09-19 14:26:16 +02:00
2025-09-25 09:23:47 +02:00
2025-08-18 14:23:09 +02:00
2025-08-18 14:23:09 +02:00
2025-10-01 07:55:42 -05:00
2025-10-03 12:13:12 -05:00
2025-09-13 16:55:07 -07:00
2025-10-03 10:24:14 -07:00
2025-06-19 14:28:24 +02:00
2025-06-19 14:28:24 +02:00
2025-07-22 18:07:11 +02:00
2025-08-24 11:41:11 -06:00
2025-07-01 12:29:29 +02:00
2025-08-28 13:14:50 +02:00
2025-09-19 17:19:45 -07:00
2025-07-23 11:56:02 +02:00
2025-08-17 12:46:25 +02:00
2025-06-26 09:44:45 -07:00
2025-09-09 10:27:01 -06:00
2025-10-01 07:24:55 -04:00
2025-07-17 11:26:56 +02:00
2025-08-02 12:01:37 -07:00