From patchwork Wed Mar 18 00:55:04 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Rientjes X-Patchwork-Id: 11444337 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 67AA11668 for ; Wed, 18 Mar 2020 00:55:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2832220752 for ; Wed, 18 Mar 2020 00:55:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="qtFxEZ1t" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2832220752 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EFF956B0003; Tue, 17 Mar 2020 20:55:07 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id EAF186B0006; Tue, 17 Mar 2020 20:55:07 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D9E206B0007; Tue, 17 Mar 2020 20:55:07 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) by kanga.kvack.org (Postfix) with ESMTP id C27606B0003 for ; Tue, 17 Mar 2020 20:55:07 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B640C5DE3 for ; Wed, 18 Mar 2020 00:55:07 +0000 (UTC) X-FDA: 76606663854.05.air39_840abd9ff6100 X-Spam-Summary: 2,0,0,3901f8ad49f453e8,d41d8cd98f00b204,rientjes@google.com,,RULES_HIT:41:355:379:800:960:966:973:988:989:1260:1277:1313:1314:1345:1359:1437:1516:1518:1535:1542:1593:1594:1711:1730:1747:1777:1792:2196:2198:2199:2200:2393:2559:2562:2731:3138:3139:3140:3141:3142:3152:3353:3865:3866:3867:3868:3870:3871:3874:4250:4385:5007:6261:6653:8660:9038:10004:10400:10450:10455:11026:11658:11914:12043:12296:12297:12438:12517:12519:12533:12555:12679:12895:13148:13230:13439:13870:14096:14097:14181:14659:14721:19904:19999:21080:21324:21444:21451:21627:21966:21990:30054:30056,0,RBL:209.85.215.193:@google.com:.lbl8.mailshell.net-62.18.0.100 66.100.201.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:25,LUA_SUMMARY:none X-HE-Tag: air39_840abd9ff6100 X-Filterd-Recvd-Size: 5584 Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Wed, 18 Mar 2020 00:55:07 +0000 (UTC) Received: by mail-pg1-f193.google.com with SMTP id b22so6691958pgb.6 for ; Tue, 17 Mar 2020 17:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=qphLOGPy6WLUhsMBU8OI5qX+iRggfdyjjgGh+WRxITI=; b=qtFxEZ1tEfyhjZbnoCgzo2KFHjYTGvQbyI/GaTKSU/Rff4KJsQ3n3ogaKhZYh+UU88 AusapqIj2GUNUFJoPJvxqaYi8WKTm4c9VO18BCUGX7VzJzO6v88iKiICtlFqw4iSHLo5 p6A/a+RGqkDmGWMKMx4PhEL9AS6cZWgx5RASsxA4t1sy5RqohSdkI1UgLgcDHhNFuhui oaIjooqb3AEk5y0ndnpsid5p/iZVw3Huvm/sVmpiyFIKvuaqk0OK/Gc7IxzuETa9FQm2 z/xqK794DS3AzyQd/eHNnSqp390NKPpgEYSfgumfPKn6pYfuKTB+ac73FnBBIrMUgxNh 04YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=qphLOGPy6WLUhsMBU8OI5qX+iRggfdyjjgGh+WRxITI=; b=YWJMjlyyguGlZeAiLY9XFRTST7NOPxvjZt/2Zn3uoglg18ACZpfg2IQj5WSWD4FVYV F+OyBwbszo4QBtL4XLGhDfmwJntN/nRUCt6APFSmcgsPGdOAm0UJMfASM28EDDUz1Lp2 3y6sreR9JxrfpEohlHIM62FjVJiBeERbR4XgqW1/DZNC+1pJK7/mUhebk2gyDx4vrI4f U1DEsSPfnVI0GJZDVxHWRc9uMWGx5zwv4/QJSW9ZdjMeYFWNmy5ERbhJ8/00z7d6G6EJ n3DMVgELw/g5wEEH3M+gBOw1AnRmh9eLPu432Hbukomq1qqbEnxQJU1hyEJGfrm1wW4N MoSQ== X-Gm-Message-State: ANhLgQ0agQo3y6OpVOM/ZsweYhRm7DuP4zXse7LsCoSii8J10kMITf0e 36ivfbRhzQ7uZdOFNSQJlLz0mw== X-Google-Smtp-Source: ADFU+vtQBxL6vqci+cLw5OR67p9pEL3mCFri1YWV9aBD17Zc1SJcCsF17VbdCUEKbvqTUVZBiXjPuw== X-Received: by 2002:aa7:8d82:: with SMTP id i2mr1596369pfr.179.1584492905844; Tue, 17 Mar 2020 17:55:05 -0700 (PDT) Received: from [2620:15c:17:3:3a5:23a7:5e32:4598] ([2620:15c:17:3:3a5:23a7:5e32:4598]) by smtp.gmail.com with ESMTPSA id 25sm4276095pfn.190.2020.03.17.17.55.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 17:55:05 -0700 (PDT) Date: Tue, 17 Mar 2020 17:55:04 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Andrew Morton , Tetsuo Handa cc: Vlastimil Babka , Robert Kolchmeyer , Michal Hocko , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [patch v2] mm, oom: prevent soft lockup on memcg oom for UP systems In-Reply-To: Message-ID: References: <8395df04-9b7a-0084-4bb5-e430efe18b97@i-love.sakura.ne.jp> <202003170318.02H3IpSx047471@www262.sakura.ne.jp> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: When a process is oom killed as a result of memcg limits and the victim is waiting to exit, nothing ends up actually yielding the processor back to the victim on UP systems with preemption disabled. Instead, the charging process simply loops in memcg reclaim and eventually soft lockups. Memory cgroup out of memory: Killed process 808 (repro) total-vm:41944kB, anon-rss:35344kB, file-rss:504kB, shmem-rss:0kB, UID:0 pgtables:108kB oom_score_adj:0 watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [repro:806] CPU: 0 PID: 806 Comm: repro Not tainted 5.6.0-rc5+ #136 RIP: 0010:shrink_lruvec+0x4e9/0xa40 ... Call Trace: shrink_node+0x40d/0x7d0 do_try_to_free_pages+0x13f/0x470 try_to_free_mem_cgroup_pages+0x16d/0x230 try_charge+0x247/0xac0 mem_cgroup_try_charge+0x10a/0x220 mem_cgroup_try_charge_delay+0x1e/0x40 handle_mm_fault+0xdf2/0x15f0 do_user_addr_fault+0x21f/0x420 page_fault+0x2f/0x40 Make sure that once the oom killer has been called that we forcibly yield if current is not the chosen victim regardless of priority to allow for memory freeing. The same situation can theoretically occur in the page allocator, so do this after dropping oom_lock there as well. Suggested-by: Tetsuo Handa Tested-by: Robert Kolchmeyer Cc: stable@vger.kernel.org Signed-off-by: David Rientjes --- mm/memcontrol.c | 2 ++ mm/page_alloc.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/mm/memcontrol.c b/mm/memcontrol.c --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1576,6 +1576,8 @@ static bool mem_cgroup_out_of_memory(struct mem_cgroup *memcg, gfp_t gfp_mask, */ ret = should_force_charge() || out_of_memory(&oc); mutex_unlock(&oom_lock); + if (!fatal_signal_pending(current)) + schedule_timeout_killable(1); return ret; } diff --git a/mm/page_alloc.c b/mm/page_alloc.c --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3861,6 +3861,8 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order, } out: mutex_unlock(&oom_lock); + if (!fatal_signal_pending(current)) + schedule_timeout_killable(1); return page; }