From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A41DC433FE for ; Mon, 18 Oct 2021 10:13:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9223360FD8 for ; Mon, 18 Oct 2021 10:13:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9223360FD8 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=virtuozzo.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id EAE996B006C; Mon, 18 Oct 2021 06:13:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E5E38900002; Mon, 18 Oct 2021 06:13:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D4E026B0072; Mon, 18 Oct 2021 06:13:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) by kanga.kvack.org (Postfix) with ESMTP id C2F8D6B006C for ; Mon, 18 Oct 2021 06:13:11 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 73980180FEAF3 for ; Mon, 18 Oct 2021 10:13:11 +0000 (UTC) X-FDA: 78709145382.02.2117F19 Received: from relay.sw.ru (relay.sw.ru [185.231.240.75]) by imf30.hostedemail.com (Postfix) with ESMTP id 873C3E0016B0 for ; Mon, 18 Oct 2021 10:13:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=Content-Type:MIME-Version:Date:Message-ID:From: Subject; bh=RjQ2q0eEBKUC2hw/uFRyVd7II2frLBeK42RcVtr41GU=; b=YdtmgWLsg/9itCN0w gaNBRGfhIxNAIsOrvb79eZIkBpOZ7CZv91nsy63JFIByh51HEzOSr7LaoE/DPpCnbwVT7Fz6deWga 3qvoCB+/JJird1u8Xkc8qoPNqN6hyBAQ+QqhpptZZesFoyaujeaovPqgzcP6IbmvsVDDwm/pBVKIQ =; Received: from [172.29.1.17] by relay.sw.ru with esmtp (Exim 4.94.2) (envelope-from ) id 1mcPdh-006L2E-Bu; Mon, 18 Oct 2021 13:13:05 +0300 Subject: Re: [PATCH memcg 0/1] false global OOM triggered by memcg-limited task From: Vasily Averin To: Michal Hocko Cc: Johannes Weiner , Vladimir Davydov , Andrew Morton , Roman Gushchin , Uladzislau Rezki , Vlastimil Babka , Shakeel Butt , Mel Gorman , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel@openvz.org References: <9d10df01-0127-fb40-81c3-cc53c9733c3e@virtuozzo.com> <6b751abe-aa52-d1d8-2631-ec471975cc3a@virtuozzo.com> Message-ID: <4a6f801b-28d3-94d7-2e65-212ad8c5a412@virtuozzo.com> Date: Mon, 18 Oct 2021 13:12:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <6b751abe-aa52-d1d8-2631-ec471975cc3a@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 873C3E0016B0 X-Stat-Signature: 8dg84k1yq3ukhjbm3n1j557s3nfxwwtf Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=virtuozzo.com header.s=relay header.b=YdtmgWLs; spf=pass (imf30.hostedemail.com: domain of vvs@virtuozzo.com designates 185.231.240.75 as permitted sender) smtp.mailfrom=vvs@virtuozzo.com; dmarc=pass (policy=quarantine) header.from=virtuozzo.com X-HE-Tag: 1634551987-511946 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: On 18.10.2021 13:05, Vasily Averin wrote: > On 18.10.2021 12:04, Michal Hocko wrote: >> On Mon 18-10-21 11:13:52, Vasily Averin wrote: >>> Partially this problem depends on one of my recent patches, disabled unlimited >>> memory allocation for dying tasks. However I think the problem can happen >>> on non-killed tasks too, for example because of kmem limit. >> >> Could you be more specific on how this can happen without your patch? I >> have to say I haven't realized this side effect when discussing it. > > We can reach obj_cgroup_charge_pages() for example via > > do_user_addr_fault > handle_mm_fault > __handle_mm_fault > p4d_alloc > __p4d_alloc > p4d_alloc_one > get_zeroed_page > __get_free_pages > alloc_pages > __alloc_pages > __memcg_kmem_charge_page > obj_cgroup_charge_pages > > Here we call try_charge_memcg() that return success and approve the allocation, > however then we hit into kmem limit and fail the allocation. btw. in OpenVZ kernels we trying to cleanup the memory in when task hit kmem limit, therefore we moved kmem limit check into try_charge_memcg. Are any improvements for kmem controller interesting for upstream? Thank you, Vasily Averin