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 30CEEC77B70 for ; Mon, 17 Apr 2023 15:20:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 829658E0003; Mon, 17 Apr 2023 11:20:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B12A8E0001; Mon, 17 Apr 2023 11:20:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62B4D8E0003; Mon, 17 Apr 2023 11:20:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4F3068E0001 for ; Mon, 17 Apr 2023 11:20:42 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 247BB40620 for ; Mon, 17 Apr 2023 15:20:42 +0000 (UTC) X-FDA: 80691245124.09.AE4CC2A Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by imf30.hostedemail.com (Postfix) with ESMTP id 3272180019 for ; Mon, 17 Apr 2023 15:20:39 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=I4ojaBcr; spf=pass (imf30.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.44 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=1681744840; 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=DQDSqHH17hYfTNLrFjs84ctoH0UTXd1VRJaXaEoqgiA=; b=KR7bUyoroCmWwGtLVVJDisYgvrYDvzby45dFl9PFiJ5dNiQJhAwICLlMus7Eai5771XD16 BMpXoQ6rs8zmf9FTFiBaziklLQ20l76oXjCPyCN8Ltkk0Tlq/Y+DmGusMm6O890VxVkt2N lnyDS/A/2YEfWqwtJiITi0rR3a7KtqE= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=I4ojaBcr; spf=pass (imf30.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.44 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=1681744840; a=rsa-sha256; cv=none; b=OIKJDRxiQZFXvOiCpL86CFjXn7OtpndrBnuyyjY5dIMyhIKDKmVu2wdlh7CsjXx0bE9gR+ fm/6huczvyMkzpG63WGWzWnIcOkPZosknmxMIneIHnV+Fpfe/rkTmXB7QKb/hODpguwRBE biRZ7Scfle+mHoSP3JWeBoBSdEdZdYA= Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-2f4c431f69cso993174f8f.0 for ; Mon, 17 Apr 2023 08:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681744839; x=1684336839; 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=DQDSqHH17hYfTNLrFjs84ctoH0UTXd1VRJaXaEoqgiA=; b=I4ojaBcrnVZQs/M/AZcS0EaF0gOS2a9WvXZNBiTDSMeZFlGhGUnr3r6xBnT++FkAKb jmeXkOY09WH6pKRmuGLdOi3wSGFkVkJcrBhOtKVsIV6A20MrPqxly55z/iM1ieHndmug xpjE0PMitt1yczm2b48xTNbWsV2dw53QXv/fZoIaGyoY8+FjweN+D865xRoBp8It9axF l7qinG2ZsUa4XrYjvtNGZcbwcbqRfoRZvRslXrgza0rjcGj5u9TNaxkDuoYIk7YbTl4b /Z8pWo9ROMugg7Rm9HJxlGYso5B8jWYp9rI4BeZb+UMWzry9DTyvbGioN8GNUlbhRadf K9qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681744839; x=1684336839; 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=DQDSqHH17hYfTNLrFjs84ctoH0UTXd1VRJaXaEoqgiA=; b=ZcRWoZoBbYy+altMOEuiIXqdJrXrFABxerAEhxGMhqH72eGXFdlsSg8dzvQs/ea621 H4Nih4Jm7Mb6Zdnt+mKfAe5Gf0wxsyHRG8sV4ZgGZdMO6AEEmf/LxrbJ5OHKhpYXXaFp KNg2SOSCto7AjEkZqiR5BW1VSwdWNYerUqJEZXX8tSc5aKle50/osQrT9BeDQq1wSz9k x+6mx1hGYVi10gbAfFkrGv6Ws8XA6jEFVOKkbMTBCrJWVVlrVbWaSgHwe9qtk+dUfrJF JnyGYr4hHbqeresm7cDrmQY2jr1OAuCi5VCI5Dxa3xhZCYQSWIuVzgUYFMKAykKXnHhz 2poQ== X-Gm-Message-State: AAQBX9dvbh/5BlzbIbUl61t2+lRlKMxUVgFH15NBsOkP98Wh2QiUMlAI N09V2B8xrmKBnfxy1r3S0X4= X-Google-Smtp-Source: AKy350ZOMCW2n6XzeidxNZXgiJylme1WhhGqKzfcA0zTI7glb7Vc9xWe4n4TEYopToDAF7gTFOFUMA== X-Received: by 2002:adf:f8c5:0:b0:2cf:ec6c:f253 with SMTP id f5-20020adff8c5000000b002cfec6cf253mr6174725wrq.20.1681744838549; Mon, 17 Apr 2023 08:20:38 -0700 (PDT) Received: from localhost (host86-156-84-164.range86-156.btcentralplus.com. [86.156.84.164]) by smtp.gmail.com with ESMTPSA id s15-20020adfeb0f000000b002c55306f6edsm10750461wrn.54.2023.04.17.08.20.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Apr 2023 08:20:37 -0700 (PDT) Date: Mon, 17 Apr 2023 16:20:36 +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> <34959b70-6270-46cf-94c5-d6da12b0c62d@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 8fwontqmrurp8sn8ask8hfbt4kbwymnk X-Rspam-User: X-Rspamd-Queue-Id: 3272180019 X-Rspamd-Server: rspam06 X-HE-Tag: 1681744839-388220 X-HE-Meta: U2FsdGVkX1+Ov61EuhBmx8Bw0Ys7lsNb+HNLFTWRbH2GLOrm3z6oij9PIk9VinasEJwT1fGGsP053rWeiwlz1zeKMoJPJXR+fiQhU4RcuJCyd9xrmha2aIaWKWPSxEzW/LWKgINVXaoH6lGjMxPsZ/62rBHAgEF5BtpWtshhGP837TGRwWwiX90T0tcpiPd1drCbWn1K5TZmuKvSk0N7WSZOy5XvSQ5/Rh9XCsSxECDG4/Xbce6mp+OcHccEw87fxmxyHRXqwLZkUvCz5F4ANaONA623cBsN7plhYcOApiWw4wKFVXbDx9BlOSGNaxHhVtaEsAW4kyyMfGctyFt6dEPZfEh02j/7R1/czP5Q2KQq38pSmpmXUDy0/l0nUXeC7i2tE+hn1LtePZbfg7qOFOnRvL+O27otFIHBxXHMMFPGNlcSMWAb6DSpq3op7pWNuXnRYMxaknIdt1BwoHwa8cG+8aXXE3kV1cjbsG8MkTcAfTsNwarrf6O0GBO67hK4RQzP5TZHfvJC6pKqlGElK33InDVzDxq26g2TG0iIcP8W+oz9i0g1I/Vpo4PT4Jwf39m7NFN0Zb0a7onPMylFCP1vYsnzv3TVHRp21HnX/Mk59oluW1zWlbcB+3yCa+UGrUN6OZyKZjq7q4xMBIaoZyI0/LeVftpWHM9hZk0128kQdbugafKrBzdXbxDfDURwcYyy2Gtznvk0HlL/yzLJAAQ3jCt7oc0Xt1BFZ4HxefdrSggWXW+JYqbk2n6SfHzJXAvy3p5KXX9wPfatVPyt/r6EDhCGwATT9Q3JiUFYA+lhIXkg750d1YkvJxmJBVZHkEaoeFJIDz29sRjesy+iEYxJKw7yRnK2l1LffqBjI+i84A43A1irJJ7gUTmg/VeVx9V6QijkAfsyqhp5kfQRMXTXxPYkezLdLvW/+w8SvDU9HdvrAWNJwE4Ir52Lq89CibFH0vagU5IeXWMAsQy Y8CaNa8F ygM97RfgC2pXiV0bsBo0mWTI7Hr8hbeYmKfdJZa6HmC2otE8UOE89KNzFNh+1/sDA2aqVCBoQI7XFklrXgipJtFomu5l5vI9+NUOcpOMGOq6bd/n0OpYij4JQvUMDlt8XyxbdyV4fxnL11szWB+ken/8Cd+rt876L3KgrNR7G+3L8WIL6iNm89oKIs8IzyP/eMx/mPFQjydLjt/tMPVqJ7De5hBEXpGF0cqnHDmk64/JGHTTfPFZFl1hxG1SMAHRqySIb6VSY/+YtYPm59sF4k3OP6EphWG9/UI+ZRPrabT9RRXYOW4FLTCDB3MMdsveU5WTvywFOn3E68mdQVKPHQEUYP5HF+lZdCcIkfrmQfsCCy13oRnXfrDmZiGtr3cP0+DS0AVpY51vx4AkUKiWwfaPuZQyXM7+k92y0cT19MBQ6ERYqj03undt7wzE5q+eZXQ07EJdujf3nbuJuhFOPa+cM2yBCP6V/hTL7aPXsyKUt9kLwUhM2/kPykg86GucQeS+Neub0/j4hkA8A+iiqSBJzig== 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 11:15:10AM -0300, Jason Gunthorpe wrote: > On Mon, Apr 17, 2023 at 03:00:16PM +0100, Lorenzo Stoakes wrote: > > 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" > > > > Having written a bunch here I suddenly realised that you probably mean for > > this flag to NOT be applied to the io_uring code and thus have it enforce > > the 'anonymous or hugetlb' check by default? > > Yes > > > So you mean to disallow file-backed page pinning as a whole unless this > > flag is specified? > > Yes > > > For FOLL_GET I can see that access to the underlying > > data is dangerous as the memory may get reclaimed or migrated, but surely > > DMA-pinned memory (as is the case here) is safe? > > No, it is all broken, read-only access is safe. > > We are trying to get a point where pin access will interact properly > with the filesystem, but it isn't done yet. > > > Or is this a product more so of some kernel process accessing file-backed > > pages for a file system which expects write-notify semantics and doesn't > > get them in this case, which could indeed be horribly broken. > > Yes, broadly > > > I am definitely in favour of cutting things down if possible, and very much > > prefer the use of uaccess if we are able to do so rather than GUP. > > > > I do feel that GUP should be focused purely on pinning memory rather than > > manipulating it (whether read or write) so I agree with this sentiment. > > Yes, someone needs to be brave enough to go and try to adjust these > old places :) Well, I liek to think of myself as stupid^W brave enough to do such things so may try a separate patch series on that :) > > I see in the git history this was added to solve CVE-2018-1120 - eg > FUSE can hold off fault-in indefinitely. So the flag is really badly > misnamed - it is "FOLL_DONT_BLOCK_ON_USERSPACE" and anon memory is a > simple, but overly narrow, way to get that property. > > If it is changed to use kthread_use_mm() it needs a VMA based check > for the same idea. > > Jason I'll try my hand at patching this also! As for FOLL_ALLOW_BROKEN_FILE_MAPPINGS, I do really like this idea, and think it is actually probably quite important we do it, however this feels a bit out of scope for this patch series. I think perhaps the way forward is, if Jens and Pavel don't have any issue with it, we open code the check and drop FOLL_SAME_FILE for this series, then introduce it in a separate one + replace the open coding there? I am eager to try to keep this focused on the specific task of dropping the vmas parameter as I think FOLL_ALLOW_BROKEN_FILE_MAPPINGS is likely to garner some discussion which should be kept separate.