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.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 D12A8C433DB for ; Mon, 22 Feb 2021 07:34:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E58D560234 for ; Mon, 22 Feb 2021 07:34:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E58D560234 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=srcf.ucam.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EA1636B0006; Mon, 22 Feb 2021 02:34:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E52396B006C; Mon, 22 Feb 2021 02:34:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D68296B006E; Mon, 22 Feb 2021 02:34:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0099.hostedemail.com [216.40.44.99]) by kanga.kvack.org (Postfix) with ESMTP id BFD1F6B0006 for ; Mon, 22 Feb 2021 02:34:54 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7D1EB180622C9 for ; Mon, 22 Feb 2021 07:34:54 +0000 (UTC) X-FDA: 77845092108.29.FD213D4 Received: from cavan.codon.org.uk (cavan.codon.org.uk [176.126.240.207]) by imf15.hostedemail.com (Postfix) with ESMTP id A2E93A0009C5 for ; Mon, 22 Feb 2021 07:34:52 +0000 (UTC) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id 2065540A21; Mon, 22 Feb 2021 07:34:52 +0000 (UTC) Date: Mon, 22 Feb 2021 07:34:52 +0000 From: Matthew Garrett To: Mike Rapoport Cc: Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Michal Hocko , 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 Subject: Re: [PATCH v17 08/10] PM: hibernate: disable when there are active secretmem users Message-ID: <20210222073452.GA30403@codon.org.uk> References: <20210208084920.2884-1-rppt@kernel.org> <20210208084920.2884-9-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210208084920.2884-9-rppt@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A2E93A0009C5 X-Stat-Signature: nfopi3x79judbq5ww79rsdkqwpdirw39 Received-SPF: none (codon.org.uk>: No applicable sender policy available) receiver=imf15; identity=mailfrom; envelope-from=""; helo=cavan.codon.org.uk; client-ip=176.126.240.207 X-HE-DKIM-Result: none/none X-HE-Tag: 1613979292-550216 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 Mon, Feb 08, 2021 at 10:49:18AM +0200, Mike Rapoport wrote: > 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. Sorry for being a bit late to this - from the point of view of running processes (and even the kernel once resume is complete), hibernation is effectively equivalent to suspend to RAM. Why do they need to be handled differently here?