This getdents64 deadlock is fairly repeatable. I've gotten it to
occur maybe five more times since my last message--always by
initiating a rebuild on a source RPM, where the %clean scriptlet
rm -Rf's five separate directory trees. Exactly which rm -Rf
operation triggers the deadlock varies, and it sometimes takes
more than one testcase run to trigger it.
When the deadlock occurs, the only thing that appears to break it
is to allocate or unlink an inode on the same filesystem as the
deadlocked rm -Rf operation (this trick works every time). Once
that happens, the operation continues normally, until the
testcase gets run again and trips the deadlock all over.
Any idea how to trace this further? I'm really not much of a
kernel hacker. If I knew exactly where a getdents64() call ends
up in the XFS driver, I suppose I might be able to take it a
little further...
--
Kelledin
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"
|