Re: [PATCH] Compound page overhaul
From: David Howells
Date: Tue Nov 23 2004 - 14:08:08 EST
William Lee Irwin III <wli@xxxxxxxxxxxxxx> wrote:
> The MMU-less code appears to assume the refcounts of the tail pages
> will remain balanced, and elevates them to avoid the obvious disaster.
> But this looks rather broken barring some rather unlikely invariants.
I had to fix it to make it work, but what's currently lurking in Andrew's tree
seems more or less correct, just not necessarily safe.
> I presume the patch is backing that out so refcounting works properly, or in
> the nomenclature above (for which there is a precedent) makes the refcount a
> superpage property uniformly across MMU and MMU-less cases.
My patch drops the old !MMU page refcount wangling stuff in favour of using
compound pages, which seem to work just as well.
> It's unclear (to me) how the current MMU-less code works properly, at
> the very least.
For the most part it's down to two !MMU bits in page_alloc.c - one sets all
the refcounts on the pages of a high-order allocation, and the other
decrements them all again during the first part of freeing.
This works okay with access_process_vm() as is because that pins the mm_struct
semaphore too; but it's also possible that something else does or will pin a
secondary page and then drop the semaphore.
> It would appear to leak memory since there is no obvious guarantee the
> reference to the head page will be dropped when needed, though things may
> have intended to free the various tail pages.
Actually, it's more a problem of the "superpage" being freed when the subpages
have elevated counts.
> i.e. AFAICT things really need to acquire and release references on the
> whole higher-order page as a unit for refcounting to actually work,
> regardless of MMU or no.
I agree.
> It may also be helpful for Greg Ungerer to help review these patches,
> as he appears to represent some of the other MMU-less concerns, and
> may have more concrete notions of how things behave in the MMU-less
> case than I myself do (hardware tends to resolve these issues, but
> that's not always feasible; perhaps an MMU-less port of a "normal"
> architecture would be enlightening to those otherwise unable to
> directly observe MMU-less behavior). In particular, correcting what
> misinterpretations in the above there may be.
The FRV arch does both MMU and !MMU versions. It's settable by a config
option, and I check both.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/