Bug 404711

Description of problem:
This problem was initially discovered in bug #220052 while trying to install
RHEL5 with gfs2 as the root filesystem. Some screenshots of the panic are in
that bug report.

The first lock is requested to unlink an already existing
inode (replacing a file) and the second lock is requested when the destination
directory needs to alloc some space. It is rare that these two events happen
during the same rename call, and even more rare that these two instances try to
lock the same rgrp. It is, however, possible.

Running these set of commands 2-3 times in a gfs2 filesystem will trigger this
panic.

mkdir first second;
for i in `seq 1 78`; do touch first/foo$i; done;
mv first/* second/;
cp a100MBfile first/foo1;
mv first/foo1 second/; /* This mv, unlinks file 'second/foo1' and also causes
directory 'second' to trigger an allocation request */
rm -Rf first second;

Here, 78 is my magic number for the number of foo* files that the destination
directory can hold. Adding any more information to the directory will trigger
an allocation request.

Version-Release number of selected component (if applicable):


How reproducible:
fairly easy.

Steps to Reproduce:
1. Run the above set of instructions on a gfs2 filesystem a few times.