On Mon, 7 Sep 1998 18:44:02 -0700, "David S. Miller"
<davem@dm.cobaltmicro.com> said:
> I think people need to look at the swap changes.
> One thing I have just noticed is that a (possibly important) invariant
> has changed. Now there is one place in the kernel where
> swap_duplicate() is called before a page is entered into the swap
> cache.
The ordering should not matter. The swap cache is absolutely not
interrupt safe, so in the absense of blocking, we should be protected by
the global kernel lock here. The only way we might get unexpected
behaviour from the order
> if (!swap_duplicate(entry)) /* Account for the swap cache */
> goto out_free_page;
> if (!add_to_swap_cache(new_page, entry))
> goto out_free_page;
is if one or other calls fail. Under normal circumstances, the
swap_duplicate will only fail if the swap is no longer used by this
point (eg. another thread has paged it in and modified it, invalidating
the swap cache entry). The add_to_swap_cache cannot fail except through
an error logged to the console.
> Ie. always it is the case that the entry is in the swap cache before
> it is duplicated. This invariant has been around for some time which
> is why I look at it suspiciously. Whoops, I look again and there is
> in fact one other place where the ordering is different
> (vmscan.c:try_to_swap_out).
Yes. vmscan has done it the other way around since 2.1.89. We also do
a swap_duplicate on fork (obviously!) without ever even looking at the
swap cache. The two are very different things.
> This could be a red herring, I'll look at it some more.
OK, do let me know if it still worries you, but I know Bill has had
these patches out for a while, and they have been in use prior to
2.1.120 without anyone reporting errors. Specifically, the ordering of
the duplicate should matter not at all.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html