linux-kernel - Re: [PATCH] trim memory not covered by WB MTRRs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Jun 2007 18:54:37 -0400 (EDT)
From:	Justin Piszcz <jpiszcz@...idpixels.com>
To:	Randy Dunlap <randy.dunlap@...cle.com>
cc:	Jesse Barnes <jesse.barnes@...el.com>,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH] trim memory not covered by WB MTRRs



On Wed, 6 Jun 2007, Randy Dunlap wrote:

> On Wed, 6 Jun 2007 15:28:43 -0700 Jesse Barnes wrote:
>
>> On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
>>> Nope, I booted with only netconsole= options.  I have a lot of HW in
>>> the box and I guess the buffer is too small.  Not sure where to
>>> change it in the kernel.  Looking..
>>
>> It's called "kernel log buffer size" and it's in "General setup".
>
> or you can just boot with "log_buf_len=256k" on the kernel boot line (e.g.)
>
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>

Hm, not sure if it was from the patch or what but I ran this:

1. swapoff -a
2. ./eatmem

The machine responded to ping and alt-sysrq-b but the box remain 
unresponsive, I guess the kernel did not kill the process? :(

The moments before it 'froze'

top - 18:48:01 up 15 min,  7 users,  load average: 6.61, 18.50, 13.31
Tasks: 200 total,  18 running, 182 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us, 90.7%sy,  0.0%ni,  5.9%id,  3.3%wa,  0.0%hi,  0.0%si, 
0.0%st
Mem:   8039576k total,  7998860k used,    40716k free,        8k buffers
Swap:        0k total,        0k used,        0k free,     1664k cached

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   248 root      11  -5     0    0    0 R   85  0.0   0:16.05 kswapd0
  2265 nut       18   0 13320  244    4 R   40  0.0   0:03.13 newhidups
  2267 nut       18   0 12216  168    4 R   40  0.0   0:02.04 upsd
  2474 ntp       18   0 22192  400    8 R   39  0.0   0:02.00 ntpd
  3563 jpiszcz   18   0 41964 1264    4 R   38  0.0   0:02.20 pine
  3530 root      18   0 96240 3132   36 R   37  0.0   0:02.09 kdm_greet
  2052 root      18   0  6080  112    4 R   37  0.0   0:02.00 hald-addon-stor
  4479 war       17   0 18012  700  252 R   33  0.0   0:01.81 top
  4480 war       19   0 6948m 6.8g    4 R   22 88.4   0:05.81 eatmem
  2095 root      18   0 13128  216    8 R   10  0.0   0:00.50 dirmngr
  2545 root      18   0 95788 2488    4 R    5  0.0   0:00.25 apache2
  3564 war       18   0 41620  832    4 R    5  0.0   0:00.34 pine
  2270 nut       15   0 12212  144    4 S    1  0.0   0:00.05 upsmon
   561 root      10  -5     0    0    0 S    0  0.0   0:00.02 xfsbufd

Very simply program:

#include <iostream>
using namespace std;

int main()
{
   long int interations = 10000000;
   int counter = 1;

   for(counter;counter<interations;counter++)
   {
      double *d = new double[100];
   }

   return 0;
}

Any idea why the OOM killer can or does not kill it?

Justin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/