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 6C2B2C433EF for ; Fri, 17 Dec 2021 22:59:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C7A6E6B0072; Fri, 17 Dec 2021 17:59:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C29466B0073; Fri, 17 Dec 2021 17:59:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA3C16B0074; Fri, 17 Dec 2021 17:59:36 -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 97B876B0072 for ; Fri, 17 Dec 2021 17:59:36 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 584638CE0C for ; Fri, 17 Dec 2021 22:59:26 +0000 (UTC) X-FDA: 78928804332.15.3DEE90F Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by imf29.hostedemail.com (Postfix) with ESMTP id 70F19120037 for ; Fri, 17 Dec 2021 22:59:23 +0000 (UTC) Received: by mail-ed1-f49.google.com with SMTP id b7so13410551edd.6 for ; Fri, 17 Dec 2021 14:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rs3RPGk851m6kBvnTkDZNuCHS7bqxE4YiPXPeOnsMec=; b=WSqIxUtqn5jcmA6NC9BVpsfsO/6YYpI4P+quaDiBpik06F329fj372+mpAs6nkU6hi UgKtVq/JNx9O5+tUI1FaDEc9lAWL66/z1RpLwMtAJZ086ni6cHm+R02sIgHA08fo/qlY ertG4Ei0o7WJ3lUoVgGOz1iW744OYt4w3zD7E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rs3RPGk851m6kBvnTkDZNuCHS7bqxE4YiPXPeOnsMec=; b=Y2v64vNUyumQqCVGWIvt7nJt7iZ+GOCr0wlD6hQ4XlhdWBIcVjos+pJmSvoY2v5sS+ YmvlR38k3WJYHW8gpi4CVKwmaocRCe39F+ZwPNb4FxeMsF+z87XVGfB9RU1Fqpix3r+D z0ywvQ2V2wa/h2uvBbq2rT8xhPFye2HtKo+fYZiQ18Pm/d+SpO1tVRwrEwph6PRJyWIA JeJGEyLB+PXs8ATmBQf8Ddjpj4L3O/b6TRajRyv3U2fdumSmYUL12LlnqgWf3W1/wB+g 0NSakWvjGdbIELjcf25gyCpH/EZomm4BVbsN067eMNoTU2lrIlBLvBmIhr+RsgmwHF4z RlVw== X-Gm-Message-State: AOAM533K/+5ZtivP2RT1Ak6l+CYdUITM4nhFLwsGJSbuQtGrQ0SWbPHS OGQqyo0kh7SJe9B8aXohJ9oA0BwFSK0GyShnU0k= X-Google-Smtp-Source: ABdhPJzoVTzG+0riCcllyQHeY6qWIH9UMIyLJcHoGIMiXNw7pT9p3RlilWpiy5onNhrIO55j6z14Ag== X-Received: by 2002:a50:ab41:: with SMTP id t1mr4912237edc.389.1639781964244; Fri, 17 Dec 2021 14:59:24 -0800 (PST) Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com. [209.85.221.44]) by smtp.gmail.com with ESMTPSA id e1sm4064286edc.27.2021.12.17.14.59.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Dec 2021 14:59:24 -0800 (PST) Received: by mail-wr1-f44.google.com with SMTP id s1so6776224wrg.1 for ; Fri, 17 Dec 2021 14:59:23 -0800 (PST) X-Received: by 2002:adf:f54e:: with SMTP id j14mr4140437wrp.442.1639781952748; Fri, 17 Dec 2021 14:59:12 -0800 (PST) MIME-Version: 1.0 References: <20211217113049.23850-1-david@redhat.com> <20211217113049.23850-7-david@redhat.com> <9c3ba92e-9e36-75a9-9572-a08694048c1d@redhat.com> <02cf4dcf-74e8-9cbd-ffbf-8888f18a9e8a@redhat.com> <0aa27d7d-0db6-94ee-ca16-91d19997286b@redhat.com> In-Reply-To: <0aa27d7d-0db6-94ee-ca16-91d19997286b@redhat.com> From: Linus Torvalds Date: Fri, 17 Dec 2021 14:58:56 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 06/11] mm: support GUP-triggered unsharing via FAULT_FLAG_UNSHARE (!hugetlb) To: David Hildenbrand Cc: Linux Kernel Mailing List , Andrew Morton , Hugh Dickins , David Rientjes , Shakeel Butt , John Hubbard , Jason Gunthorpe , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Matthew Wilcox , Vlastimil Babka , Jann Horn , Michal Hocko , Nadav Amit , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Linux-MM , "open list:KERNEL SELFTEST FRAMEWORK" , "open list:DOCUMENTATION" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 70F19120037 X-Stat-Signature: z5w51cmwzby76f846kcfr91oq4xddtm4 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=WSqIxUtq; spf=pass (imf29.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.49 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspamd-Server: rspam10 X-HE-Tag: 1639781963-925476 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 Fri, Dec 17, 2021 at 2:29 PM David Hildenbrand wrote: > > While I do care about future use cases, I cannot possibly see fork() not > requiring the mmap_lock in the foreseeable future. Just so much depends > on it as of now. It's not that *fork()* depends on it. Of course fork() takes the mmap_sem. It's that fast-gup really really doesn't want it, and can't take it. So any fast-gup user fundamentally cannot look at mapcount(), because that would be fundamentally wrong and racy, and could race with fork. And yet, as far as I can tell, that's *exactly* what your gup patches do, with gup_pte_range() adding + if (!pte_write(pte) && gup_must_unshare(flags, page, false)) { + put_compound_head(head, 1, flags); + goto pte_unmap; + } which looks at the page mapcount without holding the mmap sem at all. And see my other email - I think there are other examples of your patches looking at data that isn't stable because you don't hold the right locks. And you can't even do the optimistic case without taking the lock, because in your world, a COW that optimistically copies in the case of a race condition is fundamentally *wrong* and buggy. Because in your world-view, GUP and COW are very different and have different rules, but you need things to be *exact*, and they aren't. And none of this is anything at least I can think about, because I don't see what the "design" is. I really have a hard time following what the rules actually are. You seem to think that "page_mapcount()" is a really simple rule, and I fundamentally disagree. It's a _very_ complicated thing indeed, with locking issues, AND YOU ACTIVELY VIOLATE THE LOCKING RULES! See why I'm so unhappy? We *did* do the page_mapcount() thing. It was bad. It forced COW to always take the page lock. There's a very real reason why I'm pushing my "let's have a _design_ here", instead of your "let's look at page_mapcount without even doing the locking". And yes, I *know* that fork() takes the mmap_sem, and likely always will. That really isn't the problem here. The problem is that your page_mapcount() paths DO NOT take that lock. Btw, maybe I'm misreading things. I looked at the individual patches, I didn't apply them, maybe I missed something. But I don't think I am. Linus