Description of problem:
This is a regression introduced by commit f2ffb1e.
Before commit f2ffb1e, function basic_dentry_checks had access to a
complete inode tree, so it was able to check the formal inode number
of every dentry against what it previously found in the inode in
pass1. But commit f2ffb1e changed function basic_dentry_checks so
that it bypasses the check if the reference count is 1, which is
most likely, and it's going to be correct 99% of the time. The
comments state:

"Since we don't have ii or di, the only way to validate formal_ino
is to read in the inode, which would kill performance. So skip it
for now."

The problem is, problems can slip through, undetected, and will
only be fixed with a second run of fsck.gfs2. For example, during
testing, I found a set of gfs2 metadata that had two dentries
pointing to the same dinode. The first dentry encountered by pass2
was wrong, but it was not checked for this reason. The second
dentry was correct. The first run of fsck did not catch the problem
and reacted by setting link count to 2 for the dinode, keeping
both dentries. The second run found the problem and fixed it,
changing the link count back to 1 and deleting the bad dentry.

Note that this problem only applies to non-directories, since
directories will have a value in the dirtree to check against.

Version-Release number of selected component (if applicable):
RHEL7.3 pre-release

How reproducible:
Always

Steps to Reproduce:
1.Restore metadata set 00716231-LogVolUser1.150113.prefsck.902920.mda
  to a device
2.Run fsck.gfs2 -y
3.Run fsck.gfs2 without -y

Actual results:
The first run acts like it fixed all the problems.
The second run complains about a dinode with the wrong formal inode number.
The bad dentry, "goog-phish-shavar.sbstore" is deleted from the
directory.

Expected results:
The problem in goog-phish-shavar.sbstore should be found and
fixed on the first run. The second run should come up clean and
give a 0 return code.

Additional info:
I've got a working patch for this.