Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 20 Apr 2023 12:31:41 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Lorenzo Stoakes <lstoakes@gmail.com>
Cc:     Pavel Begunkov <asml.silence@gmail.com>,
        Matthew Wilcox <willy@infradead.org>,
        Jens Axboe <axboe@kernel.dk>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>,
        David Hildenbrand <david@redhat.com>, io-uring@vger.kernel.org
Subject: Re: [PATCH v4 4/6] io_uring: rsrc: avoid use of vmas parameter in
 pin_user_pages()
Message-ID: <ZEFa3YO+0/HZ3Hz/@nvidia.com>
References: <f82b9025-a586-44c7-9941-8140c04a4ccc@lucifer.local>
 <69f48cc6-8fc6-0c49-5a79-6c7d248e4ad5@kernel.dk>
 <bec03e0f-a0f9-43c3-870b-be406ca848b9@lucifer.local>
 <8af483d2-0d3d-5ece-fb1d-a3654411752b@kernel.dk>
 <d601ca0c-d9b8-4e5d-a047-98f2d1c65eb9@lucifer.local>
 <ZEAxhHx/4Ql6AMt2@casper.infradead.org>
 <ZEAx90C2lDMJIux1@nvidia.com>
 <ZEA0dbV+qIBSD0mG@casper.infradead.org>
 <c94afa59-e1b9-d7b0-a83e-6c722324e7ef@gmail.com>
 <5e4a23f1-c99e-45d6-8402-6c2df8fa06e0@lucifer.local>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5e4a23f1-c99e-45d6-8402-6c2df8fa06e0@lucifer.local>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?TSBso2i9mvH6W6WoQroNaNG2bfiujQtgWBpQujKSEpxl3EUPfkXgTBbr116p?=
 =?us-ascii?Q?AEZ1pOSh1v5lwfbtBTVWYwnNhMqB52ZMppZ7kXUTEBIG7Wjx6JdGFhITjOVS?=
 =?us-ascii?Q?J1b09WZmNWygtdIn+rH8Gb9kd+KkpZuQ2jzf9Xil23eF7cmI9uJNEw6vDjNH?=
 =?us-ascii?Q?rj5gU4oDjKvi5jqFW/FZZqhqteS3hsXL5D5wbAbMbkx/EbkcseMG08gBALwc?=
 =?us-ascii?Q?DrGxPIIAB55/l5J20Kc230biuS6mTucDbjMKs/fAP+SUToJYf+Hp860ywggx?=
 =?us-ascii?Q?ivEjP8W5NnxB3bRGcJ23rwMaC1r4CiG67FBL9NkgoF08IIU95YNsxjYanN6U?=
 =?us-ascii?Q?0mJtAy7y79Xl9ECg7RolsrijZqYqqjPIsXzG4rgXIpLVNj41J1hlrAsa9QxM?=
 =?us-ascii?Q?n59ybM7eBpfdIEwJdtjjwLhzyjDmWf4qkf4LbGytukVYGxV0Xv750rvZrmdI?=
 =?us-ascii?Q?IUOoT6HAl43NnWBcRkXME3/VgOEGpYmQH7SUaFVubg7KRMFLSIq/5WFpGjvo?=
 =?us-ascii?Q?KQpGF9yzZiVrCxWiSdpKVos0nOxQZGt1Zy+wS46kp+SE1WMsvuYaF8Ccb4LM?=
 =?us-ascii?Q?f5aB3UGlInA2eyN9tXD7ZYT0LsjVqQvVi26oRLmQPwoSDC8eGyJwpKY7SiKJ?=
 =?us-ascii?Q?tvEcUCxCyNmb2gf2gPVoWXC+wWx6/jWt7SJHmpTAYFhu7huuBlkFPUpDS0K8?=
 =?us-ascii?Q?11MXoE2SpDe3yrrdRwKPax9kjaGdrY7m9j6ecQfO5KhIqPnCAVtcdeI0O5PS?=
 =?us-ascii?Q?ZP4mxBoJtl5HPbq4fBmNZdIY5kCg7wrGt23hqpJpXBNI6aP2+41l9N39MK8p?=
 =?us-ascii?Q?Vj7dWKVavelOL95h+WEAFGi40M6X7MMgTov2ZO1G6Khr/qY4r/YRouZw4jUt?=
 =?us-ascii?Q?1H5KKAJfHa+Z6BdWHH5efVKjHfQXj+B2ElXXM4bSpFOgHNNMHK9IuJYmZUlC?=
 =?us-ascii?Q?nsTdEBzRY4VbNyDEdZ5l5NTjuuwFa9kRtplh55YIRQ1z/TTD7uPfHbdMD3CG?=
 =?us-ascii?Q?SIQYnI0Wvxbv0I5Jszsb1CVhMc8NYH/U7ijLoeFilHKA5pCjLwuOAvB3d6ib?=
 =?us-ascii?Q?xQrcAeWy99rLjRpjsh0meDoIyt/ylAAYz2W1QLmdi9mcv+IH6oYJ8xPg88Oi?=
 =?us-ascii?Q?JpCOxq+4E+RifNb0jp6xbxH1PYuTwdMQr84yNlEvqq6Nkk6V9ykI+rb9ZZ2o?=
 =?us-ascii?Q?g2YKJi460D/e2sz5EdVyshjUuuwv40MFmoaLF3nnP5T6LMwp2JlZCcG0K+vM?=
 =?us-ascii?Q?F2l4RmVESkDfsKFc2FuJ1jFb2+Rzy6/zSyrocwKUJCN9ULmxwH/PNvtx/7VV?=
 =?us-ascii?Q?HuyS9uZdkzIZ2OZ2UEOXhPXGhB59Jpr022aa1Gf5WOV4xz2VfZT3qsV6icGe?=
 =?us-ascii?Q?jcl+cAgY+DRdBn3e/diLfakt2ANk3SH/v9Pfgsrloq+rhO2hahrWg0oqeUqQ?=
 =?us-ascii?Q?Gm6scLL8GRdr4h92d3QAgcD2UtwJGwmPbh/VfPFBfj9GQeSykF+eZPrx/OF4?=
 =?us-ascii?Q?ty0dORa3wh4DffVvyaJVkbvXKh+obDe8VcG5M9iV1eG786j6XBk6MLnWz7wT?=
 =?us-ascii?Q?yVf4baIykXefCmnSWnvXgIOWZO6h7DiUtwYwSttD?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 18638c1e-e81b-4326-9917-08db41b457d0
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2023 15:31:42.7773
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: x9217FtAGwNl6BmOulaIkJSFbdPbQH/BByTSsR+YLvoTPvk47GQ4yvuSLRqI9jOy
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR12MB5219
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Apr 20, 2023 at 03:19:01PM +0100, Lorenzo Stoakes wrote:

> So I guess the question is, do you feel the requirement for vm_file being
> the same should apply across _any_ GUP operation over a range or is it
> io_uring-specific?

No need at all anywhere.

GUP's API contract is you get a jumble of pages with certain
properties. Ie normal GUP gives you a jumble of CPU cache coherent
struct pages.

The job of the GUP caller is to process this jumble.

There is no architectural reason to restrict it beyond that, and
io_uring has no functional need either.

The caller of GUP is, by design, not supposed to know about files, or
VMAs, or other MM details. GUP's purpose is to abstract that.

I would not object if io_uring demanded that all struct pages be in a
certain way, like all are P2P or something. But that is a *struct
page* based test, not a VMA test.

Checking VMAs is basically io_uring saying it knows better than GUP
and better than the MM on how this abstraction should work.

Jason