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=-5.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 111E5C433ED for ; Tue, 18 May 2021 10:37:44 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8CB3761350 for ; Tue, 18 May 2021 10:37:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8CB3761350 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YOMhvMG0onk8c3wlJY++mvC0ckFvTa3dEFAGb46qKcU=; b=gBs3GQ195dFYk7N32p4NP4+Sq O7zU72IKH9AA6yhj/KUbKqUTWvqCrTY3wJlhoJdkuO0b14PO1DQPLrZqrnlTXhunduI5TL1cbhKsU pvBKFo/QYesOe7NY8J+qDemt9LLF4a5Q94xro0aehhi5CDubYhOuMvG41CgMukr4szaJcTY5B7KgK /uYSKNilPSQZL+NA1NSHWSTWEfxpv6mvvks8dedFY9Z9xdGNIlLvBxLSL7SRC0r1Uln1fChHSrp56 QuEknXTzUY2eBU7wb8o3MP+vrzk2fNr1UUhRGuPYi7djMo0EY7e4UMdlij1O9cWKHwXtyqvgIRGF4 t7IBdlyGw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lix4o-000PL9-CK; Tue, 18 May 2021 10:35:51 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lix4l-000PKc-BT for linux-arm-kernel@desiato.infradead.org; Tue, 18 May 2021 10:35:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To: Subject:Sender:Reply-To:Content-ID:Content-Description; bh=4vp8lNy9snZR0aaM1NkHvO7WK4qnZ3T1+NZIbLJBP3o=; b=mXexZjmr9KjJr9/kJIEiqwgYCy WG1Npr0aC3bTUCcxd1Am88eVpxF97EjJ15aMgFqwYe+qKmighvv2Nq81OB2e9oV/rEpB5JiFF1Itd R+T8MpHww5xdH5wpZLTyeZ7Qchz1JFadCZqWobINXxaUiF7V3IMFFr9xHZyTuiwlXoijY4cixRXJI JtGDmpd2yk7wg8bgrk9n7531rrF+NcwIxtJBQMr5qqI2+gmed3t847HxRUpL7YMzWW4CCKul7qRq2 pFtDHSZ2nUDMIsKoSNonLw4b9QFCgWrL7+/PqDHBW3wgUmGFDLnE2lVA4khPwZ7SJlmkTx8A7Eat6 S6pCvU8w==; Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lix4i-00EZRc-Lq for linux-arm-kernel@lists.infradead.org; Tue, 18 May 2021 10:35:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621334143; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4vp8lNy9snZR0aaM1NkHvO7WK4qnZ3T1+NZIbLJBP3o=; b=ZwUzp8clzqz94eMLKgAuRc5EK2MmHmTQEGXoGuY9lxD5tdHeKRIb0T/t8+fTKEAS6qiOPd uBtjkvHBH45G/VDKY28wP6+BOCF2aBaGK+ckbvkzbFdm0m72xiPJSOf3x3BfgCnMAGPFQB EIJySHH9b/pcyM0AV1OIyNfdqz8hPXU= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-145-2nQ1lnwDPjWxSlf9haGGPA-1; Tue, 18 May 2021 06:35:40 -0400 X-MC-Unique: 2nQ1lnwDPjWxSlf9haGGPA-1 Received: by mail-wm1-f72.google.com with SMTP id f8-20020a1c1f080000b0290169855914dfso401724wmf.3 for ; Tue, 18 May 2021 03:35:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=4vp8lNy9snZR0aaM1NkHvO7WK4qnZ3T1+NZIbLJBP3o=; b=rUGGJT875TXUgOrVJ8asPdJ51wejERoYWERxpYSR2cVs0G9CLzCuY+VT0C94NvBI1j UuPAnMe676hVXGBLQeifqmsaIINWwRJHVOvyJpXNw91SBTQrrH9sgJuK6JrsbSakUjYR OdcovCJy4shbjY4oZPu/kCrRr/A9rCvrLOsA6S3OtZ1bqHzdZRV71+6RrQ5d+IabJ4fg /yHX5MA9p1y+vqj6Ya8UAzqCB81fJpnNZSVPV5DNrlgpw377pGnPJMqnANT+hVrYJQgh GIXxiHaT4/reTM37Zu+XII0yltfyimE76U3mNYybMKp678jg4Mg+fUdK1o8vBTSra1Ui OCxw== X-Gm-Message-State: AOAM531hkiNDvKVXY46RRL1trQwX3CsX881NPHfgykhKsM7zV+Mm/6br B3eYWPv+aqRwKB2DJCQbrd15c9mzsH3Ms2sWhZYW41Bee4SZvqGxsFCzOh+c2vyEAHY7YzHTzNM 9Oy+Y9DjW3Oag/WDOBlS6OD8WWhqaT8fZIf4= X-Received: by 2002:a5d:4c91:: with SMTP id z17mr6097352wrs.349.1621334139163; Tue, 18 May 2021 03:35:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwivDOaaOEtmmfekeSrzIxF+whFkS4KLINBSXbPJdxKCFo9r8ATuUwdqMoXxsMMTM3AMH6k8g== X-Received: by 2002:a5d:4c91:: with SMTP id z17mr6097320wrs.349.1621334138962; Tue, 18 May 2021 03:35:38 -0700 (PDT) Received: from [192.168.3.132] (p5b0c64fd.dip0.t-ipconnect.de. [91.12.100.253]) by smtp.gmail.com with ESMTPSA id s15sm1725827wrt.54.2021.05.18.03.35.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 May 2021 03:35:38 -0700 (PDT) Subject: Re: [PATCH v19 5/8] mm: introduce memfd_secret system call to create "secret" memory areas To: Michal Hocko Cc: Mike Rapoport , 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 References: <20210513184734.29317-1-rppt@kernel.org> <20210513184734.29317-6-rppt@kernel.org> <8e114f09-60e4-2343-1c42-1beaf540c150@redhat.com> From: David Hildenbrand Organization: Red Hat Message-ID: <00644dd8-edac-d3fd-a080-0a175fa9bf13@redhat.com> Date: Tue, 18 May 2021 12:35:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210518_033544_805139_30B82A6F X-CRM114-Status: GOOD ( 33.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 18.05.21 12:31, Michal Hocko wrote: > On Tue 18-05-21 12:06:42, David Hildenbrand wrote: >> On 18.05.21 11:59, Michal Hocko wrote: >>> On Sun 16-05-21 10:29:24, Mike Rapoport wrote: >>>> On Fri, May 14, 2021 at 11:25:43AM +0200, David Hildenbrand wrote: >>> [...] >>>>>> + if (!page) >>>>>> + return VM_FAULT_OOM; >>>>>> + >>>>>> + err = set_direct_map_invalid_noflush(page, 1); >>>>>> + if (err) { >>>>>> + put_page(page); >>>>>> + return vmf_error(err); >>>>> >>>>> Would we want to translate that to a proper VM_FAULT_..., which would most >>>>> probably be VM_FAULT_OOM when we fail to allocate a pagetable? >>>> >>>> That's what vmf_error does, it translates -ESOMETHING to VM_FAULT_XYZ. >>> >>> I haven't read through the rest but this has just caught my attention. >>> Is it really reasonable to trigger the oom killer when you cannot >>> invalidate the direct mapping. From a quick look at the code it is quite >>> unlikely to se ENOMEM from that path (it allocates small pages) but this >>> can become quite sublte over time. Shouldn't this simply SIGBUS if it >>> cannot manipulate the direct mapping regardless of the underlying reason >>> for that? >>> >> >> OTOH, it means our kernel zones are depleted, so we'd better reclaim somehow >> ... > > Killing a userspace seems to be just a bad way around that. > > 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. 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 ... -- Thanks, David / dhildenb _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel