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=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 3F485C43460 for ; Fri, 14 May 2021 13:18:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 99EF161574 for ; Fri, 14 May 2021 13:18:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 99EF161574 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C89446B0036; Fri, 14 May 2021 09:18:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C0FDF6B006E; Fri, 14 May 2021 09:18:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3C296B0070; Fri, 14 May 2021 09:18:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id 69DC16B0036 for ; Fri, 14 May 2021 09:18:48 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0D83218033E7F for ; Fri, 14 May 2021 13:18:48 +0000 (UTC) X-FDA: 78139891536.12.3F082AB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf03.hostedemail.com (Postfix) with ESMTP id D0CB0C0007E9 for ; Fri, 14 May 2021 13:18:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620998326; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3Qai09ABkyx5du95Ox4wpA5Z6s77EwapfOJRz22dS3w=; b=UAXcpjlv3euHmCCmmxK9Q+EgcTEDLxWUI1nA9jtzaP2HV9AuP79qO4mrk/frCbDUvjkMA7 a1A+/PxNTf//AadKewlz4UaM4yHK1C7XmUO+iNI4Ej7hr2UoQyLggkFVjB6Wb5iCsGz3T3 DoPdvjb1+yYADlN28ENsvDSn0v8xuN8= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-473-OMqzWpwWO3STUPXxqhODFg-1; Fri, 14 May 2021 09:18:45 -0400 X-MC-Unique: OMqzWpwWO3STUPXxqhODFg-1 Received: by mail-qt1-f197.google.com with SMTP id o5-20020ac872c50000b02901c32e7e3c21so20177431qtp.8 for ; Fri, 14 May 2021 06:18:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3Qai09ABkyx5du95Ox4wpA5Z6s77EwapfOJRz22dS3w=; b=U0dV+TSx4/L3GBy1uDYjXGQXiNoZReRfw8AGHhjj7WLSPFLz34O2g3gl0QD2ZZ7hVJ g8ogM4VX9419mGp7dwX5Fe+pd/4IXSoz2tL/f22v0FGqtwmy9jB67Z6/Naa7hrcYb+Ny QMCOioJhjpbSXUjqbukr01qCbE0A6vRT/rUcqvd+2MVab30rsgt+d9qEEsKqFsW1DtH4 m6Cxw5j6PKnSXaRt5lw3miKypgX3Gdj1fk3zabFy6A/wj6RN3YIZLM8Rn9gZdj98xsd0 EpZkdfe9yGrUU4NZYI+KDdV5x0GBrQZQjfUUDfrXbmReToeCb1FwOQktYn8Uz69K+wRa Ru6A== X-Gm-Message-State: AOAM530hDcVVMxWnY/PyDckS6W1cnGg31mLli5SMCR7cMOPb8B1xy5EF /dgXA5Fw35ONhEOKk4nFAJ1xcQryk3o5T1848swMSxDjBEtchnm8KjfTCSweIeR0BdNEEs18jvy aAV36nWqQtvg= X-Received: by 2002:ac8:7f83:: with SMTP id z3mr33555899qtj.239.1620998324353; Fri, 14 May 2021 06:18:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx3kctbzKjpHxKCqh39AwL0aUlnZiYbR9dALp56fd/jcHwHnn1BUyd8IvocfrZuPfoOuUfHDQ== X-Received: by 2002:ac8:7f83:: with SMTP id z3mr33555862qtj.239.1620998323921; Fri, 14 May 2021 06:18:43 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-72-184-145-4-219.dsl.bell.ca. [184.145.4.219]) by smtp.gmail.com with ESMTPSA id l10sm4983447qtn.28.2021.05.14.06.18.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 May 2021 06:18:43 -0700 (PDT) Date: Fri, 14 May 2021 09:18:42 -0400 From: Peter Xu To: Hugh Dickins Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Nadav Amit , Miaohe Lin , Mike Rapoport , Andrea Arcangeli , Jerome Glisse , Mike Kravetz , Jason Gunthorpe , Matthew Wilcox , Andrew Morton , Axel Rasmussen , "Kirill A . Shutemov" Subject: Re: [PATCH v2 00/24] userfaultfd-wp: Support shmem and hugetlbfs Message-ID: References: <20210427161317.50682-1-peterx@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: D0CB0C0007E9 Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=UAXcpjlv; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf03.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=peterx@redhat.com X-Rspamd-Server: rspam03 X-Stat-Signature: 4dh85r4godpfchipak9t3rr7eakbtwjc X-HE-Tag: 1620998326-568113 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: Hugh, On Fri, May 14, 2021 at 12:07:38AM -0700, Hugh Dickins wrote: > On Wed, 12 May 2021, Peter Xu wrote: > > On Tue, Apr 27, 2021 at 12:12:53PM -0400, Peter Xu wrote: > > > This is v2 of uffd-wp shmem & hugetlbfs support, which completes uffd-wp as a > > > kernel full feature, as it only supports anonymous before this series. > > > > Ping.. > > > > Thinking about a repost, as this series shouldn't be able to apply after we've > > got more relevant patches into -mm. E.g., the full minor fault, and also some > > small stuff like pagemap, as we need one more patch to support shmem/hugetlbfs > > too. > > > > Hugh, haven't received any further comment from you on shmem side (or on the > > general idea). It would be great to still have some of your input. > > > > Let me know if you prefer to read a fresh new version otherwise. > > I am very sorry to let you down, Peter, repeatedly; but it is now very > clear that I shall *never* have time to review your patchset - I am too > slow, have too much else to attend to, and take too long each time to > sink myself deep enough into userfaultfd. Never mind! It's just that I'm kind of obliged to ask for your opinion as you contributed part of the idea while you are also the shmem maintainer. :) So that's what I did before I start to bother Andrew (since I know Andrew is 100% busy.. that's also why I tend to not ask Andrew for review pings as best as I can for all my works; while Andrew can chim in anytime anyways as in the loop). > > I realize that you're being considerate, and expecting no more than > a few comments from me, rather than asking for formal review; but it's > still too much for me to get into. I'm actually even be prepared to receive a full-series NACK anytime. :) To me it's more important to have the right direction first, as I didn't receive that during RFC so I moved on, assuming no one thinks it wrong. However it's indeed true that you never let me down (as far as I see from the other discussions) that you do very in-depth review to hunt down any single potential risks you may have noticed even in an rare error path - that's just too attractive a reviewer to all the patch writters! > > The only reason I was involved at all, was when you were wondering how > to handle the pagetable entries for shmem. I suggested one encoding, > Andrea suggested slightly differently: Andrea's was more elegant (no > "swap type" required), and it looked like you went with his - good. > > I wonder whether you noticed > https://lore.kernel.org/linux-mm/20210407084238.20443-2-apopple@nvidia.com/ > which might interfere. I've had no more time to look at that than yours, > so no opinion on it (and I don't know what happened to it after that). Thanks for the pointer. Looks like there'll be some slight rebase work and totally orthogonal on the ideas, then we'll see who will do the rebase (yeh probably me :). Hmm, meanwhile if that's the initial versions I might go and suggest a renaming of pfn_swap_entry_to_page() to start with pte_swp_*() as it operates on swp pte not a pfn. However probably too late for a v8 series so I'll give up. It also has mentioned something like "special swap pte", hope that won't get confused with what this series is proposing. We'll see when it becomes a problem, so far seems still okay. > > Please keep uppermost in mind when modifying mm/shmem.c for userfaultfd, > the difference between shared and private; and be on guard against the > ways in which CONFIG_USERFAULTFD=y might open a door to abuse. Will do. Then I'll move this series on. Re shared/private, let me mention one thing just in case for any use of peace of mind: the most dangerous place for uffd-wp+shmem should be the UFFDIO_WRITEPROTECT page resolving ioctl when we want to re-grant the write bit to ptes if needed (for minor mode, the danger point is UFFDIO_CONTINUE instead), however it should be even safer than UFFDIO_CONTINUE as UFFDIO_WRITEPROTECT never grants the write bit for real but leave that all to page fault handler (in change_pte_range()): } else if (uffd_wp_resolve) { /* * Leave the write bit to be handled * by PF interrupt handler, then * things like COW could be properly * handled. */ ptent = pte_clear_uffd_wp(ptent); } While the newprot will never have the write bit either afaik, mwriteprotect_range(): newprot = vm_get_page_prot(dst_vma->vm_flags); The last risk is the dirty_accountable trick in change_pte_range(), but as you analyzed in the other thread, userfaultfd never uses MM_CP_DIRTY_ACCT, so it should be safe too. Thanks, -- Peter Xu