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 75C9BC433F5 for ; Tue, 26 Oct 2021 13:57:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DB97060C41 for ; Tue, 26 Oct 2021 13:57:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DB97060C41 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=i-love.sakura.ne.jp Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 2E402940009; Tue, 26 Oct 2021 09:57:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C3A4940007; Tue, 26 Oct 2021 09:57:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A7BD940009; Tue, 26 Oct 2021 09:57:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0229.hostedemail.com [216.40.44.229]) by kanga.kvack.org (Postfix) with ESMTP id 0C8CC940007 for ; Tue, 26 Oct 2021 09:57:06 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A80EE82499A8 for ; Tue, 26 Oct 2021 13:57:05 +0000 (UTC) X-FDA: 78738740010.32.F8728D7 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf29.hostedemail.com (Postfix) with ESMTP id A04AC9000247 for ; Tue, 26 Oct 2021 13:57:04 +0000 (UTC) Received: from fsav314.sakura.ne.jp (fsav314.sakura.ne.jp [153.120.85.145]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 19QDulsa003967; Tue, 26 Oct 2021 22:56:47 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav314.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav314.sakura.ne.jp); Tue, 26 Oct 2021 22:56:47 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav314.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 19QDukhj003946 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Oct 2021 22:56:46 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Message-ID: <62a326bc-37d2-b8c9-ddbf-7adaeaadf341@i-love.sakura.ne.jp> Date: Tue, 26 Oct 2021 22:56:44 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Subject: Re: [PATCH memcg v3 2/3] mm, oom: do not trigger out_of_memory from the #PF Content-Language: en-US To: Michal Hocko Cc: Vasily Averin , 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, Johannes Weiner , Vladimir Davydov , Andrew Morton References: From: Tetsuo Handa In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A04AC9000247 Authentication-Results: imf29.hostedemail.com; dkim=none; spf=none (imf29.hostedemail.com: domain of penguin-kernel@i-love.sakura.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@i-love.sakura.ne.jp; dmarc=none X-Stat-Signature: 8ynp5d4ezisrtxy1tofrhafqarnftjkm X-Rspamd-Server: rspam06 X-HE-Tag: 1635256624-154060 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 2021/10/25 17:04, Michal Hocko wrote: > I do not think there is any guarantee. This code has meant to be a > safeguard but it turns out to be adding more harm than a safety. There > are several scenarios mentioned in this thread where this would be > counter productive or outright wrong thing to do. Setting PR_IO_FLUSHER via prctl(PR_SET_IO_FLUSHER) + hitting legacy kmem charge limit might be an unexpected combination? > > On the other hand it is hard to imagine any legitimate situation where > this would be a right thing to do. Maybe you have something more > specific in mind? What would be the legit code to rely on OOM handling > out of the line (where the details about the allocation scope is lost)? I don't have specific scenario, but I feel that it might be a chance to retry killable vmalloc(). Commit b8c8a338f75e ("Revert "vmalloc: back off when the current task is killed"") was 4.5 years ago, and fuzz testing found many bugs triggered by memory allocation fault injection. Thus, I think that the direction is going towards "we can fail memory allocation upon SIGKILL (rather than worrying about depleting memory reserves and/or escalating to global OOM killer invocations)". Most memory allocation requests which allocate memory for userspace process are willing to give up upon SIGKILL. Like you are trying to add NOFS, NOIO, NOFAIL support to vmalloc(), you could consider KILLABLE support as well. Of course, direct reclaim makes it difficult to immediately give up upon SIGKILL, but killable allocation sounds still nice even if best-effort basis.