From: Michael Ellerman <michael@ellerman.id.au>
To: David Miller <davem@davemloft.net>
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: bug in lmb_enforce_memory_limit()
Date: Thu, 14 Aug 2008 21:26:53 +1000 [thread overview]
Message-ID: <1218713213.10673.17.camel@localhost> (raw)
In-Reply-To: <20080814.012004.193702132.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]
On Thu, 2008-08-14 at 01:20 -0700, David Miller wrote:
> I just mentioned this to Ben H. on IRC and promised I would report it
> here. :-)
>
> The first loop over lmb.memory in this function interprets the
> memory_limit as a raw size limit, and that's fine so far.
>
> But the second loop over lmb.reserved interprets this value
> instead as an "address limit."
>
> I haven't cobbled together a fix myself, but probably the way to do
> this is, when we're about break out of the first loop over lmb.memory,
> walk through the now-trimmed memory blobs and trim those from
> lmb.reserved, one by one.
Perhaps after the first loop we should set memory_limit to equal
lmb_end_of_DRAM(), then the second loop should work as it is.
I think that actually makes memory_limit (the variable) more useful, and
avoids more code like we have in numa_enforce_memory_limit(), which
doesn't use memory_limit exactly because it isn't the value we're
actually interested in (because of holes).
> This bug got introduced by:
>
> commit 2babf5c2ec2f2d5de3e38d20f7df7fd815fd10c9
> Author: Michael Ellerman <michael@ellerman.id.au>
> Date: Wed May 17 18:00:46 2006 +1000
>
> [PATCH] powerpc: Unify mem= handling
>
> back when LMB was still a powerpc local item. :-)
Guilty as charged. I have some tests for that code, but clearly not
enough - and it gets very little exercise otherwise.
> This led me to another bug which probably a lot of platforms are
> effected by.
>
> If you do this command line memory limiting, and the kernel was placed
> by the boot loader into physical ram (say at the end of the available
> physical memory) that gets trimmed out by the command line option, we
> hang or crash right as we boot into userspace because freeing up
> initmem ends up freeing invalid page structs.
>
> I think, on sparc64, instead of adding all kinds of complicated logic
> to free_initmem() I'm simply going to only poison the pages and
> not free them at all if cmdline_memory_size has been set.
Would it be that much extra logic to check that the address is less than
the limit? Especially if we changed memory_limit to incorporate holes.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2008-08-14 11:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-14 8:20 bug in lmb_enforce_memory_limit() David Miller
2008-08-14 8:20 ` David Miller
2008-08-14 11:26 ` Michael Ellerman [this message]
2008-08-15 22:25 ` David Miller
2008-08-16 0:46 ` Michael Ellerman
2008-08-16 2:57 ` David Miller
2008-08-18 2:00 ` Michael Ellerman
2008-08-18 2:03 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1218713213.10673.17.camel@localhost \
--to=michael@ellerman.id.au \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.