In vm_map_copy_swap_object the object lock is not needed to protect charge/ucred because they are protected by the map lock.

[jeff]

Summary

I believe that the map lock actually protects these two object fields. It would be nice to document the object fields with a lock key like we do elsewhere. If people agree that this synchronization is sufficient I can document this particular case.

This shows up on tmpfs buildkernel. We do have swap but we don't need the anonymous object book keeping.

[kib]

I believe that the lack of swap accounting to the vnode owner is a bug in tmpfs.

I think that the change would work for now, until the tmpfs bug is fixed, but please put an XXX comment there.

[jeff]

In D22747#497793, @kib wrote:

I believe that the lack of swap accounting to the vnode owner is a bug in tmpfs.

I think that the change would work for now, until the tmpfs bug is fixed, but please put an XXX comment there.

If you look all of the cred/charge accounting still happens. It just doesn't happen under the object lock. I do not think the object lock is necessary here. All modifications are done under the map lock until the final drop of the object releases the space. At that point it is guaranteed single threaded.

[markj]

sys/vm/vm_map.c

3888 ↗

(On Diff #65450)

It would be nice to have a flavour of vm_object_reference() that asserts that the ref_count is at least 1, as it must be in this case. We could use xadd instead of cmpxchg there too.