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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 49953FA372C for ; Fri, 8 Nov 2019 06:37:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0E98F21D7B for ; Fri, 8 Nov 2019 06:37:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="LlvNmAWE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E98F21D7B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 98D566B0006; Fri, 8 Nov 2019 01:37:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 93DFA6B0007; Fri, 8 Nov 2019 01:37:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 82CC26B0008; Fri, 8 Nov 2019 01:37:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0238.hostedemail.com [216.40.44.238]) by kanga.kvack.org (Postfix) with ESMTP id 6D0856B0006 for ; Fri, 8 Nov 2019 01:37:20 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id F3510180AD815 for ; Fri, 8 Nov 2019 06:37:19 +0000 (UTC) X-FDA: 76132153398.11.cork16_5c1c2a103830 X-HE-Tag: cork16_5c1c2a103830 X-Filterd-Recvd-Size: 2945 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Fri, 8 Nov 2019 06:37:19 +0000 (UTC) Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D6CA421882; Fri, 8 Nov 2019 06:37:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573195038; bh=sXe/lKnHWXWz0aIej4oPyDwjQIRvSAnRd4dPdmDpkII=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LlvNmAWEIFV3DOIrxKnv8p/Io0xVltpUHrWIziebLbV98yw0fcsZwyxSmE25Af5V8 lCAriWwM88CjnNik4h37rJD5I1XjJYSR0YIZdq/vgelAa8ihvdPvFW8FOf3VIdZNCg QIjP4MEv3UaTX2KWtlJdvJUdrv5bRc0tOXixTUxM= Date: Fri, 8 Nov 2019 07:37:15 +0100 From: Greg KH To: Joel Fernandes Cc: Andrew Morton , linux-kernel@vger.kernel.org, Nicolas Geoffray , kernel-team@android.com, Hugh Dickins , linux-kselftest@vger.kernel.org, linux-mm@kvack.org, Shuah Khan Subject: Re: [PATCH 1/2] memfd: Fix COW issue on MAP_PRIVATE and F_SEAL_FUTURE_WRITE mappings Message-ID: <20191108063715.GA513315@kroah.com> References: <20191107195355.80608-1-joel@joelfernandes.org> <20191107170023.0695732bb67eb80acd4caee5@linux-foundation.org> <20191108020614.GA99567@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191108020614.GA99567@google.com> User-Agent: Mutt/1.12.2 (2019-09-21) 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 Thu, Nov 07, 2019 at 09:06:14PM -0500, Joel Fernandes wrote: > On Thu, Nov 07, 2019 at 05:00:23PM -0800, Andrew Morton wrote: > > On Thu, 7 Nov 2019 14:53:54 -0500 "Joel Fernandes (Google)" wrote: > > > > > F_SEAL_FUTURE_WRITE has unexpected behavior when used with MAP_PRIVATE: > > > A private mapping created after the memfd file that gets sealed with > > > F_SEAL_FUTURE_WRITE loses the copy-on-write at fork behavior, meaning > > > children and parent share the same memory, even though the mapping is > > > private. > > > > That sounds fairly serious. Should this be backported into -stable kernels? > > Yes, it should be. The F_SEAL_FUTURE_WRITE feature was introduced in v5.1 so > v5.3.x stable kernels would need a backport. I can submit a backport tomorrow > unless we are Ok with stable automatically picking it up (I believe the > stable folks "auto select" fixes which should detect this is a fix since I > have said it is a fix in the subject line). Never rely on "auto select" to pick up a patch for stable if you already know it should go to stable. Just mark it as such, or tell stable@vger after the fact. thanks, greg k-h