Bug 245983 - HugePages_Rsvd wraps hugely negative
HugePages_Rsvd wraps hugely negative
Status: CLOSED NOTABUG
Product: Bugzilla
Classification: Community
Component: Test (Show other bugs)
2.8
other Linux
low Severity medium (vote)
: ---
: ---
Assigned To: PnT DevOps Devs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-27 15:27 EDT by IBM Mirproxy
Modified: 2013-06-23 22:45 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-04 12:25:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
[PATCH]_hugetlb:_fix_absurd_HugePages_Rsvd (1.22 KB, application/octet-stream; charset=ISO-8859-1)
2007-06-27 15:27 EDT, IBM Mirproxy
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 29824 None None None Never

  None (edit)
Description IBM Mirproxy 2007-06-27 15:27:00 EDT
=Comment: #0=================================================
ADAM G. LITKE <litke@us.ibm.com> - 2006-11-29 10:31 EDT
---Problem Description---
If you truncated an mmap'ed hugetlbfs file, then faulted on the truncated area,
/proc/meminfo's HugePages_Rsvd wrapped hugely "negative".
 
Contact Information = Adam Litke/<a href="mailto:agl@us.ibm.com">agl@us.ibm.com</a>
 
---Additional Hardware Info---
hugetlbfs mounted
10 huge pages allocated
 
---uname output---
Linux beavis.ltc.austin.ibm.com 2.6.18-1.2747.el5 #1 SMP Wed Aug 30 18:29:48 EDT
2006 ppc64 ppc64 ppc64 GNU/Linux

---Steps to Reproduce---
The latest libhugetlbfs development snapshots have a test case for this bug.

1. Download libhugetlbfs
<a
href="http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20061108.tar.gz">http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20061108.tar.gz</a>
2. Mount hugetlbfs and allocate some huge pages (try 10)
3. Unpack and build libhugetlbfs
4. Run tests/obj32/truncate_sigbus_versus_oom <nr free hugepages>

The test should FAIL and an examination of /proc/meminfo should show an
extremely large value for HugePages_Rsvd.
=Comment: #1=================================================
ADAM G. LITKE <litke@us.ibm.com> - 2006-11-29 10:33 EDT
<a href="attachment.cgi?id=22577" class="" title="[PATCH] hugetlb: fix absurd
HugePages_Rsvd">Created an attachment (id=22577)</a> [<a
href="attachment.cgi?id=22577&action=edit">edit</a>]
[PATCH] hugetlb: fix absurd HugePages_Rsvd

The attached patch was accepted upstream (see below) and resolves the issue. 
Modified to apply cleanly to the 2.6.18-1.2747.el5 kernel.

commit ebed4bfc8da8df5b6b0bc4a5064a949f04683509
Author: Hugh Dickins <<a href="mailto:hugh@veritas.com">hugh@veritas.com</a>>
Date:	Sat Oct 28 10:38:43 2006 -0700

    [PATCH] hugetlb: fix absurd HugePages_Rsvd

    If you truncated an mmap'ed hugetlbfs file, then faulted on the truncated
    area, /proc/meminfo's HugePages_Rsvd wrapped hugely "negative".  Reinstate
my
    preliminary i_size check before attempting to allocate the page (though
this
    only fixes the most obvious case: more work will be needed here).

    Signed-off-by: Hugh Dickins <<a href="mailto:hugh@veritas.com">hugh@veritas.com</a>>
    Cc: Adam Litke <<a href="mailto:agl@us.ibm.com">agl@us.ibm.com</a>>
    Cc: David Gibson <<a href="mailto:david@gibson.dropbear.id.au">david@gibson.dropbear.id.au</a>>
    Cc: "Chen, Kenneth W" <<a href="mailto:kenneth.w.chen@intel.com">kenneth.w.chen@intel.com</a>>
    Signed-off-by: Andrew Morton <<a href="mailto:akpm@osdl.org">akpm@osdl.org</a>>
    Signed-off-by: Linus Torvalds <<a href="mailto:torvalds@osdl.org">torvalds@osdl.org</a>>
Comment 1 IBM Mirproxy 2007-06-27 15:27:13 EDT
Created attachment 158045 [details]
[PATCH]_hugetlb:_fix_absurd_HugePages_Rsvd
Comment 2 IBM Mirproxy 2007-06-27 15:27:22 EDT
------- Comment From tmello@br.ibm.com 2007-06-27 15:07 EDT-------
Some comment.

Note You need to log in before you can comment on or make changes to this bug.