linux-kernel - Re: [BUG] deadlock on rename

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <53100B62.8000704@hp.com>
Date:	Thu, 27 Feb 2014 23:06:58 -0500
From:	Waiman Long <waiman.long@...com>
To:	jaegeuk.kim@...sung.com
CC:	Al Viro <viro@...IV.linux.org.uk>,
	"Linux Kernel, Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] deadlock on rename_lock

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