On Mon, 25 May 1998 09:03:30 -0400, Bill Hawes <whawes@star.net> said:
> I'm not concerned with the _final_ free_page, but rather the one that
> takes the page count from 2 to 1. The test_and_atomic_dec will take the
> count from 2 to 1, and then there's a test for PageSwapCache with count
> == 1 leading to a panic. You have comments in vmscan indicating that
> this may occur, and if it wasn't possible to have PageSwapCache with
> count == 1, what would be the point in having shrink_mmap() check for
> it?
Actually, I think that in this case, the code should _usually_ delete
the swap cache immediately the final pte reference is cleared. All The
normal course of action is for all page frees from vm to go through
free_page_and_swap_cache, but that one case where a vma dies during
swapout is a special case: the page may be unlocked and freed for IO at
any point, but during any unlink from a vma, the page will still have
itse swap cache freed during the final unlink.
The only exception I can see right now is if the IO completes right in
the middle of an is_page_shared() test. In that case, it does appear we
may see an elevated page count with no page_free_after flag set, and
will count the flag as indicated a page share. This would inhibit the
delete_swap_cache(), leaving us with an unshared swap cache page.
That's a perfectly legal situation in itself, but it might leave us open
to the situation you describe.
It also highlights the dangers in doing non-interrupt-protected compound
tests on the page state of locked pages. I'll have a quick check over
the rest of the pagein code to make sure we don't rely on the validity
of is_page_shared() on potentially locked pages elsewhere.
> It's true that in the majority of cases the free_page_and_swap_cache
> call will clear the swap cache flag before doing the free, but as long
> as it's possible to have the swap cached page with count 1, doing a
> panic isn't a good idea.
Agreed.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu