On 8/29/25 17:43, Darrick J. Wong wrote: > On Wed, Aug 27, 2025 at 12:59:55PM +0200, Miklos Szeredi wrote: >> FUSE_INIT has always been asynchronous with mount. That means that the >> server processed this request after the mount syscall returned. >> >> This means that FUSE_INIT can't supply the root inode's ID, hence it >> currently has a hardcoded value. There are other limitations such as not >> being able to perform getxattr during mount, which is needed by selinux. >> >> To remove these limitations allow server to process FUSE_INIT while >> initializing the in-core super block for the fuse filesystem. This can >> only be done if the server is prepared to handle this, so add >> FUSE_DEV_IOC_SYNC_INIT ioctl, which >> >> a) lets the server know whether this feature is supported, returning >> ENOTTY othewrwise. >> >> b) lets the kernel know to perform a synchronous initialization >> >> The implementation is slightly tricky, since fuse_dev/fuse_conn are set up >> only during super block creation. This is solved by setting the private >> data of the fuse device file to a special value ((struct fuse_dev *) 1) and >> waiting for this to be turned into a proper fuse_dev before commecing with >> operations on the device file. > > By the way, how is libfuse supposed to use SYNC_INIT? I gather libfuse > will have to start up the background fuse workers threads to listen for > events /before/ the actual mount() call? libfuse actually starts worker threads dynamically. Not something that I like too much, but I also don't want to change it too much. The io-uring threads are started all at once, when FUSE_INIT is received. Regarding the /dev/fuse worker threads, there are also existing races with actual thread buffer size - I'm going to change it to only allow one thread until FUSE_INIT is processed. Thanks, Bernd
