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)
Feb 8 2024, 9:35 PM
Unknown Object (File)
Dec 25 2023, 3:09 PM
Unknown Object (File)
Dec 23 2023, 12:56 AM
Unknown Object (File)
Dec 12 2023, 9:58 AM
Unknown Object (File)
Dec 5 2023, 10:58 AM
Unknown Object (File)
Oct 22 2023, 6:32 PM
Unknown Object (File)
Sep 17 2023, 10:10 AM
Unknown Object (File)
Sep 12 2023, 12:54 AM
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.