Thanks for looking at these patches! I'm adding in Ming Lei, as I had taken several ideas from ublkm I guess I also should also explain in the commit messages and code why it is done that way. On 3/23/23 11:27, Miklos Szeredi wrote: > On Tue, 21 Mar 2023 at 02:11, Bernd Schubert <bschubert@xxxxxxx> wrote: >> >> This adds a delayed work queue that runs in intervals >> to check and to stop the ring if needed. Fuse connection >> abort now waits for this worker to complete. > > This seems like a hack. Can you explain what the problem is? > > The first thing I notice is that you store a reference to the task > that initiated the ring creation. This already looks fishy, as the > ring could well survive the task (thread) that created it, no? You mean the currently ongoing work, where the daemon can be restarted? Daemon restart will need some work with ring communication, I will take care of that once we have agreed on an approach. [Also added in Alexsandre]. fuse_uring_stop_mon() checks if the daemon process is exiting and and looks at fc->ring.daemon->flags & PF_EXITING - this is what the process reference is for. > > Can you explain why the fuse case is different than regular io-uring? libfuse sends IORING_OP_URING_CMD - forward command and everything is handled by fuse.ko - fuse.ko receives the SQE and stores it. On shutdown that command needs to be completed with io_uring_cmd_done(). If you forget to do it - worker queues will go into D-state and print warning messages in intervals in uring code. Purpose of check of PF_EXITING is to detect if the daemon is getting killed and to release uring resources, even if you didn't umount yet. Thanks, Bernd
