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=-8.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 4E9A9C433DB for ; Mon, 8 Feb 2021 10:36:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F170364E54 for ; Mon, 8 Feb 2021 10:36:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232553AbhBHKgL (ORCPT ); Mon, 8 Feb 2021 05:36:11 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:40435 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232312AbhBHKeC (ORCPT ); Mon, 8 Feb 2021 05:34:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612780356; 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=gTqE4GAwIRRw8Nu7Vah8lYA78avuk6Kq3uIkNKISp9U=; b=SREtDrSMxvS8bZqrF3nPI2eX301bODYy+p2eWNfPi9VQychFQSGs3suFhP+a9NrNyAeUMJ /B1KF0bA1OHewhykKyyQPUfUk/RXqkciOFPHQsbuDG1pmVa7LXKzVluOQ0x59COgwgAJ3G JLO/LFizdJPe5ctXDJ3ptYoZHgRGO48= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-281-shzg6BOVMaWLsYhbKcL92A-1; Mon, 08 Feb 2021 05:32:32 -0500 X-MC-Unique: shzg6BOVMaWLsYhbKcL92A-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2E0C4835E20; Mon, 8 Feb 2021 10:32:27 +0000 (UTC) Received: from [10.36.113.240] (ovpn-113-240.ams2.redhat.com [10.36.113.240]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8816A5D9DD; Mon, 8 Feb 2021 10:32:13 +0000 (UTC) Subject: Re: [PATCH v17 08/10] PM: hibernate: disable when there are active secretmem users To: Michal Hocko , Mike Rapoport Cc: Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , 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, Hagen Paul Pfeifer , Palmer Dabbelt References: <20210208084920.2884-1-rppt@kernel.org> <20210208084920.2884-9-rppt@kernel.org> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <38c0cad4-ac55-28e4-81c6-4e0414f0620a@redhat.com> Date: Mon, 8 Feb 2021 11:32:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On 08.02.21 11:18, Michal Hocko wrote: > On Mon 08-02-21 10:49:18, Mike Rapoport wrote: >> From: Mike Rapoport >> >> It is unsafe to allow saving of secretmem areas to the hibernation >> snapshot as they would be visible after the resume and this essentially >> will defeat the purpose of secret memory mappings. >> >> Prevent hibernation whenever there are active secret memory users. > > Does this feature need any special handling? As it is effectivelly > unevictable memory then it should behave the same as other mlock, ramfs > which should already disable hibernation as those cannot be swapped out, > no? > Why should unevictable memory not go to swap when hibernating? We're merely dumping all of our system RAM (including any unmovable allocations) to swap storage and the system is essentially completely halted. -- Thanks, David / dhildenb