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 X-Spam-Level: X-Spam-Status: No, score=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62123C43600 for ; Wed, 19 May 2021 07:13:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 022B7613B5 for ; Wed, 19 May 2021 07:13:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 022B7613B5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 66C786B006E; Wed, 19 May 2021 03:13:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F8B86B0070; Wed, 19 May 2021 03:13:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 421B56B0071; Wed, 19 May 2021 03:13:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0004.hostedemail.com [216.40.44.4]) by kanga.kvack.org (Postfix) with ESMTP id 060976B006E for ; Wed, 19 May 2021 03:13:28 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9EEAB8249980 for ; Wed, 19 May 2021 07:13:28 +0000 (UTC) X-FDA: 78157114896.38.5A6E72E Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf17.hostedemail.com (Postfix) with ESMTP id 51CE040002F9 for ; Wed, 19 May 2021 07:13:28 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 306EE6135B; Wed, 19 May 2021 07:13:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621408407; bh=Ki50aQXwD1+I3Hw9xcIirZa4MRm+9KRJ+IEPHMwhBkI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oYyy/RZh+KV4+OBVGMz4vRqytOJ3S6neHrNHLUg1kHLXII61rwPkBThjJAvrsmUZo FjnPqLIJ5kAx/qeZGbRsU6kB8hQ4Hhb8cAmXfxBQtvxU8dgEHEV4y4yEtokhAPiKIr /MuOkK56iFsIUVMsvkPHddFEnBeu4T4s7c6IPe+YOzaeJb9MlSBih46lnNG19GWJXN Dr+Kz+dEZLJXS9T0HxuiavOJs0HPv1T3S1Qsh+y5zhmE6RBkRzoRn73O2mfgQvXLJ6 Y/WFNcW+0oFbapTux4HghodwAEaeJ7uRFxUxBZQ17d8823037Btr6+DWDVvpylUSU6 pxMi/n2f2auLQ== Date: Wed, 19 May 2021 10:13:09 +0300 From: Mike Rapoport To: Michal Hocko Cc: David Hildenbrand , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Hagen Paul Pfeifer , Ingo Molnar , James Bottomley , Kees Cook , "Kirill A. Shutemov" , Matthew Wilcox , Matthew Garrett , Mark Rutland , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , "Rafael J. Wysocki" , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , Yury Norov , linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org, x86@kernel.org Subject: Re: [PATCH v19 5/8] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: References: <20210513184734.29317-1-rppt@kernel.org> <20210513184734.29317-6-rppt@kernel.org> <8e114f09-60e4-2343-1c42-1beaf540c150@redhat.com> <00644dd8-edac-d3fd-a080-0a175fa9bf13@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 51CE040002F9 Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="oYyy/RZh"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of rppt@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=rppt@kernel.org X-Rspamd-Server: rspam03 X-Stat-Signature: 6j17gne96geph9dz39f8x1hombsrw4p3 X-HE-Tag: 1621408408-91326 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 Tue, May 18, 2021 at 01:08:27PM +0200, Michal Hocko wrote: > On Tue 18-05-21 12:35:36, David Hildenbrand wrote: > > On 18.05.21 12:31, Michal Hocko wrote: > > > > > > Although I have to say openly that I am not a great fan of VM_FAULT_OOM > > > in general. It is usually a a wrong way to tell the handle the failure > > > because it happens outside of the allocation context so you lose all the > > > details (e.g. allocation constrains, numa policy etc.). Also whenever > > > there is ENOMEM then the allocation itself has already made sure that > > > all the reclaim attempts have been already depleted. Just consider an > > > allocation with GFP_NOWAIT/NO_RETRY or similar to fail and propagate > > > ENOMEM up the call stack. Turning that into the OOM killer sounds like a > > > bad idea to me. But that is a more general topic. I have tried to bring > > > this up in the past but there was not much of an interest to fix it as > > > it was not a pressing problem... > > > > > > > I'm certainly interested; it would mean that we actually want to try > > recovering from VM_FAULT_OOM in various cases, and as you state, we might > > have to supply more information to make that work reliably. > > Or maybe we want to get rid of VM_FAULT_OOM altogether... But this is > really tangent to this discussion. The only relation is that this would > be another place to check when somebody wants to go that direction. If we are to get rid of VM_FAULT_OOM, vmf_error() would be updated and this place will get the update automagically. > > Having that said, I guess what we have here is just the same as when our > > process fails to allocate a generic page table in __handle_mm_fault(), when > > we fail p4d_alloc() and friends ... > > From a quick look it is really similar in a sense that it effectively never > happens and if it does then it certainly does the wrong thing. The point > I was trying to make is that there is likely no need to go that way. As David pointed out, failure to handle direct map in secretmem_fault() is like any allocation failure in page fault handling and most of them result in VM_FAULT_OOM, so I think that having vmf_error() in secretmem_fault() is more consistent with the rest of the code than using VM_FAULT_SIGBUS. Besides if the direct map manipulation failures would result in errors other than -ENOMEM, having vmf_error() may prove useful. -- Sincerely yours, Mike.