From patchwork Tue Aug 7 07:25:53 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 10558285 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 5C55B96FA for ; Tue, 7 Aug 2018 07:26:03 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 41C2A28E15 for ; Tue, 7 Aug 2018 07:26:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3445529AC4; Tue, 7 Aug 2018 07:26:03 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id ACA0428E15 for ; Tue, 7 Aug 2018 07:26:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B4146B0008; Tue, 7 Aug 2018 03:26:01 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 960286B000A; Tue, 7 Aug 2018 03:26:01 -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 801496B000C; Tue, 7 Aug 2018 03:26:01 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by kanga.kvack.org (Postfix) with ESMTP id 239486B0008 for ; Tue, 7 Aug 2018 03:26:01 -0400 (EDT) Received: by mail-ed1-f71.google.com with SMTP id t17-v6so5051654edr.21 for ; Tue, 07 Aug 2018 00:26:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:message-id; bh=tO17PQk9X6YjtkR0bcBaYTwsQHR3FHpFiZXYXH0V89E=; b=TUgYwOZd/WpVAPdckXI7oNYm7U21mEEAFKc6A/WnG/W50yNIHg3ivFGs0pJ4Er4e3C qAd0Ep/6X93whsquOwl42Xe1WMV0pbMxfvBcsnLOIX2rcwUTUa/MV/MQJrvqOEKSPtAZ YNyc+2K2izhx0XEjVW254T12LT5YCj5cMSYCMgTgfmMV75NJYAdWqy9dBnfQH6PcYZib HMfrHZn83ig92HjkgOif9LJivbThxCBXB+NN7Xs3++d5dxCXnwHsX+YIXrs+3NQGj+dp 3WyFDQShPZ2AtYRJxX7cXZdzzDpjqvFr/86X4q1O1GX5VMGp3KeYS7mRdYMfEsnre74+ i3TA== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of mstsxfx@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=mstsxfx@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Gm-Message-State: AOUpUlE0B/dGoSCjzNE9kLRcl6y3XGI0dMkrvujaGjJ0mP8OrpkR8Nvi ncL6UnUBX1oLQ7TwTE9QOsF1rlq1uWMV2QnRwtXW6dPrwVNXPTcM8672+n4Yo8rODJrhsi4VoqG RARkO+2jqCW2iYFIrNm7RSNmQsDuhNpDF8bnfI5A5rvqNbSVXTnGtieIz3Jwvm1ba1Xc/wPqj6+ PYGymu/vGWjgG0m5nVacjM7elkslbF2lA3b1hRWHkx4A2mGBbMMetSKNufwFsqbX2CvNAoHddxE 8VNDtVNQBtBKbQrGuzbQgy2d8vTdNpNABxwnkTM8gvKKQU9Rrq/abJs59uNlTogvLlAgLxOZ/wg 6lU2J24z7rQZCKjzgfiRPXta1KPGjFYA2+sHArEVLbexuYNLB97e1tS3269a7NcGhRUWr88baA= = X-Received: by 2002:a50:be49:: with SMTP id b9-v6mr21180787edi.46.1533626760597; Tue, 07 Aug 2018 00:26:00 -0700 (PDT) X-Received: by 2002:a50:be49:: with SMTP id b9-v6mr21180737edi.46.1533626759668; Tue, 07 Aug 2018 00:25:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533626759; cv=none; d=google.com; s=arc-20160816; b=fXCd7Iz9N2HKvRgATmO3srIMN0nliWG29aopGFIOb8tKd/aI+3EQ61/ALYGGteUsLe E8WGxG5OCeFL2mb3ElvguG/etDnpt0is12JplB3F8A5wVru4+Q0OaTQ1NY1XX1eJa2UF HRnzq9FMScCXGPeHUN0vRrojBN2AmOMkepo4FtocCK+++/lseXkaECyUQTbQ6gGMrq94 3X8lRTlK3pWZNEMoxCMs3KW6EQOhlVzOKGYulhxrKx0WYOFyRovzarJr5h2cUZBwAsAZ gtKRSzFsRfy49ChmHKdznECkejw/cEB7shdsQ+VVzKVnNBnj8Fg5dUDAE/zJVZuEjFo+ tONA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:subject:cc:to:from:arc-authentication-results; bh=tO17PQk9X6YjtkR0bcBaYTwsQHR3FHpFiZXYXH0V89E=; b=omVNvrdz5k62AaeL6VrEeJWJz2vM6NwJLVaiLmZlDYQujqRsVBtu7WXoRuSTnXKOD5 fRxWkXhxjIv5umPa6irnbcovSWJC47JsjQn+piNTWRv0V5iqj7uqbCMnnGg83OdaNX0K L2MMAB9YJ4GWk2ORSVsPvM6PGUpRifYvXTBicNwD9iC/sAoKiEkLGDKQlJcLFQDuxqPR eza8xD25qa49T9AKnyaEWaS5szZUqAP2KPrSp6xMBfP5E5T9h6TZKp5RjipaNITyRvIR PIa1W9YW85Yy6Lzt5PenZAjqguV1Ut4F5Na3wrSo8asIeTccA9/fJfolNizSOJX9ohY7 4tqw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of mstsxfx@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=mstsxfx@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id h4-v6sor313092edq.9.2018.08.07.00.25.59 for (Google Transport Security); Tue, 07 Aug 2018 00:25:59 -0700 (PDT) Received-SPF: pass (google.com: domain of mstsxfx@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; spf=pass (google.com: domain of mstsxfx@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=mstsxfx@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Google-Smtp-Source: AAOMgpfx/tukHLhaVXmKs3g+zpYfn+QQFB6JWDvSh/Znty4Y0S19A6blIZB+XNdA9bfYycbo32aUdA== X-Received: by 2002:a50:8cd1:: with SMTP id r17-v6mr21534411edr.113.1533626759309; Tue, 07 Aug 2018 00:25:59 -0700 (PDT) Received: from tiehlicka.suse.cz (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id 40-v6sm591791edz.30.2018.08.07.00.25.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Aug 2018 00:25:58 -0700 (PDT) From: Michal Hocko To: Andrew Morton Cc: Johannes Weiner , Vladimir Davydov , , Greg Thelen , Tetsuo Handa , Dmitry Vyukov , LKML , Michal Hocko Subject: [PATCH] memcg, oom: be careful about races when warning about no reclaimable task Date: Tue, 7 Aug 2018 09:25:53 +0200 Message-Id: <20180807072553.14941-1-mhocko@kernel.org> X-Mailer: git-send-email 2.18.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: X-Virus-Scanned: ClamAV using ClamSMTP From: Michal Hocko "memcg, oom: move out_of_memory back to the charge path" has added a warning triggered when the oom killer cannot find any eligible task and so there is no way to reclaim the oom memcg under its hard limit. Further charges for such a memcg are forced and therefore the hard limit isolation is weakened. The current warning is however too eager to trigger even when we are not really hitting the above condition. Syzbot[1] and Greg Thelen have noticed that we can hit this condition even when there is still oom victim pending. E.g. the following race is possible: memcg has two tasks taskA, taskB. CPU1 (taskA) CPU2 CPU3 (taskB) try_charge mem_cgroup_out_of_memory try_charge select_bad_process(taskB) oom_kill_process oom_reap_task # No real memory reaped mem_cgroup_out_of_memory # set taskB -> MMF_OOM_SKIP # retry charge mem_cgroup_out_of_memory oom_lock oom_lock select_bad_process(self) oom_kill_process(self) oom_unlock # no eligible task In fact syzbot test triggered this situation by placing multiple tasks into a memcg with hard limit set to 0. So no task really had any memory charged to the memcg : Memory cgroup stats for /ile0: cache:0KB rss:0KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB swap:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB : Tasks state (memory values in pages): : [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name : [ 6569] 0 6562 9427 1 53248 0 0 syz-executor0 : [ 6576] 0 6576 9426 0 61440 0 0 syz-executor6 : [ 6578] 0 6578 9426 534 61440 0 0 syz-executor4 : [ 6579] 0 6579 9426 0 57344 0 0 syz-executor5 : [ 6582] 0 6582 9426 0 61440 0 0 syz-executor7 : [ 6584] 0 6584 9426 0 57344 0 0 syz-executor1 so in principle there is indeed nothing reclaimable in this memcg and this looks like a misconfiguration. On the other hand we can clearly kill all those tasks so it is a bit early to warn and scare users. Do that by checking that the current is the oom victim and bypass the warning then. The victim is allowed to force charge and terminate to release its temporal charge along the way. [1] http://lkml.kernel.org/r/0000000000005e979605729c1564@google.com Fixes: "memcg, oom: move out_of_memory back to the charge path" Noticed-by: Greg Thelen Reported-and-tested-by: syzbot+bab151e82a4e973fa325@syzkaller.appspotmail.com Signed-off-by: Michal Hocko --- mm/memcontrol.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 4603ad75c9a9..1b6eed1bc404 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1703,7 +1703,8 @@ static enum oom_status mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int return OOM_ASYNC; } - if (mem_cgroup_out_of_memory(memcg, mask, order)) + if (mem_cgroup_out_of_memory(memcg, mask, order) || + tsk_is_oom_victim(current)) return OOM_SUCCESS; WARN(1,"Memory cgroup charge failed because of no reclaimable memory! "