UFS: make mkdir() and link() reliable when using SU and reaching nlink limit

[kib]

Summary

PR: 165392

[mckusick]

This looks like the correct solution to me. As noted in bug report 165392, link and rename also need the same fix.

Peter Holm has a long-standing test that also triggers either this bug or one related to it. I was never able to track down the cause so it has been disabled for years but should be resurrected.

[kib]

Also handle link(). Rename cannot be handled this way, and would require a separate patch.

[mckusick]

This looks good. I concur that rename requires a different approach so can be the subject of another change.

[kib]

In fact the patch for link() is wrong, for the reasons similar to rename(). vpp is locked so needs to be handled around ufs_sync_nlink().

[kib]

Try to fix link() handling, one more vnode is locked there.

[mckusick]

Right. I should have noticed that something was missing in ufs_sync_nlink() when it did not include a use of vn_lock_pair(). I believe that this is now correct.

The rename system call will only have a permanent link count increase when moving a directory where the destination directory link count will increase by one. The tricky part is handling transient link count overages when a file with UFS_LINK_MAX links is moved and temporarily gets UFS_LINK_MAX + 1 until its old name is removed from its previous location. Rather than writing a lot of special purpose code to handle this very obscure case, I think we should simply not allow rename of files with UFS_LINK_MAX existing links.