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.4 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 9BCA2C433E0 for ; Mon, 6 Jul 2020 12:52:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7916B20771 for ; Mon, 6 Jul 2020 12:52:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="B1r3fG6d" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728989AbgGFMwf (ORCPT ); Mon, 6 Jul 2020 08:52:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40664 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728940AbgGFMwf (ORCPT ); Mon, 6 Jul 2020 08:52:35 -0400 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 174A4C061794 for ; Mon, 6 Jul 2020 05:52:35 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id h19so45189158ljg.13 for ; Mon, 06 Jul 2020 05:52:35 -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=r/l418RqBKygT3XUaVVUWM37eZi8gQrBBNYXDXbn38k=; b=B1r3fG6dsH/qouMx2ubARUPAdcsyFNEgp1v1D8jfa52c8J7fRImq0ys4SnNlP6XrN2 99Raf5nlxeqcQN1Tn47ilpKlji+mfh9L+e+Rup7zFPMbiIFcs8P2uqJ4ASVgCVZ66Hl3 6/zGA4OKUhaVEjYmTMnmmU1m9r5vvu7tNcDRxLkBGD8VQXhgpGDcZzSvZFhoW7xr7Ugo seaC0JArz8AlAHcKsDf4KJxiCUXx/Jd+yuiCpMAl4YopCCdiTLEoUUy+wjdBQ17l/PUy FYI8QkWPGr6GT3rclGkWVFo64BXFXCZb4R0vyPT+BKs0jBiNdc13WXKOOvLxnvW2WDNJ xcPA== 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=r/l418RqBKygT3XUaVVUWM37eZi8gQrBBNYXDXbn38k=; b=Uz8Jja4b8si1s8azZf8LrRXczIruPf3Fd9Mr44FgmWkSyvm0wOw4H1n4PdDjEo+7FL Q6zYHbq+ePjOfpvVe4YYATDReIfrhTjHtoTYctoY4ZyVa4hWr4jTS7p/pV574D2jsX6K Pcrg0P4ObSalWmND2rqbOUobtik2+Tc1jHfYjz2+SYpfozKacZe2MRed1swViRwCun5U t477f8vCEmKyF7glWl8G+PPIGIIO8di8wrbTAQqgjAOY0TcDHh3ZHoTd99AMaGTVRADM rMDh632biKsrVLzY96zoCcyNZN4z2oLyq3xw5W23LI9EgffxTX9R/cv5air6AyMzjf4y wvhg== X-Gm-Message-State: AOAM533IzRDqhDAPoN+ek7jtK298sE1gqu8wWbL+Ezq6FZ+n21HFOYFz HciZA/USq49iuBSRpjC0W7YN8ycZNZ8fOBV0+YIdvA== X-Google-Smtp-Source: ABdhPJwjpTKLYWq+hR31eDYdmY+r8r9swuzWK5B3LmVV+w60tAqfgVu13/vDXFsFyS2tITflFJ5EFbHXt6vJDWkzwko= X-Received: by 2002:a05:651c:3cf:: with SMTP id f15mr26115232ljp.365.1594039953375; Mon, 06 Jul 2020 05:52:33 -0700 (PDT) MIME-Version: 1.0 References: <20200703224411.GC25072@amd> <20200704114820.GA16083@amd> <57ab4fb3-3f82-d34f-ad74-2214b45a4dd9@amazon.com> In-Reply-To: <57ab4fb3-3f82-d34f-ad74-2214b45a4dd9@amazon.com> From: Jann Horn Date: Mon, 6 Jul 2020 14:52:07 +0200 Message-ID: Subject: Re: [RFC]: mm,power: introduce MADV_WIPEONSUSPEND To: Alexander Graf Cc: Pavel Machek , "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" , "mhocko@kernel.org" , "fweimer@redhat.com" , "keescook@chromium.org" , "luto@amacapital.net" , "wad@chromium.org" , "mingo@kernel.org" , "bonzini@gnu.org" , "MacCarthaigh, Colm" , "Singh, Balbir" , "Sandu, Andrei" , "Brooker, Marc" , "Weiss, Radu" , "Manwaring, Derek" Content-Type: text/plain; charset="UTF-8" Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Mon, Jul 6, 2020 at 2:27 PM Alexander Graf wrote: > Unless we create a vsyscall that returns both the PID as well as the > epoch and thus handles fork *and* suspend. I need to think about this a > bit more :). You can't reliably detect forking by checking the PID if it is possible for multiple forks to be chained before the reuse check runs: - pid 1000 remembers its PID - pid 1000 forks, creating child pid 1001 - pid 1000 exits and is waited on by init - the pid allocator wraps around - pid 1001 forks, creating child pid 1000 - child with pid 1000 tries to check for forking, determines that its PID is 1000, and concludes that it is still the original process 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.4 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 2585DC433E1 for ; Mon, 6 Jul 2020 12:52:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DFAFF20786 for ; Mon, 6 Jul 2020 12:52:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="B1r3fG6d" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DFAFF20786 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 5BE396B0003; Mon, 6 Jul 2020 08:52:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 56FD16B0005; Mon, 6 Jul 2020 08:52:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 45F526B0006; Mon, 6 Jul 2020 08:52:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0242.hostedemail.com [216.40.44.242]) by kanga.kvack.org (Postfix) with ESMTP id 311116B0003 for ; Mon, 6 Jul 2020 08:52:36 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D50BA180AD806 for ; Mon, 6 Jul 2020 12:52:35 +0000 (UTC) X-FDA: 77007639870.06.chain53_5a0c18d26eab Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id A05B110039B7E for ; Mon, 6 Jul 2020 12:52:35 +0000 (UTC) X-HE-Tag: chain53_5a0c18d26eab X-Filterd-Recvd-Size: 4409 Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Mon, 6 Jul 2020 12:52:35 +0000 (UTC) Received: by mail-lj1-f171.google.com with SMTP id d17so30457455ljl.3 for ; Mon, 06 Jul 2020 05:52:35 -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=r/l418RqBKygT3XUaVVUWM37eZi8gQrBBNYXDXbn38k=; b=B1r3fG6dsH/qouMx2ubARUPAdcsyFNEgp1v1D8jfa52c8J7fRImq0ys4SnNlP6XrN2 99Raf5nlxeqcQN1Tn47ilpKlji+mfh9L+e+Rup7zFPMbiIFcs8P2uqJ4ASVgCVZ66Hl3 6/zGA4OKUhaVEjYmTMnmmU1m9r5vvu7tNcDRxLkBGD8VQXhgpGDcZzSvZFhoW7xr7Ugo seaC0JArz8AlAHcKsDf4KJxiCUXx/Jd+yuiCpMAl4YopCCdiTLEoUUy+wjdBQ17l/PUy FYI8QkWPGr6GT3rclGkWVFo64BXFXCZb4R0vyPT+BKs0jBiNdc13WXKOOvLxnvW2WDNJ xcPA== 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=r/l418RqBKygT3XUaVVUWM37eZi8gQrBBNYXDXbn38k=; b=F2lP2WvY6ss1DVBkb9Tx17rm3ZGf7C1ncu0XRGfyv4W5wdQhIvUymIorVPNz03Ojn2 AWG3cA2QGjH0jwM+xkOpc5b+5KWlAOwYKx2PGCtFBgtHJq6F+ZiwQwyUmdb89mpcDuyD 43Re+4kSAhR87jamODB1UExoAu39x+pj7sb2+3yZj/PE/xkqGyNmBqcyuvJ2Wr9U4mKy d/e/lr3t3FvluwxZb/b5GQRXFlgKRu7WHQMFfRit/1Wc6ri5vVKsBOzBadaqjqFfpOR7 pynfi3Atl8+wbEgZXGyPhMenyTmBtTk4f/8YFtbF54oQZaUOXSvh9eq8MucS8rf06KLA QYHw== X-Gm-Message-State: AOAM53290tHtqNySGsYnFZ0lvaAnQ6jku68ZzS9/tWr9W+na8R78P97A IKpYhZwH2SDxJsU7cbX5Fsoz6uYrOvhMQBpwZqGVkw== X-Google-Smtp-Source: ABdhPJwjpTKLYWq+hR31eDYdmY+r8r9swuzWK5B3LmVV+w60tAqfgVu13/vDXFsFyS2tITflFJ5EFbHXt6vJDWkzwko= X-Received: by 2002:a05:651c:3cf:: with SMTP id f15mr26115232ljp.365.1594039953375; Mon, 06 Jul 2020 05:52:33 -0700 (PDT) MIME-Version: 1.0 References: <20200703224411.GC25072@amd> <20200704114820.GA16083@amd> <57ab4fb3-3f82-d34f-ad74-2214b45a4dd9@amazon.com> In-Reply-To: <57ab4fb3-3f82-d34f-ad74-2214b45a4dd9@amazon.com> From: Jann Horn Date: Mon, 6 Jul 2020 14:52:07 +0200 Message-ID: Subject: Re: [RFC]: mm,power: introduce MADV_WIPEONSUSPEND To: Alexander Graf Cc: Pavel Machek , "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" , "mhocko@kernel.org" , "fweimer@redhat.com" , "keescook@chromium.org" , "luto@amacapital.net" , "wad@chromium.org" , "mingo@kernel.org" , "bonzini@gnu.org" , "MacCarthaigh, Colm" , "Singh, Balbir" , "Sandu, Andrei" , "Brooker, Marc" , "Weiss, Radu" , "Manwaring, Derek" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: A05B110039B7E X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jul 6, 2020 at 2:27 PM Alexander Graf wrote: > Unless we create a vsyscall that returns both the PID as well as the > epoch and thus handles fork *and* suspend. I need to think about this a > bit more :). You can't reliably detect forking by checking the PID if it is possible for multiple forks to be chained before the reuse check runs: - pid 1000 remembers its PID - pid 1000 forks, creating child pid 1001 - pid 1000 exits and is waited on by init - the pid allocator wraps around - pid 1001 forks, creating child pid 1000 - child with pid 1000 tries to check for forking, determines that its PID is 1000, and concludes that it is still the original process From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jann Horn Subject: Re: [RFC]: mm,power: introduce MADV_WIPEONSUSPEND Date: Mon, 6 Jul 2020 14:52:07 +0200 Message-ID: References: <20200703224411.GC25072@amd> <20200704114820.GA16083@amd> <57ab4fb3-3f82-d34f-ad74-2214b45a4dd9@amazon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <57ab4fb3-3f82-d34f-ad74-2214b45a4dd9-vV1OtcyAfmbQT0dZR+AlfA@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Alexander Graf Cc: Pavel Machek , "Catangiu, Adrian Costin" , "linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org" , "linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org" , "rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org" , "len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org" , "mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , "fweimer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , "keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org" , "luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org" , "wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org" , "mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , "bonzini-mXXj517/zsQ@public.gmane.org" Ma List-Id: virtualization@lists.linuxfoundation.org On Mon, Jul 6, 2020 at 2:27 PM Alexander Graf wrote: > Unless we create a vsyscall that returns both the PID as well as the > epoch and thus handles fork *and* suspend. I need to think about this a > bit more :). You can't reliably detect forking by checking the PID if it is possible for multiple forks to be chained before the reuse check runs: - pid 1000 remembers its PID - pid 1000 forks, creating child pid 1001 - pid 1000 exits and is waited on by init - the pid allocator wraps around - pid 1001 forks, creating child pid 1000 - child with pid 1000 tries to check for forking, determines that its PID is 1000, and concludes that it is still the original process