Fix panic while looking up a symlink due to NULL i_op->get_link

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2048567

When following a trailing symlink in rcu-walk mode it's possible for the dentry to become invalid between the last dentry seq lock check and getting the link path (eg. a concurrent unlink) when using an xfs file system.

This occurs because xfs can re-use inodes whereas the VFS requires an inode not change before it's actually freed. This normally doesn't occur while the rcu read lock is held (eg. during rcu-mode path walks) or until after an rcu grace period.

So this needs to be fixed in xfs but simply introducing an rcu grace period delay has significant effects on the now expected performance of some work loads so it can't be done without further significant work (of the order of 1 to 2 years with current work loads).

Because of this a work around is needed while we wait for the xfs work to be done since a work-around will not be accepted into the upstream kernel as it's seen as a band-aid only and not a real solution.

The first patch here addresses the related problem of the link path string being freed while the VFS is traversing it which is much more likely with the xfs inode re-use problem described above. It simply allocated storage for the link path string and passes that to the VFS to use and disard when done.

The second patch is a work around to mitigate the xfs inode re-use in the xfs. All it does is check if the dentry has become invalid, which it surely has if an unlink has occured, before attempting to use the ->get_link() inode operation to get the link path string.

Since the work around isn't an acceptable fix for upstream we need a RHEL-only change for this while we wait for the upstream work to be done.

Signed-off-by: Ian Kent ikent@redhat.com