Messages in this thread | | | Date | Fri, 14 Apr 2006 12:53:20 -0700 | From | Andrew Morton <> | Subject | Re: Implement lookup_swap_cache for migration entries |
| |
Christoph Lameter <clameter@sgi.com> wrote: > > On Fri, 14 Apr 2006, Andrew Morton wrote: > > > > > What locking ensures that the state of `entry' remains unaltered across the > > > > is_migration_entry() and migration_entry_to_page() calls? > > > > > > entry is a variable passed by value to the function. > > > > Sigh. > > > > What locking ensures that the state of the page referred to by `entry' is > > stable? > > Oh, that. > > Well, there is no locking when retrieving a pte atomically from the page > table. In do_swap_cache we figure out the page from the pte, lock the page > and then check that the pte has not changed. If it has changed then we > redo the fault. If the pte is still the same then we know that the page > was stable in the sense that it is still mapped the same way. So it was > not freed. > > This applies to all pages handled by do_swap_page(). > > The differences are: > > 1. A migration entry does not take the tree_lock in lookup_swap_cache(). > > 2. The migration thread will restore the regular pte before > dropping the page lock. > > So after we succeed with the page lock we know that the pte has been > changed. The fault will be redone with the regular pte.\
So we're doing a get_page() on a random page which could be in any state - it could be on the freelists, or in the per-cpu pages arrays, it could have been reused for something else.
There's code in the kernel which assumes that we don't do that sort of thing. For example:
static inline int page_is_buddy(struct page *page, int order) { #ifdef CONFIG_HOLES_IN_ZONE if (!pfn_valid(page_to_pfn(page))) return 0; #endif
if (PageBuddy(page) && page_order(page) == order) { BUG_ON(page_count(page) != 0); return 1; } return 0; }
- 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/
| |