Re: [BUG] deadlock on rename_lock

[Waiman Long]

On 02/27/2014 07:45 PM, Jaegeuk Kim wrote:
> Hi Al,
>
> In the following configuration, I met a deadlock condition like below.
>
> Kernel: 3.14-rc3
> Workload: fsstress with 10 threads
> Reproducible scenario: N/A
>
> Is it related to this patch?
> commit 1370e97bb2eb1ef2df7355204e5a4ba13e12b861
> Author: Waiman Long<Waiman.Long@xxxxxx>
> Date:   Thu Sep 12 10:55:34 2013 -0400
>
>      seqlock: Add a new locking reader type
>
> In d_walk(),
>                  /*
>                   * might go back up the wrong parent if we have had a
> rename
>                   * or deletion
>                   */
>                  if (this_parent != child->d_parent ||
>                           (child->d_flags&  DCACHE_DENTRY_KILLED) ||
>
> -->  I suspect that the upper conditions can trigger rename_retry even
> though rename_retry was done once before.
>
>                           need_seqretry(&rename_lock, seq)) {
>                          spin_unlock(&this_parent->d_lock);
>                          rcu_read_unlock();
>                          goto rename_retry;
>                  }
>
> Thanks,

It seems like the rename_lock may not be able to fully protect against 
the setting of the DCACHE_DENTRY_KILLED flag. Al, should this case be 
handled separately? I am 100% sure if we could just release the lock and 
let it try again without causing infinite loop.

-Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/