From: Ingo Molnar <mingo@elte.hu>
To: Andrew Lutomirski <luto@mit.edu>
Cc: Andi Kleen <ak@linux.intel.com>,
mingo@redhat.com, wzt <wzt.wzt@gmail.com>,
linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de,
hpa@zytor.com, Michal Hocko <mhocko@suse.cz>,
Zhitong Wang <zhitong.wangzt@alibaba-inc.com>
Subject: Re: [PATCH] x86: Fix memory leak of init_vdso_vars()
Date: Thu, 21 Jul 2011 20:38:20 +0200 [thread overview]
Message-ID: <20110721183820.GA381@elte.hu> (raw)
In-Reply-To: <CAObL_7HyjsPKnyDEEa0T8iTetpkd9Hq7RTBymieazzGOsXQLdA@mail.gmail.com>
* Andrew Lutomirski <luto@mit.edu> wrote:
> On Thu, Jul 21, 2011 at 1:08 PM, Andi Kleen <ak@linux.intel.com> wrote:
> > On Thu, Jul 21, 2011 at 10:33:14AM -0400, Andy Lutomirski wrote:
> >> From: Zhitong Wang <wzt.wzt@gmail.com>
> >>
> >> If init_vdso_vars ran out of memory (not very likely), then it would
> >> leak a few pages as well.
> >>
> >> Also rename init_vdso_vars to just init_vdso, since initializing
> >> vvars is just about the only thing this function doesn't do.
> >
> > Just add a GFP_PANIC, there's no way to recover from this.
> > Your system will not work without a vdso.
>
> Ingo objected to this before, although I'm not convinved. Calling
> init_vdso_vars more than once will cause major problems (like
> double-patching of alternatives). If there's too little memory for
> it to work, then presumably there's also too little memory to start
> init.
>
> (Also, I bet that no one ever audited whether the ELF loader works
> right if the vDSO failed to load.)
>
> Ingo?
This assumes that the system actually needs an ELF loader - if a
static binary is booted via a init= boot parameter it might not be
needed.
Memory failure injection code will also cause this to panic early
during bootup spuriously.
Really, we should cleanly tear down what we built up and fail cleanly
as well, no need to be sloppy since we already have the patch. That
some other code down the boot chain might be sloppy is no excuse to
be sloppy here.
Would be nice to stick a WARN_ON() into the oom branch though, as
it's clearly an anomalous condition.
(btw., there's no GFP_PANIC, we never had any such flag for the page
allocator.)
Thanks,
Ingo
next prev parent reply other threads:[~2011-07-21 18:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-05 6:21 [PATCH] x86: Fix memory leak of init_vdso_vars() wzt
2011-07-07 13:14 ` Michal Hocko
2011-07-07 18:33 ` Andi Kleen
2011-07-11 3:23 ` wzt wzt
2011-07-11 10:04 ` Ingo Molnar
2011-07-21 14:33 ` Andy Lutomirski
2011-07-21 17:08 ` Andi Kleen
2011-07-21 17:26 ` Andrew Lutomirski
2011-07-21 18:38 ` Ingo Molnar [this message]
2011-07-21 19:39 ` Andrew Lutomirski
2011-07-21 19:43 ` Ingo Molnar
2011-07-21 19:47 ` [PATCH] x86-64: Do not allocate memory for the vDSO Andy Lutomirski
2011-07-21 20:52 ` [tip:x86/vdso] x86-64, vdso: " tip-bot for Andy Lutomirski
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=20110721183820.GA381@elte.hu \
--to=mingo@elte.hu \
--cc=ak@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@mit.edu \
--cc=mhocko@suse.cz \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=wzt.wzt@gmail.com \
--cc=x86@kernel.org \
--cc=zhitong.wangzt@alibaba-inc.com \
/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.