When booting a vanilla 2.4.20 kernel (gentoo and debian) the kernel reports this: Memory: 775476k/786368k available (1189k kernel code, 10508k reserved, 492k data, 108k init, 0k highmem) When booting the same machine with the kernel mentioned in the summary, I get this: Memory: 771028k/786368k available (1724k kernel code, 12780k reserved, -2228k data, 304k init, 0k highmem) Kernel config is mostly the same for both kernels (except for 1 or 2 extra features not available in 2.4.20) 2.4.20 compiled with "gcc version 2.95.3 20010315 (release)" 2.4.20-gentoo-r5 compiled with "gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice) (dont have gcc-2 on the gentoo partition yet, hope that's not the problem)
The same kernel (mostly identical config, except for some drivers) compiled with gcc-2 on a different machine reports: Memory: 126848k/131008k available (1428k kernel code, 3776k reserved, 602k data, 96k init, 0k highmem) Does this mean it's a problem with gcc-3?
ok, just recompiled gentoo-sources-2.4.20-r5 on the first box with gcc-2; the reported memory usage is slightly different but 'data' is still negative. Same config than the 128MB box, so this problem only seems to happen if theres "too much" ram installed.
Do you get this bug with -r6? Can you please attach your kernel config if this still occurs...
can't reboot right now, but I'll check as soon as possible
Reporter, are you sure the kernels in the original report and comment #2 are the same version with the same patches applied? The only way I see to get a negative value for `data' is you have your code and data sections in reversed order. From `arch/i386/mm/init.c' (assuming x86): codesize = &_etext - &_text; datasize = &_edata - &_etext; Obviously, if code and data are in the wrong order, data size is reported as datasize = -(codesize + datasize); and this should be independent of the total amount of RAM. (only patch I know of that changes section layout is grsecurity, but since no one else seems to have reported this yet, this looks more like a missing patch to me).
Sorry, took a while to reboot; busy box. 2.4.20-r6 does not fix it; and I don't think I'm skipping any patches; just plain emerge gentoo-sources -> configure/build kernel: Memory: 771260k/786368k available (1464k kernel code, 12548k reserved,\ -1956k data, 284k init, 0k highmem) Am I really the only one with this problem? Relevant USE flags are: -build +crypt -evms2 -aavm -usagi -doc +tcltk Resulting segment order is: 0 .data.startup 1 __ex_table 2 __ksymtab 3 .data 4 .data.cacheline_aligned 5 .data.init_task 6 .data.page_aligned 7 .bss 8 .data.init 9 .setup.init 10 .initcall.init 11 .text.init 12 .text 13 .rodata 14 .rodata.page_aligned 15 .kstrtab 16 .comment 17 .note Section order in vanilla kernel: 0 .text 1 .rodata 2 .kstrtab 3 __ex_table 4 __ksymtab 5 .data 6 .data.init_task 7 .text.init 8 .data.init 9 .setup.init 10 .initcall.init 11 .data.page_aligned 12 .data.cacheline_aligned 13 .bss 14 .comment 15 .note So yes, it seems they are rearranged in some way; and the code in mm/init.c is still the same. How do I undo this? Kernel devs?
Tested -r6 on a couple of different boxes with different kernel configs; roblem remains: &_etext > &_edata; still same code is used to calculate datasize. Increasing severity; one of the patches seems to be incomplete
how about -r7 ?
nope still data nagative
Hmm...this is indeed related to the `grsecurity' patch. Somewhere between 1.9.9c and 1.9.9g, `grsecurity' started patching the linker script, but not the way `datasize' is calculated. Haven't been following grsecurity during the summer... first version after 1.9.9h I could find on the 'net is 1.9.12, which has the problem corrected, but is for kernel version 2.4.22. [reporter (or someone with sufficient privileges), could you decrease severity again? The only thing affected is the displayed data size at boot-time -- most people won't even notice]
Created attachment 19498 [details, diff] grsecurity-1.9.9g-datasize_fix.patch Being too lazy for any more research, here's the relevant part of 1.9.12 backported to 1.9.9g. With the USE flags given in comment #6, it applies cleanliest (i.e., without any offset warnings) as the very last patch.
<font size=+20>THAT'S IT!!!</font> FINALLY NO MORE TRIAL AND ERROR! but i'm not lowering severity, if something as obvious as this goes unnoticed, who knows what else is lurking there but i followed your other advice
just for the record, my data size is now a sane 140K
You have a workaround, and it seems the problem is purely cosmetic in any case. We'll get this into the next revision, thanks for all the hard work guys.
I assume that this is only an x86 problem?
To be honest, I've never tried grsecurity on anything but x86, but from looking at the grsec patch, i386 seems to be the only arch that moves sections around. However... even though this patch does exactly the same as grsec-1.9.12, on second thought the results are still quite different from an unpatched kernel (140K compared to 492K in the original report and 602K in comment #1). Reason being, the unpatched kernel also includes readonly data and the kernel symbols (and some other small sections) in its calculations. Moving the `_data' label back to the end of .data.startup would get results closer to the original kernel. (thoughts?)
In CVS with -r8.
