> On Mon, 12 Aug 2002, Christian Ehrhardt wrote:
> > Note the strange use of continue and break which both achieve the same!
> > What was meant to happen (judging from rmap-13c) is that we break
> > out of the for-Loop once SWAP_FAIL or SWAP_ERROR is returned from
> > try_to_unmap_one. However, this doesn't happen and a subsequent call
> > to pte_chain_free will use the wrong value for prev_pc.
> Excellent hunting! Thank you!
> Your fix should work too, although in my opinion it's a
> little bit too subtle, so I've changed it into:
> case SWAP_FAIL:
> ret = SWAP_FAIL;
> goto give_up;
> case SWAP_ERROR:
> ret = SWAP_ERROR;
> goto give_up;
Any chance this is the cause of the following?
Subject: Re: [patch 1/21] random fixes
From: Adam Kropelin <email@example.com>
Date: 2002-08-12 2:54:31
FYI, just got this while un-tarring a kernel tree with
(no nvidia ;)
Date: Sun, 11 Aug 2002 20:40:31 -0700
From: Andrew Morton <firstname.lastname@example.org>
That'll be this one:
BUG_ON(page->pte.chain != NULL);
we've had a few reports of this dribbling in since rmap went in. But
nothing repeatable enough for it to be hunted down.
But we do have a repeatable inconsistency happening with ntpd and
memory pressure. That may be related, but in that case it's probably
related to mlock().
So. An open bug, alas.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/