lkml.org 
[lkml]   [2012]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: processes hung after sys_renameat, and 'missing' processes
On Wed, Jun 6, 2012 at 5:29 PM, Dave Jones <davej@redhat.com> wrote:
>
> Like this ?

No.

>  void d_move(struct dentry *dentry, struct dentry *target)
>  {
>        write_seqlock(&rename_lock);
> +
> +       BUG_ON(!spin_is_locked(&target->d_parent->d_lock));
> +
> +       if (dentry->d_parent != NULL)
> +               BUG_ON(!spin_is_locked(&dentry->d_parent->d_lock));

It's true that the d_lock needs to be held too, but we actually do
that in __d_move() (which calls dentry_lock_for_move), so the callers
don't have to worry about that part.

So Al meant you to test mutex_is_locked(dentry->d_inode->i_mutex) of
the parents.

And I'd suggest making it just a WARN_ON_ONCE(), because if you make
it a BUG_ON() and it triggers, your system will likely be dead. And
ONCE is all that matters - it should never happen.

> To be clear, do you want me to try that with or without the reverts ?

I think either would be interesting. *If* that d_move() from
d_splice_alias ever triggers, that would be an interesting backtrace
to see too.

Of course, if that d_splice_alias change is the cause of this, then
with those two commits reverted you'd not be able to reproduce the
problem, which would also be interesting to know, so either way it
would be good information.

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

\
 
 \ /
  Last update: 2012-06-07 03:21    [W:0.096 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site