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
| ||
|
Date: Mon, 22 Aug 2016 12:54:41 +0200 From: Michal Hocko <mhocko@...nel.org> To: Greg KH <gregkh@...uxfoundation.org> Cc: Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Markus Trippelsdorf <markus@...ppelsdorf.de>, Arkadiusz Miskiewicz <a.miskiewicz@...il.com>, Ralf-Peter Rohbeck <Ralf-Peter.Rohbeck@...ntum.com>, Jiri Slaby <jslaby@...e.com>, Olaf Hering <olaf@...fle.de>, Vlastimil Babka <vbabka@...e.cz>, Joonsoo Kim <js1304@...il.com>, linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org> Subject: Re: OOM detection regressions since 4.7 On Mon 22-08-16 06:05:28, Greg KH wrote: > On Mon, Aug 22, 2016 at 11:37:07AM +0200, Michal Hocko wrote: [...] > > > From 899b738538de41295839dca2090a774bdd17acd2 Mon Sep 17 00:00:00 2001 > > > From: Michal Hocko <mhocko@...e.com> > > > Date: Mon, 22 Aug 2016 10:52:06 +0200 > > > Subject: [PATCH] mm, oom: prevent pre-mature OOM killer invocation for high > > > order request > > > > > > There have been several reports about pre-mature OOM killer invocation > > > in 4.7 kernel when order-2 allocation request (for the kernel stack) > > > invoked OOM killer even during basic workloads (light IO or even kernel > > > compile on some filesystems). In all reported cases the memory is > > > fragmented and there are no order-2+ pages available. There is usually > > > a large amount of slab memory (usually dentries/inodes) and further > > > debugging has shown that there are way too many unmovable blocks which > > > are skipped during the compaction. Multiple reporters have confirmed that > > > the current linux-next which includes [1] and [2] helped and OOMs are > > > not reproducible anymore. A simpler fix for the stable is to simply > > > ignore the compaction feedback and retry as long as there is a reclaim > > > progress for high order requests which we used to do before. We already > > > do that for CONFING_COMPACTION=n so let's reuse the same code when > > > compaction is enabled as well. > > > > > > [1] http://lkml.kernel.org/r/20160810091226.6709-1-vbabka@suse.cz > > > [2] http://lkml.kernel.org/r/f7a9ea9d-bb88-bfd6-e340-3a933559305a@suse.cz > > > > > > Fixes: 0a0337e0d1d1 ("mm, oom: rework oom detection") > > > Signed-off-by: Michal Hocko <mhocko@...e.com> > > > --- > > > mm/page_alloc.c | 50 ++------------------------------------------------ > > > 1 file changed, 2 insertions(+), 48 deletions(-) > > So, if this goes into Linus's tree, can you let stable@...r.kernel.org > know about it so we can add it to the 4.7-stable tree? Otherwise > there's not much I can do here now, right? My plan would be actually to not push this to Linus because we have a proper fix for Linus tree. It is just that the fix is quite large and I felt like the stable should get the most simple fix possible, which is this partial revert. So, what I am trying to tell is to push a non-linus patch to stable as it is simpler. -- Michal Hocko SUSE Labs
Powered by blists - more mailing lists