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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD4D9C433F5 for ; Sat, 23 Apr 2022 11:48:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38A8F6B0073; Sat, 23 Apr 2022 07:48:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 339976B0074; Sat, 23 Apr 2022 07:48:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 201376B0075; Sat, 23 Apr 2022 07:48:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 0CFB56B0073 for ; Sat, 23 Apr 2022 07:48:56 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id D005481416 for ; Sat, 23 Apr 2022 11:48:55 +0000 (UTC) X-FDA: 79387972230.06.1CF764B Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf01.hostedemail.com (Postfix) with ESMTP id 158DE40027 for ; Sat, 23 Apr 2022 11:48:51 +0000 (UTC) Received: from fsav112.sakura.ne.jp (fsav112.sakura.ne.jp [27.133.134.239]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 23NBmTfj015009; Sat, 23 Apr 2022 20:48:29 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav112.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav112.sakura.ne.jp); Sat, 23 Apr 2022 20:48:29 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav112.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 23NBmSiS015000 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Sat, 23 Apr 2022 20:48:28 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <8a6659ba-13ba-b9be-08c8-f02f106d55fb@I-love.SAKURA.ne.jp> Date: Sat, 23 Apr 2022 20:48:28 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v2 8/8] mm: Centralize & improve oom reporting in show_mem.c Content-Language: en-US To: Kent Overstreet Cc: Michal Hocko , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, hch@lst.de, hannes@cmpxchg.org, akpm@linux-foundation.org, linux-clk@vger.kernel.org, linux-tegra@vger.kernel.org, linux-input@vger.kernel.org, rostedt@goodmis.org, Roman Gushchin References: <20220421234837.3629927-1-kent.overstreet@gmail.com> <20220421234837.3629927-14-kent.overstreet@gmail.com> <20220422234820.plusgyixgybebfmi@moria.home.lan> <20220423004607.q4lbz2mplkhlbyhm@moria.home.lan> From: Tetsuo Handa In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 158DE40027 X-Stat-Signature: pz6xcaexrc3ejxc958zc6f1ojp3xxi5z Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=none; spf=none (imf01.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 X-HE-Tag: 1650714531-697993 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 2022/04/23 10:25, Roman Gushchin wrote: >>> I agree. However the OOM killer _has_ to make the progress even in such rare >>> circumstances. >> >> Oh, and the concern is allocator recursion? Yeah, that's a good point. > > Yes, but not the only problem. > >> >> Do you know if using memalloc_noreclaim_(save|restore) is sufficient for that, >> or do we want GFP_ATOMIC? I'm already using GFP_ATOMIC for allocations when we >> generate the report on slabs, since we're taking the slab mutex there. > > And this is another problem: grabbing _any_ locks from the oom context is asking > for trouble: you can potentially enter the oom path doing any allocation, so > now you have to check that no allocations are ever made holding this lock. > And I'm not aware of any reasonable way to test it, so most likely it ends up > introducing some very subtle bags, which will be triggered once a year. > You can't allocate memory nor hold locks from OOM context. Since oom_lock mutex serializes OOM reporting, you could use statically pre-allocated buffer for holding one line of output. Correlating whole report will be done by the userspace program with the aid of CONFIG_PRINTK_CALLER=y.