From: Ingo Molnar <mingo@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Baoquan He <bhe@redhat.com>, Takashi Iwai <tiwai@suse.de>,
Viresh Kumar <viresh.kumar@linaro.org>,
x86@kernel.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org,
Jiang Liu <jiang.liu@linux.intel.com>,
"Lee, Chun-Yi" <jlee@suse.com>,
"Lee, Chun-Yi" <joeyli.kernel@gmail.com>,
Andy Lutomirski <luto@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH v3] kexec: fix out of the ELF headers buffer issue in syscall kexec_file_load()
Date: Fri, 2 Oct 2015 09:13:39 +0200 [thread overview]
Message-ID: <20151002071339.GA2159@gmail.com> (raw)
In-Reply-To: <20151001160741.07eac580c087ddb89a3e314c@linux-foundation.org>
* Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 29 Sep 2015 20:58:57 +0800 "Lee, Chun-Yi" <joeyli.kernel@gmail.com> wrote:
>
> > This patch modified the code in fill_up_crash_elf_data by using
> > walk_system_ram_res instead of walk_system_ram_range to count the max
> > number of crash memory ranges. That's because the walk_system_ram_range
> > filters out small memory regions that are resided in the same page, but
> > walk_system_ram_res does not.
> >
> > The oringial issue is page fault error that sometimes happened on big machines
> > when preparing ELF headers:
> >
> > [ 305.291522] BUG: unable to handle kernel paging request at ffffc90613fc9000
> > [ 305.299621] IP: [<ffffffff8103d645>] prepare_elf64_ram_headers_callback+0x165/0x260
> > [ 305.308300] PGD e000032067 PUD 6dcbec54067 PMD 9dc9bdeb067 PTE 0
> > [ 305.315393] Oops: 0002 [#1] SMP
> > [...snip]
> > [ 305.420953] task: ffff8e1c01ced600 ti: ffff8e1c03ec2000 task.ti: ffff8e1c03ec2000
> > [ 305.429292] RIP: 0010:[<ffffffff8103d645>] [<ffffffff8103d645>] prepare_elf64_ra
> > m_headers_callback+0x165/0x260
> > [...snip]
> >
> > After tracing prepare_elf64_headers and prepare_elf64_ram_headers_callback,
> > the code uses walk_system_ram_res to fill-in crash memory regions information
> > to program header, so it counts those small memory regions that are resided in
> > a page area. But, when kernel was using walk_system_ram_range in
> > fill_up_crash_elf_data to count the number of crash memory regions, it filters
> > out small regions. I printed those small memory regions, for example:
> >
> > kexec: Get nr_ram ranges. vaddr=0xffff880077592258 paddr=0x77592258, sz=0xdc0
> >
> > Base on the code in walk_system_ram_range, this memory region will be filtered
> > out:
> >
> > pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593
> > end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593
> > end_pfn - pfn = 0x77593 - 0x77593 = 0 <=== if (end_pfn > pfn) is FALSE
> >
> > So, the max_nr_ranges that's counted by kernel doesn't include small memory
> > regions. That causes the page fault issue happened in later code path for
> > preparing EFL headers.
> >
> > This issus is not easy to reproduce on small machines that don't have too
> > many CPUs because the allocated page aligned ELF buffer has more free space
> > to cover those small memory regions' PT_LOAD headers.
> >
>
> fyi, I added a cc:stable to my copy of this patch.
Note that I already have it applied, with a much improved changelog:
e3c41e37b0f4 ("x86/kexec: Fix kexec crash in syscall kexec_file_load()")
Thanks,
Ingo
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Lee, Chun-Yi" <joeyli.kernel@gmail.com>,
Vivek Goyal <vgoyal@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
x86@kernel.org, Stephen Rothwell <sfr@canb.auug.org.au>,
Viresh Kumar <viresh.kumar@linaro.org>,
Takashi Iwai <tiwai@suse.de>,
Jiang Liu <jiang.liu@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>, Baoquan He <bhe@redhat.com>,
linux-kernel@vger.kernel.org, kexec@lists.infradead.org, "Lee,
Chun-Yi" <jlee@suse.com>
Subject: Re: [PATCH v3] kexec: fix out of the ELF headers buffer issue in syscall kexec_file_load()
Date: Fri, 2 Oct 2015 09:13:39 +0200 [thread overview]
Message-ID: <20151002071339.GA2159@gmail.com> (raw)
In-Reply-To: <20151001160741.07eac580c087ddb89a3e314c@linux-foundation.org>
* Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 29 Sep 2015 20:58:57 +0800 "Lee, Chun-Yi" <joeyli.kernel@gmail.com> wrote:
>
> > This patch modified the code in fill_up_crash_elf_data by using
> > walk_system_ram_res instead of walk_system_ram_range to count the max
> > number of crash memory ranges. That's because the walk_system_ram_range
> > filters out small memory regions that are resided in the same page, but
> > walk_system_ram_res does not.
> >
> > The oringial issue is page fault error that sometimes happened on big machines
> > when preparing ELF headers:
> >
> > [ 305.291522] BUG: unable to handle kernel paging request at ffffc90613fc9000
> > [ 305.299621] IP: [<ffffffff8103d645>] prepare_elf64_ram_headers_callback+0x165/0x260
> > [ 305.308300] PGD e000032067 PUD 6dcbec54067 PMD 9dc9bdeb067 PTE 0
> > [ 305.315393] Oops: 0002 [#1] SMP
> > [...snip]
> > [ 305.420953] task: ffff8e1c01ced600 ti: ffff8e1c03ec2000 task.ti: ffff8e1c03ec2000
> > [ 305.429292] RIP: 0010:[<ffffffff8103d645>] [<ffffffff8103d645>] prepare_elf64_ra
> > m_headers_callback+0x165/0x260
> > [...snip]
> >
> > After tracing prepare_elf64_headers and prepare_elf64_ram_headers_callback,
> > the code uses walk_system_ram_res to fill-in crash memory regions information
> > to program header, so it counts those small memory regions that are resided in
> > a page area. But, when kernel was using walk_system_ram_range in
> > fill_up_crash_elf_data to count the number of crash memory regions, it filters
> > out small regions. I printed those small memory regions, for example:
> >
> > kexec: Get nr_ram ranges. vaddr=0xffff880077592258 paddr=0x77592258, sz=0xdc0
> >
> > Base on the code in walk_system_ram_range, this memory region will be filtered
> > out:
> >
> > pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593
> > end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593
> > end_pfn - pfn = 0x77593 - 0x77593 = 0 <=== if (end_pfn > pfn) is FALSE
> >
> > So, the max_nr_ranges that's counted by kernel doesn't include small memory
> > regions. That causes the page fault issue happened in later code path for
> > preparing EFL headers.
> >
> > This issus is not easy to reproduce on small machines that don't have too
> > many CPUs because the allocated page aligned ELF buffer has more free space
> > to cover those small memory regions' PT_LOAD headers.
> >
>
> fyi, I added a cc:stable to my copy of this patch.
Note that I already have it applied, with a much improved changelog:
e3c41e37b0f4 ("x86/kexec: Fix kexec crash in syscall kexec_file_load()")
Thanks,
Ingo
next prev parent reply other threads:[~2015-10-02 7:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-29 12:58 [PATCH v3] kexec: fix out of the ELF headers buffer issue in syscall kexec_file_load() Lee, Chun-Yi
2015-09-29 12:58 ` Lee, Chun-Yi
2015-09-30 3:04 ` Dave Young
2015-09-30 3:04 ` Dave Young
2015-09-30 11:27 ` Minfei Huang
2015-09-30 11:27 ` Minfei Huang
2015-10-01 8:54 ` [tip:x86/urgent] x86/kexec: Fix kexec crash " tip-bot for Lee, Chun-Yi
2015-10-01 23:07 ` [PATCH v3] kexec: fix out of the ELF headers buffer issue " Andrew Morton
2015-10-01 23:07 ` Andrew Morton
2015-10-02 7:13 ` Ingo Molnar [this message]
2015-10-02 7:13 ` Ingo Molnar
2015-10-02 7:15 ` [tip:x86/urgent] x86/kexec: Fix kexec crash " tip-bot for Lee, Chun-Yi
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=20151002071339.GA2159@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=hpa@zytor.com \
--cc=jiang.liu@linux.intel.com \
--cc=jlee@suse.com \
--cc=joeyli.kernel@gmail.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=sfr@canb.auug.org.au \
--cc=tglx@linutronix.de \
--cc=tiwai@suse.de \
--cc=vgoyal@redhat.com \
--cc=viresh.kumar@linaro.org \
--cc=x86@kernel.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.