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 13B25C77B76 for ; Mon, 17 Apr 2023 19:00:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 75EBE6B0071; Mon, 17 Apr 2023 15:00:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 70D0A6B0072; Mon, 17 Apr 2023 15:00:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D50E8E0001; Mon, 17 Apr 2023 15:00:54 -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 4B5826B0071 for ; Mon, 17 Apr 2023 15:00:54 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 0E52140540 for ; Mon, 17 Apr 2023 19:00:54 +0000 (UTC) X-FDA: 80691800028.10.CE4E4AD Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf12.hostedemail.com (Postfix) with ESMTP id 250D74002D for ; Mon, 17 Apr 2023 19:00:51 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=G1ZPJObc; spf=pass (imf12.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=1681758052; 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=XK4v5MJMwmg+Uel4aUp/2qOZYeDNDYULZOv/n+WFDZk=; b=kXvrvlvuKlWGbNoPkEUOAIiAP90oXVKDDCDR6PcNF4jPqT9BnORuesgN1+9IWq1+emnMfB W9ajByM4FyuuAwN9W+dUVo9YmPpPOs3uWqk8NCS5dKFQDKuBd7CeOcSankp9P9UdmIvQiA 2ruwM6UgxcgaLt81U9F+SVmQU/BDx7U= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=G1ZPJObc; spf=pass (imf12.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=1681758052; a=rsa-sha256; cv=none; b=TI2m9MUjCh/xiYwMxjj2v1GbykPZOhY2dkg6za8DQZSECQfc1z8/zysN719R6dpKAjm2gj 6SmStsDtsT824RQQtSIu8/ZeMGIrpOMgdpryCkJEUPyxX58zdArppo/mMkPFIW+m5wARvP 7kcNtFKYnk1W42SIiSsuCpGo128FSXY= Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-3f173af6712so9081025e9.1 for ; Mon, 17 Apr 2023 12:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681758050; x=1684350050; 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=XK4v5MJMwmg+Uel4aUp/2qOZYeDNDYULZOv/n+WFDZk=; b=G1ZPJObcoBUqGxehJKZEXfV1+MWzSvUo1KE8wI0JiRKiPIVlpzSw3afP9Hc15URNfP UYuUbv3JZTzLoAPploAib34jgxjztxEIiEKTrUEiI8Fu9fu6eFYyUNkGIwMvht2C2M7H DpbzjmzEtPm7VcCZ/dUg/uHYOw6yLpxBGVVMNioK+Vnqk/El795yQ1w6JxVuCwBdcck/ dKI+/adzYBfI8MHdgG8FUvJsNUI47CqYZI4dx9TOwieCyM46BLUmATHMK68wkus+m7j0 JBdACn+dScNqPJnxIsQoe5YcR9/KW0cwPYINq9THObvSHobeGf4R4X89G+sLDUkzYzrp tg3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681758050; x=1684350050; 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=XK4v5MJMwmg+Uel4aUp/2qOZYeDNDYULZOv/n+WFDZk=; b=jNXH7lgPd/EJV3u/EGNbrrP6P0ND3h2BIMakxQ7HE53XWMI0yK33iGLCWG6kzi68Cn nzI9J2vrtggSZ2HUiA30Ha3coSyOvj8aj9uuXA1DhZ7UzJvllmgeBthCYZbpFIuKtqGx P2uAhfz/Rur43yRICwmgz9MqzijkFFu3DHLdrtMCdEkPc16QpfKDTDn42P2ffdf8QoPB LQONkCWBxuCFqoJHkmQQbD63aWSgErDEN615gUM/vU5WDHFdfQc6A4cM4HntwSrPJLC6 KgUR2Q20z4/0tRHp4Y9XHekksS338SECDfq8T6Z8xbQy3x9xP76jpr9Blk+ADGDJ801G kLmw== X-Gm-Message-State: AAQBX9c2nvZKCnWqWaimWo8zkloE4+2Ev9bRFIRa8vGO+Db3EhPqDvof 058Fj0or8g0L+Hi9+rmeiAQ= X-Google-Smtp-Source: AKy350bhGCCOD3qqpqZLlv4//cNtwXXpoLWQVBGSi2t0ax4dpauuk4Cmae7AnPqgCtwC64G7rPe+xw== X-Received: by 2002:adf:f741:0:b0:2db:2678:ffed with SMTP id z1-20020adff741000000b002db2678ffedmr7914wrp.7.1681758050053; Mon, 17 Apr 2023 12:00:50 -0700 (PDT) Received: from localhost (host86-156-84-164.range86-156.btcentralplus.com. [86.156.84.164]) by smtp.gmail.com with ESMTPSA id y18-20020adff6d2000000b002daf0b52598sm11144482wrp.18.2023.04.17.12.00.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Apr 2023 12:00:49 -0700 (PDT) Date: Mon, 17 Apr 2023 20:00:48 +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-Stat-Signature: r5yu73q9s6qyy33ze6gydnbbtoq55599 X-Rspam-User: X-Rspamd-Queue-Id: 250D74002D X-Rspamd-Server: rspam06 X-HE-Tag: 1681758051-268832 X-HE-Meta: U2FsdGVkX19V4b75RVQJpsG3RIXQTSkgHplTx7VVY3AzzPXMdk4/YaSAzi5oFrPkf0T7j5wyX6bJXty0Yfwc3fFGfFNfrQ64vC4jyVKTAO9/FCy+CjwYl8h6PB/pn3ahDMqlcNV6JTKDsb8eTwtQtynwALhtdCVRdbGDwK8V2CqnnaUhDzzPDxDVGi6iXRn2ImMNhGoZxepaXLrooLSkWpnoSX4j/JmQ57zJ2PGIXVVSM2Md2Tz+FcRKZ7bv7y/YVDZJeAiOxu/sEZNMp0/T7p1ebcJ0CW/tCOrwGjmgrIzuDzrt3P0nBEmiQqKTedrLsJAjeEPTtXoo6dqU6AwFOTlGRqN+6+Csmob7wt3VqgG8SdUcJiBfWH09z9qoRsHA5ZXFTjveNy1LcWcV19Hm76P0Zzu9C6EVtrUlj+gz6wcFWzzaIMQj/aBUvKE+n/91yLky/9RsJy4FJx2JWC2C8mQxJmXzx71Msjdrd+u9JYTxVddB7kTIZIKigMKV8qjaQnyBkLvBZ4PMyf8iIit/fD7zBfml8YarJ8uE7Ntu+WEdXMsdmPeYnqLLu+Kp9HNe+1ghWVKrbOodSA6S7lOxqiuwniwqGuesqUhR5IQJnoZL8rpZzDodxdOC/5mc9J7O4yvTpZktm2ClajpvQmH7ubnMDa/NNNTSnZ3FB59rulTyqd1xxOoTdn7yCgZRaw2swSnes5tgT8vEg9S+T3TkqKNxbO2Puaza5/14hPyY5/+4Q+bM9QTJ+OOOCiURJHBWCkqFlrX+PBXkpO4Y8yE9i1OK+6u8gmBsnxWJTy5S8q913+t5izwFbn5ll4mW1YLuG974Ecl94zH77ggWv5xJhqCz72hIXiaHdDfP+sQ3i2YtOFwTeYmwMC8yD1uMGnEk//0Ajm2i+dcklc9BXl6M9+H6Vh93zM/RyWLGoF2PnLfTDLK93cYtNfugtxN75K0OMegfUQCjfAooW2d9z74 4Dma2iTy E/1Nnw3dhaZxvG1bAuUOP0ADXur5YX2Kg5zYSXLPlRHZE7ADuYtghtxwgcGacnzsQ6uqnchAGlC5t46M+VBpjmmhB+bklv1S239FuGQaT6Gy27Y9rLhXXycXXhwHLCCkncqYxy1wYHvoQrfl0u+kFcxapC1XWKll9VLmYCw9XxKqIK0133gxWmQZHdSSCNhkwE34p25WuTRwg71zvax8m0bfKhF3iD9sLl5D6Li+8L2CHy46y3uE/upYFFYX8FJwLOqvJ3Zq0F/L+L5HgdW0LOz8c2+jIgGNXpCgp5QWMWKw3+8eKcGMgnwcFLpM/O0Ku9zBe+cxrx0ayT3YOD+z45GygKaliXbmhSENWkb8XOWEeTojAuttN1W4llLtQlryNEZDuZEjI8O/1IzRujdKSl34Glz6G2YZ+nHBGhjpQ4MISqOuWI0JugThwV18MSUTOTHBVMxy4Uinm69lGq9+nCE6CZ70WnpQZH+wFNL/YrNXXUYNz2V2GpGP8W8HIN5ETHcHbOZ2vNFJFRSG7WrYcq9h51Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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 10:26:09AM -0300, Jason Gunthorpe wrote: > On Mon, Apr 17, 2023 at 02:19:16PM +0100, Lorenzo Stoakes wrote: > > > > I'd rather see something like FOLL_ALLOW_BROKEN_FILE_MAPPINGS than > > > io_uring open coding this kind of stuff. > > > > > > > How would the semantics of this work? What is broken? It is a little > > frustrating that we have FOLL_ANON but hugetlb as an outlying case, adding > > FOLL_ANON_OR_HUGETLB was another consideration... > > It says "historically this user has accepted file backed pages and we > we think there may actually be users doing that, so don't break the > uABI" > > Without the flag GUP would refuse to return file backed pages that can > trigger kernel crashes or data corruption. > > Eg we'd want most places to not specify the flag and the few that do > to have some justification. > > We should consdier removing FOLL_ANON, I'm not sure it really makes > sense these days for what proc is doing with it. All that proc stuff > could likely be turned into a kthread_use_mm() and a simple > copy_to/from user? > > I suspect that eliminates the need to check for FOLL_ANON? > > Jason The proc invocations utilising FOLL_ANON are get_mm_proctitle(), get_mm_cmdline() and environ_read() which each pass it to access_remote_vm() and which will be being called from a process context, i.e. with tsk->mm != NULL, but kthread_use_mm() explicitly disallows the (slightly mind boggling) idea of swapping out an established mm. So I don't think this route is plausible unless you were thinking of somehow offloading to a thread? 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? 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. (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? I'm guesing nothing like that exists yet?