• Al Viro's avatar
    parallel lookups machinery, part 3 · 94bdd655
    Al Viro authored
    We will need to be able to check if there is an in-lookup
    dentry with matching parent/name.  Right now it's impossible,
    but as soon as start locking directories shared such beasts
    will appear.
    
    Add a secondary hash for locating those.  Hash chains go through
    the same space where d_alias will be once it's not in-lookup anymore.
    Search is done under the same bitlock we use for modifications -
    with the primary hash we can rely on d_rehash() into the wrong
    chain being the worst that could happen, but here the pointers are
    buggered once it's removed from the chain.  On the other hand,
    the chains are not going to be long and normally we'll end up
    adding to the chain anyway.  That allows us to avoid bothering with
    ->d_lock when doing the comparisons - everything is stable until
    removed from chain.
    
    New helper: d_alloc_parallel().  Right now it allocates, verifies
    that no hashed and in-lookup matches exist and adds to in-lookup
    hash.
    
    Returns ERR_PTR() for error, hashed match (in the unlikely case it's
    been found) or new dentry.  In-lookup matches trigger BUG() for
    now; that will change in the next commit when we introduce waiting
    for ongoing lookup to finish.  Note that in-lookup matches won't be
    possible until we actually go for shared locking.
    
    lookup_slow() switched to use of d_alloc_parallel().
    
    Again, these commits are separated only for making it easier to
    review.  All this machinery will start doing something useful only
    when we go for shared locking; it's just that the combination is
    too large for my taste.
    Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    94bdd655
namei.c 115 KB