• Vivek Goyal's avatar
    ovl: A new xattr OVL_XATTR_METACOPY for file on upper · 0c288874
    Vivek Goyal authored
    Now we will have the capability to have upper inodes which might be only
    metadata copy up and data is still on lower inode.  So add a new xattr
    OVL_XATTR_METACOPY to distinguish between two cases.
    
    Presence of OVL_XATTR_METACOPY reflects that file has been copied up
    metadata only and and data will be copied up later from lower origin.  So
    this xattr is set when a metadata copy takes place and cleared when data
    copy takes place.
    
    We also use a bit in ovl_inode->flags to cache OVL_UPPERDATA which reflects
    whether ovl inode has data or not (as opposed to metadata only copy up).
    
    If a file is copied up metadata only and later when same file is opened for
    WRITE, then data copy up takes place.  We copy up data, remove METACOPY
    xattr and then set the UPPERDATA flag in ovl_inode->flags.  While all these
    operations happen with oi->lock held, read side of oi->flags can be
    lockless.  That is another thread on another cpu can check if UPPERDATA
    flag is set or not.
    
    So this gives us an ordering requirement w.r.t UPPERDATA flag.  That is, if
    another cpu sees UPPERDATA flag set, then it should be guaranteed that
    effects of data copy up and remove xattr operations are also visible.
    
    For example.
    
    	CPU1				CPU2
    ovl_open()				acquire(oi->lock)
     ovl_open_maybe_copy_up()                ovl_copy_up_data()
      open_open_need_copy_up()		 vfs_removexattr()
       ovl_already_copied_up()
        ovl_dentry_needs_data_copy_up()	 ovl_set_flag(OVL_UPPERDATA)
         ovl_test_flag(OVL_UPPERDATA)       release(oi->lock)
    
    Say CPU2 is copying up data and in the end sets UPPERDATA flag.  But if
    CPU1 perceives the effects of setting UPPERDATA flag but not the effects of
    preceding operations (ex. upper that is not fully copied up), it will be a
    problem.
    
    Hence this patch introduces smp_wmb() on setting UPPERDATA flag operation
    and smp_rmb() on UPPERDATA flag test operation.
    
    May be some other lock or barrier is already covering it. But I am not sure
    what that is and is it obvious enough that we will not break it in future.
    
    So hence trying to be safe here and introducing barriers explicitly for
    UPPERDATA flag/bit.
    Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
    Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
    Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
    0c288874
util.c 18.4 KB