linux-kernel - Re: Panic on OOM

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]

Message-ID: <alpine.DEB.2.00.1106141900001.7025@chino.kir.corp.google.com>
Date:	Tue, 14 Jun 2011 19:05:56 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	cfowler@...dc.com
cc:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Panic on OOM

On Tue, 14 Jun 2011, Chris Fowler wrote:

> Previous version is 2.6.33.
> 
> This box is a small device and I've configured it so that it on OOM or
> panic will reboot.  A device that is locked or out of memory is useless
> and if it reboots it will pick up where it left off.  This has worked
> well for me.
> 

Not sure why you're responding to Kame when you're really replying to my 
email.  The problem is not the oom killer, Chris says that the kernel 
reports that it will reboot in 10 seconds, because of his 
/proc/sys/kernel/panic setting, yet that never happens.  He is able to 
induce a panic easily with the oom killer, but the problem being reported 
here has nothing to do with the VM.

> -------- [ cpuinfo]----------------------------------------------------
> processor	: 0
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 28
> model name	: Intel(R) Atom(TM) CPU N270   @ 1.60GHz
> stepping	: 2
> cpu MHz		: 1600.245
> cache size	: 512 KB
> fdiv_bug	: no
> hlt_bug		: no
> f00f_bug	: no
> coma_bug	: no
> fpu		: yes
> fpu_exception	: yes
> cpuid level	: 10
> wp		: yes
> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc up
> arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3
> xtpr pdcm movbe lahf_lm dts
> bogomips	: 3200.49
> clflush size	: 64
> cache_alignment	: 64
> address sizes	: 32 bits physical, 32 bits virtual
> power management:
> -------- [ cpuinfo]----------------------------------------------------
> 
> config attached
> 
> 
> I've not tried reboot=force.  I will do that next
> 

If that works, then we'll know that the forced machine restart is stalling 
or looping.  Using "reboot=force" supposedly will ensure that no such 
condition may ever exist for x86.  Do you know the last kernel version 
that actually worked correctly?
--
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/