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 596CCC77B73 for ; Wed, 19 Apr 2023 18:45:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B18AC6B0071; Wed, 19 Apr 2023 14:45:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC9006B0072; Wed, 19 Apr 2023 14:45:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 990FA900002; Wed, 19 Apr 2023 14:45:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8B8326B0071 for ; Wed, 19 Apr 2023 14:45:11 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 46418AC384 for ; Wed, 19 Apr 2023 18:45:11 +0000 (UTC) X-FDA: 80699018022.26.12E74EA Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf10.hostedemail.com (Postfix) with ESMTP id 5E063C002D for ; Wed, 19 Apr 2023 18:45:09 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=bR1dkYt4; spf=pass (imf10.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681929909; 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=xfA92ZDWa3tFrZEqbNbZTNF9MWgNQXkklE0ML2qGCi8=; b=OTzkWPCGTL0rFPeYQY/6+4akDS5ctibOBBov5v83LOSzCwm7IJkR8TQYjf/abNknAO6ZfH Wg90wogJROcYoxKcVt2RkOmfEhdzyzYV6dZOMq7TH2/xMpzl/mO7rmiwiVHuaL4bAxRgtj oSf0tMmvz9FOou6LWD3XbeHnp0/BjTU= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=bR1dkYt4; spf=pass (imf10.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681929909; a=rsa-sha256; cv=none; b=8CtX7kLzq/FvJ0wlsYiRtjZO9Zg0uBHbomYTv1LsdQahU8zWExI8l2uWbujrdFRNtEAA2+ izQU/yA6Z4LOLjDaa/ZSAQl+zseQ+eW94RHCN8KCBRyzKfB/AF8Nr6j/LcmEsEZN6eZWet 9n7R7MyCBM3p/ZnxK0htx9l5WjGmrjI= Received: by mail-wm1-f41.google.com with SMTP id v20-20020a05600c471400b003ed8826253aso2632754wmo.0 for ; Wed, 19 Apr 2023 11:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681929908; x=1684521908; 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=xfA92ZDWa3tFrZEqbNbZTNF9MWgNQXkklE0ML2qGCi8=; b=bR1dkYt4Ga9qoGYOjrE1JO+w2XRcZejVe/7lGlkWQI19Ddb80Wmyr8oVnJCBh2EJr0 kPBHPHrumApNAfxu4PjCNlzv2fuKy1Sh1ZrkJWc/cd2mjQN1gStgblOU+zk6erYMDf7/ 5C+iCLszgCC15OQ9vSQI7isnvi51p78CWC54EPuJsV4au/7yOE6d0s6Ehl5bN456mSmZ gQLzgoUnjjToQNvCFSGWoL3h1noAIP/5ETYQa+IIApUcHT4uTOsqrvKcM7KTmTC5J6HJ LAujbpJDDEbJqtXqw/AbLlLXdzPInzR/HsFpleDe5mwl+2aLNeW9NBqdQdEH1PT+PO5W WY8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681929908; x=1684521908; 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=xfA92ZDWa3tFrZEqbNbZTNF9MWgNQXkklE0ML2qGCi8=; b=SQeU/ToaAkkVEjOXXC8hy9Tlu5UFwv0CqYy4oix1aalx2sDUjuaygIpnP5Nsy320W6 Ppyh7wPsrw4BkVpjQwIJLohyZw2Wia+mwDJvnRsn08OL+ZOlfft7csUS+IYPGtZotfGG bwPrwY6+h7bIZwrNv7Jidf+XqMPv1NhoXUys3TZK65CX0iqRnAv566UzW3CyAakGG8dO 5btwSjzuAJdst0w6p10H10Z5fM1CuUUc6QHnsejKcuiAw3+9DAvq6s+ZFmNhvKpuGqLC T7th8XnVzNDN8Oz/6W87OP1HvkIzzicHXaGyq3RhclcMoZ6cQp8CgpfzrcOofVCsxjKg yaMA== X-Gm-Message-State: AAQBX9d2Pc2cB4GETMraGfHeWI0jp0VNJ4jp39bRVm9mW5XCw0ue+xjH t2q6g9QL+cP0Pm6Hw+qGszI= X-Google-Smtp-Source: AKy350aoV810DLoDWAD0ai0Hb41gGEXLSlJwB5TdjddxVt+yFuIRAfMXTSpF67oE5LJ4PfVb77lGoA== X-Received: by 2002:a7b:cbd1:0:b0:3f1:6836:5db5 with SMTP id n17-20020a7bcbd1000000b003f168365db5mr2707956wmi.5.1681929907613; Wed, 19 Apr 2023 11:45:07 -0700 (PDT) Received: from localhost ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.gmail.com with ESMTPSA id h16-20020a05600c351000b003eddc6aa5fasm3014514wmq.39.2023.04.19.11.45.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Apr 2023 11:45:06 -0700 (PDT) Date: Wed, 19 Apr 2023 19:45:06 +0100 From: Lorenzo Stoakes To: Matthew Wilcox Cc: Jason Gunthorpe , Jens Axboe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , David Hildenbrand , Pavel Begunkov , 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: <8bf0df41-27ef-4305-b424-e43045a6d68d@lucifer.local> References: <936e8f52-00be-6721-cb3e-42338f2ecc2f@kernel.dk> <69f48cc6-8fc6-0c49-5a79-6c7d248e4ad5@kernel.dk> <8af483d2-0d3d-5ece-fb1d-a3654411752b@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 5E063C002D X-Stat-Signature: zddjx58xdif8fr43fwtyfqizwqts5pty X-Rspam-User: X-HE-Tag: 1681929909-936156 X-HE-Meta: U2FsdGVkX1/o6LzxRd4dTjGFPUYy94as/qCXfVnoThriw6ZwcjSTsf7PLfwCr9Eyf+k1qnGAKC0GHsKSwhzenvqIHcTCyb/sVdqrz9D0txkMfObf5FUeeUJbitbIQZlRoMK8EejfDzMZCCsULdQo56O2/rgdtLp1ylwKpVGcfp6eCIwWKrR2zVcyUY3SKRgdiI30nPEgWb0jimckaksdV2YSJcLYgA06VhAIifWsKD1Kx4mwI2A4Z0kCCgzIHbG9LQCk5rjfzmEo+Msd3bRmjCfmAKOGznHbqeFW6ZoLh8iW36DH9ieMPsq03a+BjyZCx99DfJLpbaTFXteMQl4phUON4VC5lZck1cQUKj5MGcw9crzrYXRfDMaDxMMcdDvH0G/Crfmx2wUHt1dJVhRuhIzkLg3spxm5mqFxYMWW2Lh63cSNf6ZpIH0PmJYc9IIcayJNUusPA26FazOZzboxa5pxpT0J4CzfB17RiIdNdQIqtfJeZAnzXx7VGCTe8fSn0B5Oih7x5s1wsmptQGkTsn0IT3jth07EggIbuV71zf8AFP+1kPw6bjZojgJuLvtgift1MvO7ZxjSbnZGmIvgDoESlbL74S1lBx2ar4VsFG7Rn/EY9PUQoMaUSyzTgcVXFN0DLSjr+bPtFiuLKSHvW6ogF4DTxt9d0qSnOuckqNlpcURHAIPipOTA5kl3tot0n95UQ+NolLaGhQRzBB00VEhTkazg0j9E/s+jdBH+HQUdfeMGRVoaqT4/nKc3+2fnGymW1E+MeGEUAUcxXsG03D3KitpYeqdcQ+7v5FtvChn/lwLBpFfwarcxX6NgZM7Hzu/FYKppYtTOu7thv2VyZhHcnC+hNOP6KHCHmcwB+Ft9sGMDV4XFT4akBdEHAt6d7UmQNfCjqxocWIOCXismvvy7ak8JplhuekWIn/bBB8Uo3vCpmK0PrAvvYvUL98XHV7BrNH/PzRoUOB/oJq0 YuEdcXUy ezYFURPVkDv+xmda//bn2n8yeYNGx8idMCtmPbHG+C9/oqz7mD8h38gdw7UgFhU5xZ9x0I27rwlNKGp/Sdlzn75AJRqKCeTY+n+JPuB1IKXhlXl2h4DXMOnE8nISEebb+GXkgM4Gb4Bjhi5/7qmmfjeaHPhdOlV9eSTzd50DknGaOuWxefgQqoRiuRxjyG7CQQJMsykkHkk8glc40HM+oYqVYA3lfZJZFykwVH0+LQfp/SP29bETdR9ONRvGJpkLNzwPAcs0Pj4bK3A483F7En/pUR4jcMvJvukpVIJXveC63SnZEkTESyF8LUNZ1HGNxsZ6vClss9YfJY00fsVGkMYEC0xvdLSlKA4Sowb6Bs4+krX1ffkMvaFIJjyz/K68OILbovPxmICaDDC+5V1rvm6csUnYoQcs76kvKdk38gu/spVUd5/8EyaoJKeLLEuvg6P5dWChURR9Z5sYYTtBlOO4vyDop7N4FpnJzyUhj0lxZX+P5zbzZqbZmxoY5asUdreqVjyRL48S6c6lf3iujSRbrLQ0iiIOyYdiobSHyxruEWr0eozTiq0E4WvxodvYfCHEV8obCJ3LvWCo= 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 Wed, Apr 19, 2023 at 07:35:33PM +0100, Matthew Wilcox wrote: > On Wed, Apr 19, 2023 at 03:24:55PM -0300, Jason Gunthorpe wrote: > > On Wed, Apr 19, 2023 at 07:23:00PM +0100, Matthew Wilcox wrote: > > > On Wed, Apr 19, 2023 at 07:18:26PM +0100, Lorenzo Stoakes wrote: > > > > So even if I did the FOLL_ALLOW_BROKEN_FILE_MAPPING patch series first, I > > > > would still need to come along and delete a bunch of your code > > > > afterwards. And unfortunately Pavel's recent change which insists on not > > > > having different vm_file's across VMAs for the buffer would have to be > > > > reverted so I expect it might not be entirely without discussion. > > > > > > I don't even understand why Pavel wanted to make this change. The > > > commit log really doesn't say. > > > > > > commit edd478269640 > > > Author: Pavel Begunkov > > > Date: Wed Feb 22 14:36:48 2023 +0000 > > > > > > io_uring/rsrc: disallow multi-source reg buffers > > > > > > If two or more mappings go back to back to each other they can be passed > > > into io_uring to be registered as a single registered buffer. That would > > > even work if mappings came from different sources, e.g. it's possible to > > > mix in this way anon pages and pages from shmem or hugetlb. That is not > > > a problem but it'd rather be less prone if we forbid such mixing. > > > > > > Cc: > > > Signed-off-by: Pavel Begunkov > > > Signed-off-by: Jens Axboe > > > > > > It even says "That is not a problem"! So why was this patch merged > > > if it's not fixing a problem? > > > > > > It's now standing in the way of an actual cleanup. So why don't we > > > revert it? There must be more to it than this ... > > > > https://lore.kernel.org/all/61ded378-51a8-1dcb-b631-fda1903248a9@gmail.com/ > > So um, it's disallowed because Pavel couldn't understand why it > should be allowed? This gets less and less convincing. > > FWIW, what I was suggesting was that we should have a FOLL_SINGLE_VMA > flag, which would use our shiny new VMA lock infrastructure to look > up and lock _one_ VMA instead of having the caller take the mmap_lock. > Passing that flag would be a tighter restriction that Pavel implemented, > but would certainly relieve some of his mental load. > > By the way, even if all pages are from the same VMA, they may still be a > mixture of anon and file pages; think a MAP_PRIVATE of a file when > only some pages have been written to. Or an anon MAP_SHARED which is > accessible by a child process. Indeed, my motive for the series came out of a conversation with you about vmas being odd (thanks! :), however I did end up feeling FOLL_SINGLE_VMA would be too restricted and would break the uAPI. For example, imagine if a user (yes it'd be weird) mlock'd some pages in a buffer and not others, then we'd break their use case. Also (perhaps?) more feasibly, a user might mix hugetlb and anon pages. So I think that'd be too restrictive here. However the idea of just essentially taking what Jens has had to do open-coded and putting it into GUP as a whole really feels like the right thing to do. I do like the idea of a FOLL_SINGLE_VMA for other use cases though, the majority of which want one and one page only. Perhaps worth taking the helper added in this series (get_user_page_vma_remote() from [1]) and replacing it with an a full GUP function which has an interface explicitly for this common single page/vma case. [1]:https://lore.kernel.org/linux-mm/7c6f1ae88320bf11d2f583178a3d9e653e06ac63.1681831798.git.lstoakes@gmail.com/