• Dave Chinner's avatar
    xfs: inodes are new until the dentry cache is set up · 58c90473
    Dave Chinner authored
    Al Viro noticed a generic set of issues to do with filehandle lookup
    racing with dentry cache setup. They involve a filehandle lookup
    occurring while an inode is being created and the filehandle lookup
    racing with the dentry creation for the real file. This can lead to
    multiple dentries for the one path being instantiated. There are a
    host of other issues around this same set of paths.
    The underlying cause is that file handle lookup only waits on inode
    cache instantiation rather than full dentry cache instantiation. XFS
    is mostly immune to the problems discovered due to it's own internal
    inode cache, but there are a couple of corner cases where races can
    We currently clear the XFS_INEW flag when the inode is fully set up
    after insertion into the cache. Newly allocated inodes are inserted
    locked and so aren't usable until the allocation transaction
    commits. This, however, occurs before the dentry and security
    information is fully initialised and hence the inode is unlocked and
    available for lookups to find too early.
    To solve the problem, only clear the XFS_INEW flag for newly created
    inodes once the dentry is fully instantiated. This means lookups
    will retry until the XFS_INEW flag is removed from the inode and
    hence avoids the race conditions in questions.
    THis also means that xfs_create(), xfs_create_tmpfile() and
    xfs_symlink() need to finish the setup of the inode in their error
    paths if we had allocated the inode but failed later in the creation
    process. xfs_symlink(), in particular, needed a lot of help to make
    it's error handling match that of xfs_create().
    Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
    Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
    Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
xfs_iops.h 1.32 KB