On Thu, Nov 5, 2026 at 10:37 PM Fujii Masao <[email protected]> wrote: > > On Thu, Nov 5, 2026 at 6:25 PM Xuneng Zhou <[email protected]> wrote: > > I could > > write a follow-up patch or review it if you already did. > > I tried to write a patch that keeps postmaster-local copies of the io_uring > descriptors and passes them to io_uring_queue_exit() for cleanup. Attached. > > Per [1], io_uring_queue_exit() seems to use sq.kring_entries. Since this is > a pointer [2], simply copying the descriptor would leave it pointing into > shared memory. So, the patch also saves the pointed-to value locally. > > But, I'm not sure this is the right approach... It relies on liburing's > implementation rather than a documented guarantee, so future liburing changes > would be really easily able to break it. This seems very fragile. Thought? > Is there a better approach? > > Regards, > > [1] https://github.com/axboe/liburing/blob/liburing-2.7/src/setup.c#L430-L445 > [2] > https://github.com/axboe/liburing/blob/liburing-2.7/src/include/liburing.h#L77-L83
It does seem fragile. I tried to look for similar use cases in other projects and see how they do it. However, it seems few share io_uring rings across fork() the way we do. Most create rings per thread or per process. So they won't bother doing the local-copy. It maybe worth asking the liburing maintainer whether a copy of struct io_uring is valid input for io_uring_queue_exit(). There's a somewhat hacky alternative. On kernel 6.5+ with liburing 2.5+, we create the rings with io_uring_queue_init_mem() in our own shared memory, so noting maps the ring fds. For those rings, closing the fd is what the teardown has to do, which is also io_uring_queue_exit() does from liburign 2.8 on. In theory, we could just make local copy of the those fd and just close them during cleanup, without invoking into liburing. However, this is against the convention of paring registeration and teardown. -- Regards, Xuneng Zhou HighGo Software Co., Ltd.
