Page MenuHomeFreeBSD

Update vm object lock assertions in the swap pager
ClosedPublic

Authored by alc on Aug 26 2017, 9:11 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Oct 4, 4:17 AM
Unknown Object (File)
Tue, Sep 23, 11:44 PM
Unknown Object (File)
Aug 26 2025, 10:32 PM
Unknown Object (File)
Jul 30 2025, 1:26 PM
Unknown Object (File)
Jul 29 2025, 7:25 PM
Unknown Object (File)
Jul 28 2025, 4:30 PM
Unknown Object (File)
Jul 28 2025, 4:18 AM
Unknown Object (File)
Jul 27 2025, 11:49 PM
Subscribers
None

Details

Summary

Update a couple vm object lock assertions in the swap pager to reflect the new use of the vm object's lock to synchronize updates to a radix trie mapping per-vm object page indices to on-disk swap blocks.

Fix a typo in a nearby comment.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Aug 26 2017, 9:22 PM

This change reveals a problem: vm_fault_soft_fast() is (indirectly) calling vm_pager_page_unswapped() with only a read lock.

In D12134#251899, @alc wrote:

This change reveals a problem: vm_fault_soft_fast() is (indirectly) calling vm_pager_page_unswapped() with only a read lock.

My understanding is that this is a valid assert in the following situation: we have a swap object with a valid page which was swapped in and not dirtied. Then, on a write fault, any (fast or normal) fault handlers could free the swap space. It is possible because swap pager page-in leaves the backed swap space intact as (IMO very small) optimization.

I think that as a solution we can leave the swap allocated. If the page going to swap later again, swp_pager_meta_build() correctly frees the old space. This causes some time-limited leak of the swap space, which is IMO acceptable.

alc edited edge metadata.

Update vm_fault_dirty().

This revision now requires review to proceed.Aug 28 2017, 4:32 AM
In D12134#251911, @kib wrote:
In D12134#251899, @alc wrote:

This change reveals a problem: vm_fault_soft_fast() is (indirectly) calling vm_pager_page_unswapped() with only a read lock.

My understanding is that this is a valid assert in the following situation: we have a swap object with a valid page which was swapped in and not dirtied. Then, on a write fault, any (fast or normal) fault handlers could free the swap space. It is possible because swap pager page-in leaves the backed swap space intact as (IMO very small) optimization.

It might also be the case that we write fault on a just laundered page before it is reclaimed.

I think that as a solution we can leave the swap allocated. If the page going to swap later again, swp_pager_meta_build() correctly frees the old space. This causes some time-limited leak of the swap space, which is IMO acceptable.

Agreed.

This revision is now accepted and ready to land.Aug 28 2017, 8:43 AM
This revision was automatically updated to reflect the committed changes.