Bug 55282 - /proc/meminfo reports incorrectly
/proc/meminfo reports incorrectly
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2001-10-29 01:39 EST by Jim Wright
Modified: 2007-04-18 12:37 EDT (History)
1 user (show)

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

Attachments (Terms of Use)

  None (edit)
Description Jim Wright 2001-10-29 01:39:26 EST
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:

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 04:03:42 EST
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 11:14:45 EST
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-29 20:33:51 EST

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.