From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-vw0-f49.google.com ([209.85.212.49]) by canuck.infradead.org with esmtps (Exim 4.72 #1 (Red Hat Linux)) id 1PxINx-0003X3-15 for kexec@lists.infradead.org; Wed, 09 Mar 2011 12:21:01 +0000 Received: by vws7 with SMTP id 7so412909vws.36 for ; Wed, 09 Mar 2011 04:20:59 -0800 (PST) Date: Wed, 9 Mar 2011 20:20:46 +0800 From: =?utf-8?Q?Am=C3=A9rico?= Wang Subject: Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden Message-ID: <20110309122046.GC16951@cr0.redhat.com> References: <20100825002258.GD28360@kryten> <4D771EE6.5050404@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4D771EE6.5050404@linux.vnet.ibm.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kexec-bounces@lists.infradead.org Errors-To: kexec-bounces+dwmw2=twosheds.infradead.org@lists.infradead.org To: Mahesh Jagannath Salgaonkar Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, "Eric W. Biederman" , akpm@linux-foundation.org, Anton Blanchard On Wed, Mar 09, 2011 at 12:02:06PM +0530, Mahesh Jagannath Salgaonkar wrote: >On 08/25/2010 06:07 AM, Eric W. Biederman wrote: >> Anton Blanchard writes: >> >>> On ppc64 the crashkernel region almost always overlaps an area of firmware. >>> This works fine except when using the sysfs interface to reduce the kdump >>> region. If we free the firmware area we are guaranteed to crash. >> >> That is ppc64 bug. firmware should not be in the reserved region. Any >> random kernel like thing can be put in to that region at any valid >> address and the fact that shrinking the region frees your firmware means >> that using that region could also stomp your firmware (which I assume >> would be a bad thing). >The issue only happens while shrinking the region using sysfs interface. >We already have checks in kexec for not to stomp over on the firmware >overlap area while loading capture kernel. Currently we do a top-down >allocation for the firmware region which means it sits at the top of the >RMO, right in the middle of the crashdump region. We can not move the >crashkernel region beyond firmware region because kernel needs its some >of memory in RMO region. The crashkernel region is specified via kernel cmdline, so why not just drop a failure when it overlaps with RMO region? Am I missing something? Thanks. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec