Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 6 Jun 2012 17:42:35 -0700 | Subject | Re: 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/
| |