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)
Dec 20 2023, 7:56 AM
Unknown Object (File)
Nov 23 2023, 11:29 PM
Unknown Object (File)
Nov 8 2023, 2:55 PM
Unknown Object (File)
Nov 7 2023, 7:27 AM
Unknown Object (File)
Nov 6 2023, 4:01 PM
Unknown Object (File)
Oct 7 2023, 1:45 PM
Unknown Object (File)
Oct 6 2023, 6:23 AM
Unknown Object (File)
Oct 5 2023, 2:59 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.