Miklos Szeredi: > Basically yes. Accessing the file type in inode->i_mode is OK, but > for all other fields getattr() needs to be called. > > > If it is true, current linux lookup routines are totally broken since > > they check inode.i_mode so often without vfs_getattr(). > > They only check the file type.
When you create/remove something, lookup operation involves accessing inode->i_uid, i_gid, permission bits in i_mode, i_ino and i_flags. For example, - lookup involves permission check which uses i_flags. i_flags is handled by ioctl generally. in this case, ioctl(GETFLAGS) or something is necessary too? - may_open() checks inode->i_uid. - unlink(2) and rmdir(2) check the sticky bit and inode->i_uid. - notify_change() which is called by chmod family is checking i_[ug]id. - find_inode_number() searches the cached inode by its name and returns i_ino. - vfs_quota_on() calls path_lookup() and then write back the gotten inode by vfs_quota_on_inode() and write_inode_now(). It involves referenccing and updating inode members. - while I don't know whether fuse supports NFS-export or not, nfsd depends upon inode->i_ino in many cases (before NFS GETATTR operation). Are they all wrong too? Or i_nlink is the exception? > It wouldn't help. The problem is that fuse doesn't (and cannot) > initialize the fields of the root inode at mount time. What I meant is, for example, to issue stat(2) just after fuse_main(). Is it unavialbe too? > Note, that relying on cached attribute values is wrong anyway, in > network filesystems the attributes can become stale and need to be > refreshed before being used. Yes, that's why d_revalidate and FS_REVAL_DOT exists. But revalidating or refreshing doesn't involve getattr I think. Junjiro Okajima ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
