Page MenuHomeFreeBSD

vm_page: Tighten the object lock assertion in vm_page_invalid()
ClosedPublic

Authored by markj on Dec 3 2021, 5:49 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Dec 14, 12:07 PM
Unknown Object (File)
Fri, Dec 13, 7:02 PM
Unknown Object (File)
Nov 5 2024, 4:27 AM
Unknown Object (File)
Oct 22 2024, 4:18 PM
Unknown Object (File)
Oct 5 2024, 8:48 AM
Unknown Object (File)
Oct 4 2024, 11:09 PM
Unknown Object (File)
Oct 2 2024, 7:25 AM
Unknown Object (File)
Oct 1 2024, 4:13 PM
Subscribers

Details

Summary

A page must not become invalid while vm_fault_soft_fast() is attempting
to map unbusied pages for reading.

Note that all callers hold the object write lock already, and
vm_page_set_invalid() asserts the object write lock.

I am not really sure it is wise to permit clearing of valid bits without
xbusy, either. Currently all vm_page_invalid() callers have the page
xbusied, but there is one user of vm_page_set_invalid() that only
sbusies the page. It can be trivially converted to xbusy the page, I
think. Is there any reason to permit clearing of valid bits from a
shared-busy page?

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Dec 3 2021, 5:49 PM

Are you referencing vfs_bio' vfs_vmio_invalidate() as the place where page is sbusied for invalidation? Generally buffer cache only uses sbusy and not xbusy, because it might recurse.

This revision is now accepted and ready to land.Dec 4 2021, 5:06 AM
In D33250#751733, @kib wrote:

Are you referencing vfs_bio' vfs_vmio_invalidate() as the place where page is sbusied for invalidation?

Yes.

Generally buffer cache only uses sbusy and not xbusy, because it might recurse.

Right, ok. In this one case I believe it may not be a problem, not sure yet.