statfs(2): allow to interrupt busying
ClosedPublic
Actions

Authored by kib on Jul 27 2026, 1:45 PM.

Details

Reviewers

markj
olce
jah

Commits

rGb72f9bfc4513: statfs(2): allow to interrupt busying
rGfb4d7bd4b767: vfs_busy(): add MBF_PCATCH flag to allow interrupting the sleep

Summary

There are probably more places which could benefit from allowing to
interrupt vfs_busy() calls at syscalls top level.

Requested by:   Peter Eriksson <pen@lysator.liu.se>


vfs_busy(): add MBF_PCATCH flag to allow interrupting the sleep

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

kib created this revision.Jul 27 2026, 1:45 PM

Herald added subscribers: olce, imp. · View Herald TranscriptJul 27 2026, 1:45 PM

kib requested review of this revision.Jul 27 2026, 1:45 PM

emaste added a subscriber: emaste.Jul 27 2026, 1:58 PM

kib added reviewers: markj, olce, jah.Jul 28 2026, 1:19 AM

kib removed a subscriber: olce.

Coorect MBF_MASK.

jah added inline comments.Jul 28 2026, 7:01 AM

sys/kern/vfs_subr.c
934	If we were to leak the flag here, what would be the impact? It would seem that the pending unmount (whether successful or not) should always ultimately clear the flag, at which point it would also issue a wakeup(). That wakeup might harmlessly do nothing if our canceled wait happened to be the only one, but that seems less potentially disruptive than possibly waking up N other vfs_busy() callers.
936	spelling nit: then -> than
941	Should this case reacquire mountlist_mtx if MBF_MNTLSTLOCK was passed? It seems we expect failed calls of vfs_busy() in general to return with the lock still held, though perhaps there's no caller that would pass both MBF_PCATCH and MBF_MNTLSTLOCK. If we do want to reacquire that lock, then it might be cleaner to move this error-handling case below the call to MNT_ILOCK() at line 945.