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.l...@hp.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
