• Al Viro's avatar
    parallel lookups machinery, part 2 · 84e710da
    Al Viro authored
    We'll need to verify that there's neither a hashed nor in-lookup
    dentry with desired parent/name before adding to in-lookup set.
    
    One possible solution would be to hold the parent's ->d_lock through
    both checks, but while the in-lookup set is relatively small at any
    time, dcache is not.  And holding the parent's ->d_lock through
    something like __d_lookup_rcu() would suck too badly.
    
    So we leave the parent's ->d_lock alone, which means that we watch
    out for the following scenario:
    	* we verify that there's no hashed match
    	* existing in-lookup match gets hashed by another process
    	* we verify that there's no in-lookup matches and decide
    that everything's fine.
    
    Solution: per-directory kinda-sorta seqlock, bumped around the times
    we hash something that used to be in-lookup or move (and hash)
    something in place of in-lookup.  Then the above would turn into
    	* read the counter
    	* do dcache lookup
    	* if no matches found, check for in-lookup matches
    	* if there had been none of those either, check if the
    counter has changed; repeat if it has.
    
    The "kinda-sorta" part is due to the fact that we don't have much spare
    space in inode.  There is a spare word (shared with i_bdev/i_cdev/i_pipe),
    so the counter part is not a problem, but spinlock is a different story.
    
    We could use the parent's ->d_lock, and it would be less painful in
    terms of contention, for __d_add() it would be rather inconvenient to
    grab; we could do that (using lock_parent()), but...
    
    Fortunately, we can get serialization on the counter itself, and it
    might be a good idea in general; we can use cmpxchg() in a loop to
    get from even to odd and smp_store_release() from odd to even.
    
    This commit adds the counter and updating logics; the readers will be
    added in the next commit.
    Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    84e710da
inode.c 53.1 KB