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.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 CFE41C433E1 for ; Fri, 3 Jul 2020 22:53:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9170B21531 for ; Fri, 3 Jul 2020 22:53:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="M7+yQAj4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9170B21531 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0D0258D00A4; Fri, 3 Jul 2020 18:53:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 080428D0010; Fri, 3 Jul 2020 18:53:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED83C8D00A4; Fri, 3 Jul 2020 18:53:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) by kanga.kvack.org (Postfix) with ESMTP id D79D68D0010 for ; Fri, 3 Jul 2020 18:53:33 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 74B351E03 for ; Fri, 3 Jul 2020 22:53:33 +0000 (UTC) X-FDA: 76998267906.16.pig35_4d1823326e95 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 41BDB100E6903 for ; Fri, 3 Jul 2020 22:53:33 +0000 (UTC) X-HE-Tag: pig35_4d1823326e95 X-Filterd-Recvd-Size: 4940 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Fri, 3 Jul 2020 22:53:32 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id z24so13785826ljn.8 for ; Fri, 03 Jul 2020 15:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xCR5VvhKlbkEFM6sZwEPdCYNVIQ/fI7Y+3OKvD7Y5CE=; b=M7+yQAj4FyVF9DU+YNPXjKkVGTGKftdJcKKszBlVnX5aS/jz3jwzpl3oRMTykHtghk CMx1MmsupZzmxYmq0YdqHf4JFlGmU+ghnqWOKgIEdrvyFQ8Qa99a2FdkXrdi2Se/MLsL nlVcruJkxMDHASJOxyYFVac4TY50weNssjd+pcNnCBmcp3Oz3AkyGCqXTM+LdkZ0pRFo SJAmicXgGy4doAWU9fLljh5vtUNMBTr+DM4EVbJvY2Mmd+0/V3H4Ly/4mbVGWiUWaTQs 5AIO+GujEt3x4dZHcu5ilq/o638RybF8ne644ndhtl4BYMHpGmDujSfX0aKEpdomjKD8 kEdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xCR5VvhKlbkEFM6sZwEPdCYNVIQ/fI7Y+3OKvD7Y5CE=; b=gh7LC/0h0+NSIJ3PkoZ9vA2Dj/HiIibrWpqgY4xeeevz0OjfJ69GgoX0IAvmz6598Z NhS4bGXnAL0ZQqI3/crBtgqNOYWInYsZz1pD0/8JSUuSeGruOmBTha7PwKtj49KeyE+1 +ar002NGe8I3Drh+u6N7PqjT1G40THaUgJrLeSYztXOqtTtTvYocLstGJP4UjkBKi4QD y23R4c7f/4hL4C36e/C28MVYAGHChRsK1fgBPbHmsOtobMClzudaiVrf+Eyy9zY58O62 +Pml2hwIW9Tqv93sbt99O5CZOwuFCGPbebteGogWVsHsbHLT5LrtE+3zksYo9Tpt9Nbq EQ2w== X-Gm-Message-State: AOAM53150/O5YJXHfxWBcBvJKQteVtSmquhhyWoUzlSma9yKjE/6mxD+ 4z8Bf7zt0Yj+7ItYhcXrXmn6k/9GoadOfyAd+f4x6Q== X-Google-Smtp-Source: ABdhPJy0/d7YQxkDTsZvXO7ow32yFdRcjugFg1twpCSkcbrbcdxZ/z4wQIr7NksLBKL4GwroBCtrf1lXG19AlZ5fv5c= X-Received: by 2002:a2e:9dcc:: with SMTP id x12mr4527117ljj.415.1593816811282; Fri, 03 Jul 2020 15:53:31 -0700 (PDT) MIME-Version: 1.0 References: <20200703113026.GT18446@dhcp22.suse.cz> <20200703223453.GA25072@amd> In-Reply-To: <20200703223453.GA25072@amd> From: Jann Horn Date: Sat, 4 Jul 2020 00:53:04 +0200 Message-ID: Subject: Re: [RFC]: mm,power: introduce MADV_WIPEONSUSPEND To: Pavel Machek Cc: Michal Hocko , "Catangiu, Adrian Costin" , "linux-mm@kvack.org" , "linux-pm@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "linux-api@vger.kernel.org" , "akpm@linux-foundation.org" , "rjw@rjwysocki.net" , "len.brown@intel.com" , "fweimer@redhat.com" , "keescook@chromium.org" , "luto@amacapital.net" , "wad@chromium.org" , "mingo@kernel.org" , "bonzini@gnu.org" , "Graf (AWS), Alexander" , "MacCarthaigh, Colm" , "Singh, Balbir" , "Sandu, Andrei" , "Brooker, Marc" , "Weiss, Radu" , "Manwaring, Derek" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 41BDB100E6903 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000176, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Jul 4, 2020 at 12:34 AM Pavel Machek wrote: > On Fri 2020-07-03 15:29:22, Jann Horn wrote: > > On Fri, Jul 3, 2020 at 1:30 PM Michal Hocko wrote: > > > On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > > > > This patch adds logic to the kernel power code to zero out contents of > > > > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > > > > to any suspend state equal or greater/deeper than Suspend-to-memory, > > > > known as S3. > > > > > > How does the application learn that its memory got wiped? S2disk is an > > > async operation and it can happen at any time during the task execution. > > > So how does the application work to prevent from corrupted state - e.g. > > > when suspended between two memory loads? > > > > You can do it seqlock-style, kind of - you reserve the first byte of > > the page or so as a "is this page initialized" marker, and after every > > read from the page, you do a compiler barrier and check whether that > > byte has been > > That would also need smp cpu barriers, and guarantee that first byte > is always ... cleared first, and matching barriers in kernel space, > too, no? Not if it happens in the guts of the suspend stuff, when userspace is frozen, I think?