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=-3.9 required=3.0 tests=BAYES_00,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 DF920C433E2 for ; Thu, 10 Sep 2020 17:36:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 034E32222C for ; Thu, 10 Sep 2020 17:36:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="CyoQUM+S" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 034E32222C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 13FFE6B0070; Thu, 10 Sep 2020 13:36:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C75B6B0071; Thu, 10 Sep 2020 13:36:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAA5C6B0072; Thu, 10 Sep 2020 13:35:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D03D06B0070 for ; Thu, 10 Sep 2020 13:35:59 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 89E91181AEF21 for ; Thu, 10 Sep 2020 17:35:59 +0000 (UTC) X-FDA: 77247854838.26.low92_120f7dd270e7 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 549511804B667 for ; Thu, 10 Sep 2020 17:35:59 +0000 (UTC) X-HE-Tag: low92_120f7dd270e7 X-Filterd-Recvd-Size: 5638 Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Thu, 10 Sep 2020 17:35:58 +0000 (UTC) Received: by mail-lj1-f194.google.com with SMTP id s205so9267134lja.7 for ; Thu, 10 Sep 2020 10:35:58 -0700 (PDT) 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=tV9NvYryEbzez94zd9hdsCWt3FfBuGGawTOfDap0eBk=; b=CyoQUM+SKXH6085O6WtByg3nDuki2CTSBORvYvwm25BqShZutFnNs6mSZACayZwSEH qcd6gDs3XmrAOcCBysWWLpsCbEXmLRDCQnQxo0ENK46fWC+ppV/l5rSOr47qH79HuDsY BAC6cJAHl7u65bYmrM5WLZPBZBfoI7ltEXEKA= 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=tV9NvYryEbzez94zd9hdsCWt3FfBuGGawTOfDap0eBk=; b=c6kmd38uoXm6lZf1ur2zCPZbGBlFH4BtoroNJhGLtQ6KhX9qANESRe7NyoGEYXPpZR CiXygaNh4Qj60TW9IAWiY9pjYI5gPohhjtsrzokyV7w2eehomV1i3vYeZffZli4dYb9j bA6ZeeYRB7BRN48bHYb/JRuL/FbsUrfick5viPQtbyPuSAZJJtn539Ya9PBgrgKzxGNM ozCw7QDj8D+GvCC9Ql18OVdEFzSHZ2EYL2/gILxXwIJj55uyrJoJroZ2g6aMnIsKbN2Q iu+pzt4Dz4qr940RQWY9YVLsssHLHFiKCifGDuXhjnSfPBpFgWuftgheyrFAJUoJXDkk z0rA== X-Gm-Message-State: AOAM532RNYEVy/vVLt6YGNSTJV1tJf+xlDNxrXbqauVmtoOJLS343bez 2Hi2ncxQTvdixMXrzkpCbeYxjyckNsDvyQ== X-Google-Smtp-Source: ABdhPJxIVzDr3nWGZZMh8G2uSXsDPQWqftWfhnHlJ6IlKR4wGCaatuFeQFy2OYYjljOgxXb8vqA+5A== X-Received: by 2002:a2e:97d3:: with SMTP id m19mr5120182ljj.296.1599759356348; Thu, 10 Sep 2020 10:35:56 -0700 (PDT) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id i12sm1495726lfi.48.2020.09.10.10.35.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2020 10:35:55 -0700 (PDT) Received: by mail-lf1-f47.google.com with SMTP id d15so4022084lfq.11 for ; Thu, 10 Sep 2020 10:35:54 -0700 (PDT) X-Received: by 2002:a19:7d8b:: with SMTP id y133mr4765702lfc.152.1599759354367; Thu, 10 Sep 2020 10:35:54 -0700 (PDT) MIME-Version: 1.0 References: <20200907180058.64880-1-gerald.schaefer@linux.ibm.com> <20200907180058.64880-2-gerald.schaefer@linux.ibm.com> <0dbc6ec8-45ea-0853-4856-2bc1e661a5a5@intel.com> <20200909142904.00b72921@thinkpad> <20200909192534.442f8984@thinkpad> <20200909180324.GI87483@ziepe.ca> <20200910093925.GB29166@oc3871087118.ibm.com> In-Reply-To: <20200910093925.GB29166@oc3871087118.ibm.com> From: Linus Torvalds Date: Thu, 10 Sep 2020 10:35:38 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding To: Alexander Gordeev Cc: Jason Gunthorpe , Gerald Schaefer , Dave Hansen , John Hubbard , LKML , linux-mm , linux-arch , Andrew Morton , Russell King , Mike Rapoport , Catalin Marinas , Will Deacon , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Jeff Dike , Richard Weinberger , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Arnd Bergmann , Andrey Ryabinin , linux-x86 , linux-arm , linux-power , linux-sparc , linux-um , linux-s390 , Vasily Gorbik , Heiko Carstens , Christian Borntraeger , Claudio Imbrenda Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 549511804B667 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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, Sep 10, 2020 at 2:40 AM Alexander Gordeev wrote: > > It is only gup_fast case that exposes the issue. It hits because > pointers to stack copies are passed to gup_pXd_range iterators, not > pointers to real page tables itself. Can we possibly change fast-gup to not do the stack copies? I'd actually rather do something like that, than the "addr_end" thing. As you say, none of the other page table walking code does what the GUP code does, and I don't think it's required. The GUP code is kind of strange, I'm not quite sure why. Some of it unusually came from the powerpc code that handled their special odd hugepage model, and that may be why it's so different. How painful would it be to just pass the pmd (etc) _pointers_ around, rather than do the odd "take the address of local copies"? Linus