[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87boatooea.fsf@xmission.com>
Date: Fri, 08 Mar 2013 08:19:09 -0800
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Vivek Goyal <vgoyal@...hat.com>
Cc: Jingbai Ma <jingbai.ma@...com>, mingo@...hat.com,
kumagai-atsushi@....nes.nec.co.jp, hpa@...or.com,
yinghai@...nel.org, kexec@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/5] crash dump bitmap: scan memory pages in kernel to speedup kernel dump process
Vivek Goyal <vgoyal@...hat.com> writes:
> On Thu, Mar 07, 2013 at 01:54:45PM -0800, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal@...hat.com> writes:
>> > I think this is not a good idea. It has several issues.
>>
>> Actually it does not appear to be doing any work in the first kernel.
>
> Looks like patch3 in series is doing that.
>
> machine_crash_shutdown(&fixed_regs);
> + generate_crash_dump_bitmap();
> machine_kexec(kexec_crash_image);
>
> So this bitmap seems to be being set just before transitioning into
> second kernel.
>
> I am sure you would not like this extra code in this path. :-)
Ouch! I had totally missed that. No that is not at all acceptable.
I was blind that day. The only call I saw was in patch 4 that put
the call generated the bitmap in the new proc file.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists