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 0EBD6C77B75 for ; Tue, 18 Apr 2023 16:25:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B3458E0002; Tue, 18 Apr 2023 12:25:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 63C968E0001; Tue, 18 Apr 2023 12:25:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4DF3F8E0002; Tue, 18 Apr 2023 12:25:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 3EC898E0001 for ; Tue, 18 Apr 2023 12:25:55 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 005174024B for ; Tue, 18 Apr 2023 16:25:54 +0000 (UTC) X-FDA: 80695038270.27.A298277 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf18.hostedemail.com (Postfix) with ESMTP id F12B71C0013 for ; Tue, 18 Apr 2023 16:25:52 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=n2VCFbIA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of asml.silence@gmail.com designates 209.85.218.43 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=1681835153; 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=MvjA55Gc3aWxcMuhy2Rkbkg3pMI9os2W61bZ2H26VU4=; b=1KSruaUaKwKTTAD+z3+8Y23giqIH7/ouksVz46cqFP4p+gzj8MOy9eNog8nbQNagiIjqUA bwpsbGuqv/IIp7gkBFQjmm3WPqrULeIQQmDF5WKSp2fVAO4eyS5m+CD9aPP5/ODWqUo5lr 3+L5okEl+qPY5Zj5C9x2zTIqnIA8G3s= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=n2VCFbIA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of asml.silence@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=asml.silence@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681835153; a=rsa-sha256; cv=none; b=SOYneXKk8rNZXZIbsBryfuENpHcXbrw18MrmHVqPzi/dHHzbO7+Nqo4lvfKBwf+d96xgze TqM6XG8OeFsT/13WWSZuA1ceQk84c62Q6WJItS9In8OVcobqZSgozPJwV2QBLamp+WMggU fWhJiKeJSV/asRPP5c5uPSu3vUKATgM= Received: by mail-ej1-f43.google.com with SMTP id xi5so74668677ejb.13 for ; Tue, 18 Apr 2023 09:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681835151; x=1684427151; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=MvjA55Gc3aWxcMuhy2Rkbkg3pMI9os2W61bZ2H26VU4=; b=n2VCFbIATWDM5hKDcLG6t9AjZbOeQBV8c3ZWryvHrbp+i4WaWaiG5FQmfdJkSLcfMy 6EhhPS6XuzIhFbCZO/XFBdOwZt5bMNGXKx7K+jMevW4FD1SZc49zgXod5xvjFsR9lFbf 5AmfiUtNKwLE+vVTY+8vL2+46RoMwZvZJGq/FuOMwIw4ZA9SG5ywDupoNzmVu6YwCXFh FIgy7CewOyOp+2zx7sEBhLORyzQdVcUyC/nrIRw6yHsfKZuX4XVeZ+Xo3WZh//xkzP59 WMDwsI1BvdxjvJtY2BhM9voKMv2ZkCnKARz1v42CesSn0BkP44hjr7SzS9XguujZ/StS 9RWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681835151; x=1684427151; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MvjA55Gc3aWxcMuhy2Rkbkg3pMI9os2W61bZ2H26VU4=; b=L84uahsLT9x8CQkovtzowcVJ/Au5va9nLCVgWSb47q2PC+lM+F7hXIdLUrxxJdGpYI 2b2gBF2gF0niXRul3YC9flk+QH51bvuf+BlUHCizQPSB6UrM3WVGDGleYdHx7DZLXt6u Kw944SgvIEuiqKUoe6LH0PVkPIgyLW4OVaNF1lfFbS8dvDR9bG1qvQZHKuhOUrsdI21K VEkgzF3kiDyomPnxhgoTi8WX95Cy5WKznT314Lsh3umiFIc8dOncIuzILf/DL3BfdotV hrNPuysCGcTpqFSlBuw7LbcX+IeT/9i8eW48I7wVhB/CC+vzJDGEAzm5l5QhSbxCXJsM GovA== X-Gm-Message-State: AAQBX9dA4779ow+hFRgGRLpS5cvu1AEKoTa2+1AYDgqs6pTvydxqKdA9 G7cIuXxKglMbelAA8CQzlJk= X-Google-Smtp-Source: AKy350ZkVJISWnhpVGG5sxLQynoSO5sv0d/saS2NkhXaBr9KUvKPUlk6p98b5jA4/zBZPllKnbDT3Q== X-Received: by 2002:a17:907:86ac:b0:953:24dd:9ddb with SMTP id qa44-20020a17090786ac00b0095324dd9ddbmr2252006ejc.13.1681835151380; Tue, 18 Apr 2023 09:25:51 -0700 (PDT) Received: from ?IPV6:2620:10d:c096:310::26ef? ([2620:10d:c092:600::2:5697]) by smtp.gmail.com with ESMTPSA id k13-20020a17090632cd00b0094e96e46cc0sm8216153ejk.69.2023.04.18.09.25.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Apr 2023 09:25:51 -0700 (PDT) Message-ID: Date: Tue, 18 Apr 2023 17:25:08 +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 5/7] io_uring: rsrc: use FOLL_SAME_FILE on pin_user_pages() To: Jason Gunthorpe , Lorenzo Stoakes Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Matthew Wilcox , David Hildenbrand , Jens Axboe , io-uring@vger.kernel.org References: <17357dec04b32593b71e4fdf3c30a346020acf98.1681508038.git.lstoakes@gmail.com> Content-Language: en-US From: Pavel Begunkov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: F12B71C0013 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: ja5n6dpzo79bo4s1p98hmnqhm9h7bpgs X-HE-Tag: 1681835152-71216 X-HE-Meta: U2FsdGVkX1/aC8Rp5gj9jumo1ucc59/K8TDTXfNF3jJkapHitKpgkvFac9cHjVeREYmUt4ZK/HStCufFVbjKk/GlxX8il3eNiYeVl/ShBj9r4GhIXIwtGpZjm0XmgwCpJHXySCbW9D3Cmk3pID+IrVdCSzSHKvmwYWrrHb3DqaUdDs7G0WqHbYQVd9czM9Jh7TUmj2wqBpD86RFf9pmpEuKhSGtWtam8e1s4kPnYIUFxlGzFtr9joCQjlv9n2EHXc5x+lMZwOIhgcVsZaX4G1bEVsFgN98FWSHcxJSUl2oGSY3wdONym5UO6ExnjvuzXJ7go0MayyxE+2nOI35Qrt4A2hHzV1sWxnw/xfihOvQhhcwFBWq1+6E6IxUOcU7kqjd0D8GE/6X/N9xh3UmXPsIkPpMPq86AIO+wGpZREQESSq8Evfc/Ij77McNoYdUi0p8lU/LogZrQ3Aq9X+xzD+OLcT8RM83QvXE6USimOSAm6Q03zCdCGBKpM2r9oLZfUp2XsE3IKJGdBSIujPUHDymcVAXJHocfm4siEQX/8zUFdvt8SqFK3dddXcVhxLWjKJLBDXioN0RRoL89m+Zu+u+rK5z2xcSuQf6Sv+0Y0XvhJZks1pwC6T4DTZ4ND18FLBti+/r2baOaPStg9Xnzx2xT5Qe14pJvp1sZtCCIewmjq/C2iJvlkAbozCqATnsqhesiVQZJUCE1x7WvDkx5YWcRxC+suvOPqVsBuGzwTK9gCMvK27Ck9X8jYdplSefGpSq5Om5Y9OiarmnTAab98xEY1H8FKibOnakg49IhJKZ5RwzxrHJ2ailkW6dGrGL9s++u30rZQ2x9tiW6A+UYQBV/Opi3wA1d6JsUFqtRwV+lsFkEU6DcIyU0ueP1ThXrSlKKiyyemexQNptU/cHznw6srMF5WXSLH25Rgkh+rezEugModAbS47KHuNyswFgx3oh7xP4EwyO41JRxfkqN Hm2ZylUz saNzOYaVpVN5CcmBOTuWKqv5Ay9ry32RfFouU0JbzwgumCyk4tbhpwmigbbq3jWNekqMRCUk7BPFxYIHETNl9uL1u64WIY4cmFUp/kZzUlv4qKSs4v0ATUQ4ag1MehcOZ5UVCjbAR5Rz+YNzhrph3Qd2abKZ/8VJDGnNTTxqFrPsD0nhSJagEEZPdFyuBdcVulJ1d0B6GHTGYiNOSearyvbX6V+o1t+3CIvgKCPcriPSeLtb8FREUNeg2DSBjY02shylM2oB+ZZQARyZdE8IrLWEGVyC8YtuyY38ABvPzXMMeJZSKz/PTHjO6gw7gdDonBusk9WvnODgerY6T09LFJkyCiaVrqExNUKC3mU0RwLSnpTVRqdW+O7tc+YF6orF5VYoLLmseY5aAfA+lXmvS6wauAcvS6JBCtbfHGyV8Xw5DQLfAHOy3CGAo+WIjIfM9PnDK9Erg2SWDb5n0CMFm6OQ0u/PcjEM7sGyGovtLoyw+stnhmSOG7P7KnP+bka0fkVr0egapUcDNAzRgTYKJEh/HTg== 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/17/23 13:56, Jason Gunthorpe wrote: > On Sat, Apr 15, 2023 at 12:27:45AM +0100, Lorenzo Stoakes wrote: >> Commit edd478269640 ("io_uring/rsrc: disallow multi-source reg buffers") >> prevents io_pin_pages() from pinning pages spanning multiple VMAs with >> permitted characteristics (anon/huge), requiring that all VMAs share the >> same vm_file. > > That commmit doesn't really explain why io_uring is doing such a weird > thing. > > What exactly is the problem with mixing struct pages from different > files and why of all the GUP users does only io_uring need to care > about this? Simply because it doesn't seem sane to mix and register buffers of different "nature" as one. It's not a huge deal for currently allowed types, e.g. mixing normal and huge anon pages, but it's rather a matter of time before it gets extended, and then I'll certainly become a problem. We've been asked just recently to allow registering bufs provided mapped by some specific driver, or there might be DMA mapped memory in the future. Rejecting based on vmas might be too conservative, I agree and am all for if someone can help to make it right. > If there is no justification then lets revert that commit instead. > >> /* don't support file backed memory */ >> - for (i = 0; i < nr_pages; i++) { >> - if (vmas[i]->vm_file != file) { >> - ret = -EINVAL; >> - break; >> - } >> - if (!file) >> - continue; >> - if (!vma_is_shmem(vmas[i]) && !is_file_hugepages(file)) { >> - ret = -EOPNOTSUPP; >> - break; >> - } >> - } >> + file = vma->vm_file; >> + if (file && !vma_is_shmem(vma) && !is_file_hugepages(file)) >> + ret = -EOPNOTSUPP; >> + > > Also, why is it doing this? There were problems with filesystem mappings, I believe. Jens may remember what it was. > All GUP users don't work entirely right for any fops implementation > that assumes write protect is unconditionally possible. eg most > filesystems. > > We've been ignoring blocking it because it is an ABI break and it does > sort of work in some cases. > > I'd rather see something like FOLL_ALLOW_BROKEN_FILE_MAPPINGS than > io_uring open coding this kind of stuff. -- Pavel Begunkov