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.8 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,URIBL_BLOCKED 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 D803CC43461 for ; Thu, 10 Sep 2020 18:33:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3BB2E21D40 for ; Thu, 10 Sep 2020 18:33:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="KlHKM3kh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3BB2E21D40 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 123A1900006; Thu, 10 Sep 2020 14:33:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0AF65900002; Thu, 10 Sep 2020 14:33:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6897900006; Thu, 10 Sep 2020 14:33:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0147.hostedemail.com [216.40.44.147]) by kanga.kvack.org (Postfix) with ESMTP id D0E68900002 for ; Thu, 10 Sep 2020 14:33:36 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 78BAC181AEF1D for ; Thu, 10 Sep 2020 18:33:36 +0000 (UTC) X-FDA: 77248000032.25.alarm40_1e03832270e8 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id 34BC31804E3A0 for ; Thu, 10 Sep 2020 18:33:36 +0000 (UTC) X-HE-Tag: alarm40_1e03832270e8 X-Filterd-Recvd-Size: 6290 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Thu, 10 Sep 2020 18:33:35 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id u4so9454459ljd.10 for ; Thu, 10 Sep 2020 11:33:35 -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=qxUvMosCQmqJOT3+XnukK6QXCPsj7s8SUCtblFuQCtk=; b=KlHKM3khaRQUhJpR9UdzFB5LWAQF17Brw1Ft7CKtiriIUBpvA7+djFgchHKossZjUO VhqJr4lFUYp9ylSJpdlZ0hFaIz/Ssta/iioJv0jWuQQR7zk9LpCYLPwRfEoZmfrs0FFc eJ9cpxyshw+kFNXrIvj9XAnDrbJSgUK0YSwsk= 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=qxUvMosCQmqJOT3+XnukK6QXCPsj7s8SUCtblFuQCtk=; b=HqEQW4VLe/b8uJBqBKvqL8+NVRCky5l0kJ+GdcTS5HE+ogmLC5U6ZPvXqFVz/QtI1N GTFLAtaeJuFS5FeUok6s9mgMgY3Vr683PJKFLiUw+qWYNoaTOa1BMIACQ7NIoJpxvLK3 PL7S0xoTN1XUlAdd0XZ1eklsw3pjRVC53bhQp0V389l45Nwg/wVfCD780T80HhVG/q2o weM60MJ11zIcDzv9LmtE0ihcqsha5xdnpZFYoXsV1ijlTrzGYUhrcHSysKObZgQgVENI D4NXzGbVvxxCMACh4ZsKgdnN0lpyLM1cKRliHzzMWX0PsuPGA1wZcorj5q0H9pUIc0Xg fR8A== X-Gm-Message-State: AOAM531bbs2xhzT/9CPIsYtnY3v06HcmNxFC5+Lp3sGwXmuqyYXtOoCX b7M8lHGbNzO+39b5kUI3Cm4q4v/nYIJipg== X-Google-Smtp-Source: ABdhPJz79XBKTN8gVZiPN4jYchp+s52xswysd+NXpr+a1qxqwj6+J+NVk2kJB+3re83TdpxkMlr63w== X-Received: by 2002:a2e:b174:: with SMTP id a20mr5088182ljm.407.1599762814165; Thu, 10 Sep 2020 11:33:34 -0700 (PDT) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com. [209.85.208.170]) by smtp.gmail.com with ESMTPSA id u5sm1528353lfq.17.2020.09.10.11.33.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2020 11:33:34 -0700 (PDT) Received: by mail-lj1-f170.google.com with SMTP id k25so9445957ljg.9 for ; Thu, 10 Sep 2020 11:33:33 -0700 (PDT) X-Received: by 2002:a05:651c:104c:: with SMTP id x12mr5572300ljm.285.1599762813344; Thu, 10 Sep 2020 11:33:33 -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> <20200910181319.GO87483@ziepe.ca> In-Reply-To: <20200910181319.GO87483@ziepe.ca> From: Linus Torvalds Date: Thu, 10 Sep 2020 11:33:17 -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: Jason Gunthorpe Cc: Alexander Gordeev , 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: 34BC31804E3A0 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 11:13 AM Jason Gunthorpe wrote: > > So.. To change away from the stack option I think we'd have to pass > the READ_ONCE value to pXX_offset() as an extra argument instead of it > derefing the pointer internally. Yeah, but I think that would actually be the better model than passing an address to a random stack location. It's also effectively what we do in some other places, eg the whole logic with "orig" in the regular pte fault handling is basically doing unlocked loads of the pte, various decisions on that, and then doing a final "is this still the same pte" after it has gotten the page table lock. (And yes, those other pte fault handling cases are different, since they _do_ hold the mmap lock, so they know the page *tables* are stable, and it's only the last level that then gets re-checked against the pte once the pte itself has also been stabilized with the page table lock). So I think it would actually be a better conceptual match to make the page table walking interface be "here, this is the value I read once carefully, and this is the address, now give me the next address". The folded case would then just return the address it was given, and the non-folded case would return the inner page table based on the value. I dunno. I don't actually feel all that strongly about this, so whatever works, I guess. Linus