[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180930092741.GC6950@dhcp-128-65.nay.redhat.com>
Date: Sun, 30 Sep 2018 17:27:41 +0800
From: Dave Young <dyoung@...hat.com>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: thomas.lendacky@....com, brijesh.singh@....com,
Lianbo Jiang <lijiang@...hat.com>, bhe@...hat.com,
tiwai@...e.de, x86@...nel.org, kexec@...ts.infradead.org,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
mingo@...hat.com, baiyaowei@...s.chinamobile.com, hpa@...or.com,
dan.j.williams@...el.com, bp@...e.de, tglx@...utronix.de,
Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [PATCH 1/3] x86/kexec: Correct KEXEC_BACKUP_SRC_END off-by-one
error
On 09/30/18 at 05:21pm, Dave Young wrote:
> Hi Bjorn,
>
> On 09/27/18 at 09:21am, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas <bhelgaas@...gle.com>
> >
> > The only use of KEXEC_BACKUP_SRC_END is as an argument to
> > walk_system_ram_res():
> >
> > int crash_load_segments(struct kimage *image)
> > {
> > ...
> > walk_system_ram_res(KEXEC_BACKUP_SRC_START, KEXEC_BACKUP_SRC_END,
> > image, determine_backup_region);
> >
> > walk_system_ram_res() expects "start, end" arguments that are inclusive,
> > i.e., the range to be walked includes both the start and end addresses.
>
> Looking at the function comment of find_next_iomem_res, the res->end
> should be exclusive, am I missing something?
Oops, you fix it in 2nd patch, I apparently miss that.
Since the fix of checking the end is in another patch, probably merge
these two patches so that they are in one patch to avoid break bisect.
Thanks
Dave
Powered by blists - more mailing lists