Page MenuHomeFreeBSD

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

Authored by kib on Jun 18 2022, 11:07 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 21, 4:59 AM
Unknown Object (File)
Wed, Mar 19, 1:00 PM
Unknown Object (File)
Thu, Mar 13, 3:40 AM
Unknown Object (File)
Wed, Mar 12, 1:21 PM
Unknown Object (File)
Tue, Mar 11, 5:29 PM
Unknown Object (File)
Tue, Mar 11, 12:43 PM
Unknown Object (File)
Feb 17 2025, 8:59 PM
Unknown Object (File)
Feb 7 2025, 12:38 PM
Subscribers

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

kib requested review of this revision.Jun 18 2022, 11:07 AM

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 retitled this revision from UFS: make mkdir() reliable when using SU and reaching nlink limit to UFS: make mkdir() and link() reliable when using SU and reaching nlink limit.

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

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

This revision is now accepted and ready to land.Jun 19 2022, 7:11 PM

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 planned changes to this revision.Jun 19 2022, 7:21 PM

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

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.

This revision is now accepted and ready to land.Jun 19 2022, 10:06 PM