io_uring_prep_files_update(3)

okay bestie, welcome to the liburing Manual page for io_uring_prep_files_update(3) — yes, the manual name is folded in right up here so we can get straight to the group-chat explanation. 💅

💖 NAME

io_uring_prep_files_update — prepare a registered file update request. That's the whole vibe: you're prepping, not submitting, not doing the absolute most. ✨

✨ SYNOPSIS

#include <liburing.h>

void io_uring_prep_files_update(struct io_uring_sqe *sqe,
                                const int *fds,
                                unsigned nr_fds,
                                int offset);

🌸 DESCRIPTION

okay so io_uring_prep_files_update(3) gets a request ready for updating a number of previously registered file descriptors. It sets up the submission queue entry sqe to use the file descriptor array pointed to by fds and of nr_fds in length, updating that amount of previously registered files starting at offset. Lowkey simple, highkey powerful. ✨

Once a previously registered file is updated with a new one, the existing entry is updated and then removed from the table. This operation is equivalent to first unregistering that entry and then inserting a new one, just bundled into one combined operation. It's giving two-step, one-request. 💅

If offset is specified as IORING_FILE_INDEX_ALLOC, io_uring will allocate free direct descriptors instead of having the application pass them, and store the allocated direct descriptors into the fds array. Then cqe->res will return the number of direct descriptors allocated. No cap, the kernel is doing the alloc math for you. 🫶

💀 RETURN VALUE

None. That’s the whole answer — this prep function doesn’t return a value, bestie. 😌

😭 ERRORS

These are the errors that are reported in the CQE res field. On success, res will contain the number of successfully updated file descriptors. On error, the following errors can occur:

• -ENOMEM — the kernel was unable to allocate memory for the request. 💀
• -EINVAL — one of the fields set in the SQE was invalid. 🚩
• -EFAULT — the kernel was unable to copy in the memory pointed to by fds. 😭
• -EBADF — one of the descriptors located in fds didn't refer to a valid file descriptor, or one of the file descriptors in the array referred to an io_uring instance. 🙈
• -EOVERFLOW — the product of offset and nr_fds exceed the valid amount or overflowed. 🌀

🧚 NOTES

As with any request that passes in data in a struct, that data must remain valid until the request has been successfully submitted. It need not remain valid until completion. Once a request has been submitted, the in-kernel state is stable. Very early kernels (5.4 and earlier) required state to be stable until the completion occurred. Applications can test for this behavior by inspecting the IORING_FEAT_SUBMIT_STABLE flag passed back from io_uring_queue_init_params(3). This is the kind of detail that separates the besties from the chaos gremlins. 🧠✨

🌈 SEE ALSO

• io_uring_get_sqe(3)
• io_uring_submit(3)
• io_uring_register(2)

---

xoxo, your liburing bestie 💖 — this page is from liburing-2.2, dated March 13, 2022.