From: ebiederm@xmission.com (Eric W. Biederman)
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Jingbai Ma <jingbai.ma@hp.com>, mingo@redhat.com,
        kumagai-atsushi@mxc.nes.nec.co.jp, hpa@zytor.com, yinghai@kernel.org,
        kexec@lists.infradead.org, linux-kernel@vger.kernel.org
References: <20130307145808.29098.41592.stgit@k.asiapacific.hpqcorp.net>
	<20130307152108.GC2790@redhat.com> <87k3piri3e.fsf@xmission.com>
	<20130308155216.GB8219@redhat.com>
Date: Fri, 08 Mar 2013 08:19:09 -0800
In-Reply-To: <20130308155216.GB8219@redhat.com> (Vivek Goyal's message of
	"Fri, 8 Mar 2013 10:52:16 -0500")
Message-ID: <87boatooea.fsf@xmission.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [RFC PATCH 0/5] crash dump bitmap: scan memory pages in kernel to speedup kernel dump process
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1116
Lines: 30

Vivek Goyal <vgoyal@redhat.com> writes:

> On Thu, Mar 07, 2013 at 01:54:45PM -0800, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal@redhat.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/