Messages in this thread | | | Date | Mon, 12 Aug 2002 19:44:54 -0500 (CDT) | From | Thomas Molina <> | Subject | Re: pte_chain leak in rmap code (2.5.31) |
| |
On Mon, 12 Aug 2002, Rik van Riel wrote:
> 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; > } > } > give_up:
Any chance this is the cause of the following?
---------------extract-----------------------
Subject: Re: [patch 1/21] random fixes From: Adam Kropelin <akropel1@rochester.rr.com> Date: 2002-08-12 2:54:31
FYI, just got this while un-tarring a kernel tree with 2.5.31+everything.gz: (no nvidia ;)
Date: Sun, 11 Aug 2002 20:40:31 -0700 From: Andrew Morton <akpm@zip.com.au>
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 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/
| |