• David Howells's avatar
    afs: Fix race in commit bulk status fetch · a28f239e
    David Howells authored
    When a lookup is done, the afs filesystem will perform a bulk status-fetch
    operation on the requested vnode (file) plus the next 49 other vnodes from
    the directory list (in AFS, directory contents are downloaded as blobs and
    parsed locally).  When the results are received, it will speculatively
    populate the inode cache from the extra data.
    
    However, if the lookup races with another lookup on the same directory, but
    for a different file - one that's in the 49 extra fetches, then if the bulk
    status-fetch operation finishes first, it will try and update the inode
    from the other lookup.
    
    If this other inode is still in the throes of being created, however, this
    will cause an assertion failure in afs_apply_status():
    
    	BUG_ON(test_bit(AFS_VNODE_UNSET, &vnode->flags));
    
    on or about fs/afs/inode.c:175 because it expects data to be there already
    that it can compare to.
    
    Fix this by skipping the update if the inode is being created as the
    creator will presumably set up the inode with the same information.
    
    Fixes: 39db9815 ("afs: Fix application of the results of a inline bulk status fetch")
    Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    Reviewed-by: default avatarMarc Dionne <marc.dionne@auristor.com>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    a28f239e
dir.c 52 KB