Messages in this thread |  | | Date | Fri, 14 Sep 2001 12:45:18 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: 2.4.10pre VM changes: Potential race condition on swap code |
| |
On Thu, 13 Sep 2001, Marcelo Tosatti wrote: > > > > > > CPU0 CPU1 CPU2 > > > do_swap_page() try_to_swap_out() swapin_readahead() ..... > > > BOOM. > > > > > > Now, if we get additional references at valid_swaphandles() the above race > > > is NOT possible: we're guaranteed that any get_swap_page() will not find > > > > Err I mean _will_ find the swap map entry used and not use it, then. > > > > > the swap map entry used. See?
Yes, I see it now: had trouble with the line wrap!
Sure, that's one of the scenarios we were talking about, and getting additional references in valid_swaphandles will stop that particular race.
It won't stop the race with "bare" read_swap_cache_async (which can happen with swapoff, or with vm_swap_full deletion if multithreaded), and won't stop the race when valid_swaphandles->swap_duplicate comes all between try_to_swap_out's get_swap_page and add_to_swap_cache.
The first of those is significantly less likely than swapin_readahead instance. The second requires interrupt at the wrong moment: can certainly happen, but again less likely.
Adding back reference bumping in valid_swaphandles would reduce the likelihood of malign read_swap_cache_async/try_to_swap_out races, but please don't imagine it's the final fix.
Hugh
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |