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 04B5CC77B72 for ; Mon, 17 Apr 2023 11:27:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7DEF38E0002; Mon, 17 Apr 2023 07:27:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 78F5E8E0001; Mon, 17 Apr 2023 07:27:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 656D98E0002; Mon, 17 Apr 2023 07:27:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 571988E0001 for ; Mon, 17 Apr 2023 07:27:30 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 25FF71A0549 for ; Mon, 17 Apr 2023 11:27:30 +0000 (UTC) X-FDA: 80690657460.23.4DBD72D Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by imf17.hostedemail.com (Postfix) with ESMTP id C54CB40020 for ; Mon, 17 Apr 2023 11:27:26 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=iJ8T0QKB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.50 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681730846; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=T1bjYOZ0+WFkX3zMO2+p0oL2JA0K0j319E8cjNoH3SQ=; b=Vm1GL7p6Q+M2x0pYLHAx3fxmCVG2aJ6p3xhO4Oa2SnUPVLn80ghq7suCOTbcZzQCHS3dQh q5d4/upZkcVYCVJLJDOj6cCAUTVxdxq8IP+7vpsQzx+6Y22N2LCnHkSQtHtN2M729gGpAA VZAY+OdaO/Hnn0UhFiMDNYJGQU/goQ4= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=iJ8T0QKB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.50 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681730846; a=rsa-sha256; cv=none; b=YnuIIoLUqor6wtbSKjZ2LxeUJ/qtLQgHlIkctxYDOXwVtieEDuAsSLQAv7aQPnNi5nSHH/ L77PFFb5iuE38/KK40Bw1xtjItqdyfMI9ct5rw6NXICMENnVe5oHRqaJtj3x4m6VWOPFfH gs7zSpuphyJddGPHH7+FpsTLf2H42+s= Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-2f27a9c7970so1362032f8f.2 for ; Mon, 17 Apr 2023 04:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681730845; x=1684322845; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=T1bjYOZ0+WFkX3zMO2+p0oL2JA0K0j319E8cjNoH3SQ=; b=iJ8T0QKBqr0mm2B+ByRi/km6mBfPBPFP+G0Ah/RNFPO50HvSIryJeXEpglA5ysuQMN 3424CMWcaQkffQS4XPgTABCKtuEUsQPxy9pOwqSYwjLebtqOeBLsFWN/DQDch0uHyOYt gYYot8hUgSJlpImrN3+9F1dZBDgqcMv57NZeAXjFY7cyjcADnbvtcq4bCSeNSsbFhYHI sCO43GjLGvm4F6CVgTQNSaqtpRxqdtvlkQv6FDp2LjyQc/W9C++QpIkJScxG3hqvuvRV BcpjclI+vUxGFoEsITwTiA9RK81fxd7kSMaBoB7H5LugBy+UHO3ioxqomPecbiIBSwBJ H8hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681730845; x=1684322845; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=T1bjYOZ0+WFkX3zMO2+p0oL2JA0K0j319E8cjNoH3SQ=; b=YQkIyU+Zok4128XZeziT8hDcSJYVIQVYep9Ej9ODDcZ6YJuso3FVQRsLnIP1quK66/ iWwEJqkSDWEjYgGz3+wTnVoTlr9BDz5YL2RBScfqxbmNdC4310xKsfLCF4+dW1Ids1RZ rC17kYSyeNWnN4NjFybU2VjQunr8M7FyYvmCQELreGc8bzukYeJh7G1LoyidzGxrtx88 MeHLtTr/j1nBNA5YkWVuQE74Qd418w1NYW6sfngBjAq+LxRSwy6U9HDMcriCW8ayld48 2qluNEVD9D8OsHml9bfgyx2wy6h6AF+RPeqiRCw61+NionJUQfouTA70VhvycVr7kYFr 2BOQ== X-Gm-Message-State: AAQBX9dT+zHbLoY7bJD/y/fT2grJIpA3FOt2l8QKsx9HP1M+oae55l7h UZb4LrKFjKZSQxzVkUTOB0Y= X-Google-Smtp-Source: AKy350ZNtknwYsgyT9D24QijtMkYk8/hy75MlISQ9kZqMOVw2VRsKIIhnRMvUrL+KiinweLLr0sqnA== X-Received: by 2002:a5d:558f:0:b0:2f9:9f6f:e4d with SMTP id i15-20020a5d558f000000b002f99f6f0e4dmr3102635wrv.39.1681730844892; Mon, 17 Apr 2023 04:27:24 -0700 (PDT) Received: from localhost (host86-156-84-164.range86-156.btcentralplus.com. [86.156.84.164]) by smtp.gmail.com with ESMTPSA id b2-20020adfe302000000b002fae2a08089sm1610694wrj.70.2023.04.17.04.27.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Apr 2023 04:27:24 -0700 (PDT) Date: Mon, 17 Apr 2023 12:27:22 +0100 From: Lorenzo Stoakes To: David Hildenbrand Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Matthew Wilcox , Jens Axboe Subject: Re: [PATCH v3 4/7] mm/gup: introduce the FOLL_SAME_FILE GUP flag Message-ID: References: <2feedd2bad6fd1ec4bc4639f9d9012c5ae2faf1f.1681558407.git.lstoakes@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: C54CB40020 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: paubf4ceukwtsgzmqrfmrm5o3gyw7oe7 X-HE-Tag: 1681730846-91786 X-HE-Meta: U2FsdGVkX19/zXNAnwZ6/OSXcxtG1lzUPw5Yu+kUUuGYyjeVDC4o2xWK0vaNpwMEkBF7gKfWZlET5+4k60HJmNLoAwG1apO7okdfHZnIkrxVQPFiGSCX3g7pOjWH5EjYte9zA193QQOgzQDK/0ISMS+X+46gzxcIIcpRkG64aaT/V+Td7QXmzPT/ObRzc4RoZ/KITKNhHGmzZeyhpVisuG/5xv1tfa9fHEF41hh1+DuKQOQTyC6RqUR+HLrnGd2SbCI9BnpjyL8XyBg/NBlzIQjnI4JC751ilnmvqINHrGTKzU06H+7jSGIO1KGEsmwP6cNoRo+8QTefChiDvKSPMUY074YxKW2D0m2XibS6DSU/24I++Y73TI8hlq1kAWQKpvJu/z9Dt0kEoGXr8M8pibWEgDUhkWaJ2bplCd4R6yXl6cCBEIviYuy579cK5jWeC/MdeFkJA7RXshMpgSRVqNS0KeAN0IHOQ2YCuJfkYsaFACBl73eXtbSxnnRgkQYYrvm4oHx/7f2dAEt9d0SZghWcGdOyDAK2sdnQWtf4jl8cG6YJ89hcZTvRlNNC0TySQBmNkwEPUd/YWdsyOAtuR9WdE5d28xVSqHpzHFgcaKB8gfhMHh7qLCw/rMfeODtkERl+Ys1J64afDYQWUF97ZW8cmLR3gi5C4278R6TzxyWJBj76Ref6KHEcuA4/BfogFIX/oPROozLMcLqMNxMB/K4ndJaMriDgnDOp8pL/SlkcyEVExgu7JGUBvBnXxN0y7+UinUqSVFIPGYOghap4X7eIivOWmrDyvRzZbdKAcqWpQHtCTvfh92AyMAbY3Flhl0axa15kyaNKnvU42bcNs/NYWwEJzJ776yiJ7DuKOkUfAIk/xguUGoF+aDI+lujFxaSB1D36X4yg+zJHscREhtimzvIy7CJK0r9MCTklSyOLopWYT6kXu5IPhK/yCCT/XchqDCCDlBsvMQDlLcm dH+BdG8V KwUdW3jemk+ocRCXPrtXmrP8zpkQSgd95W8JmCmAZBt+bZgIgFiqKhU8PAx3UtWmkQKVTSOGFN1xp2NvtlQaoIwFPVCh7PhYv1KG0cjum/Yj6QCPYuYkp22WIkCSiYXHrVqj3Oe0NZCf9jOuitHA3MTp7D5Qh1wrdFhLD24eGeev07ebg/Ct2w1Dkr9dLhsxVNlnA0hvcZ75Vv8xlsxHBHS0/XrS0HMoRokFDtluWNkgzOErrFBLBizk/biVB14fE6r4gPXCYtGWnkNPQxZWQ7E4aN8cuOkZ7fnr0AyMurp42W8gI3BYMx3VBMESKOVa7tRQpRKjzgXfAu4eF9Lvn3/bXNZ+U+PQjkrgkqY5Z6ExZ5V3ZJNUStsN7k8lx2WZcWwPFmvj++s4ugV4GRtcZDalmCpSGqe/cMligkQRdOmc0lecKAHKSv4XqQJ1NgQY2Yd0jihHyT1CZSJch2VXKBfz+HxmRVWfr10qp 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 Mon, Apr 17, 2023 at 01:13:58PM +0200, David Hildenbrand wrote: > On 15.04.23 14:09, Lorenzo Stoakes wrote: > > This flag causes GUP to assert that all VMAs within the input range possess > > the same vma->vm_file. If not, the operation fails. > > > > This is part of a patch series which eliminates the vmas parameter from the > > GUP API, implementing the one remaining assertion within the entire kernel > > that requires access to the VMAs associated with a GUP range. > > > > Signed-off-by: Lorenzo Stoakes > > [...] > > > --- > > &start, &nr_pages, i, > > @@ -1595,7 +1603,7 @@ long faultin_vma_page_range(struct vm_area_struct *vma, unsigned long start, > > * We want to report -EINVAL instead of -EFAULT for any permission > > * problems or incompatible mappings. > > */ > > - if (check_vma_flags(vma, gup_flags)) > > + if (check_vma_flags(vma, vma->vm_file, gup_flags)) > > return -EINVAL; > > FOLL_SAME_FILE is never set here, just pass NULL instead of vma->vm_file. > > > As we're not allowing to drop the mmap lock, why can't io_uring simply go > over all VMAs once, after pinning succeeded, and make sure that the files > match (or even before pinning)? > > In most cases, we're dealing with a single VMA only, it's not like the > common case is that io_uring pins accross 100s of VMAs. > > So I really wonder if the GUP complexity is justified by something. This is one that needs some input from Jens I think (added to cc, for some reason I didn't include him on this one but I did on the one updating uring to use it). I agree it'd be better not to introduce this flag if we can avoid it, intent was to avoid having to add complexity to the uring code when we're already iterating through VMAs in the GUP code, but as you say it's highly likely most cases will consist of a single VMA anyway. If Jens is OK with us iterating here I'm more than happy to respin without adding the flag! > (removing the VMAs is certainly a welcome surprise -- as it doesn't make any > sense when used with FOLL_UNLOCKABLE). This is a product of reading the GUP code when writing the GUP bit for the book and wishing it were more sane :) I suspect I'll have some more patches in this area aimed at marrying the disparate APIs where sensible to do so. > > -- > Thanks, > > David / dhildenb > >