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 D1435C77B76 for ; Mon, 17 Apr 2023 19:46:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B4356B0072; Mon, 17 Apr 2023 15:46:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 464858E0002; Mon, 17 Apr 2023 15:46:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32BFB8E0001; Mon, 17 Apr 2023 15:46:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 242276B0072 for ; Mon, 17 Apr 2023 15:46:03 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BB9051A068E for ; Mon, 17 Apr 2023 19:46:02 +0000 (UTC) X-FDA: 80691913764.01.3EC963E Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by imf08.hostedemail.com (Postfix) with ESMTP id D1459160007 for ; Mon, 17 Apr 2023 19:46:00 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=eveHTvGU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.44 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=1681760760; 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=ZkpPzDKNye1p0Bi+afxT2w5cRXkVMuat6OESCAZjOlc=; b=QLwf+/vLoK7ujD4MR7ggMPzsYgcV33wWht9sxdVLqESRg+X0PiJtXVnSgk4femELkgaT71 eOki3YQ2q3H6LSsairW0tN6jwvA0nfDHpx4XFGS+Qk1cii550a2YhJk0aH9I0cA4QMojYw BA8E/uPmcyvO0VFNykd9NllmD2LoVM4= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=eveHTvGU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681760760; a=rsa-sha256; cv=none; b=Ua7UHI2oPvG3E0X2760aisz8z9LLBxH273snRd+gSYA7V1cF3QlTtYRnn9iRIbNJoF7MOa p8KfYpKQ08EH+GXnLMVjie+/YMb0/mA2ItrjDLFbnHpQlX+LlPwds9CT9rukWe99m9SDZ8 LBQOMzvhfz3PedPkd4iVeSd+avosKps= Received: by mail-wm1-f44.google.com with SMTP id n9-20020a05600c4f8900b003f05f617f3cso20370567wmq.2 for ; Mon, 17 Apr 2023 12:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681760759; x=1684352759; 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=ZkpPzDKNye1p0Bi+afxT2w5cRXkVMuat6OESCAZjOlc=; b=eveHTvGUwIurwIcZKUmMfKipRZuwNBExVEK2kdyUYD0mnRERq6S3CwOETEFUtNJQQq Pk2wet28Bgynh2pkDhehnVB5XyZV+DnbnPCAyUVzlk8I19H05Ql0ddI/t6QR3SxVfIU0 zMr5yTp0l0m0AgWqmorrSokbryOwFZ/Fq9htulGq4Qn7fv97hO5keJ8tbBf7OYrdE9k4 /PBIifCiGixNUFRM1Gf0WHm76UVfb4lp1X1rLzkPHsboYi2+Un59c1ALyX3kylx/9qLv zhOzHSKCrCHv7bNKUOiOyUQ+KFpbE+k8xA//HfyiaRWJD8sXvKS9oYa+hYwtUxchU+rS Oo2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681760759; x=1684352759; 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=ZkpPzDKNye1p0Bi+afxT2w5cRXkVMuat6OESCAZjOlc=; b=EZK4Uq6dc5bdzpBAkeC5tdHeh4NOH09KORCGdexX2g5JjI6aW6J7OpkoMG8cvxJe3L 1I3xhZuH9LUa/iW+caDq57/vD+nLXcTHn+5JGfUU8uVZVrbcrMTYUSiBXweaQ4ZnHVJF ZYrtWVgvRrK0HK/+Ro1ppe8y0JPwR4kqZH7vG0ie3xDDqiEAStVH1v/NyaoNJ7OS7NOs c/UGyjw1xW/2RppPFzJ12SMfX4b5Q87atF1lHeHGPPl/X1oOtbEXbGIPYI+99RgL3ILJ Xz4JeWNd52r6BD8rv4Fl8wNtRbd/fcVdAHJPreitUUBTS4m+XYv0tURlhc4br4RwY8I0 pMkQ== X-Gm-Message-State: AAQBX9e5eu3x4SV8bk3eBY/wsvYL8oRshwx4WV1yEwOKW2g8FuQIpbCp 6dhCn8HZt6YYcliwSCUxYsM= X-Google-Smtp-Source: AKy350YDgkjLDIWkKtzJAjyjc2v/ajp+V10odWq38ZQIndOmbKq5H3vd95BsZsLjPRBK6X0UuwLjtA== X-Received: by 2002:a05:600c:22cf:b0:3ef:5940:5f45 with SMTP id 15-20020a05600c22cf00b003ef59405f45mr10682246wmg.23.1681760759266; Mon, 17 Apr 2023 12:45:59 -0700 (PDT) Received: from localhost (host86-156-84-164.range86-156.btcentralplus.com. [86.156.84.164]) by smtp.gmail.com with ESMTPSA id n16-20020a05600c4f9000b003f1712b1402sm5598569wmq.30.2023.04.17.12.45.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Apr 2023 12:45:58 -0700 (PDT) Date: Mon, 17 Apr 2023 20:45:57 +0100 From: Lorenzo Stoakes To: Jason Gunthorpe Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Matthew Wilcox , David Hildenbrand , Jens Axboe , Pavel Begunkov , io-uring@vger.kernel.org Subject: Re: [PATCH 5/7] io_uring: rsrc: use FOLL_SAME_FILE on pin_user_pages() Message-ID: References: <17357dec04b32593b71e4fdf3c30a346020acf98.1681508038.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: D1459160007 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: xzpffoeuexy84b4tfda5ddcnanaoxi1k X-HE-Tag: 1681760760-534457 X-HE-Meta: U2FsdGVkX1+WqF0qxD/aqesByWogdGSr2LPLWe6XLc6TYLS9a5vaI1sjXcRlk9Z9c3k311Z+AKDqKTI9IgccGJk2/FlQEpQzrJvRQGP0IAWZGhHqqCIloFgcHpx7/EcuOUiPYRZyjGQ3pCuB8JTMx4vpiSCc7HaYdJRKRVhHaO7spp7rmhJFiSJOqQzBXRDBN2SfGT9jH8Z9FtXaj4FXZozjw8AuvgkzCAAuLDXExRvdfFlM+VYno5XoHE1t+UP1h/Hy+8onkIRSs+QWf9Vv2XUom5VPMgaq/xZy2sr9FV/DLdvNFnyuAkWre0RBRMdJ1J7bXowhOEBlw5MV0Kru183+BN9CXvMlEwo9oyK1WR45id+P1BvTiivPIlmOZCa0g9Ywx+qCYoQ+VSHnq22ti0d2cKXHED9IU99CuBjuxzSJiZMeSSO9m/IOiAfGpdQxS1WyzrSzejXtpFtT91vGv8cfzYsspLU2EawHWmrcn44UBXYC7QZRoDs2BIZ/i+3r8cU6aO8omsj5gxL9q+tCsI2OlBc7DlkrV8x/7kEL0O13+NPd9E2qLR4dTMLb0URcSVSYtKn/KIp1asRjKfyeI8nOIznGMsfRcQ1PFTEiCXJhHa385j05AF/RYC6t/ylSWhWYyVYMABLFQprYBwnY4sfNghas7X9FaBHijX75x1Rb15v7x1z8QxHogqvZvuPNWbzWgKCDF2m2Sp8R4v/716JOXGEz4skAfopFY1obThysMazqAmAn7DtIPDK0j1d7PF9XYHAA6AFgqGAS+Kjvyb7H8hL9BOZZ8OdDCynT4sbT7SGIXqu8oJYcg/VomUTQ9kf3RQuEL01BFBp0pipPnbrs/kYSm877IzzsAHc+Ohke441hX7i0Puqod31Pg+vACJbG+KZfuef+Is4PNEe/FtX6olnOPn85v8mZnboYjoqLrgrFyAoIS4k0lziHNkp01P0oPMSAfBOkf76paHJ F5kF0NaJ Dt17GBJ5rvBo/gdFyjzA0acec7S8scppeKsZiCE6JV+Iy1/uy7qaD1Kzza23eHu3qrU7K6jLVny5BildAtKew/WXonCEvGKlGUP0tGQ9SmSr0UrES2/D5f9RfYfw/JFimFVtrVmPmxct4RQKBqJnglRR7PJ0Bs+5ct9ndRm3Wav6GA5s6rXFu3in7kg5JKPTr5YwZG8LyaKXlU2f49XImMkX0vD0aOGKieSsaAmkKkKx1/tUlBrH7bvhIVc5HpUkF29UkKvAJ6JMxndsMG6A85f1QPA33NfsViq/+u0mSLYWG9529VQ6r7KqOzsrfXbwobSAK8WmRuuC9af1nmMEZ5aEm9p6imihmQB8V344daBT2MW3c95VDYxWKnakb8VCockCFQeHvZRs22gwToA4i0pgQCi5CffNsoPFoaWPJW55T+3VNiPDHlJKWTdxI1aeSrw+BHQUluzBHT3aevS6H5l3wk9y7C4Q7MNCkPfUZerqKqyJF40Hyg++1iF9OqYF+qbjIeRp3cyakasM= 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 04:24:04PM -0300, Jason Gunthorpe wrote: > On Mon, Apr 17, 2023 at 08:00:48PM +0100, Lorenzo Stoakes wrote: > > > So I don't think this route is plausible unless you were thinking of > > somehow offloading to a thread? > > ah, fair enough > > > In any case, if we institute the FOLL_ALLOW_BROKEN_FILE_MAPPINGS flag we > > can just drop FOLL_ANON altogether right, as this will be implied and > > hugetlb should work here too? > > Well.. no, as I said read-only access to the pages works fine, so GUP > should not block that. It is only write that has issues > > > Separately, I find the semantics of access_remote_vm() kind of weird, and > > with a possible mmap_lock-free future it does make me wonder whether > > something better could be done there. > > Yes, it is very weird, kthread_use_mm is much nicer. > > > (Section where I sound like I might be going mad) Perhaps having some means > > of context switching into the kernel portion of the remote process as if > > were a system call or soft interrupt handler and having that actually do > > the uaccess operation could be useful here? > > This is the kthread_use_mm() approach, that is basically what it > does. You are suggesting to extend it to kthreads that already have a > process attached... Yeah, I wonder how plausible this is as we could in theory simply eliminate these remote cases altogether which could be relatively efficient if we could find a way to batch up operations. > > access_remote_vm is basically copy_to/from_user built using kmap and > GUP. > > even a simple step of localizing FOLL_ANON to __access_remote_vm, > since it must have the VMA nyhow, would be an improvement. This is used from places where this flag might not be set though, e.g. acess_process_vm() and ptrace. However, access_remote_vm() is only used by the proc stuff, so I will spin up a patch to move this function and treat it as a helper which sets FOLL_ANON. > > Jason