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 848DCC77B72 for ; Thu, 20 Apr 2023 13:40:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE128900003; Thu, 20 Apr 2023 09:40:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B6A52900002; Thu, 20 Apr 2023 09:40:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A0A9B900003; Thu, 20 Apr 2023 09:40:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8EFAD900002 for ; Thu, 20 Apr 2023 09:40:08 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 16D201A02B9 for ; Thu, 20 Apr 2023 13:40:08 +0000 (UTC) X-FDA: 80701878096.06.25B1B80 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by imf28.hostedemail.com (Postfix) with ESMTP id 0A205C000D for ; Thu, 20 Apr 2023 13:40:04 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b="JGy/6vdl"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of asml.silence@gmail.com designates 209.85.218.46 as permitted sender) smtp.mailfrom=asml.silence@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681998005; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6+FbR3f35Ea1Q5h4PMa66mgR6tADBXSDeYnQHZVkU7M=; b=vAbLxKKyP6qSZJDe3wQBs2M+kFM33GTvpx0UZWTteDo8XjRPJZLX37Bulmz7FMT2zZAe+H IdYjmLQYwrHEzUYzNhaJ5YLALLoCMVmedmMgAz69Slw4FcaKUWFzae1r3agv80QhwCD9hf WvPQVv5m2xezztGsKreRm94nL4/T+38= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b="JGy/6vdl"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of asml.silence@gmail.com designates 209.85.218.46 as permitted sender) smtp.mailfrom=asml.silence@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681998005; a=rsa-sha256; cv=none; b=NLDHx2gMUNXeCHILE8aD1tLFoy12sYdA2Dhge3sMnexIBdudW0RCTcLDpP9rNHC1kx4qHt 4tRHIPwbYU15PIFm9YFMPJgWcbA/eVXlF1My+gtKTYjWbuW6O53PXxGLiqLi0jopoq3JNl bNXcLRDBsIn0Tk25KFPZbc1mioKATCY= Received: by mail-ej1-f46.google.com with SMTP id dm2so6426627ejc.8 for ; Thu, 20 Apr 2023 06:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681998003; x=1684590003; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=6+FbR3f35Ea1Q5h4PMa66mgR6tADBXSDeYnQHZVkU7M=; b=JGy/6vdlhycjs0A1ZxdvEqVuHFFrwFP+hCc/vnEOLzg9Etz+bmipAQ+qZxhjfZ/ecp kq47QHxN808TUrxwXfA+WAtH+B+XgAuKWNPFHuCpDUcUBk26hRcMOY279DMz9WwSOrJe oS6v5lfQ8/Ze8O0tgVgiGIKs2SeG1kFSFIJyqSGMtNLlM6qiFn7gqqthumuqMmOjAVFm fuWa9om+ulIuvUaAbBfLjsLXzwp8pW3b5PzEAoZyn51gVICu+2WlwiNsp7pTnL0Fy2s7 hg9qgO57OBB3dQ8ld/02kJj5xu6rGaPO4lT39bO2rZTamRStnI+Znt1uY3ZdYvztULHL s7+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681998003; x=1684590003; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6+FbR3f35Ea1Q5h4PMa66mgR6tADBXSDeYnQHZVkU7M=; b=XC1Yl6Ixiswk6yNumkEhdTJPOnV9Yfm/FduY+l0xMsIc61P4XEiK8fWiRzzgNcShGG 1zroMAQyBwudfE6ZKqWg/YhMCIrS+q8iaPxSj/XmWhZT1btz8LOwijncRNsMFM6TDea5 VE6TRGq0eWhuWHMx+XIBXXwcxDxg2B3OryJSwA1aO0xXU3Rgoxxb+htNay08edgEeGDP 2MDd99kmT+EYQwEygVm+02+zk7shXNSY5gpc2OxVNQ6t/2/+TyM/G45nQW0lmyDCkUhK xaLS5Qc8wDNigQIpQ4DIsaoYW0q+BpCZ7pUrleM1p18k50Hf9DlnM4R+dY47LgOSa723 Zj1Q== X-Gm-Message-State: AAQBX9do1fcKxOQfWIEruH9vzneQHGdr/8DM0HH4S29PWpUlcnolRwSf f7cll9NrLietIF0sFuK9Esk= X-Google-Smtp-Source: AKy350aO8sDsBSOJ20epFjGg6Rn4Rg3tRiQyvP4oz3yfAvPZtWgW/5hYn1Z12PeDVF6InuQwvfMr7A== X-Received: by 2002:a17:906:2ad1:b0:94e:83d3:1b51 with SMTP id m17-20020a1709062ad100b0094e83d31b51mr1372015eje.23.1681998003188; Thu, 20 Apr 2023 06:40:03 -0700 (PDT) Received: from ?IPV6:2620:10d:c096:310::26ef? ([2620:10d:c092:600::2:7db2]) by smtp.gmail.com with ESMTPSA id r20-20020a170906705400b0094f05fee9d3sm732721ejj.211.2023.04.20.06.40.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Apr 2023 06:40:02 -0700 (PDT) Message-ID: Date: Thu, 20 Apr 2023 14:36:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v4 4/6] io_uring: rsrc: avoid use of vmas parameter in pin_user_pages() Content-Language: en-US To: Matthew Wilcox , Jason Gunthorpe Cc: Lorenzo Stoakes , Jens Axboe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , David Hildenbrand , io-uring@vger.kernel.org References: <956f4fc2204f23e4c00e9602ded80cb4e7b5df9b.1681831798.git.lstoakes@gmail.com> <936e8f52-00be-6721-cb3e-42338f2ecc2f@kernel.dk> <69f48cc6-8fc6-0c49-5a79-6c7d248e4ad5@kernel.dk> <8af483d2-0d3d-5ece-fb1d-a3654411752b@kernel.dk> From: Pavel Begunkov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 0A205C000D X-Stat-Signature: wyhism6duhj1agw6p8pnmdxptwx51wnq X-HE-Tag: 1681998004-271699 X-HE-Meta: U2FsdGVkX19IVuwUjDcMY4gaN27Bb/3hUucXqVlJyFAlF6JuVoinI8QovC9RGpj6yH796u0xDkG+V6MhvVAj5FxzoeAWG1rGupK4R5wOY+pemLEB88CKIhVSc7HhgG1bJvvaxpin7KXyB4KfgVMb1vIOhmdcEbPtlwvzOLxogDzYg266/PMLmiav5nKwwSj/ppRdHgU9SZzcERmBDcBVM5L6bu+V10QycWyceRNbVgGveFNozWjsmd9N4PlBBRY8PQX7wCbN2XnkgUaH8L8ZXkfFQ+KC1GXKPK0ZgPH5xyb+PV80ew9pyj1eWiWr+3uKegqNTXtbQ8O9TOaDgGNSWGLXb/DeIpjZJW8TRJ1Zf0jIUb8oAIdZNrvPg8Imu7dzkBznqI+rKG68Y10+C1lOsU+ziRnco79Ar88MhvEkbTS7a2gHxEHotkeRIKjpHJW2VghmzZREYHlNCaR/Lr+I3xrcFKIkLYbrcEJWtaPc7K7vCOUQblGT4Qh9ME7mDQJ5l4gJg9g1hSWK5yCg2gvwnHliKAq4AP9oEk4EWHVPKf+ZXL1IzkghiMZjzD7RbXLLEG2R+aOzLoCdR3WebGxshHhU53Lgpm0b4U7epmojBQj5vQWcmperqq7pB/9RIQOLXomUMZ2gYExVlUGyIlVmrFkkZrCwffDnZZ0PE7laWuZ0fnX89ZhEb+33wHTEVPjUN7OK/iB7Xs0pCFouZvIvzoPeA+SM3P2dLIzAMk17fiEKqaOt2SQMszD0kkQgzVdYfhPHGM64L9Zfk2ofVsLFcVi7B6ZRskAVxHv6cN1kkBVX011y/ixFTCFGUagqHWGcf1trqd0N8ucYejcBNcrqjtRuGUR7SpfW2KzdxG86BKuwZevgjz/8Sf+AAjGMQGhmyk/NkxnxxvO6lh9rA2CG7E1WETv4YV50CcuNBBsYq3GQvCRb/QqFEdbISa43jqskvyE0Gxz1UlfW4IP2M9W fA5JL5mO 2N/npbYjMcqby3gruZCVYZ6z0YvC8TxuepTR4ctjXs2JskN5bkfRkhcnVsAW/FDh+KkfDw+37VkbRfsG2Vv5Vpp3iAnO800DYtGGI1vlJauUXd9PR8mumF0MmFYpbugr1lZjsyth0l2i8F3ZeEFZHcz8qgXbsSaeK/TKH4TFvcIeGzx5dCcxwNf4PRPu/ahgofXegbPW6GNnvpYiyfVRg28rG1Z4VXzslGwP/uY+2kUCKB/bj1F2ByS9F718/QzOGGFGk4WXI1DSWcbKARRdXWHlyJXrd86caB3+uCIq8QClu4rX+1Y9vNKsmdmDzP9irOA3qsujJdbxDLmtETEWIIJ2jMaiF4gvjBkKS5fSw3Rjd3mKmxc7xdutiAHcFbRgLUp7Ktpo2eZuqKLIqHmo8+S6G+Yz3/ZOeBYV6shwWpTOaszVR6QVOqC/KoJo1JLdDepbAG6Hfl5oV2EaM5ZmhXvU8sjp4kyZa0f8CuiTlgDkt/5F7Q6ZE3vTVs6juF97zUAyp+hLl/4LmucHT7OU7gL89hXc999QsVevGCEaHqscGr9LWddcMqTIJPO+AdeOhX8hap3NJy59JR++DdaRjM0PpALXGMNwsXXNTYY4FybDFmhk= 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 4/19/23 19:35, 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. Excuse me? I'm really sorry you "couldn't understand" the explanation as it has probably been too much of a "mental load", but let me try to elaborate. Because it's currently limited what can be registered, it's indeed not a big deal, but that will most certainly change, and I usually and apparently nonsensically prefer to tighten things up _before_ it becomes a problem. And again, taking a random set of buffers created for different purposes and registering it as a single entity is IMHO not a sane approach. Take p2pdma for instance, if would have been passed without intermixing there might not have been is_pci_p2pdma_page()/etc. for every single page in a bvec. That's why in general, it won't change for p2pdma but there might be other cases in the future. > 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. -- Pavel Begunkov