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 06597C43462 for ; Wed, 19 May 2021 07:13:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D8E2B61353 for ; Wed, 19 May 2021 07:13:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239144AbhESHOq (ORCPT ); Wed, 19 May 2021 03:14:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:36636 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235329AbhESHOq (ORCPT ); Wed, 19 May 2021 03:14:46 -0400 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: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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.