linux-kernel - Re: [BUG?] OOM with large cache....(x86

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: <200711202147.32354.nickpiggin@yahoo.com.au>
Date:	Tue, 20 Nov 2007 21:47:32 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	pomac@...or.com
Cc:	Linux-kernel@...r.kernel.org
Subject: Re: [BUG?] OOM with large cache....(x86_64, 2.6.24-rc3-git1, nohz)

On Tuesday 20 November 2007 20:09, Ian Kumlien wrote:
> On tis, 2007-11-20 at 15:13 +1100, Nick Piggin wrote:

> > It's also used up all your 2.5GB of swap. The output of your `free` shows
> > a fair bit of disk cache there, but it also shows a lot of swap free,
> > which isn't the case at oom-time.
>
> Yes, as i said those was from several hours later...

OK, missed that.

> > Unfortunately, we don't show NR_ANON_PAGES in these stats, but at a
> > guess, I'd say that the file cache is mostly shrunk and you still don't
> > have enough memory. trackerd probably has a memory leak in it, or else is
> > just trying to allocate more memory than you have. Is this a regression?
>
> I have had it happen twice before, without tracker running...

Does the machine recover afterward, or is the memory freed up after
the OOM kill? How about if you kill X and do a sysrq+E then sysrq+I
(to kill all tasks)?

If the memory still isn't freed after that, then we could have a
kernel memory leak.

> It didn't quite get to the oom stage, it just failed alot of allocations
> while having 1.5 or more memory locked in cache.
>
> http://marc.info/?l=linux-kernel&m=118895576924867&w=2

OK, yes this is a different case, and it is very far off the OOM
killing stage. Atomic allocations can fail quite easily, but
kswapd will have started up and will start freeing memory.

Actually there are some patches gone into 2.6.24 that have fixed
some corner cases with the network stack making order-1 allocations
when it should be order-0. That might help your atomic allocation
failures, but they aren't really a bug anyway (unless networking
fails to recover).

Thanks for reporting all this...
-
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/