| 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
| ||
|
Message-ID: <5852cd26-e013-8313-30f0-68a92db02b8f@Quantum.com>
Date: Thu, 25 Aug 2016 13:30:23 -0700
From: Ralf-Peter Rohbeck <Ralf-Peter.Rohbeck@...ntum.com>
To: Michal Hocko <mhocko@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Markus Trippelsdorf <markus@...ppelsdorf.de>,
Arkadiusz Miskiewicz <a.miskiewicz@...il.com>,
Jiri Slaby <jslaby@...e.com>, Olaf Hering <olaf@...fle.de>
CC: Greg KH <gregkh@...uxfoundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
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 23.08.2016 00:43, Michal Hocko wrote:
> OK, fair enough.
> I would really appreciate if the original reporters could retest with
> this patch on top of the current Linus tree. The stable backport posted
> earlier doesn't apply on the current master cleanly but the change is
> essentially same. mmotm tree then can revert this patch before Vlastimil
> series is applied because that code is touching the currently removed
> code.
> ---
> From 90b6b282bede7966fb6c830a6d012d2239ac40e4 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 late rc and stable is to simply ignore the
> compaction feedback and retry as long as there is a reclaim progress
> and we are not getting OOM for order-0 pages. We already do that for
> CONFING_COMPACTION=n so let's reuse the same code when compaction is
> enabled as well.
>
> [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_20160810091226.6709-2D1-2Dvbabka-40suse.cz&d=DQIBAg&c=8S5idjlO_n28Ko3lg6lskTMwneSC-WqZ5EBTEEvDlkg&r=yGQdEpZknbtYvR0TyhkCGu-ifLklIvXIf740poRFltQ&m=RnSShi4nOuCcTfoBOsx8P8OCPnA5R6zXLo9uZ2RBNjM&s=sJBmU_ySuE2OhXkEeFyTfUr05xjB-mO4aQ5yl4w8z1M&e=
> [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_f7a9ea9d-2Dbb88-2Dbfd6-2De340-2D3a933559305a-40suse.cz&d=DQIBAg&c=8S5idjlO_n28Ko3lg6lskTMwneSC-WqZ5EBTEEvDlkg&r=yGQdEpZknbtYvR0TyhkCGu-ifLklIvXIf740poRFltQ&m=RnSShi4nOuCcTfoBOsx8P8OCPnA5R6zXLo9uZ2RBNjM&s=9oXRJsI8kr1rfMU9tAb9q0-8YlBCZO0XCCFRo0ASjlg&e=
>
> Fixes: 0a0337e0d1d1 ("mm, oom: rework oom detection")
> Signed-off-by: Michal Hocko <mhocko@...e.com>
> ---
> mm/page_alloc.c | 51 ++-------------------------------------------------
> 1 file changed, 2 insertions(+), 49 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 3fbe73a6fe4b..7791a03f8deb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3137,54 +3137,6 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
> return NULL;
> }
>
> -static inline bool
> -should_compact_retry(struct alloc_context *ac, int order, int alloc_flags,
> - enum compact_result compact_result,
> - enum compact_priority *compact_priority,
> - int compaction_retries)
> -{
> - int max_retries = MAX_COMPACT_RETRIES;
> -
> - if (!order)
> - return false;
> -
> - /*
> - * compaction considers all the zone as desperately out of memory
> - * so it doesn't really make much sense to retry except when the
> - * failure could be caused by insufficient priority
> - */
> - if (compaction_failed(compact_result)) {
> - if (*compact_priority > MIN_COMPACT_PRIORITY) {
> - (*compact_priority)--;
> - return true;
> - }
> - return false;
> - }
> -
> - /*
> - * make sure the compaction wasn't deferred or didn't bail out early
> - * due to locks contention before we declare that we should give up.
> - * But do not retry if the given zonelist is not suitable for
> - * compaction.
> - */
> - if (compaction_withdrawn(compact_result))
> - return compaction_zonelist_suitable(ac, order, alloc_flags);
> -
> - /*
> - * !costly requests are much more important than __GFP_REPEAT
> - * costly ones because they are de facto nofail and invoke OOM
> - * killer to move on while costly can fail and users are ready
> - * to cope with that. 1/4 retries is rather arbitrary but we
> - * would need much more detailed feedback from compaction to
> - * make a better decision.
> - */
> - if (order > PAGE_ALLOC_COSTLY_ORDER)
> - max_retries /= 4;
> - if (compaction_retries <= max_retries)
> - return true;
> -
> - return false;
> -}
> #else
> static inline struct page *
> __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
> @@ -3195,6 +3147,8 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
> return NULL;
> }
>
> +#endif /* CONFIG_COMPACTION */
> +
> static inline bool
> should_compact_retry(struct alloc_context *ac, unsigned int order, int alloc_flags,
> enum compact_result compact_result,
> @@ -3221,7 +3175,6 @@ should_compact_retry(struct alloc_context *ac, unsigned int order, int alloc_fla
> }
> return false;
> }
> -#endif /* CONFIG_COMPACTION */
>
> /* Perform direct synchronous page reclaim */
> static int
This worked for me for about 12 hours of my torture test. Logs are at
https://filebin.net/2rfah407nbhzs69e/OOM_4.8.0-rc2_p1.tar.bz2.
Ralf-Peter
----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.
Powered by blists - more mailing lists