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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 053C6C19F2D for ; Tue, 9 Aug 2022 20:30:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7EC508E0008; Tue, 9 Aug 2022 16:30:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 79B2E8E0001; Tue, 9 Aug 2022 16:30:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 663278E0008; Tue, 9 Aug 2022 16:30:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 549AA8E0001 for ; Tue, 9 Aug 2022 16:30:52 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 35F5D1C69B4 for ; Tue, 9 Aug 2022 20:30:52 +0000 (UTC) X-FDA: 79781197944.03.BE134B5 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf20.hostedemail.com (Postfix) with ESMTP id 603E41C017D for ; Tue, 9 Aug 2022 20:30:51 +0000 (UTC) Received: by mail-ed1-f41.google.com with SMTP id f22so16545599edc.7 for ; Tue, 09 Aug 2022 13:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=SGeHWpS8KXCNe1fs123Ae1bZ4jHY7XPArBiSK195qHo=; b=diZ72ruOeFCCt/uKAyC4hFEGjST0bkVVYN2Yxf3d0zX/HotIMYgB0uLJgA4xp6aHl1 b/YZNcRaInm3BeLB5q6B+tIq7+Cr7Jg7X2XQ5MJ95vhSXGcwq90tjIn+warmeDgCniS1 CMV4iqB9gpLMcU5qcvguZuHFhANUGStypzYYQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=SGeHWpS8KXCNe1fs123Ae1bZ4jHY7XPArBiSK195qHo=; b=yULVUqYlW0qrPn3BcvN01PXWfaLnTZYT0fUY3fTJ0b1iLe3tcf3KwQsP+6fbqTTT+L fB09oqobfj/eZlx70TUAJ9eAZurYYVdlteKRcFu0FKdTqZ7vmRdlJZdzPFn8jaWSGs7D 9hg7eDGMRAGbrRagpHfVL0ty0LoR+wn1d4oX4cFIcpypMqijQxIGtVf+4AHIxOBGk5tE On9p59TP+q/1kpe6b2MKxaTIxqpCuop5+RsKdmD7SPQvgDR2JSnpQvZRV0GxzNPqh4n/ ShxZ2bPVpm7S7WM6FTroNb3V/dfHv7WBPJ0hPLhAhDoyLeRhZjibrB4ufh61Py4vBBUv m6eA== X-Gm-Message-State: ACgBeo3EhRdKlOo/PtEj/wQA2wPFg6aaKNfSaLWgfc7Vr6dyVysdhDBh SGqsqgvUSRfZzuO5w2gcCItYs3a++/sQcbemumU= X-Google-Smtp-Source: AA6agR5qRlsIov1yrY+6hs3uXjEFLJKUhPSqKfBI6dFfXgHnM6XaX7C8gwzwUMVtokLj8kkb2WRSbg== X-Received: by 2002:a05:6402:42d3:b0:435:2c49:313d with SMTP id i19-20020a05640242d300b004352c49313dmr23169640edc.86.1660077049902; Tue, 09 Aug 2022 13:30:49 -0700 (PDT) Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com. [209.85.128.43]) by smtp.gmail.com with ESMTPSA id ec33-20020a0564020d6100b004418c7d633bsm1179603edb.18.2022.08.09.13.30.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Aug 2022 13:30:47 -0700 (PDT) Received: by mail-wm1-f43.google.com with SMTP id ay12so4010849wmb.1 for ; Tue, 09 Aug 2022 13:30:45 -0700 (PDT) X-Received: by 2002:a05:600c:4ed0:b0:3a3:3ef3:c8d1 with SMTP id g16-20020a05600c4ed000b003a33ef3c8d1mr130608wmq.154.1660077044845; Tue, 09 Aug 2022 13:30:44 -0700 (PDT) MIME-Version: 1.0 References: <20220808073232.8808-1-david@redhat.com> <91e18a2f-c93d-00b8-7c1b-6d8493c3b2d5@redhat.com> In-Reply-To: From: Linus Torvalds Date: Tue, 9 Aug 2022 13:30:28 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1] mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org, Andrew Morton , Greg Kroah-Hartman , Axel Rasmussen , Peter Xu , Hugh Dickins , Andrea Arcangeli , Matthew Wilcox , Vlastimil Babka , John Hubbard , Jason Gunthorpe Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660077051; a=rsa-sha256; cv=none; b=vadpvx2XTOQojBshmyJwMQInFFM1AZlpj2PqIkviD4mWA+VM/UWO2b+gLBd7SreFOSu3s8 +O4KAoIsHvmJfeMDCsoeuVVmKTsjGStkDOvLMdcMOsGLoB8PwKbPMIodDGTV60w/j5FdUQ la1ixNtGQRq94cr6KIMaQpKTLgXVb9A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660077051; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SGeHWpS8KXCNe1fs123Ae1bZ4jHY7XPArBiSK195qHo=; b=4d/Qxj8lKK7j1qiH/QmULeWIHqxqgFUtZxa8raN1Cys344zKiXYZVyptzegITs8A3iRneC DZaolN9hB2zBfIM3iT39qE3eSbXjHLfcYgUK0hDH13TbP5oIOfDRB8CglwPnkiQSp8W4yk wOr3CMeSPHevLN2moPSdoxf+k8hBmVk= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=diZ72ruO; spf=pass (imf20.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.41 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Stat-Signature: kh7e9jt7sqkgk37zni7fixpiuze4zi7g X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 603E41C017D Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=diZ72ruO; spf=pass (imf20.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.41 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-HE-Tag: 1660077051-40308 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 Tue, Aug 9, 2022 at 1:20 PM David Hildenbrand wrote: > > IIUC VM_MAYSHARE is always set in a MAP_SHARED mapping, but for file > mappings we only set VM_SHARED if the file allows for writes Heh. This is a horrific hack, and probably should go away. Yeah, we have that if (!(file->f_mode & FMODE_WRITE)) vm_flags &= ~(VM_MAYWRITE | VM_SHARED); but I think that's _entirely_ historical. Long long ago, in a galaxy far away, we didn't handle shared mmap() very well. In fact, we used to not handle it at all. But nntpd would use write() to update the spool file, adn them read it through a shared mmap. And since our mmap() *was* coherent with people doing write() system calls, but didn't handle actual dirty shared mmap, what Linux used to do was to just say "Oh, you want a read-only shared file mmap? I can do that - I'll just downgrade it to a read-only _private_ mapping, and it actually ends up with the same semantics". And here we are, 30 years later, and it still does that, but it leaves the VM_MAYSHARE flag so that /proc//maps can show that it's a shared mapping. Linus