Page MenuHomeFreeBSD

Handle ERELOOKUP from VOP_FSYNC()
ClosedPublic

Authored by kib on Jan 18 2023, 9:12 PM.
Tags
None
Referenced Files
F86564417: D38114.id115281.diff
Sat, Jun 22, 6:51 AM
F86564305: D38114.id115277.diff
Sat, Jun 22, 6:48 AM
Unknown Object (File)
Fri, Jun 21, 9:47 AM
Unknown Object (File)
Fri, Jun 21, 9:04 AM
Unknown Object (File)
May 15 2024, 9:16 PM
Unknown Object (File)
May 12 2024, 9:57 AM
Unknown Object (File)
May 8 2024, 6:03 PM
Unknown Object (File)
May 8 2024, 5:58 PM
Subscribers

Details

Summary

We need to repeat the operation if the vnode was relocked.

Reported by: markj

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

kib requested review of this revision.Jan 18 2023, 9:12 PM

Thanks, this fixes the panic I saw.

sys/vm/vm_object.c
1239

Why isn't it necessary to relock the vnode here like we do in md? And if we can simply call VOP_FSYNC() in a loop like this, why not handle the retry entirely in the VOP?

sys/vm/vm_object.c
1239

Generally it is useful to unlock the vnode since it allows SU thread and bufdaemon to clean more dependencies that perhaps caused the relock during ffs_fsyncvnode().

I added the relock there.

Relock for vm_object_sync()

kib marked an inline comment as done.Jan 18 2023, 9:57 PM
markj added inline comments.
sys/vm/vm_object.c
1245
This revision is now accepted and ready to land.Jan 18 2023, 10:15 PM
kib marked an inline comment as done.

Avoid duplicating VOP_FSYNC() call.
Move comment to the more logical place. Make it stylish.

This revision now requires review to proceed.Jan 18 2023, 10:31 PM
markj added inline comments.
sys/vm/vm_object.c
1250
This revision is now accepted and ready to land.Jan 19 2023, 3:49 PM