Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3963506imm; Mon, 6 Aug 2018 13:57:30 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfikTRtbtUCYJbkwK0vKRtqR8eBhBL+/cLyZjfibzWyyp7/2r7yuBcX6wk4NG4f4YJTiYmr X-Received: by 2002:a17:902:47c2:: with SMTP id d2-v6mr8972505plh.139.1533589050216; Mon, 06 Aug 2018 13:57:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533589050; cv=none; d=google.com; s=arc-20160816; b=uBmmVGuaVeEOpeGXJUpFtO/OuWeHiGz3cbzZHI/bpdPVEiV2zXD/PhDt1b4P0PxtYH tXUXgpF/9ASFveHLTWSvkGwatZI5h8IBWSWsW5uNNzOtCHrgWGn5UOhnC6wtzrYOz4v8 Ay7KNYYpDZViGkiu9gAJRNA0DalQ0Lj9UP0w8aIFv8pcIzWlA5w2lA/LqWjM+Ym4ctbu NF4nMTnFBwmUhstLnjVPrL/uja9lTsivZOVcxSiXEOqFYRfr6ugWM7hWUMOqhmG2HbO9 NDkz3fsXYIU5lEKEtcrd+CMpTM+oxuwLYpicsW+5riEnQ+GLdlyTewMf+NjcNovTHsOt oIdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=6HXaYYKmE91FxjbuUX3MCqmf2ECVDh20hIiFowtSRdk=; b=KzSybk9ODBo/DmsvBWOrX5tZm3lqcErMZoZTDouna8xThArG7ivM7S/1Zp4vklr/v0 ElGoNLwHx5kwokLYHvuqV3FZ285kuAPcw49du5QUMtZEYNp8DXLAyqwxHpfQ2KhKdS4z 7Oo98jeKikLbL2SJReMspU7JcnOZicE9exgPp2VCQByuLqu/Qg+qaydwJXme/Yk3H0MB wQUGeaPpfKE+fwFhEO7BiX2VXsLlxotlCykR8EY0JqsEhn24HIINkx+DkpOJ4KLT2V8H tF+X2zZVNEX2BPQ0rXK6flVp/hVGK6BentdQKx8/guAukyQIJ3XF4SVcgrcR1hYTcndP KWRQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3-v6si12070237pld.36.2018.08.06.13.57.15; Mon, 06 Aug 2018 13:57:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732944AbeHFXGM (ORCPT + 99 others); Mon, 6 Aug 2018 19:06:12 -0400 Received: from mx2.suse.de ([195.135.220.15]:43774 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728948AbeHFXGM (ORCPT ); Mon, 6 Aug 2018 19:06:12 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 104B2AE82; Mon, 6 Aug 2018 20:55:20 +0000 (UTC) Date: Mon, 6 Aug 2018 22:55:19 +0200 From: Michal Hocko To: Tetsuo Handa Cc: syzbot , cgroups@vger.kernel.org, dvyukov@google.com, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, vdavydov.dev@gmail.com Subject: Re: WARNING in try_charge Message-ID: <20180806205519.GO10003@dhcp22.suse.cz> References: <0000000000006350880572c61e62@google.com> <20180806174410.GB10003@dhcp22.suse.cz> <20180806175627.GC10003@dhcp22.suse.cz> <078bde8d-b1b5-f5ad-ed23-0cd94b579f9e@i-love.sakura.ne.jp> <20180806203437.GK10003@dhcp22.suse.cz> <3cf8f630-73b7-20d4-8ad1-bb1c657ee30d@i-love.sakura.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3cf8f630-73b7-20d4-8ad1-bb1c657ee30d@i-love.sakura.ne.jp> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 07-08-18 05:46:04, Tetsuo Handa wrote: > On 2018/08/07 5:34, Michal Hocko wrote: > > On Tue 07-08-18 05:26:23, Tetsuo Handa wrote: > >> On 2018/08/07 2:56, Michal Hocko wrote: > >>> So the oom victim indeed passed the above force path after the oom > >>> invocation. But later on hit the page fault path and that behaved > >>> differently and for some reason the force path hasn't triggered. I am > >>> wondering how could we hit the page fault path in the first place. The > >>> task is already killed! So what the hell is going on here. > >>> > >>> I must be missing something obvious here. > >>> > >> YOU ARE OBVIOUSLY MISSING MY MAIL! > >> > >> I already said this is "mm, oom: task_will_free_mem(current) should ignore MMF_OOM_SKIP for once." > >> problem which you are refusing at https://www.spinics.net/lists/linux-mm/msg133774.html . > >> And you again ignored my mail. Very sad... > > > > Your suggestion simply didn't make much sense. There is nothing like > > first check is different from the rest. > > > > I don't think your patch is appropriate. It avoids hitting WARN(1) but does not avoid > unnecessary killing of OOM victims. > > If you look at https://syzkaller.appspot.com/text?tag=CrashLog&x=15a1c770400000 , you will > notice that both 23766 and 23767 are killed due to task_will_free_mem(current) == false. > This is "unnecessary killing of additional processes". Have you noticed the mere detail that the memcg has to kill any task attempting the charge because the hard limit is 0? There is simply no other way around. You cannot charge. There is no unnecessary killing. Full stop. We do allow temporary breach of the hard limit just to let the task die and uncharge on the way out. -- Michal Hocko SUSE Labs