Bug 55282 - /proc/meminfo reports incorrectly
Summary: /proc/meminfo reports incorrectly
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.2
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-10-29 06:39 UTC by Jim Wright
Modified: 2007-04-18 16:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-29 16:16:58 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jim Wright 2001-10-29 06:39:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-7 i686)

Description of problem:
On a system with more than 4gb installed using the enterprise kernel,
/proc/meminfo reports incorrectly - it overflows an unsigned 32 bit value.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. install, say, 6gb memory
2. install rh72 with enterprise kernel
3. cat /proc/meminfo
	

Additional info:

The code in fs/proc/proc_misc.c appears to be able to handle large values:

#define B(x) ((unsigned long long)(x) << PAGE_SHIFT)

        len = sprintf(page, "        total:    used:    free:  shared:
buffers:  cached:\n"
                "Mem:  %8Lu %8Lu %8Lu %8Lu %8Lu %8Lu\n"
                "Swap: %8Lu %8Lu %8Lu\n",
                B(i.totalram), B(i.totalram-i.freeram), B(i.freeram),
                B(i.sharedram), B(i.bufferram),
                B(cached), B(i.totalswap),
                B(i.totalswap-i.freeswap), B(i.freeswap));


However, the code in include/linux/kernel.h appears to be where the
limitation derives from.

struct sysinfo {
        long uptime;                    /* Seconds since boot */
        unsigned long loads[3];         /* 1, 5, and 15 minute load
averages */
        unsigned long totalram;         /* Total usable main memory size */
        unsigned long freeram;          /* Available memory size */
        unsigned long sharedram;        /* Amount of shared memory */
        unsigned long bufferram;        /* Memory used by buffers */
        unsigned long totalswap;        /* Total swap space size */
        unsigned long freeswap;         /* swap space still available */
        unsigned short procs;           /* Number of current processes */
        unsigned short pad;             /* explicit padding for m68k */
        unsigned long totalhigh;        /* Total high memory size */
        unsigned long freehigh;         /* Available high memory size */
        unsigned int mem_unit;          /* Memory unit size in bytes */
        char _f[20-2*sizeof(long)-sizeof(int)]; /* Padding: libc5 uses
this.. */};

Comment 1 Arjan van de Ven 2001-10-29 09:03:42 UTC
we know the fix is trivial in theory, however some userland applications like
top use this field blindly and often use 32 bit values ;(

Comment 2 Philip Pokorny 2001-10-29 16:14:45 UTC
That's odd, because TOP is actually displaying the *correct* memory size of 6GB.

I wonder if the problem isn't the limit of 8 digits on the field width.  If that
limit was increased to 10 or removed, the correct value might display?  I may
try testing that.  The (unsigned long long) cast should eliminate the 32 bit
limit on the "size" of memory.  The B macro would suggest that "totalram" is
actually in units of PAGES (2^PAGE_SHIFT bytes).  With 4k pages, totalram should
max out at 16 Terabytes of RAM.

Comment 3 Jim Wright 2001-10-30 01:33:51 UTC
Nevermind.

Already fixed in the 2.4.9-7 errata kernel.


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