grsecurity forums

While trying to parse a 85M learning log using gradm -F -L i keep facing a kill by the VM.

Code: Select all

__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process gradm


I am currently using 2.4.25 with latest grsec 2.0 rc and the gradm that comes with it. The box is a 800MHz duron with 256Mb of RAM and 128M of swapspace. Can anyone give me a hint on how to track down this problem?

TIA

Hi Sleight of Mind,

Sleight of Mind wrote:While trying to parse a 85M learning log using gradm -F -L i keep facing a kill by the VM.

Code: Select all

__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process gradm


I am currently using 2.4.25 with latest grsec 2.0 rc and the gradm that comes with it. The box is a 800MHz duron with 256Mb of RAM and 128M of swapspace. Can anyone give me a hint on how to track down this problem?

TIA

That's a problem of the mainline 2.4 kernel. 2.4 got a new VM in 2.4.23 from Andrea Arcangeli, which also disables the OOM killer and the logic of the new VM is broken. There were several reports on LKML w/o any fixes yet, only to bring-back-in the OOM killer. You might want to try this:

http://marc.theaimsgroup.com/?l=linux-k ... 204478&w=2

or this:

http://marc.theaimsgroup.com/?l=linux-k ... 216326&w=2

Please note: your error is not grsecurity related!

ciao, Marc

afaik there is a way to bring back the old OOM killer behaviour, by enabling CONFIG_OOM_KILLER. But i think that is not the problem here. It is not about which task gets killed when the system runs out of memory, but why the system runs out of memory. If everything works properly no task would be killed at all.
As soon as gradm starts it starts eating memory, far over 200Mb. When there is no more left (the box has 256) a task gets killed, usually gradm first, but sometimes other tasks get killed as well.
Isn't this all just a problem with gradm consuming too much memory? I asume gradm was made to be available on systems with less RAM as well.

-Rik

*bump*
anyone got an idea? I still got this problem.

Hey,

Sleight of Mind wrote:*bump*
anyone got an idea? I still got this problem.

please check out latest CVS tree of grsec2 for 2.4. I am almost quite sure Brad has fixed huge memory consumptions in cvs tree (he told about it in #grsecurity, afaik)

Also, please enable the old OOM_KILLER behaviour. The new VM in 2.4 is bogus in some situations.

ciao, Marc

with CONFIG_OOM_KILLER enabled i get this output:

Code: Select all

grsec: From 10.0.0.5: /dev/grsec: being fed garbage 292 bytes sent 288 required
Out of Memory: Killed process 23324 (named).
Out of Memory: Killed process 4211 (named).
Out of Memory: Killed process 22695 (named).
Out of Memory: Killed process 12625 (named).
Out of Memory: Killed process 8120 (named).
Out of Memory: Killed process 13118 (gradm).


logically gradm still gets killed since it is consuming loads of memory (near 250Mb at the time the process gets killed). This time i used the latest cvs version of gradm2 (cvs checkout gradm2).

The output gradm gave was:

Code: Select all

$ gradm -F -L /tmp/grsec_learning.logs -O /etc/grsec/acl_new
Beginning full learning 1st pass...done.
Beginning full learning role reduction...done.
Beginning full learning 2nd pass...Terminated


Why is gradm consuming this amount of memory? My learning logs are still 85M big and look Ok (checked with head and tail).

Concerning memory... Recently, I experimented with grsec2-test (for 2.6) and gradm2 too, so...

To analyze 57M log, and to build ACL, it took ca. 400M RAM (fortunately, I've 1G of RAM)... It really is very hungry to memory...