On 10/2/23 03:57, Yuan Yao wrote: > Hi, I’m Yuan, particularly interested in this patch set, and I've > noticed some ambiguity regarding the behavior of atomic_open for > symbolic links. > > > I think this part may cause a problem if we atomic_open a symbolic > link.The previous behavior for fuse_create_open() will only do lookup > but not open the symbolic link. But, with the full atomic open kernel > patch. My understanding is that when the kernel performs an atomic_open > operation on a symbolic link, the dentry returned from the FUSE server > contains the inode pointing to the opened symbolic link. However, after > atomic_open() is called, the may_open() function in namei.c checks the > node's i_mode and identifies it as a symbolic link, resulting in an > ELOOP error. Thanks for testing it, I didn't manage to look into it yet, but will for sure do during the next days (I hope tomorrow). > > > My concernn is: what is the expected behavior for opening a symbolic > link, both on the kernel side and the server side? Is it possible for > the fuse server to return the dentry containing the inode of the link > destination instead of the inode of the symbolic link itself? nfs_atomic_open handles -ELOOP. Possibly fuse server needs to check for O_NOFOLLOW, but I'm not sure. Will look into that in the morning. Thanks, Bernd
