On Mon, 22 Sep 2014, Sasha Levin wrote:
>
> int migrate_page_move_mapping(struct address_space *mapping,
> struct page *newpage, struct page *page,
> struct buffer_head *head, enum migrate_mode mode,
> int extra_count)
> {
> int expected_count = 1 + extra_count;
> void **pslot;
>
> if (!mapping) {
> /* Anonymous page without mapping */
> if (page_count(page) != expected_count)
> return -EAGAIN;
> return MIGRATEPAGE_SUCCESS;
> }
>
> spin_lock_irq(&mapping->tree_lock);
>
> pslot = radix_tree_lookup_slot(&mapping->page_tree,
> page_index(page)); <==== Returned NULL
>
> expected_count += 1 + page_has_private(page);
> if (page_count(page) != expected_count ||
> radix_tree_deref_slot_protected(pslot, &mapping->tree_lock) != page) { <==== Dereferenced that NULL
> spin_unlock_irq(&mapping->tree_lock);
> return -EAGAIN;
> }
>
> I don't think it's just a missing '!= NULL' check
I agree: we have had this page locked since before the
mapping = page_mapping(page), so it ought to be in its radix_tree.
Though if we believe that argument, then am I not implying that the
"radix_blah() != page" check is redundant? Hmm, perhaps someone can
see why it is needed, in which case that might give a hint on the crash.
But my suspicion is that it's just for safety: it corresponds to the
original "*radix_pointer != page" check in the first mm/migrate.c in
2.6.17, which may be there just so as not to rely so heavily on mm
locking protocols enforced elsewhere.
> but I'm not sure what went wrong.
Most likely would be a zeroing of the radix_tree node, just as you
were experiencing zeroing of other mm structures in earlier weeks.
Not that I've got any suggestions on where to take it from there.
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>