Bug 240454

Summary: RHEL4 Kernel crash when specifying mem= or highmem= kernel parameter
Product: Red Hat Enterprise Linux 4 Reporter: Chris Lalancette <clalance>
Component: kernel-xenAssignee: Chris Lalancette <clalance>
Status: CLOSED WONTFIX QA Contact: Martin Jenner <mjenner>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.6CC: xen-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-09-23 05:51:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 240429    
Bug Blocks:    
Attachments:
Description Flags
RHEL4 version of the patch to fix memory parameter at PV boot-time when specifying mem=
none
RHEL4 revised patch to fix mem=
none
Another version of the mem= patch for RHEL-4; I forgot a #include for x86_64 none

Description Chris Lalancette 2007-05-17 17:05:59 UTC 
+++ This bug was initially created as a clone of Bug #240429 +++

Description of problem:
When specifying mem= or highmem= on the kernel (not HV) command-line, the kernel
will crash fairly early on, in setup-xen.c.  The problem seems to be that the
initial setup code always assumes max_pfn >= xen_start_info->nr_pages.  When
specifying mem= on the kernel command-line, however, this is not the case, so
the setup code actually allocates the p2m table as the sizeof max_pfn, and then
attempts to copy sizeof xen_start_info->nr_pages, which overflows the table and
crashes the machine.

Note that this is a problem in upstream Xen, as well as in RHEL-4 PV.

-- Additional comment from clalance on 2007-05-17 10:40 EST --
Created an attachment (id=154921)
Patch to fix mem= kernel parameter

This is the patch I am currently testing to fix the problem when specifying
mem= on the kernel command-line.  Once I confirm it in my testing, I'll post it
to xen-devel.

Chris Lalancette

-- Additional comment from clalance on 2007-05-17 13:00 EST --
Created an attachment (id=154933)
Patch to fix mem= kernel parameter (revised)

Silly me; x86_64 uses end_pfn instead of max_pfn.  Let's try again.

Chris Lalancette
Comment 1 Chris Lalancette 2007-05-17 17:15:05 UTC 
Created attachment 154937 [details]
RHEL4 version of the patch to fix memory parameter at PV boot-time when specifying mem=

RHEL-4 version of the patch for PV guests to properly set the amount of memory
when specifying mem= on the kernel commandline.

Chris Lalancette
Comment 2 RHEL Program Management 2007-05-17 17:24:21 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 3 Chris Lalancette 2007-05-17 23:21:05 UTC 
Created attachment 154963 [details]
RHEL4 revised patch to fix mem=

The previous version of this patch was a little wrong in that it didn't free
the right amount of memory and didn't work properly when max_pfn <
xen_start_info->nr_pages (which is the case with maxmem= and memory=).	This
updated patch fixes it.  Note that this patch should be applied *after* the
patches in BZ 234496.

Chris Lalancette
Comment 4 Chris Lalancette 2007-05-30 20:06:05 UTC 
Created attachment 155743 [details]
Another version of the mem= patch for RHEL-4; I forgot a #include for x86_64

This version of the patch now builds on x86_64; it was missing a #include for
<xen/interface/memory.h>

Chris Lalancette
Comment 5 Red Hat Bugzilla 2007-07-25 00:46:44 UTC 
change QA contact
Comment 6 RHEL Program Management 2007-09-07 19:35:10 UTC 
This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time.  This request will be
reviewed for a future Red Hat Enterprise Linux release.
Comment 7 Don Dutile (Red Hat) 2008-01-04 20:15:18 UTC 
clearing devel-ack; not supported upstream or rhel5.
Comment 8 Chris Lalancette 2008-09-23 05:51:12 UTC 
No customer interest at the moment, and needs more work than what I posted upstream.  I'm going to close it as WONTFIX for now, and if someone wants it in the future, we can revisit it.

Chris Lalancette